Dimensionnement adapté et Compute Optimizer

L’une des erreurs les plus courantes et les plus coûteuses en architecture cloud est le surdimensionnement — allouer davantage de ressources que nécessaire à la charge de travail. Les équipes IT pratiquent souvent le surdimensionnement en raison d’habitudes héritées des environnements sur site (acheter une capacité suffisante pour les pics de charge), par crainte d’une dégradation des performances, ou simplement parce qu’elles ne réévaluent jamais les décisions initiales de dimensionnement. Dans AWS, les instances EC2, les volumes EBS et les fonctions Lambda surdimensionnés gaspillent de l’argent à chaque minute d’exécution. Le dimensionnement adapté est le processus systématique qui consiste à identifier et éliminer ce gaspillage.

AWS Compute Optimizer analyse les métriques d’utilisation historiques de CloudWatch et utilise l’apprentissage automatique pour recommander des ressources de calcul AWS optimales. Il couvre les instances EC2, les groupes Auto Scaling EC2, les volumes EBS, les fonctions Lambda et Amazon ECS sur Fargate. Compute Optimizer nécessite au moins 30 jours d’historique des métriques pour générer des recommandations fiables. Son activation est gratuite et il fournit des recommandations accompagnées d’économies mensuelles estimées et d’un niveau de risque lié au changement.

Compute Optimizer analyse l’utilisation du CPU EC2, l’utilisation de la mémoire (via l’agent CloudWatch), le débit réseau et les IOPS EBS sur les 3, 14 ou plus de 30 derniers jours. Il recommande ensuite l’un des quatre constats suivants : Optimisé (la taille actuelle est appropriée), Surdimensionné (réduction possible), Sous-dimensionné (augmentation recommandée) ou Non optimisé (données insuffisantes). Examinez toujours le risque pour les performances : Compute Optimizer attribue à chaque recommandation un niveau de risque VeryLow, Low, Medium, High.

Les fonctions Lambda sont facturées pour chaque milliseconde d’exécution, multipliée par la mémoire allouée. Allouer davantage de mémoire que nécessaire gaspille de l’argent, mais une mémoire plus importante fournit également davantage de CPU : le bon équilibre correspond donc au paramètre de mémoire qui minimise le coût par invocation. Compute Optimizer analyse la durée des invocations Lambda, le taux d’erreur et les métriques de délai d’expiration afin de recommander le paramètre de mémoire optimal. L’outil open source Lambda Power Tuning peut également invoquer votre fonction avec différents paramètres de mémoire afin de déterminer empiriquement la configuration la plus économique.

Les volumes EBS sont souvent surdimensionnés à la fois en termes de taille (espace disque inutilisé) et d’IOPS (IOPS allouées qui ne sont jamais consommées). Compute Optimizer analyse les métriques VolumeReadOps, VolumeWriteOps, VolumeReadBytes, VolumeWriteBytes. Recommandation courante : migrer de gp2 vers gp3 (qui dissocie la taille des IOPS) — vous pouvez ajuster les IOPS indépendamment, ce qui permet souvent d’économiser 20 %. Identifiez également les volumes EBS non attachés (instances supprimées mais volumes conservés) et créez-en des instantanés ou supprimez-les.

Compute Optimizer analyse l’utilisation des ASG sur l’ensemble des instances du groupe et recommande des modifications du modèle de lancement pour le type d’instance. Si toutes les instances d’un ASG sont constamment surdimensionnées, passer à un type d’instance plus petit réduit le coût à grande échelle. Par exemple, si un ASG utilise en moyenne 10 instances m5.large, passer à m5.medium permet d’économiser 50 % par instance. Compute Optimizer recommande également des instances basées sur Graviton lorsque votre logiciel est compatible, ce qui améliore à la fois les performances et les coûts.

