Maîtriser la réduction des coûts AWS : des erreurs qui font monter en flèche votre facture

Histoire réservée aux membres

Jan Kammerath

Suivre

La capacité d'AWS à fournir des ressources presque infinies est excellente et vous ne devez jamais tenir compte des contraintes de ressources lors de la création d'applications cloud natives. Mais il y a le facteur économique et personne ne dispose de budgets infinis. J'ai récemment réduit de 65 % la facture AWS de mon entreprise pour un ensemble de comptes, ce qui représente environ 60 000 $ d'économies par an. Vous n'avez pas besoin de logiciels ou d'outils sophistiqués pour gérer vos coûts, car AWS fournit déjà un certain nombre de services pour garder vos coûts sous contrôle. Les facteurs de coûts sont presque toujours les mêmes pour la plupart des comptes et des entreprises.

Une approche fortement recommandée consiste à examiner le coût d'AWS au moins une fois par trimestre, idéalement sur une base mensuelle. Cela n'inclut pas seulement l'examen des factures, mais également l'exploration des services avec AWS Cost Explorer. Bien que Cost Explorer vous donne un bon aperçu de ce qui détermine vos coûts, il ne fournit pas de solutions sur la manière de les réduire. Pour de nombreux facteurs de coûts, vous devrez souvent analyser l'utilisation du service à l'aide de CloudWatch. Examinons ces facteurs de coûts et comment vous pouvez les contrer. Nous examinerons également de nombreux facteurs de coûts que vous ne trouverez pas dans la documentation ou les recommandations officielles d'AWS.

Le facteur de coûts le plus courant que j’ai rencontré dans de nombreuses entreprises est le surprovisionnement. Sans surprise, le surprovisionnement est également mentionné dans les certifications AWS Solutions Architect. Il s'agit de fournir des ressources avec une capacité de mémoire et de calcul bien supérieure à la capacité requise pour votre application. Il peut s'agir d'instances EC2 avec trop de mémoire ou de fonctions Lambda allouées avec une mémoire excessive ou de longs délais d'exécution.

Cela peut paraître idiot de provisionner une fonction Lambda avec seulement 512 Mo de mémoire. Toutefois, si les statistiques d'exécution montrent qu'une fonction Lambda utilise moins de 400 Mo, vous devez envisager de réduire la mémoire allouée. Une approche courante pour de nombreux développeurs consiste à déployer Lambda avec trop de mémoire et des délais d'attente d'exécution trop longs. Si votre lambda se trouve derrière une passerelle API, vous êtes de toute façon limité à une exécution maximale de 30 secondes. La puissance de calcul ou les vCPU disponibles de votre Lambda sont directement liés à l'allocation…