Piliers d’optimisation des coûts et de durabilité

Le pilier Cost Optimisation vise à éviter les coûts inutiles et à tirer le meilleur parti de vos dépenses AWS. Il s’agit souvent du pilier ayant l’impact le plus immédiat, car il est facile de surprovisionner les ressources cloud. Principes clés de conception : Mettre en place une gestion financière du cloud — considérez le coût comme une métrique de premier ordre. Adopter un modèle fondé sur la consommation — ne payez que ce que vous utilisez. Mesurer l’efficacité globale — suivez le coût par unité de valeur métier. Réduire les dépenses liées aux tâches lourdes et indifférenciées — utilisez des services gérés plutôt que de gérer l’infrastructure vous-même.

Le dimensionnement approprié est l’action d’optimisation des coûts la plus efficace : elle consiste à identifier et à éliminer les ressources surdimensionnées. Un schéma courant consiste à lancer de grandes instances lors du provisionnement initial, puis à ne jamais les réévaluer. AWS Compute Optimizer analyse les métriques d’utilisation et recommande le type d’instance optimal. Exemple courant : une instance m5.4xlarge utilisant 5 % du CPU devrait être une t3.medium, ce qui permet d’économiser 80 % des coûts de calcul. Le dimensionnement approprié s’applique à EC2, Lambda (mémoire), RDS et aux volumes EBS.

Pour les charges de travail stables, la tarification On-Demand est l’option la plus coûteuse. Des économies importantes sont possibles grâce aux solutions suivantes : Reserved Instances (1 ou 3 ans) — jusqu’à 72 % d’économies pour les charges de travail prévisibles. Savings Plans — engagement flexible (jusqu’à 66 % d’économies) s’appliquant à différentes familles d’instances et régions. Spot Instances — jusqu’à 90 % d’économies pour les charges de travail interruptibles (traitement par lots, CI/CD, sans état). Une flotte optimisée en termes de coûts combine généralement les trois solutions : Savings Plans pour la capacité de base, Spot pour les pics et On-Demand pour les cas particuliers.

Les Spot Instances utilisent la capacité AWS disponible, avec une remise pouvant atteindre 90 %, mais peuvent être interrompues avec un préavis de 2 minutes lorsque AWS doit récupérer cette capacité. Spot convient bien au traitement par lots (avec sauvegarde de points de reprise et reprise ultérieure), aux agents de compilation CI/CD, aux serveurs web sans état (derrière ALB ; ELB redirige le trafic afin d’éviter les instances interrompues) ainsi qu’aux nœuds workers EMR et EKS. Utilisez Spot Fleet ou ASG avec plusieurs types d’instances et AZ afin de diversifier les groupes de capacité et de réduire le risque d’interruption.

Les coûts de stockage S3 peuvent être considérablement réduits en utilisant la classe de stockage appropriée et en automatisant les transitions. S3 Intelligent-Tiering déplace automatiquement les objets entre les niveaux d’accès en fonction des schémas d’accès — c’est la solution idéale lorsque ces schémas sont inconnus. Les règles de cycle de vie font passer les objets selon un calendrier : de Standard → Standard-IA après 30 jours → Glacier après 90 jours → Deep Archive après 180 jours. Envisagez également S3 Select pour récupérer uniquement le sous-ensemble nécessaire des données d’un objet, afin de réduire les coûts de transfert et de traitement des données.

Sans étiquetage approprié, il est impossible de comprendre ce que dépense chaque équipe ou projet. Les balises de répartition des coûts vous permettent de ventiler les coûts par équipe, projet, environnement ou toute autre dimension que vous définissez. Activez les balises dans la console Billing, puis utilisez AWS Cost Explorer pour filtrer et regrouper les coûts par balise. Imposez l’étiquetage au moyen des politiques de balises dans AWS Organizations et utilisez les règles AWS Config pour détecter les ressources dépourvues de balises. Cela permet la refacturation informative (visibilité) et la refacturation (attribution des coûts) aux différentes équipes.