AWS Trusted Advisor est un autre outil qui fournit des informations sur la Cost Optimisation, ainsi que des vérifications de sécurité, de performances, de tolérance aux pannes et de limites de service. Principales vérifications liées aux coûts : instances EC2 faiblement utilisées (moins de 10 % de CPU pendant au moins 4 jours), adresses IP Elastic non associées (facturées lorsqu’elles ne sont pas attachées), volumes EBS sous-utilisés, répartiteurs de charge inactifs (aucune cible saine) et instances réservées inutilisées. Les vérifications de base de Trusted Advisor sont gratuites ; l’ensemble complet nécessite une offre AWS Support Business ou Enterprise.

AWS publie régulièrement de nouvelles générations d’instances EC2 plus efficaces, qui offrent de meilleures performances pour un coût inférieur ou équivalent. Passer de la 5e génération (m5, c5, r5) à la 7e génération (m7g, c7g, r7g) peut fournir 40 % de performances de calcul supplémentaires pour un coût similaire ou inférieur. Compute Optimizer signale précisément les possibilités de mise à niveau vers des générations plus récentes, notamment les instances basées sur Graviton. Les mises à niveau d’instances constituent souvent l’action de dimensionnement adapté la plus simple : même configuration, matériel plus récent, meilleures performances et coût réduit.

Les instances RDS sont coûteuses et souvent surdimensionnées. Utilisez les métriques CloudWatch pour évaluer l’utilisation de RDS : CPUUtilization, FreeableMemory, ReadIOPS et WriteIOPS. Si le CPU reste inférieur à 20 % et que la mémoire demeure constamment élevée, envisagez de réduire la taille. Pour les bases de données de production utilisant Multi-AZ, le dimensionnement adapté double les économies puisque l’instance principale et l’instance secondaire sont toutes deux modifiées. Envisagez également de passer de RDS MySQL/PostgreSQL à Aurora, qui offre souvent de meilleures performances pour un coût similaire et une meilleure efficacité économique à grande échelle.

Le dimensionnement adapté doit être un processus continu, et non une opération ponctuelle. Établissez une périodicité de revue mensuelle ou trimestrielle : récupérez les recommandations de Compute Optimizer, évaluez celles qui peuvent être appliquées sans risque, mettez les changements en œuvre pendant une fenêtre de maintenance et mesurez les économies. Automatisez les actions simples : le nettoyage des volumes EBS non attachés, la libération des adresses IP Elastic inutilisées et la suppression des répartiteurs de charge inactifs peuvent être réalisés au moyen de scripts. Créez un tableau de bord de Cost Optimisation dans CloudWatch, qui suit les dépenses mensuelles par service et met en évidence les augmentations inhabituelles.

Le dimensionnement adapté remédie au surdimensionnement au sein des architectures existantes, mais il arrive que l’architecture elle-même soit le problème. Une grande instance EC2 unique exécutant plusieurs applications peut nécessiter une décomposition architecturale (microservices sur Fargate), plutôt que le simple choix d’une instance plus petite. Une base de données monolithique peut nécessiter le partitionnement ou la mise en cache, plutôt qu’une simple réduction de la taille de l’instance. Le dimensionnement adapté est la première étape, et la plus rapide. L’optimisation de l’architecture (serverless, conteneurs, mise en cache) permet des économies plus importantes et plus durables, mais demande davantage d’efforts. Le pilier Cost Optimisation recommande de poursuivre ces deux approches.

Vérifiez votre compréhension des concepts AWS Solutions Architect (SAA-C03) présentés dans cette leçon.

Dans cette leçon, vous avez appris que : AWS Compute Optimizer utilise l’apprentissage automatique sur les métriques CloudWatch pour recommander des ressources de calcul correctement dimensionnées, le dimensionnement adapté s’applique à EC2, Lambda, EBS, aux ASG et à ECS sur Fargate, et la mise à niveau vers des générations d’instances plus récentes (en particulier Graviton) améliore à la fois les coûts et les performances. Faites du dimensionnement adapté une pratique récurrente, et non une opération ponctuelle. Nous allons maintenant découvrir les instances réservées, les Savings Plans et les modèles d’achat Spot.