Migrer vers AWS : les étapes, les stratégies et les pièges à éviter

Les motivations habituelles sont la fin de vie d'un hébergeur ou d'un matériel, le besoin d'élasticité face à des pics de charge, l'accès à des services managés (bases de données, files d'attente, stockage objet) et la volonté de réduire l'exploitation manuelle. Ce sont de bonnes raisons, à condition de les formaliser.

Une migration n'est pas une fin en soi. Un serveur déplacé tel quel vers le cloud coûte souvent plus cher qu'avant s'il n'est ni redimensionné ni automatisé. Le gain vient de l'usage des services managés, de l'automatisation et de l'arrêt des ressources inutiles, pas du simple changement d'adresse.

Posez dès le départ les objectifs mesurables : disponibilité attendue, budget mensuel cible, délai de reprise en cas d'incident, exigences réglementaires sur la localisation des données. Ils guideront toutes les décisions techniques qui suivent et permettront de juger le résultat.

Un inventaire exhaustif est indispensable : serveurs, applications, bases de données, tâches planifiées, dépendances réseau, certificats, DNS, intégrations avec des tiers. Les migrations qui échouent oublient presque toujours un composant que personne n'avait documenté, comme un script sur un serveur de sauvegarde ou une adresse IP autorisée chez un partenaire.

Pour chaque application, notez la criticité, les fenêtres de maintenance acceptables, le volume de données, la fréquence de changement et l'état du code. Ces informations déterminent la stratégie de migration et l'ordre de passage, et elles évitent de traiter tous les systèmes de la même manière.

Ce travail débouche sur une estimation des coûts cibles, avec le calculateur de tarifs AWS, et sur une décision documentée par composant. AWS propose des outils d'évaluation et de suivi comme Migration Hub, mais la qualité de l'inventaire dépend surtout de l'implication des équipes qui exploitent les systèmes.

AWS a popularisé la grille des « 6 R » pour classer les stratégies de migration, aujourd'hui étendue à sept avec la relocalisation, qui déplace une plateforme de virtualisation sans la modifier. Chaque application peut relever d'une stratégie différente ; c'est normal et même souhaitable.

Le tableau suivant résume ces stratégies. En pratique, un premier passage en rehost ou replatform, suivi d'une modernisation progressive une fois l'infrastructure stabilisée, est le chemin le plus fréquent pour les entreprises qui ne peuvent pas geler leur activité pendant le projet.

Avant de migrer quoi que ce soit, mettez en place une fondation propre : organisation multi-comptes, avec au minimum la production et le hors production séparés, gestion des identités avec IAM Identity Center, réseau VPC avec sous-réseaux publics et privés, journalisation centralisée avec CloudTrail et politiques de nommage et d'étiquetage des ressources.

Cette fondation doit être décrite en infrastructure as code (Terraform, OpenTofu ou CloudFormation). C'est ce qui rend l'environnement reproductible, auditable et évolutif. Une fondation créée à la main dans la console devient rapidement impossible à comprendre et à faire évoluer sans risque.

Définissez également la stratégie de sauvegarde, de chiffrement (KMS) et les alertes budgétaires dès ce stade. Il est beaucoup plus difficile de les ajouter après coup sur des dizaines de ressources déjà en production, et c'est souvent là que naissent les mauvaises surprises.

Commencez par une application pilote, peu critique mais représentative, pour valider les outils et la procédure. Puis organisez les migrations par vagues cohérentes, en regroupant les applications qui partagent des dépendances, afin de ne jamais couper un lien entre deux systèmes qui se parlent.

Pour les serveurs, AWS Application Migration Service réplique les disques en continu et permet une bascule avec une interruption minimale. Pour les bases de données, AWS Database Migration Service assure une réplication continue pendant que l'ancienne base reste active, ce qui permet de basculer quand tout est vérifié.

Chaque vague doit inclure des tests fonctionnels, des tests de charge, une répétition de la bascule et un plan de retour arrière écrit, avec un critère clair pour le déclencher. La bascule DNS elle-même doit être préparée en réduisant le TTL des enregistrements plusieurs jours avant.

Le premier piège est le coût. Les instances surdimensionnées, les volumes orphelins, les environnements de test jamais arrêtés et le trafic sortant non anticipé font grimper la facture. Des étiquettes systématiques, des alertes budgétaires et une revue mensuelle des coûts sont indispensables dès le premier mois.

Le second est la sécurité : permissions IAM trop larges, compartiments S3 exposés, groupes de sécurité ouverts sur Internet « temporairement ». Adoptez le moindre privilège dès le départ et activez les services de détection comme GuardDuty, qui signalent les comportements anormaux.

Le troisième est humain. Une équipe habituée à des serveurs physiques doit apprendre de nouveaux outils, de nouvelles pratiques et une nouvelle logique de coûts. Prévoyez la formation et l'accompagnement ; la réussite de la migration se mesure aussi à l'autonomie de l'équipe après le projet.

Une fois les applications stabilisées, redimensionnez les ressources à partir des métriques réelles, utilisez les instances réservées ou les Savings Plans pour les charges stables, et automatisez l'arrêt des environnements hors production en dehors des heures de travail.

C'est aussi le moment d'engager la modernisation : conteneurisation, CI/CD, bases de données managées, observabilité. La migration a créé la fondation ; la valeur vient de ce que vous construisez dessus dans les mois qui suivent.