Aller au contenu

AWS Mis à jour le 2026-07-04

Optimisation post-migration : ça fonctionne, mais c'est cher, fragile et sans surveillance

L'optimisation post-migration AWS dans l'ordre qui rapporte : redimensionnement et ménage du stockage d'abord, puis les trous de fiabilité laissés par le déménagement tel quel, puis la surveillance que personne n'a montée.

Trois mois après un déménagement tel quel, la plupart des environnements AWS partagent le même profil : tout fonctionne, la facture dépasse l’estimation de 30 à 60 %, la moitié des charges de travail sont discrètement des points de défaillance uniques, et la surveillance se résume à ce que CloudWatch collecte par défaut. L’optimisation post-migration est la passe délibérée qui règle ces trois dettes dans l’ordre — les coûts d’abord parce qu’ils financent le reste, la fiabilité ensuite, l’observabilité en troisième — en s’appuyant sur un mois de données d’utilisation réelles qui n’existaient pas le jour de la migration.

Ce qui se passe

Les migrations tel quel produisent des environnements surdimensionnés et surprovisionnés par conception. Les instances cibles ont été dimensionnées d’après les spécifications du matériel source (ou gonflées « par prudence »), les disques ont été copiés à leur taille d’origine sans égard à l’usage, et chaque serveur répliqué est devenu une instance EC2 allumée en permanence même si son ancêtre local se tournait les pouces 20 heures par jour. Rien de tout ça n’était une erreur pendant la migration — un dimensionnement prudent réduit le risque de bascule. Ça devient une erreur quand ça persiste, parce qu’AWS facture la capacité provisionnée, utilisée ou non.

La dette de fiabilité a la même origine. Un serveur migré atterrit dans une seule zone de disponibilité parce que c’est ce que la réplication produit. La base de données est un moteur autogéré sur EC2 parce que c’est ce qu’elle était sur place. Rien dans la migration n’a créé de redondance multi-AZ, de répartition de charge avec vérifications de santé, ou de sauvegardes testées — c’est du travail post-migration, et dans bien des projets, le budget s’est épuisé avant que quelqu’un le fasse. Le trou de surveillance est simplement l’état par défaut : CloudWatch collecte automatiquement les métriques de l’hyperviseur, mais la mémoire, l’espace disque, les erreurs applicatives et tout ce qui réveillerait un humain exigent une mise en place délibérée.

Quoi vérifier en premier

  • La facture, regroupée par service. Un mois dans Billing and Cost Management > Cost Explorer, regroupé par service, vous dit où va l’argent. Le calcul EC2, EBS, le traitement de données du NAT Gateway et le transfert inter-AZ sont les surprises post-migration habituelles.
  • L’utilisation CPU de la flotte. Les instances qui tournent en moyenne sous 10 % de CPU forment la liste courte du redimensionnement.
  • Les ressources orphelines. Volumes EBS détachés, Elastic IP inactives, restants de transit MGN, instantanés sans expiration — les projets de migration laissent des débris.
  • Les volumes gp2. Tout ce qui a migré il y a plus d’un an est probablement encore sur gp2; gp3 coûte moins cher par Go à performance de base égale ou meilleure.
  • Le tout-en-une-seule-AZ. Une seule passerelle NAT, du RDS mono-AZ, une couche applicative entière dans un seul sous-réseau.

Comment vérifier

# Où l'argent est allé le mois dernier, par service
aws ce get-cost-and-usage \
  --time-period Start=2026-06-01,End=2026-07-01 \
  --granularity MONTHLY --metrics UnblendedCost \
  --group-by Type=DIMENSION,Key=SERVICE

# Candidats au redimensionnement, selon l'analyse d'AWS elle-même
aws compute-optimizer get-ec2-instance-recommendations \
  --query 'instanceRecommendations[].[instanceArn,finding,recommendationOptions[0].instanceType]' \
  --output table

# Volumes détachés qui facturent encore
aws ec2 describe-volumes --filters Name=status,Values=available \
  --query 'Volumes[].[VolumeId,Size,VolumeType,CreateTime]' --output table

# Elastic IP allouées mais non associées
aws ec2 describe-addresses \
  --query 'Addresses[?AssociationId==null].[PublicIp,AllocationId]'

# Volumes encore sur gp2
aws ec2 describe-volumes --filters Name=volume-type,Values=gp2 \
  --query 'Volumes[].[VolumeId,Size]' --output table

L’utilisation par instance vit dans EC2 > Instances > Monitoring; la mémoire n’y apparaît pas sans l’agent CloudWatch, ce qui est en soi un constat. Compute Optimizer a besoin de 14 jours de données avant de se prononcer — les détails sont dans le redimensionnement avec Compute Optimizer.