Le pilier Sustainability (ajouté en 2021) vise à minimiser l’impact environnemental des charges de travail cloud en réduisant la consommation d’énergie et en améliorant l’efficacité. Principes de conception : Comprendre votre impact — mesurez l’empreinte carbone de vos charges de travail. Établir des objectifs de durabilité. Maximiser l’utilisation — dimensionnez correctement les ressources pour éviter les ressources inactives. Anticiper et adopter du matériel plus efficace — utilisez les dernières générations d’instances. Utiliser des services gérés — AWS exploite ses centres de données plus efficacement que la plupart des organisations.

Les processeurs AWS Graviton (basés sur ARM) offrent jusqu’à 60 % d’efficacité énergétique supplémentaire et un rapport prix/performances supérieur de 20 à 40 % par rapport aux instances x86. Les instances Graviton3/4 (familles c7g, m7g, r7g et t4g) sont disponibles pour la plupart des charges de travail EC2, Lambda et Fargate. Le passage de x86 à Graviton améliore simultanément les piliers Sustainability et Cost Optimisation : moins de watts par calcul et des prix d’instances inférieurs. La plupart des charges de travail (Linux, applications conteneurisées, JVM) peuvent être migrées avec un minimum de modifications.

Les ressources inactives constituent une source majeure de coûts et de gaspillage énergétique inutiles : instances EC2 utilisant 1 % du CPU, volumes EBS non attachés, adresses IP Elastic inutilisées et environnements de développement et de test oubliés fonctionnant 24 h/24 et 7 j/7. Mettez en place un calendrier d’arrêt et de démarrage pour les environnements hors production à l’aide des règles EventBridge et de l’automatisation Systems Manager : arrêtez les instances de développement à 18 h et démarrez-les à 8 h. Utilisez AWS Trusted Advisor et Cost Explorer pour identifier les instances inactives, les volumes EBS inutilisés et les Reserved Instances sous-utilisées.

Conserver les données indéfiniment gaspille de l’énergie. Le pilier Sustainability recommande de mettre en œuvre des politiques de cycle de vie des données afin de supprimer ou d’archiver automatiquement les données qui ne sont plus nécessaires. Utilisez les règles S3 Lifecycle avec des dates d’expiration pour supprimer les objets après une période de conservation. Utilisez DynamoDB TTL pour faire expirer automatiquement les anciens enregistrements. Utilisez les politiques de conservation CloudWatch Logs pour supprimer les groupes de journaux après une période définie. La suppression des données inutiles réduit à la fois vos coûts de stockage et l’énergie nécessaire à leur stockage et à leur refroidissement.

La Cost Optimisation entre parfois en conflit avec d’autres piliers. RDS Multi-AZ double le coût de votre base de données, mais il est requis par le pilier Reliability. La réplication interrégion améliore la fiabilité, mais augmente les coûts de stockage et de transfert. Une architecture active-active multirégion réduit la latence (Performance Efficiency), mais coûte 2 à 3 fois plus cher. Le Well-Architected Framework ne dit pas de toujours choisir l’option la moins chère : il demande de faire des compromis conscients entre les piliers et d’en documenter la justification. L’examen évalue votre capacité à sélectionner la solution la plus rentable qui respecte néanmoins les exigences énoncées.

Testez votre compréhension des concepts AWS Solutions Architect (SAA-C03) abordés dans cette leçon.

Dans cette leçon, vous avez appris que : Cost Optimisation combine le dimensionnement approprié, les modèles d’achat (Reserved/Savings Plans/Spot) et la gestion du cycle de vie S3 ; Sustainability se concentre sur la maximisation de l’utilisation, l’emploi d’instances Graviton et la mise en œuvre de politiques de cycle de vie des données ; et les compromis de coûts avec les autres piliers doivent être décidés consciemment en fonction des exigences métier. Les balises de coûts permettent la refacturation informative et la refacturation entre les équipes. Nous allons ensuite découvrir le Well-Architected Tool et le processus d’examen.