Pourquoi les coûts AWS explosent après une migration
Lors d'une migration vers AWS, la facture cloud dérape rarement pendant la phase de transition elle-même, mais révèle ses vrais défis une fois que l'infrastructure est stabilisée en production. Cette explosion de coûts survient pour plusieurs raisons structurelles. D'abord, les ressources ont souvent été dimensionnées « large » pour garantir la stabilité pendant la migration : les instances EC2 surdimensionnées, les volumes EBS sur-provvisionnés, les bases de données avec des réservations généreuses restent en place longtemps après que la transition soit achevée. Ensuite, la migration crée des doublons involontaires : environnements de test jamais supprimés, snapshots ou AMI orphelines, réplications de données héritées du processus de basculement qui continuent de consommer des ressources. Enfin, les équipes internes découvrent souvent que l'infrastructure héritée contenait déjà des gaspillages cachés : des services dupliqués, des couches de cache obsolètes, des bases de données jamais interrogées. Une fois en AWS, ces inefficacités deviennent visibles et mesurables par les outils AWS natifs (CloudWatch, Cost Explorer), alors qu'elles étaient masquées par les coûts fixes d'un datacenter on-premise. Le défi n'est donc pas une mauvaise migration, mais l'ajustement progressif des ressources à la vraie charge de production une fois que celle-ci s'est stabilisée et que les équipes ont récupéré une capacité d'intervention après l'urgence du cutover.
Identifier les coûts directs à optimiser après migration
Avant de lancer une stratégie d'optimisation coûts, il faut d'abord localiser où va réellement votre argent. AWS Cost Explorer est votre premier instrument : activez la ventilation par service (EC2, RDS, S3, ElastiCache, etc.), par environnement (prod, staging, dev) et par tag de projet ou centre de coûts pour comprendre la granularité réelle de vos dépenses. Généralement, trois postes de coûts absorbent 80 % de la facture après une migration. Le premier est le calcul : les instances EC2 fonctionnent à coût horaire, et une instance mal dimensionnée coûte la même chose qu'une correctement dimensionnée. Le second est le stockage : volumes EBS, snapshots non nettoyés et données archivées dans S3 s'accumulent sans attention active. Le troisième est la base de données : les instances RDS pour les bases relationnelles, les services NoSQL ou ElastiCache pour les caches. Pour chaque poste, commencez par exporter vos dépenses des trois derniers mois (ou davantage si vous venez juste de stabiliser) dans Cost Explorer, puis comparez cette ventilation à votre allocation initiale de budget. Si vous aviez prévu 10 000 euros par mois pour EC2 mais en consommez 14 000, cette différence de 4 000 euros doit être expliquée : croissance métier normale, ressources orphelines, ou sur-dimensionnement ? AWS Compute Optimizer fournit ensuite des recommandations automatisées, mais filtrez-les avec prudence : elles se basent sur les métriques passées et peuvent oublier les pics saisonniers ou les charges de test. La vraie optimisation commence quand vous avez une image claire de qui consomme quoi et pourquoi, pas quand vous suivez aveuglément une liste de recommandations.
Ajuster le sizing des ressources en fonction de la charge réelle
Une fois identifiées, les ressources surdimensionnées deviennent vos premiers gains. Le sizing optimal signifie adapter la capacité à la charge observée, pas à la capacité maximale imaginée. Pour les instances EC2, utilisez CloudWatch pour extraire les métriques CPU, mémoire (via l'agent CloudWatch si nécessaire) et bande passante des trois derniers mois. Une instance qui fonctionne à 15 % de CPU en moyenne peut généralement passer d'un type coûteux (par exemple m5.2xlarge) à un type plus petit (m5.large ou même m5.xlarge) sans risque, à condition que les pics de CPU restent sous 70-80 %. Pour une base de données RDS, regardez les IOPS réellement consommés, la mémoire utilisée et l'espace de stockage exploité : une instance db.r5.4xlarge peut souvent être ramenée à db.r5.2xlarge ou db.r5.xlarge si les requêtes ne saturent pas les ressources. La réduction doit rester progressive : réduisez d'un cran, observez pendant une à deux semaines, puis envisagez une réduction supplémentaire si les performances restent acceptables. Pour les environnements non-production (développement, staging, recette), le sizing peut être agressif : une instance de développement qui tourne 24h/24 sans besoin réel peut être réduite au minimum viable ou même arrêtée en dehors des heures de travail via des scripts AWS Lambda ou SystemsManager. Chaque réduction de type d'instance représente typiquement 30 à 50 % d'économie sur ce poste spécifique, cumulable si plusieurs ressources sont ajustées. Attention cependant : une optimisation qui dégrade la performance utilisateur ou crée de l'instabilité annule complètement le bénéfice. Consultez vos observabilité et logs applicatifs pour valider que la réduction de ressources ne provoque pas de throttling invisible ou d'erreurs amplifiées.
Optimiser les réservations d'instances et Savings Plans
Au-delà du sizing, les réservations d'instances (RI) et AWS Savings Plans sont vos levier majeurs de réduction coûts. Une instance EC2 payée à la demande (on-demand) coûte beaucoup plus qu'une instance réservée ou couverte par un Saving Plan : compter 30 à 70 % d'économie selon l'engagement et le type. Après une migration, vous avez généralement attendu quelques semaines ou mois pour valider la stabilité avant de vous engager sur des réservations. À ce stade, vous disposez enfin de vraies métriques : vous savez quelles instances tournent 24/7, lesquelles varient, et où vous avez une charge prévisible. Un Savings Plan flexible (compute, 1 an ou 3 ans selon l'appétit de risque) couvre typiquement 50 à 60 % de votre facture EC2 et RDS sans vous enfermer dans des ressources spécifiques, ce qui est pertinent post-migration quand l'architecture peut encore évoluer. Les réservations d'instances classiques (RIs) offrent jusqu'à 72 % de réduction pour un engagement 3 ans, mais exigent que vous figiez le type d'instance, la région et la zone de disponibilité : utiles seulement si votre infrastructure est vraiment stabilisée et que vous êtes confiant dans sa permanence. Avant de vous engager, validez trois points : d'abord, que votre charge est effectivement stable (même instance, même région) sur la période d'observation ; deuxièmement, que vous ne prévoyez pas de migrations ou de réductions supplémentaires dans les 12 mois ; troisièmement, que vous avez testé les alternatives (scaling horizontal, orchestration Lambda) qui pourraient réduire le besoin en réservations. L'erreur classique post-migration est de réserver immédiatement une grosse pile d'instances uniquement parce qu'elles semblent « stables » au premier mois, puis de découvrir trois mois plus tard qu'on aurait pu les réduire de 30 %. Attendez le pic et le creux naturels de votre métier avant de vous engager : si votre charge varie de 20 % entre janvier et décembre, achetez des Savings Plans flexibles, pas des RIs fixes.
Supprimer les ressources orphelines et non utilisées
Bien souvent, l'optimisation coûts la plus rapide n'est pas un ajustement fin, mais une suppression pure et simple. Lors d'une migration, on crée des snapshots pour sauvegarder l'état avant cutover, des AMI pour les templates, des volumes EBS en backup, et une fois la transition réussie, personne n'a le temps de les nettoyer. Trois mois plus tard, une douzaine d'AMI obsolètes, des snapshots dupliqués, des volumes détachés d'instances supprimées restent en place et continuent de coûter. AWS ne les facture qu'au stockage (cent euros à mille euros par mois selon le volume), mais c'est de l'argent qui ne génère aucune valeur. Vérifiez systématiquement vos snapshots EBS (EC2 / Snapshots / Owned by me) et supprimez ceux dont vous ne connaissez plus l'utilité ou la provenance. Même chose pour les AMI : lancez un rapport des AMI créées avant la migration (filtrées par tag ou date) et confirmez qu'aucune n'est un doublon oublié. Pour les volumes EBS, un volume détaché depuis plus d'un mois est un candidat à la suppression : demandez à votre équipe avant de virer, mais si personne ne peut vous dire pourquoi c'est là, c'est une orpheline. Les adresses IP élastiques non attachées (Elastic IPs) coûtent aussi, même au repos : si vous avez 5 EIP inutilisées, libérez-les. Les interfaces réseau (ENI) non utilisées, les tables de données DynamoDB vides, les caches ElastiCache jamais requêtés : tous ces éléments sont des candidats à archivage ou suppression. Systématisez ce nettoyage toutes les six à huit semaines : activez les rapports AWS Cost Anomaly Detection pour détecter les pics inhabituels (parfois révélateurs de fuites), demandez à votre équipe infrastructure de labéliser clairement les ressources (« environnement : prod », « projet : xyz ») et supprimez tout ce qui n'a pas été taggé après un délai donné. Une journée de nettoyage peut récupérer 500 à 2 000 euros par mois de coûts évitables, ce qui mérite l'investissement.
Optimiser le stockage et la gestion des données
Le stockage est souvent le deuxième poste de coûts oublié après le calcul. Après une migration, les données héritées s'accumulent : logs d'applicatifs versés dans S3 sans politique de rétention, snapshots de backup conservés indéfiniment, bases de données avec des tables mortes jamais supprimées. S3 offre plusieurs classes de stockage dont les tarifs diffèrent radicalement : S3 Standard coûte 0.023 euros par Go/mois, S3 Standard-IA (Infrequent Access) coûte 0.0125 euros, S3 Glacier coûte 0.004 euros. Une donnée consultée quotidiennement doit rester en Standard ; une donnée archivée pour raison légale mais jamais lue peut passer en Glacier dès la troisième semaine. Configurez des S3 Lifecycle Policies pour chaque bucket : par exemple, déplacer les logs d'applicatifs en Standard-IA après 30 jours et en Glacier après 90 jours, puis supprimer après 1 an. Cela réduit typiquement 40 à 60 % du coût du stockage S3 si vos données incluent beaucoup de logs ou de backups. Pour les bases de données, regardez la rétention des backups automatiques : AWS RDS garde par défaut 7 jours de backups, mais votre métier n'en exige peut-être que 3 ou 5 si vous avez un système de récupération d'urgence en place. Réduire de 7 à 5 jours économise 30 % sur ce poste. Audit aussi les tables ou partitions jamais interrogées dans vos bases NoSQL ou data warehouses : Amazon Athena coûte par requête et par données scannées, donc si une table est lue une fois par mois, elle occupe de l'espace pour un usage minuscule. Archivez-la ou fusionnez-la. Enfin, évaluez vos stratégies de réplication et de synchronisation de données : si vous répliquez une base entière vers une région secondaire pour le DR, assurez-vous que c'est nécessaire ; replier la replication sur une sélection critique de données peut réduire les coûts de 30 %. Ces ajustements de stockage ne mobilisent pas votre équipe longtemps, mais les impacts s'ajoutent rapidement : corriger S3 Lifecycle, réduire les rétentions de backups et archiver les tables mortes peut récupérer 1 000 à 3 000 euros par mois selon votre taille.
Mettre en place un suivi continu et des bonnes pratiques
L'optimisation coûts n'est jamais terminée après une migration. Elle demande un suivi régulier pour rester efficace sur le long terme. Créez un tableau de bord Cost Management : exportez vos dépenses mensuelles depuis Cost Explorer, comparez-les au budget alloué, et identifiez les dérives mois sur mois. Si votre facture saute de 10 000 à 12 000 euros sans nouvelle charge métier majeure, quelque chose a changé : nouvelles réservations oubliées, ressources orphelines en accumulation, ou déploiement accidentel en production d'environnement de test. Un simple Google Sheet avec les dépenses totales, par service, par environnement, relooké chaque mois, suffit à détecter les anomalies. Automatisez ensuite vos bonnes pratiques : configurez des budgets AWS (Billing / Budgets) qui envoient des alertes si vous dépassez un seuil donné, activez AWS Cost Anomaly Detection pour une détection d'anomalies alimentée par machine learning, et demandez à votre équipe infrastructure de tagger systématiquement toutes les ressources au moment du déploiement (projet, environnement, propriétaire) plutôt que rétrospectivement. Enfin, intégrez l'optimisation coûts dans votre cycle de reviews infrastructure : chaque trimestre, consultez Cost Explorer, identifiez les trois principaux leviers d'économie, implémentez-les, mesurez l'impact, et réitérez. Une entreprise qui vient de stabiliser une migration peut typiquement récupérer 20 à 30 % de coûts en trois à quatre mois d'optimisation progressive, juste en ajustant le sizing, activant des Savings Plans et supprimant les orphelines. Ce n'est pas magique, c'est du travail régulier et méthodique.