Tirer parti d'AWS Compute Optimizer pour un redimensionnement continu et une réduction des coûts

Le redimensionnement AWS ressemble à un exercice financier jusqu'à ce que la première mauvaise modification fasse tomber une charge de travail de production. La version utile est plus prudente : trouver des ressources clairement trop grandes, clairement trop petites, ou fonctionnant sur une génération d'infrastructure inadaptée, puis apporter des modifications qui respectent les schémas de trafic, l'état, le rollback et le comportement de l'application.

AWS Compute Optimizer aide à ce travail en analysant la configuration des ressources et les métriques d'utilisation, puis en produisant des recommandations pour des services tels que les instances EC2, les groupes Auto Scaling, les volumes EBS, les services ECS sur Fargate et les fonctions Lambda. Les recommandations sont utiles, mais elles doivent être traitées comme une aide à la décision, pas comme une vérité automatique. Compute Optimizer peut voir les métriques. Il ne peut pas toujours voir les calendriers de publication, les engagements clients, les particularités de licence ou le traitement par lots étrange qui ne s'exécute qu'à la fin du mois.

---

Comprendre AWS Compute Optimizer

AWS Compute Optimizer fournit des recommandations en analysant les métriques d'utilisation historiques pour les ressources prises en charge. La période de référence par défaut est généralement basée sur l'historique récent, et les métriques d'infrastructure améliorées peuvent étendre la fenêtre d'analyse pour certains types de ressources. La disponibilité et la rétention exactes peuvent varier selon le type de ressource, la région, les paramètres du compte et les modifications des fonctionnalités AWS. Vérifiez donc la page de service actuelle avant de construire un processus rigide autour d'un seul nombre.

