Pourquoi auditer votre infrastructure avant une migration AWS
Migrer vers AWS sans mesurer l'existant revient à naviguer sans carte. Beaucoup d'équipes découvrent seulement après basculement que leurs estimations de coûts étaient sous-évaluées, que certains serveurs consommaient bien plus de ressources qu'imaginé, ou que des dépendances cachées entre applications compliquaient le découpage en étapes. L'audit d'infrastructure existante est donc la fondation de toute stratégie de migration cohérente. Il vous permet de répondre à trois questions cruciales : qu'avez-vous réellement, combien ça coûte aujourd'hui, et combien cela coûtera dans AWS. Sans ces réponses, vous progressez à l'aveugle. Un audit rigoureux, réalisé avant même de configurer votre premier compte AWS, élimine les fausses hypothèses et vous donne les données concrètes sur lesquelles baser votre roadmap de migration. C'est aussi l'occasion d'identifier les applications obsolètes, les doublons, ou les configurations qui peuvent être rationalisées d'emblée, réduisant ainsi la complexité et les coûts du projet à long terme.
Identifier et documenter votre infrastructure actuelle
La première étape est d'inventorier précisément ce que vous possédez. Cela commence par une cartographie exhaustive de vos serveurs, qu'ils soient physiques, virtualisés on-premise ou déjà en cloud hybride. Pour chaque serveur ou instance, documentez le système d'exploitation, le processeur, la mémoire RAM, le stockage disque, les interfaces réseau, et surtout le rôle métier qu'il joue. Ne vous fiez pas seulement aux documents de procurement datant d'il y a trois ans ; allez sur le terrain et vérifiez l'inventaire dans vos hyperviseurs (vSphere, Hyper-V) ou vos systèmes de monitoring existants. Parallèlement, identifiez toutes vos bases de données : MySQL, PostgreSQL, Oracle, SQL Server, MongoDB, etc. Pour chacune, notez la version, la taille occupée en stockage, le nombre de connexions typiques, et si elle est en cluster ou standalone. N'oubliez pas les systèmes de fichiers partagés, les appliances réseau, les équilibreurs de charge, les pare-feu, et tout ce qui supporte vos applications. Cette documentation ne doit pas rester un document Excel statique : elle constitue la base de reference sur laquelle vous appliquerez les mesures de charges et que vous ferez évoluer au fil des phases de migration.
Mesurer les charges réelles : CPU, mémoire, réseau et I/O
Documenter la configuration statique d'un serveur n'est que la moitié du travail. Vous devez aussi mesurer comment ce serveur se comporte en production : quelle quantité de CPU consomme-t-il en moyenne et en pic, combien de mémoire, quel débit réseau, et surtout, quel est son profil de I/O disque. Ces données sont essentielles pour bien dimensionner les types d'instances AWS ou les classes de stockage EBS/S3 qui conviendront. Utilisez les outils de monitoring natifs de votre infrastructure pour collecter ces métriques sur une période suffisante : au minimum deux à quatre semaines, idéalement sur un mois complet pour capturer les variations mensuelles et les pics saisonniers. Si vous travaillez avec vSphere, exploitez les données de vCenter; sous Hyper-V, interrogez le host; sur des serveurs physiques, installez des agents légers (Prometheus, collectd, ou les outils de votre hyperscaler partenaire). Pour les bases de données, ne vous limitez pas aux métriques de CPU et mémoire ; mesurez aussi l'IOPS (opérations d'entrée/sortie par seconde) et la latence disque, car AWS facture les opérations IOPS en supplément, et une mauvaise estimation ici peut doubler votre facture. Relevez aussi les débits réseau entre serveurs (trafic intra-datacenter), entre datacenters s'il y a une réplication, et entre utilisateurs distants et applications. Ce profil de charge guidera votre choix entre les classes d'instances standard (M5, C5), compute-optimized, memory-optimized, ou storage-optimized selon votre charge dominante.
Quantifier les coûts actuels et projeter les coûts AWS
Maintenant que vous avez mesuré vos charges, quantifiez ce qu'elles vous coûtent aujourd'hui. Pour une infrastructure on-premise, cela inclut l'amortissement des serveurs et du stockage sur 4-5 ans, la consommation électrique, la climatisation, la location de space datacenter si nécessaire, les licences logicielles (surtout les base de données, ERP, ou OS Windows), et les coûts directs de support et maintenance auprès des fournisseurs. Beaucoup d'organisations oublient de factoriser la consommation d'électricité ou le coût implicite du personnel full-time dédié à la gestion de ce parc. Une fois ce chiffre établi, utilisez le AWS TCO Calculator (gratuit) pour simuler le même parc dans AWS avec les charges mesurées. Entrez chaque type de serveur (CPU, RAM) avec sa charge moyenne et pic, les volumes de stockage, les licences logicielles que vous devrez réacquérir (ou non), la bande passante sortante estimée, et les services managés AWS que vous envisagez (RDS pour les bases, ELB pour la charge-balancing, etc.). Le TCO Calculator vous donnera un coût annuel AWS en modes on-demand, reserved instances, et savings plans, ce qui vous permet de comparer directement. N'oubliez pas que certains éléments, comme les licences Oracle ou SQL Server, peuvent être réutilisés en AWS via des programmes BYOL (Bring Your Own License), réduisant les surcoûts. Cette comparaison chiffre le ROI de la migration et aide la direction à décider du calendrier et du budget.
Identifier les dépendances et les blocages de migration
Mesurer les charges est technique; identifier les dépendances est stratégique. Durant l'audit, tracez les flux de données et de communication entre les applications et systèmes. Certaines applications dépendent fortement d'une connectivité réseau très faible latence vers une base de données on-premise, ou d'un système legacy que vous ne pouvez pas (ou ne voulez pas) migrer immédiatement. D'autres applications émettent beaucoup de trafic sortant vers des partenaires externes et pourraient coûter cher en bande passante AWS. Identifiez aussi les applications qui nécessitent des licences propriétaires non portables, celles qui requièrent une conformité réglementaire spécifique (HIPAA, PCI-DSS, RGPD), ou celles qui sont tellement critiques que tout downtime est inacceptable et qu'une stratégie cutover instantané s'impose. Documentez aussi les dépendances humaines et organisationnelles : avez-vous une équipe capable de gérer Kubernetes en production, ou faut-il partir vers des services managés AWS pour réduire la courbe d'apprentissage. Ces dépendances et blocages détermineront votre stratégie de migration (lift-and-shift, re-platform, refactor) et vos dépendances critiques dans le cocon de migration qui sera ensuite détaillé dans les phases. Sans cette vue d'ensemble, vous risquez de vous engager dans une migration sans réaliser trop tard qu'une application clé ne peut pas être déplacée sans travail architectural majeur.
Structurer les données d'audit pour la phase de dimensionnement
L'audit produit une masse de données brutes qui doit être structurée pour servir de fondation à la phase de dimensionnement (décrite en détail dans l'article sur le dimensionnement infrastructure cible AWS). Organisez ces données selon un modèle standardisé : une feuille de calcul ou base de données par type de ressource (serveurs/instances, bases de données, stockage, réseau), avec des colonnes pour configuration statique (modèle, vCore, RAM, disque), charges mesurées (moyenne, 95e percentile, pic), coûts actuels, et notes de dépendances. Validez ces données avec vos équipes techniques : une erreur ici se propage en aval. Créez aussi un résumé exécutif de trois à cinq pages synthétisant les principaux inventaires, coûts actuels, charges dominantes, et principaux risques ou blocages identifiés. Ce résumé sert à obtenir l'accord de la direction avant de lancer les phases de dimensionnement et de migration. Gardez l'audit à jour durant les premières phases de migration, surtout si des applications ou charges changent ou sont retirées; la donnée d'audit reste votre point de référence pour évaluer si le coûts réels en production AWS correspondent à vos projections. Si des écarts importants apparaissent, c'est un signal qu'il faut affiner le dimensionnement ou identifier des sous-estimations.
Outiller l'audit : outils et partenaires
Mener un audit solide ne signifie pas tout faire manuellement. AWS propose des outils gratuits qui accélèrent le processus. AWS Application Migration Service (MGN) inclut un agent léger déployable sur des centaines de serveurs pour capturer automatiquement configuration et charge; AWS DataCenter Migration Service aide à importer les inventaires depuis vos outils de gestion existants (vCenter, System Center, Hyper-V). En amont, des outils tiers comme CloudMapper, Cloudcraft, ou Turbonomic offrent une visibilité graphique et des recommandations de dimensionnement. Pour les bases de données, AWS Database Migration Service (DMS) peut scanner une base distance pour estimer sa taille et sa complexité avant migration. Cependant, aucun outil ne remplace la rigueur manuelle et le dialogue avec les propriétaires métier des applications. Certaines équipes préfèrent confier cet audit à un partenaire AWS ou à un tiers spécialisé en migration (comme Stralya) qui a une méthodologie éprouvée, peut valider les suppositions techniques, et fournit un diagnostic non-biaisé. Le temps investi dans un audit robuste se récupère rapidement en évitant les déploiements ratés, les redimensionnements d'urgence en production, ou les factures surprises à trois mois. Un audit solide est donc un investissement, pas un coût.