Pourquoi nettoyer l'infrastructure immédiatement après la migration
La plupart des équipes qui terminent une migration AWS se concentrent sur la validation fonctionnelle du cutover et l'appaisement des utilisateurs. Cependant, les premiers jours et semaines post-migration sont critiques pour nettoyer l'infrastructure, car c'est à ce moment que les ressources orphelines, les configurations de secours devenues inutiles et les doublons sont les plus faciles à identifier et à supprimer en toute confiance.
Sans nettoyage rapide, trois problèmes s'accumulent. D'abord, la facture AWS continue à accumuler les coûts de ressources qui n'ont plus de justification métier, multipliant le TCO de la migration par un facteur qu'on aurait pu éviter. Ensuite, l'infrastructure devient de plus en plus opaque : dans trois mois, personne ne saura dire avec certitude à quoi servait ce load balancer classique ou cette base de données RDS « de secours » restée en place. Enfin, l'accumulation de ressources zombies crée une dette technique qui ralentit les opérations futures, les diagnostics de performance et les décisions de scaling.
Le nettoyage immédiat post-migration transforme une situation confuse en une infrastructure claire, rationalisée et documentée. C'est aussi le meilleur moment pour aligner les coûts cloud avec les budgets annoncés et retrouver la confiance vis-à-vis de la direction sur le retour sur investissement de la migration.
Inventaire complet des ressources et identification des orphelines
Le point de départ du nettoyage est un inventaire exhaustif de ce qui tourne réellement sur AWS après le cutover. Contrairement au plan de migration qui listait tout ce qui devait être migré, vous devez ici scanner l'infrastructure réelle pour découvrir ce qui existe, en particulier les écarts, les oublis et les ressources créées en urgence pendant le cutover mais jamais supprimées après.
AWS Cost Explorer et AWS Compute Optimizer sont vos premiers outils. Cost Explorer vous montre la ventilation des coûts par service et région, identifiant rapidement les postes budgétaires inattendus. Compute Optimizer analyse les instances EC2, EBS, RDS et Lambda pour détecter le sous-utilisé (une instance de 8 vCPU fonctionnant à 2% d'utilisation CPU depuis des semaines) et le surapprovisionné. Lancez un scan complet via la console AWS : les résultats listent les instances et volumes candidats à suppression ou redimensionnement.
Pour un inventaire plus fin, utilisez AWS Systems Manager Fleet Manager ou des outils open source comme CloudMapper ou Botocross. CloudMapper génère une représentation visuelle de votre infrastructure AWS, region par region, avec les liens de dépendance entre ressources (quelles instances utilisent quels security groups, quels volumes, quels snapshots). Botocross scrape votre compte AWS entier et exporte un inventaire en CSV exportable vers Excel pour tri et analyse.
Pendant ce scan, identifiez les catégories de ressources candidates à suppression : les instances EC2 avec zéro traffic entrant depuis le cutover, les adresses IP élastiques (EIP) flottantes non attachées (coûteuses et inutiles), les volumes EBS détachés depuis des semaines, les snapshots de volumes anciens dont vous n'avez plus besoin, les bases de données RDS multi-AZ migrées mais restées en secours, les load balancers créés à titre de test, les VPN ou Direct Connect provisionnés pour le tunnel de migration mais devenue redondant.
Documentez chaque ressource identifiée dans un tableur avec trois colonnes : identifiant AWS (ID d'instance, nom du volume, ARN), raison supposée de sa présence (sauvegarade, test, secours, oubli), et statut proposé (supprimer, réduire, laisser). Cette traçabilité est cruciale pour justifier les décisions et faciliter l'approbation par les responsables métier.
Suppression des ressources résiduelles et configurations de migration
Après validation métier de votre inventaire, passez à la suppression elle-même. Commencez par les ressources les plus sûres, c'est-à-dire celles sans dépendance évidente et sans risque opérationnel. Les adresses EIP non attachées, les snapshots de migration datant d'avant le cutover, les volumes EBS détachés sans lien vers une instance active, les security groups vides et les VPC de test sont des candidats idéaux pour un premier lot de suppressions.
Avant de supprimer une ressource, vérifiez ses dépendances dans le compte AWS. Une instance EC2 peut être attachée à un load balancer, des volumes, des network interfaces, des security groups multiples. Supprimer l'instance sans d'abord détacher ou reconfigurer le load balancer provoquera une coupure de service. Utilisez AWS CloudFormation ou l'onglet « Dependencies » dans la console pour tracer les relations de dépendance. AWS Systems Manager Dependency Mapper peut vous aider pour les dépendances complexes.
Un pattern courant post-migration : l'infrastructure d'on-premises reste partiellement en place, soit pour assurer une période de coexistence au cas où une rollback serait nécessaire, soit parce que certains systèmes non migrés restent connectés. Après validation que tous les cutover métiers sont complets et stables (généralement 1 à 2 semaines), supprimez les tunnels de migration (VPN IPSec, Direct Connect virtuel), les instances de passerelle (passerelles de replication AWS DataSync ou AWS DMS), les buckets S3 temporaires de staging créés pour le transfert de données, et les règles de routing entre on-premises et AWS devenues inutiles.
Pour les suppressions critiques ou volumineuses (supprimer 50 instances EC2 d'un coup, par exemple), utilisez AWS CloudFormation stacks ou Terraform pour exécuter les suppressions dans l'ordre correct, plutôt que manuellement via la console. Cela garantit que les dépendances sont gérées automatiquement et que chaque suppression est tracée dans les événements AWS CloudTrail.
Pendant la suppression, activez MFA (Multi-Factor Authentication) sur le compte root ou sur les utilisateurs IAM qui déclenchent ces opérations. Créez des snapshots finaux des volumes EBS importants avant suppression, au cas où une restauration d'urgence serait requise dans les 30 jours suivant le cutover. Cette « rassurance » est bon marché comparée au coût émotionnel et opérationnel d'une suppression regrettée.
Consolidation des ressources dupliquées et harmonisation
Lors d'une migration par étapes ou par cohort, il est courant de créer temporairement des ressources en double : deux clusters Kubernetes (ancien et nouveau), deux bases de données relationnelles (ancien et nouvelle instance RDS), deux load balancers (un qui testait le nouveau routing, un qui restait sur l'ancien).
Après validation que le nouveau cluster/base/load balancer fonctionne en production stable, vous devez supprimer les anciens. Contrairement à la suppression simple d'orphelines, la consolidation exige de vérifier que tout le traffic est bien basculé vers la nouvelle ressource et que personne ne la contourne accidentellement via l'ancienne.
Pour les bases de données : si vous aviez une instance RDS MySQL on-premises et que vous l'avez migrée en RDS sur AWS, supprimez l'ancienne après une semaine de validation que l'application utilise exclusivement la nouvelle. Vérifiez au préalable les connection strings dans l'application, les scripts de backup, les outils de reporting, les crons de sauvegarde. Un application qui se connecte encore à la vieille base pour des lectures non-critiques compliquera votre consolidation. Harmonisez toutes les references à la nouvelle base, puis seulement après supprimez l'ancienne.
Pour les load balancers ou API Gateways : le cutover a probablement crée une période où les deux acceptaient du traffic (pour tester le nouveau). Après stabilisation, basculez 100% du traffic vers le nouveau et surveillez les logs d'erreur du load balancer ancien. Une fois que plus aucune requête n'y arrive depuis 24 heures, vous pouvez le supprimer sans risque.
Pour les stockages (buckets S3, EFS) : certaines données peuvent avoir été copiées en plusieurs exemplaires durant la migration (snapshot source, bucket de staging, replica pour test). Après cutover validé, consolidez vers une unique source de vérité et supprimez les replicas de test. Mais conservez au moins une sauvegarde (snapshot ou backup) en cas de rollback rapide requis.
La consolidation réduit aussi la complexité opérationnelle : une équipe opérationnelle avec deux bases de données similaires à surveiller, deux configs à maintenir à jour, commettrait deux fois plus d'erreurs qu'avec une seule ressource optimisée. La consolidation crée une infrastructure plus claire et plus maintenable.
Documentation post-nettoyage et validation de coûts
Une fois le nettoyage physique terminé, documentez ce qui a été supprimé, quand et pourquoi. Cette trace est votre assurance que les décisions ont été prises rationnellement. Créez un registre d'archivage indiquant : nom de la ressource, ID AWS, date de suppression, justification, approbation, et snapshot final créé si pertinent.
Cette documentation servira trois buts. D'abord, elle exonère les responsables en cas de question ultérieure (par exemple, si un responsable métier demande pourquoi une ressource a disparu). Ensuite, elle crée une baseline post-nettoyage que vous comparerez avec les relevés de coûts mensuels suivants. Enfin, elle documente l'état réel de l'infrastructure pour les audits de conformité et les rapports de gouvernance IT.
Comparez les coûts AWS jour par jour avant et après le nettoyage. Si vous aviez une facture mensuelle de 150 000 euros avant nettoyage et 120 000 euros après, c'est un saving immédiat de 30% (360 000 euros annualisés) sans aucun changement fonctionnel, juste en supprimant du waste. Documenter ce gain auprès de la direction renforce la légitimité de l'investissement en migration et aide à justifier les budgets futurs.
La dernière étape est la création d'une Policy ou d'une procédure pour empêcher l'accumulation future de ressources orphelines. Par exemple : chaque ressource créée doit avoir un tag "Owner" et "Business Unit", chaque mois un inventaire des ressources sans owner est généré automatiquement, et les propriétaires ont 15 jours pour justifier leur présence ou elles sont supprimées. AWS Config et AWS CloudTrail permettent d'automatiser cette surveillance.
Un audit léger tous les trimestres (30 minutes pour scanner les ressources sans utilisation, les instances arrêtées depuis longtemps, les snapshots anciens) prévient l'accumulation de dette et maintient une infrastructure claire et coûteuse juste.
Risques courants et bonnes pratiques de sécurité pendant le nettoyage
Le nettoyage post-migration comporte des risques qui ne sont jamais documentés ouvertement mais qui peuvent coûter cher s'ils se matérialisent. Le premier est le risque de suppression accidentelle. Une instance qui a l'air orpheline peut être utilisée par un processus batch nocturne ou par une équipe satellite qui ne vous l'a jamais signalée. Avant de supprimer, envoyez une notification à la listserv concernée (par exemple, aux Data Scientists, à l'équipe BI, aux équipes métier) : « Nous prévoyons de supprimer l'instance prod-analytics-old-box le 2024-12-20. Si elle est critique pour vous, signalez-le avant cette date ».
Le deuxième risque est la suppression d'une ressource partagée. Par exemple, un security group utilisé par dix instances, ou un KMS key qui chiffre des centaines de snapshots. Supprimez le security group, et dix instances arrêtent de communiquer. Supprimez la KMS key, et vous ne pouvez plus restaurer les snapshots. Avant suppression, listez les ressources qui dépendent de celle-ci. Une KMS key a un onglet « Key Policy » et « Dependents » ; un security group montre les instances rattachées.
Le troisième risque concerne les données. Un volume EBS qui semble inutile peut contenir une sauvegarde informelle ou un fichier que quelqu'un avait copié « à titre de précaution ». Avant suppression d'un volume de plus de 10 GB contenant des données, créez un snapshot final et conservez-le pendant 30 jours. C'est une assurance bon marché (coûte moins d'1 euro par snapshot chez AWS) contre une réclamation ultérieure.
Le quatrième est la conformité réglementaire. Certains systèmes produisent des logs ou des données qui doivent être conservés pour raison légale (RGPD, logs d'audit, traçabilité financière). Avant de supprimer une base de données ou un bucket S3 contenant des logs, vérifiez les règles de conservation imposées. CloudTrail logs, par exemple, doivent souvent être archivés 7 ans.
Bonnes pratiques : utilisez les IAM policies pour restreindre les permissions de suppression (seuls les administrateurs AWS autorisés peuvent supprimer EC2 ou RDS), tracez chaque suppression via CloudTrail (activez le logging s'il ne l'est pas), utilisez les AWS resource tags pour catégoriser (Production, Test, Temporary) et appliquez des lifecycle policies (ex : les instances avec le tag Temporary=true sont supprimées automatiquement après 7 jours), et enfin conduisez le nettoyage en équipe avec au moins deux paires d'yeux sur chaque suppression critique.
Un pattern de confiance progressive : testez d'abord les suppressions sur un compte AWS de test, puis sur une infrastructure non-critique, puis finalement sur production. Cela crée de l'expérience et réduit les surprises.
Intégration avec la consolidation et l'optimisation des coûts
Le nettoyage post-migration est le premier chapitre d'une histoire plus longue de consolidation et d'optimisation. Une fois que vous avez éliminé les ressources orphelines et les doublons, vous passez à la consolidation active : fusionner les comptes AWS fragmentés en une structure plus centralisée, harmoniser les configurations de sécurité et de tagging, et dimensionner correctement les ressources restantes.
C'est à ce stade que vous explorez aussi des modèles de tarification plus efficaces : acheter des Reserved Instances (RI) ou Savings Plans pour les workloads stables identifiés lors du nettoyage, utiliser des instances Spot pour les charges batch et les test, rightsizing des instances surdimensionnées qui deviennent soudain visibles après suppression des doublons.
Le nettoyage crée aussi l'opportunité de revoir l'architecture même. Par exemple, un nettoyage peut révéler que vous aviez quatre petites bases RDS au lieu d'une seule bien partitionnée, créant une occasion d'une consolidation architecturale plus ambitieuse.
Dans ce contexte, le nettoyage n'est pas une activité isolée mais une phase critique d'un programme de consolidation plus large qui s'étend sur 2 à 3 mois post-migration et qui finalise la transition vers une infrastructure cloud stable et optimisée.