ACO évalue plusieurs facteurs, notamment l'utilisation du processeur, l'utilisation de la mémoire (si l'agent CloudWatch approprié est installé), le débit réseau et les E/S disque, générant des recommandations qui privilégient à la fois l'efficacité des coûts et les performances.

Métriques clés fournies par ACO

1. Résultats d'optimisation : Catégorisation de la ressource (par exemple, Sur-provisionnée, Sous-provisionnée, Optimisée).
2. Économies mensuelles estimées : Réduction de coût projetée si la recommandation est mise en œuvre.
3. Risque de performance : Une évaluation faible, moyenne ou élevée indiquant la probabilité que la mise en œuvre de la recommandation ait un impact négatif sur les performances de la charge de travail.
4. Options recommandées : Configurations de ressources alternatives spécifiques (par exemple, types d'instances, paramètres de mémoire, spécifications de volume EBS).

Remarque : Les recommandations de Compute Optimizer elles-mêmes sont disponibles sans frais de service séparés dans de nombreuses utilisations courantes, mais les métriques améliorées optionnelles et les ressources analysées peuvent toujours affecter votre facture. Vérifiez la tarification dans votre compte avant d'activer largement les fonctionnalités optionnelles.

Redimensionnement des instances Amazon EC2

Les instances EC2 sont souvent le principal moteur des coûts de calcul cloud. ACO fournit des recommandations adaptées pour les instances autonomes et les instances au sein des groupes Auto Scaling (ASG).

Identification des instances sur-provisionnées et sous-provisionnées

ACO catégorise les instances EC2 en fonction de son analyse :

• Sur-provisionnée : Instances présentant une utilisation constamment faible pour les métriques que Compute Optimizer peut voir. Il peut suggérer de passer à un type d'instance plus petit ou différent.
• Sous-provisionnée : Instances présentant une utilisation élevée ou une pression sur les ressources. Il peut suggérer une instance plus grande, une famille différente ou une configuration avec de meilleures caractéristiques de processeur, mémoire, réseau ou stockage.

Mise en œuvre des recommandations de redimensionnement EC2

La mise en œuvre d'un changement nécessite une planification minutieuse, en particulier pour les charges de travail de production. Le processus de modification d'un type d'instance implique généralement l'arrêt, la modification et le redémarrage de l'instance.

Exemple : Modification d'une instance sur-provisionnée via CLI

Si Compute Optimizer recommande de passer d'une instance m5.large à t3.large, les étapes mécaniques pour une instance soutenue par EBS sont :

1. Arrêter l'instance :

   aws ec2 stop-instances --instance-ids i-1234567890abcdef0
   

2. Modifier le type d'instance :

   aws ec2 modify-instance-attribute --instance-id i-1234567890abcdef0 --instance-type "{'Value': 't3.large'}"
   

3. Démarrer l'instance :

   aws ec2 start-instances --instance-ids i-1234567890abcdef0
   

Meilleure pratique : Effectuez toujours ces modifications pendant les périodes de faible trafic et surveillez attentivement les métriques de l'instance (CPU, latence, journaux d'application) pendant 24 à 48 heures après la mise en œuvre pour vous assurer que la nouvelle taille peut gérer la charge de pointe sans dégradation des performances.

Avant de changer le type, vérifiez si l'instance fait partie d'un groupe Auto Scaling, utilise des volumes de stockage d'instance, a des exigences de groupe de placement, utilise des hypothèses de dénomination ENA ou NVMe, ou est liée à un modèle de licence. Pour les services de production, il est souvent plus sûr d'intégrer la nouvelle taille dans un modèle de lancement, de remplacer les instances progressivement et de laisser les équilibreurs de charge drainer les connexions.

Optimisation des volumes Amazon EBS

Compute Optimizer étend ses recommandations aux volumes Elastic Block Store (EBS) attachés aux instances EC2. L'optimisation ici se concentre sur la maximisation des performances par dollar en suggérant des types de volumes modernes et en ajustant les paramètres IOPS/débit.

Recommandations de migration

Une optimisation courante consiste à migrer les volumes à usage général plus anciens, en particulier gp2, vers gp3 là où cela correspond à la charge de travail.

Type de volume	Avantage
gp2	Les performances évoluent avec la taille du volume et les crédits de burst.
gp3	Les performances peuvent être configurées séparément de la taille dans les limites du service.

Compute Optimizer peut recommander des valeurs IOPS et de débit spécifiques en fonction des modèles d'utilisation observés. Traitez ces recommandations comme un point de départ. Un volume de base de données avec un faible volume d'écriture récent peut encore avoir besoin de marge pour les fenêtres de maintenance, la compaction, les reconstructions d'index, les sauvegardes ou le rattrapage après basculement.

Étape concrète : Modification d'un volume

Les modifications de volume EBS peuvent généralement être effectuées pendant que le volume est en cours d'utilisation (contrairement à la modification d'un type d'instance EC2), bien que l'impact sur les performances doive être pris en compte.

# Exemple : Migration d'un volume vers gp3 et définition d'IOPS/débit spécifiques
aws ec2 modify-volume \
    --volume-id vol-fedcba9876543210 \
    --volume-type gp3 \
    --iops 3000 \
    --throughput 125

Surveillez l'état de la modification après la commande :

aws ec2 describe-volumes-modifications \
  --volume-ids vol-fedcba9876543210

Pour les bases de données critiques, testez d'abord la modification sur une réplique ou une copie de staging. Un changement de type de volume peut être en ligne, mais la charge de travail peut toujours ressentir des changements de comportement d'E/S si le nouveau paramètre IOPS ou débit est trop faible.

Redimensionnement des fonctions AWS Lambda

Pour les charges de travail serverless, Compute Optimizer fournit des informations critiques sur les fonctions AWS Lambda. Dans Lambda, le paramètre mémoire dicte la quantité de vCPU allouée à la fonction. Le redimensionnement de Lambda consiste principalement à trouver la configuration mémoire la plus faible qui répond toujours aux objectifs de performance.

Le compromis Mémoire/CPU

Compute Optimizer analyse les modèles d'utilisation et de durée de Lambda pour recommander des paramètres de mémoire. Une fonction peut être allouée à 1024 Mo mais fonctionner de manière acceptable à 512 Mo. Une autre fonction peut devenir moins chère lorsque la mémoire est augmentée car le CPU ajouté réduit suffisamment la durée pour compenser l'allocation mémoire plus importante.

Ce deuxième cas surprend les gens. Le coût Lambda est lié à la mémoire allouée et à la durée, donc le paramètre le moins cher n'est pas toujours la valeur mémoire la plus petite. Testez des événements représentatifs avant d'appliquer largement les recommandations.

Mise en œuvre de l'optimisation des fonctions Lambda

L'optimisation Lambda est simple, nécessitant généralement une simple mise à jour de la configuration de la fonction.

Exemple : Mise à jour de la configuration mémoire Lambda

Si ACO recommande de passer une fonction de 2048 Mo à 1024 Mo :

aws lambda update-function-configuration \
    --function-name MyOptimizedFunction \
    --memory-size 1024

Intégration de l'optimisation continue dans votre flux de travail

Le redimensionnement ne doit pas être un audit ponctuel mais une discipline continue. Compute Optimizer facilite cela grâce à son API et son intégration avec AWS Organizations.

1. Gestion centralisée

Si vous utilisez AWS Organizations, désignez un compte administrateur délégué pour Compute Optimizer. Cela permet à ACO de fournir des recommandations consolidées sur tous les comptes, offrant une vue holistique des économies potentielles à l'échelle de l'entreprise.

2. Automatisation et notification

Utilisez l'API Compute Optimizer et intégrez-la avec AWS CloudWatch Events ou Lambda pour créer des flux de travail automatisés :

• Rapports planifiés : Configurez un déclencheur quotidien ou hebdomadaire qui extrait les dernières recommandations hautement prioritaires (par exemple, celles avec les économies estimées les plus élevées).
• Alertes : Déclenchez des alertes via SNS lorsque ACO identifie des ressources avec des résultats spécifiques (par exemple, des instances sous-provisionnées avec un risque de performance élevé).
• Mise en œuvre semi-automatisée : Pour les recommandations à faible risque et à économies élevées (comme la migration EBS gp3), utilisez des fonctions Lambda pour générer automatiquement des demandes de modification ou même appliquer la modification directement après avoir passé un seuil de gouvernance nécessaire.

# Extrait de code Python conceptuel utilisant boto3 pour récupérer les recommandations
import boto3

aco_client = boto3.client('compute-optimizer')

response = aco_client.get_ec2_instance_recommendations(
    filters=[
        {'name': 'finding', 'values': ['Overprovisioned']}
    ]
)
# Traiter et agir sur les options recommandées...

Gardez la mise en œuvre séparée de la collecte des recommandations. Un rapport hebdomadaire peut lister en toute sécurité les candidats. Un bot qui arrête des instances ou modifie la mémoire Lambda sans contexte de charge de travail peut créer des incidents. Un bon compromis est d'ouvrir des tickets ou des pull requests avec la recommandation, les métriques actuelles, le changement proposé, les économies estimées et le plan de rollback.

Comment examiner une recommandation avant d'agir

Pour chaque recommandation, posez quelques questions pratiques :

1. La ressource est-elle encore utilisée, ou la suppression est-elle une meilleure réponse que le redimensionnement ?
2. La période de référence inclut-elle le trafic de pointe normal, les fenêtres de traitement par lots et les versions récentes ?
3. Les données mémoire sont-elles disponibles pour EC2, ou la recommandation est-elle principalement basée sur le CPU et le réseau ?
4. L'instance est-elle avec état, sous licence, épinglée au matériel ou configurée manuellement ?
5. Le changement peut-il être déployé derrière un groupe Auto Scaling, un déploiement bleu/vert ou une réplique ?
6. Quelle métrique prouverait que le changement a fonctionné ou échoué ?

Par exemple, une instance EC2 exécutant un rapport nocturne peut sembler inactive pendant les heures de bureau et extrêmement occupée pendant 40 minutes après minuit. Une recommandation basée sur des moyennes larges pourrait suggérer de réduire la taille, mais la vraie question est de savoir si le rapport se termine toujours avant la date limite de l'entreprise. Les économies de coûts qui cassent la fenêtre de traitement par lots ne sont pas des économies.

Modèles de déploiement qui réduisent les risques

Le chemin de mise en œuvre le plus sûr dépend de la ressource.

Pour les services EC2 sans état derrière un équilibreur de charge, préférez remplacer les instances via un groupe Auto Scaling ou un pipeline de déploiement plutôt que d'arrêter une instance en direct manuellement. Mettez à jour le modèle de lancement, ajoutez une instance avec le nouveau type, surveillez les vérifications de santé et les métriques de l'application, puis déployez le reste progressivement. Cela vous donne un rollback naturel : remettez l'ancienne version du modèle de lancement et remplacez les nouvelles instances.

Pour les hôtes EC2 avec état, suivez un chemin plus lent. Confirmez les sauvegardes, comprenez les volumes attachés, vérifiez les fenêtres de maintenance et assurez-vous que l'application peut tolérer un cycle d'arrêt/démarrage. Certaines anciennes familles d'instances et les nouvelles familles exposent les disques ou les périphériques réseau différemment, donc les scripts de démarrage qui supposent un nom de périphérique peuvent se casser après un changement de type.

Pour EBS, surveillez à la fois les métriques de coût et de performance après avoir changé le type de volume ou les performances provisionnées. Une estimation mensuelle plus basse ne suffit pas. Vérifiez la longueur de la file d'attente, la latence, le débit et les symptômes au niveau de l'application. Si le volume soutient une base de données, la latence de l'application peut vous en dire plus que le seul graphique du volume.

Pour Lambda, publiez une nouvelle version ou un déploiement basé sur un alias lorsque la fonction est importante. Envoyez une petite part du trafic vers le nouveau paramètre mémoire, comparez la durée, les erreurs, les démarrages à froid et la pression en aval, puis déplacez plus de trafic. Une fonction qui devient plus rapide avec plus de mémoire peut mettre plus de pression sur une base de données ou une API qu'elle appelle, alors surveillez l'ensemble du chemin.

Rapporter clairement les recommandations

Un rapport de redimensionnement utile ne doit pas être une feuille de calcul remplie d'ID d'instance sans contexte. Incluez la configuration actuelle, la configuration recommandée, la fenêtre d'utilisation observée, les économies mensuelles estimées, le risque de performance, le propriétaire, la méthode de déploiement proposée et le plan de rollback. Ajoutez une courte note expliquant pourquoi la recommandation est acceptée, différée ou rejetée.

Les recommandations rejetées sont toujours utiles. Un serveur de base de données peut sembler sur-provisionné parce qu'il est dimensionné pour le basculement, pas pour le trafic moyen. Un serveur de licence peut avoir besoin d'une famille d'instances fixe. Un hôte à faible utilisation peut attendre une migration planifiée. Capturer ces raisons empêche la même recommandation d'être débattue à nouveau chaque mois.

Meilleures pratiques pour l'utilisation de Compute Optimizer

Domaine	Meilleure pratique
Période de surveillance	Assurez-vous que les ressources fonctionnent sous charge typique pendant au moins 14 jours avant de faire confiance aux recommandations.
Tests de performance	Après avoir mis en œuvre une recommandation de réduction, effectuez toujours des tests de charge pour vous assurer que l'application maintient les SLO (Objectifs de niveau de service) requis.
Charges de travail spécialisées	Soyez prudent avec les applications avec état, les bases de données ou les serveurs de licence tiers qui peuvent nécessiter des types d'instances spécifiques ou des ressources minimales, même si ACO recommande une taille plus petite.
Métrique mémoire	Pour EC2, installez l'agent CloudWatch pour collecter des données d'utilisation mémoire détaillées. Sans cela, les recommandations de redimensionnement d'ACO reposent principalement sur le CPU et le réseau, ce qui peut être incomplet.
Examen continu	Traitez le tableau de bord ACO comme un document vivant. Les charges de travail changent constamment, nécessitant une réévaluation régulière du dimensionnement des ressources.

---

Vérification finale

AWS Compute Optimizer est le plus précieux lorsqu'il fait partie d'une habitude de révision. Utilisez-le pour trouver le gaspillage, repérer les ressources sous-provisionnées et remettre en question les anciennes hypothèses. Ensuite, apportez le contexte qu'AWS ne peut pas déduire : le calendrier des versions, les événements de pointe, les promesses clients, les domaines de défaillance et les chemins de rollback. Le meilleur programme de redimensionnement n'est pas celui qui accepte le plus de recommandations. C'est celui qui économise de l'argent sans rendre la production plus fragile.