La démarche

  1. Balayer les débris d’abord. Supprimez les volumes détachés (instantané d’abord en cas de doute), libérez les Elastic IP inactives, faites expirer les instantanés orphelins, finalisez les serveurs MGN restants pour libérer les ressources de transit. Zéro risque, économies le jour même.
  2. Convertir gp2 en gp3. Une opération en ligne sans arrêt pour le volume lui-même; validez les besoins en IOPS et en débit pour les rares volumes qui dépendaient du comportement de rafale proportionnel à la taille de gp2.
  3. Redimensionner avec des données, pas des opinions. Appliquez les recommandations de Compute Optimizer aux pires cas, une fenêtre de maintenance à la fois. Les familles d’instances de génération récente coûtent habituellement moins cher par unité de performance que les vieilles familles choisies par défaut par l’outil de migration.
  4. Mettre à l’horaire ce qui ne roule pas 24/7. Les instances de développement, de test et de traitement par lots reçoivent des horaires d’arrêt et de démarrage. Une instance qui roule seulement les heures ouvrables coûte environ le quart d’une instance toujours allumée — l’arithmétique est dans la tarification à l’heure d’instance sur https://calculator.aws/.
  5. S’engager seulement après le redimensionnement. Une fois la forme de la flotte stable pendant un mois, couvrez la base stable avec des Savings Plans ou de la capacité réservée — le cadre de décision est dans RI, Savings Plans ou Spot. S’engager avant le redimensionnement verrouille le surdimensionnement.
  6. Fermer les trous de fiabilité. Multi-AZ pour la couche de données, une deuxième passerelle NAT si la sortie compte, des vérifications de santé qui testent l’application plutôt que le port, des sauvegardes avec une restauration testée. Priorisez selon ce qui arrête vraiment l’entreprise, pas selon ce qui est le plus facile.
  7. Installer une vraie surveillance. L’agent CloudWatch pour la mémoire et le disque, l’expédition des journaux applicatifs, et une base d’alarmes qui réveille un humain — la base d’alarmes CloudWatch est un ensemble de départ fonctionnel.

Quand c’est la mauvaise approche

L’optimisation est le mauvais projet quand l’avenir de la charge est court — une application remplacée par du SaaS dans six mois mérite le balayage des débris et rien de plus. Elle est aussi prématurée dans les premières semaines après la bascule, quand les données d’utilisation reflètent encore le bruit de la migration plutôt que le régime stable. Et le réusinage profond — déplacer la base autogérée vers RDS, conteneuriser la couche applicative — est un projet distinct avec son propre profil de risque; ne le glissez pas dans « l’optimisation » comme s’il s’agissait d’un simple réglage.

Erreurs fréquentes

  • Acheter des Savings Plans la première semaine. Engager un à trois ans de dépenses sur un environnement qui s’apprête à rétrécir de 40 % est la façon la plus chère de se sentir proactif.
  • Redimensionner sur le CPU seulement. Les charges limitées par la mémoire ou dépendantes des rafales (crédits CPU de la famille t) vont souffrir après une réduction qui semblait sûre dans le graphique de CPU.
  • Supprimer les débris de migration sans provenance. Ce volume détaché de 500 Go est peut-être la copie pré-bascule du serveur de la comptabilité. Instantané, étiquette, un cycle d’attente, puis suppression.
  • Déclarer le travail fini après la passe de coûts. L’environnement est moins cher et toujours fragile et aveugle — les deuxième et troisième passes sont celles qui évitent l’incident de 2 h du matin.

Garder le contrôle

  • Mettez une revue mensuelle des coûts au calendrier : facture contre budget, principaux mouvements, une action.
  • Étiquetez tout avec un responsable et un environnement pendant la passe d’optimisation; la dépense sans étiquette devient inattribuable en un trimestre.
  • Configurez des alertes AWS Budgets pour que la dérive soit une notification, pas une surprise trimestrielle.
  • Relancez Compute Optimizer chaque trimestre; les charges dérivent et la bonne taille de l’an dernier est le surdimensionnement de cette année.
  • Traitez toute nouvelle demande de charge avec la discipline de dimensionnement que la migration a sautée : commencer petit, mesurer, grandir.

La migration vous a amené sur AWS; la passe d’optimisation est ce qui vous donne l’environnement que le dossier d’affaires promettait. Si personne dans votre équipe ne possède vraiment l’environnement AWS de bout en bout, c’est la racine de la plupart de ces problèmes — Stack Harbor opère des comptes AWS au quotidien sous Opérations AWS, et vous pouvez réserver une revue AWS.