Pourquoi bien dimensionner votre infrastructure cible AWS dès le départ
Le dimensionnement d'une infrastructure cloud est bien souvent le facteur invisible qui fait basculer une migration AWS vers le succès ou vers la déception. Lors des audits d'infrastructure existante, nous voyons régulièrement deux extrêmes. D'un côté, des équipes qui migrent avec exactement les mêmes ressources que leur ancien système on-premises, sans tenir compte de la réalité nuageuse : une instance t3.large sur AWS n'est pas un serveur physique dédié, et partage des ressources réseau et de stockage. De l'autre, des équipes qui surdimensionnent par peur de l'inconnu, achètent des instances beaucoup trop puissantes, et se retrouvent avec une facture AWS déraisonnable après six mois. Entre ces deux extrêmes, il y a un juste milieu déterminé par vos vrais besoins. Le dimensionnement correct de votre infrastructure cible repose sur trois piliers. D'abord, la mesure exacte de votre charge actuelle : consommation CPU réelle (pas le pic théorique, la moyenne et le percentile 95), mémoire utilisée, I/O disque par seconde, bande passante réseau sortante et entrante. Ensuite, la projection de cette charge sur les offres AWS disponibles, qui fonctionnent selon un modèle très différent du on-premises. Enfin, l'intégration des contraintes métier spécifiques à votre contexte : pics saisonniers, croissance prévue, exigences de disponibilité, dépendances applicatives que vous avez identifiées en amont. Bien dimensionner signifie aussi accepter que le dimensionnement n'est pas figé. AWS offre des mécanismes comme l'auto-scaling, les instances réservées et les savings plans qui permettent d'ajuster au fur et à mesure. Cependant, cette flexibilité ne vous dispense pas de partir sur une base saine. Une infrastructure mal dimensionnée au lancement rendra le contrôle des coûts plus difficile ensuite, car vous serez tenté de compenser la lenteur par de la ressource supplémentaire plutôt que de revoir la conception.
Collecter les métriques de charge actuelles pour dimensionner juste
Dimensionner une infrastructure cible repose en premier lieu sur des chiffres fiables. Vous avez probablement lancé un audit d'infrastructure existante pour évaluer l'état actuel : cette étape n'était pas une fin en soi, mais le point de départ de votre dimensionnement. Ce qu'il faut, ce sont des mesures quantifiables et contextualisées. Pour le calcul (CPU, mémoire), vous avez besoin de connaître non seulement la moyenne sur une période représentative (une ou deux semaines en conditions normales), mais aussi le percentile 95 en charge. Le percentile 95 signifie : sur cent heures d'observation, quatre-vingt-quinze heures vous avez consommé moins que cette limite, cinq heures vous l'avez dépassée. C'est le bon compromis entre offrir de la marge et ne pas surprovisionner pour gérer un cas anormal. Prenons un exemple concret. Un serveur applicatif utilise en moyenne 40% du CPU disponible sur votre infrastructure actuelle, mais monte à 85% lors des bulles de requêtes, et à 100% pendant les lancements de batch la nuit. Le percentile 95 se situe autour de 65% sur la période mesurée. Si vous migrez une instance ayant physiquement 16 vCPU, il faut convertir cette consommation en vCPU réels : 16 vCPU × 65% (percentile 95) = 10,4 vCPU. Sur AWS, vous choisirez une instance m5.2xlarge (8 vCPU) ou c5.2xlarge (8 vCPU) si CPU est le limitant, et vérifierez que la mémoire suffit aussi. Pour le stockage, la mesure passe par le volume total occupé aujourd'hui, le taux de croissance (Go par mois), et les pics temporaires (par exemple avant une archivage annuelle). Si vous avez 500 Go utilisés, avec une croissance de 10 Go par mois, et que votre horizon de planification est deux ans, prévoyez au minimum 500 + (24 × 10) = 740 Go, plus une marge de sécurité de 20%, donc ~900 Go. Sur AWS, un volume EBS gp3 de 1 To sera approprié. Pour la bande passante réseau, mesurez vos pics réels en Mbps ou Gbps de sortie (ce qui a un coût chez AWS, contrairement à l'entrée gratuite). Enfin, pour les bases de données, si vous avez un RDS actuel, extrayez le nombre de connexions simultanées, le volume des données actives (pas seulement l'espace disque), la fréquence des backups, et le temps RTO / RPO requis (objectif de temps de récupération, objectif de perte de données).
Traduire vos charges en offres AWS et réserver la bonne taille
Une fois vos métriques en main, vient le mappage vers les instance types AWS. C'est ici que bien des équipes déraillent, car les noms des instances (t3, m5, c5, r6i, etc.) et leurs variantes (nano, micro, small, medium, large, xlarge, 2xlarge, etc.) forment une grille complexe qu'il est facile de mal lire. AWS propose des instance families différentes selon votre profil de charge. Les instances de la famille t (t3, t3a, t4g) sont économiques et adaptées aux charges variables, car elles utilisent un système de "burst", où vous accumulez des crédits de CPU quand la charge est basse, et les dépensez lors des pics. Si votre application a une charge relativement stable (le percentile 95 n'est pas trop loin de la moyenne), une instance t3.xlarge peut suffire. Les instances m (m5, m6i, m7i) offrent un équilibre entre CPU, mémoire et réseau, et sont la base pour beaucoup d'applications d'entreprise. Les instances c (c5, c6i, c7i) sont optimisées CPU pour les calculs intensifs, datawarehousing ou applications scientifiques. Les instances r (r6i, r7i) et x (x1, x2) sont optimisées mémoire, essentielles pour les caches en mémoire (Redis), les bases de données analytiques, ou les engines de recherche. Attention à ne pas mélanger les deux approches. Beaucoup d'équipes dimensionnent une instance t3.large en supposant que le burst des crédits les sauvera lors des pics, mais découvrent rapidement que le burst s'épuise s'il y a des pics trop fréquents ou trop brutaux. Si votre charge réelle à percentile 95 est de 75% CPU en continu, vous devez acheter une instance avec assez de CPU réel pour cette charge, pas parier sur des crédits volatiles. La génération compte aussi : une instance m5 est moins puissante (par vCPU) qu'une m6i, elle-même moins puissante qu'une m7i. Pour l'espace disque, passez en revue votre besoin projeté (calculé plus haut), arrondissez à un multiple de 100 Go, et demandez-vous si vous avez besoin de performance disque spéciale (IOPS ou débit Mbps). Un gp3 standard (3 IOPS par Go, débit jusqu'à 1 Gbps) suffit pour 80% des cas. Si vous avez une base de données avec beaucoup de petites transactions (plusieurs milliers par seconde), envisagez un io2 qui offre jusqu'à 500 IOPS par Go. Une fois le type d'instance et le stockage dimensionnés, AWS vous propose plusieurs modèles d'achat. On-demand vous facture à l'heure réelle, sans engagement. Une instance réservée (1 an ou 3 ans) réduit le prix de 30 à 70%, mais demande un engagement et une prévisibilité. Un savings plan offre une réduction comparable avec plus de flexibilité (vous pouvez changer de famille ou de région). Pour une migration, il est courant de commencer en on-demand (3 à 6 mois) le temps d'évaluer la charge réelle, puis de basculer en réservé ou savings plan une fois stabilisé. Cela évite les mauvaises surprise : avoir réservé une instance trop grande pour deux ans à prix réduit est un gâchis coûteux.
Intégrer les dépendances applicatives et les contraintes métier
Votre charge en chiffres bruts n'est qu'une part de la histoire du dimensionnement. Vous avez aussi identifié vos dépendances applicatives en amont : quelle application communique avec quelle autre, à quelle fréquence, avec quel volume de données. Ces dépendances influencent à la fois le placement physique des ressources et leur dimensionnement fin. Si votre application métier dépend d'une base de données RDS, et que cette base de données dépend elle-même d'une réplica de lecture pour les reports, le dimensionnement de la base primaire ne peut pas ignorer le volume de requêtes de lecture venant des instances applicatives. Si ces instances sont surdimensionnées, elles généreront plus de requêtes qu'attendu, saturant rapidement la réplica. Inversement, si elles sont sous-dimensionnées, elles gagneront du temps en file d'attente plutôt qu'en calcul, et vous ne verrez pas d'amélioration en augmentant la capacité de la base. Autre considération : vos contraintes de disponibilité et de latence. Si vous avez une application qui demande une disponibilité de 99,99% (15 minutes d'indisponibilité par an), vous devez provisionner plusieurs instances en redondance et les placer dans au moins deux availability zones (AZ) AWS différentes. Cela implique de multiplier la capacité par au moins 2, et les coûts de données cross-AZ (0,01 USD par Go) ne sont pas négligeables. Si votre charge est répartie, une instance dans chaque AZ d'une taille inférieure peut être plus efficace qu'une grosse instance unique. Les pics saisonniers jouent aussi un rôle. Beaucoup d'entreprises connaissent des pics prévisibles (Black Friday, Noël, rentrée scolaire, fin d'année fiscale). Sur AWS, vous pouvez activer l'auto-scaling pour que votre infrastructure grandit et rétrécisse automatiquement selon des règles que vous définissez. Mais cet auto-scaling doit être dimensionné pour absorber le flux de scaling lui-même. Si vous passez de 5 instances à 20 instances en deux minutes (ce que demande un pic brutal), le processus de démarrage, de connexion à la base de données, et de remplissage des caches peut prendre 30 secondes par instance. Pendant ce temps, les instances existantes sont surchargées. Il faut donc prévoir une marge statique (par exemple, 15 instances de base) et une capacité d'auto-scale supplémentaire pour les pics. Enfin, considérez la croissance à moyen terme. Si votre charge augmente de 20% par an, votre dimensionnement initial pour un horizon de trois ans devrait intégrer cette croissance. Pas de manière linéaire (provisionner 60% de marge dès le départ gâcherait les coûts), mais via une stratégie d'expansion planifiée : commencer right-sized pour le jour 1, et prévoir des étapes de réflexion (tous les 6 ou 12 mois) pour évaluer si un upsizing est nécessaire.
Valider votre dimensionnement avant la migration
Une fois que vous avez arrêté un dimensionnement théorique, la tentation est grande de passer directement à la migration. Ne cédez pas. Il existe plusieurs tactiques pour valider votre dimensionnement sans attendre le jour de la migration. La première est la simulation en parallèle. Vous provisionner vos ressources AWS dimensionnées, et durant une semaine ou deux (en conditions normales, idéalement une semaine incluant un jour de charge plus élevée), vous faites tourner une copie non-critique de votre application dessus, en miroir avec votre infrastructure actuelle. Vous mesurez CPU, mémoire, I/O disque et latence réseau sous charge réelle. Si vous observez que le percentile 95 du CPU sur AWS dépasse régulièrement 85%, vous êtes sous-dimensionnés. Si CPU plafonne à 20%, vous surprovisionnez. Cette approche demande quelques jours de préparation (copie des données, déploiement sur AWS, monitoring), mais elle rattrape vos erreurs avant d'être en production et de coûter une régression majeure. La deuxième tactique est le load testing. Vous reproduisez votre profil de charge réelle (ou une fraction représentative) via un outil comme JMeter, LoadRunner, ou k6, et vous lancez ce test contre votre dimensionnement théorique. Cela révèle souvent des goulots qui n'apparaissent pas en observation passive : un pool de connexions base de données trop petit, un cache insuffisant, une bande passante réseau interne qui sature. Enfin, si une simulation ou un load test révèle un problème, vous avez plusieurs leviers. D'abord, augmenter les ressources (vertically scaling, monter l'instance à un plus grand type). Ensuite, ajouter des instances supplémentaires (horizontal scaling) et mettre en place un load balancer pour répartir la charge. Troisièmement, optimiser l'application elle-même (réduire la consommation CPU d'un algo, mettre en cache une requête base coûteuse). Quatrièmement, réduire la charge réelle (par exemple, limiter la fréquence de certains jobs). Dans la plupart des cas réels, une combinaison de ces leviers (par exemple, passer de m5.large à m5.xlarge ET ajouter un cache Redis) est plus rentable qu'une escalade pure des ressources. Le dimensionnement final doit tenir compte de ces apprentissages et être documenté avec transparence : quelle était votre mesure initiale, quels changements vous avez fait et pourquoi, quel est votre plan si la charge diverge après la migration.
Ajuster le dimensionnement post-lancement et maîtriser les coûts AWS
Après la migration, votre infrastructure est en production, mais votre travail de dimensionnement ne s'arrête pas là. Bien sûr, les opérations quotidiennes (patching, monitoring, alerting) ne font pas partie du champ de cette page (c'est de la régie au quotidien), mais l'ajustement du dimensionnement basé sur l'observation réelle de la charge EST du ressort de la planification de votre migration. Les trois premiers mois post-lancement sont cruciaux. Vous devez collecter les métriques réelles de CPU, mémoire, disque et réseau sous vraies conditions métier, et les comparer à votre plan. En pratique, trois scénarios peuvent se produire. D'abord, votre dimensionnement était juste, et la charge observée correspond à ce que vous aviez prévu. Dans ce cas, vous avez peu de changements à faire, mais vous pouvez commencer à envisager une réservation d'instances (1 an ou 3 ans) pour réduire le coût on-demand de 30 à 70%. Deuxièmement, votre charge est plus basse que prévu. Cela arrive souvent quand une application n'a qu'une petite fraction du datacenter sur elle-même, ou que la migration a provoqué un avantage d'efficacité non anticipé (par exemple, votre code tourne plus vite sur une CPU plus moderne). Dans ce cas, vous pouvez réduire les instances à un type plus petit. Troisièmement, votre charge est plus haute que prévu. Si c'est une surprise durable (pas un pic isolé), il faut investiguer : utilisation accidentelle de performances accrues pour lancer des traitements nouveaux, utilisateurs supplémentaires, ou erreur dans l'estimation initiale. Vous devez alors monter les instances ou ajouter de la redondance. Le coût peut aussi diverger sans que la charge change, pour d'autres raisons. Par exemple, si vous provisionnez trop de données entrantes provenant d'une autre région AWS, vous payez 0,02 USD par Go (coût cross-région), soit rapidement cher. Ou si vous laissiez tournera des snapshots de backup trop longtemps sans les archiver en Glacier (moins cher pour le stockage froid). Ces optimisations ne sont pas du dimensionnement au sens strict, mais elles en découlent : bien dimensionner signifie aussi bien comprendre la structure des coûts AWS et s'assurer que votre architecture l'honore. Un outil comme AWS Compute Optimizer (qui analyse votre charge et recommande des types d'instance) ou Cost Explorer (qui décortique votre facture par service) vous aide à piloter ces ajustements. Le dimensionnement n'est donc jamais acquis une fois pour toutes, mais une discipline continue de mesure et d'adaptation dans les six premiers mois après la migration, puis une révision annuelle ou bisannuelle pour tenir compte de la croissance métier.
Cas concrets : dimensionner une app web, une base de données, et un système batch
Voyons comment appliquer ces principes à trois profils réalistes que vous rencontrerez. Cas 1 : Application web avec beaucoup d'utilisateurs simultanés. Vous mesurez actuellement 5000 requêtes par seconde en moyenne, 12000 req/s au percentile 95. Chaque requête consomme environ 50 ms de CPU. En charge, votre serveur utilise 60% CPU, 70% mémoire (vous avez 128 Go), et génère 50 Mbps de bande passante sortante. Vous projetez 30% de croissance sur 18 mois. Sur AWS, vous dimensionnez pour 12000 req/s × 1,3 (croissance) = 15600 req/s. Si une seule instance m5.2xlarge (8 vCPU, 32 Go mémoire) peut gérer 2500 req/s, vous avez besoin de 15600 / 2500 = 6,24 instances, arrondi à 7. Vous en déployez 7 derrière un application load balancer. Pour la haute disponibilité (99,99%), vous les répartissez : 4 dans une AZ, 3 dans une autre. Coût on-demand : 7 × USD 0,394/h (m5.2xlarge) × 720h/mois = USD 1981/mois. Avec une réservation 3 ans, vous obteniez USD 600/mois environ, une belle économie. Cas 2 : Base de données relationnelle (RDS). Vous avez actuellement 2 To de données, avec 15000 transactions par seconde en pics, une mémoire de working set (données fréquemment accédées) de 400 Go. Pour RDS PostgreSQL, vous devez choisir une instance capable de supporter ces transactions et suffisamment de mémoire pour le working set en cache. Une instance db.r6i.2xlarge (8 vCPU, 64 Go RAM) serait appropriée. Vous activez les multi-AZ pour 99,99% (redondance synchrone, petit délai au commit), et provisionnez un stockage gp3 de 3 To (pour croissance et margin). Coût on-demand : USD 2,304/h × 720h = USD 1659/mois, plus USD 0,23 par Go de stockage = 3000 × USD 0,23 = USD 690/mois, total USD 2349/mois. En réservation 3 ans, la base baisserait à USD 700/mois. Cas 3 : Job batch nocturne. Vous avez un large ETL qui tourne chaque nuit pendant 4 heures, consomme 32 vCPU, 128 Go RAM, 500 Mbps de réseau pour lire depuis une source externe. Vous avez plusieurs choix. Créer une instance m5.4xlarge (16 vCPU, 64 Go) et la laisser tourner 4h/nuit, ou déployer 2× m5.2xlarge en parallèle, ou utiliser AWS Glue (service géré) ou Fargate (conteneurs sans infrastructure) qui vous charge à l'heure et à la ressource utilisée seulement. Pour 4h/nuit, une instance m5.4xlarge en on-demand coûte USD 1,504/h × 4h × 30 jours = USD 1803/mois. Avec une instance réservée légère (vous pouvez la partager avec d'autres jobs), vous tomberiez à USD 550/mois. Avec Fargate, en supposant une tarif moyenne de USD 0,04704 par vCPU-hour, 32 vCPU × 4h × 30 jours × USD 0,04704 = USD 1806/mois. Pas d'économie majeure dans ce cas, mais Fargate vous épargne la gestion d'infrastructure. Ces trois cas montrent que le dimensionnement n'est pas un calcul unique, mais une adaptation à chaque composant de votre architecture, des arbitrages entre coût, fiabilité et simplicité opérationnelle.
Les erreurs courantes à éviter dans le dimensionnement
Après avoir travaillé sur des centaines de migrations AWS, quelques pièges reviennent régulièrement. Première erreur : confondre la consommation actuelle avec la capacité actuelle. Vous mesurez qu'une instance physique utilise 30% CPU, et vous supposez que vous pouvez utiliser 30% de sa capacité sur AWS. Faux. Sur un serveur physique dédié, 30% d'utilisation peut signifier que vous avez encore énormément de marge avant saturation. Sur AWS, si le percentile 95 monte à 30%, vous êtes near-optimal. Si la plupart du temps vous êtes à 5%, le serveur est surprovisionnée. Contexte est tout. Deuxième erreur : ignorer les variations de charge. Vous mesurez 5 Go/jour de stockage consommés en moyenne, et vous provisionnez 10 Go. Mais si un job de cleanup se lance une fois par mois et consomme soudainement 30 Go d'espace temporaire, vous manquez de place. Toujours prévoir un buffer, typiquement 30 à 50% au-delà de votre pire mesure. Troisième erreur : appliquer une règle de trois naïve. "Notre serveur actuel a 16 vCPU et gère bien notre charge, donc j'achète une m5.2xlarge (8 vCPU) sur AWS." Les vCPU d'AWS ne sont pas identiques aux vCPU on-premises, les technologies de virtualisation jouent, et les vCPU "théoriques" ne sont pas garantis de manière identique. Basez-vous sur des benchmarks réels ou un load test, pas sur un compte de noyau. Quatrième erreur : négliger le coût de la redondance. Si vous avez besoin de 99,99% d'availability, vous devez multiplier par 2 au minimum (deux instances ou AZ) pour certains composants. Cela double le coût base. Si vous dimensionnez une instance unique « optimale » mais qu'elle tombe en panne, vous êtes offline. Mieux vaut deux instances de taille réduite que une grosse. Cinquième erreur : oublier les dépendances cross-composant. Vous dimensionnez votre app web correctement, mais vous oubliez que chaque requête effectue 10 requêtes base de données. Si vous augmentez les instances web, vous augmentez aussi la charge base de données, qui peut devenir goulet. Validez le chaîne entière, pas juste un composant. Sixième erreur : supposer que la validation en labo ressemble à la production. Un load test avec 1000 utilisateurs virtuels ne reproduit pas toujours les conditions d'une vraie charge client avec ses irrégularités, ses timeouts, ses reconnexions. Testez au plus proche possible du trafic réel, idéalement via une période de shadow traffic (copie du trafic réel vers votre nouvel infrastructure sans l'impacter encore). Septième erreur : ne pas réévaluer après six mois. Après le go-live, l'équipe se soulage et oublie de regarder si le dimensionnement a besoin d'ajustement. Vous vous retrouvez à payer pour de la capacité non utilisée ou, pire, à souffrir de sous-dimensionnement chronique caché par l'auto-scaling qui cache le problème. Planifiez une révision mensuelle les trois premiers mois, puis trimestrielle.