Amazon SAA-C03: Calcul, Auto Scaling et gestion des instances — Guide d'étude

By Laurynas Brazys · 16 July 2026 · #amazon #saa-c03 #certification #exam-prep #study-guide

Fait partie du AWS SAA-C03 — Guide d’étude complet. Entraînez-vous avec des réponses vérifiées dans le centre d’examens Amazon, ou passez des tests chronométrés sur ExamRoll.io.

Types d’instances EC2 et AMI

La sélection de la bonne famille d’instances EC2 est le fondement d’une couche de calcul bien architecturée, car la famille, la génération et la taille déterminent ensemble l’architecture CPU, le ratio mémoire/vCPU, la bande passante réseau et les accélérateurs disponibles. L’usage général (M6i, M7g, série T) convient aux tiers web équilibrés et aux charges de travail mixtes. Les instances optimisées pour le calcul (C7i, C7gn) sont adaptées aux simulations, à l’encodage, aux traitements par lots et aux frontaux web qui sont limités par le CPU. Les instances optimisées pour la mémoire (R7i, X2idn) ciblent les bases de données en mémoire et les caches. Les instances optimisées pour le stockage (I4i, D3) ciblent le NoSQL, HDFS et l’entreposage de données (data warehousing). Le calcul accéléré (P5, G5, Trn1, Inf) fournit des GPU ou des puces de ML. Les instances Graviton (suffixe g) offrent généralement un rapport prix/performance de 20 à 40 % supérieur pour les charges de travail à montée en charge horizontale (scale-out) qui se compilent sans problème pour ARM64.

La famille T est à capacité extensible (burstable) et utilise par défaut le mode standard, où les crédits CPU s’accumulent au repos et sont consommés lors des pics d’activité ; lorsque les crédits sont épuisés, la performance est limitée au niveau de base. Pour les charges de travail avec des pics imprévisibles — petits tiers web, dev/test, ou environnements Elastic Beanstalk soutenant un frontal à activité irrégulière — les instances T en mode illimité permettent à l’instance d’emprunter des crédits et de facturer une petite surtaxe par vCPU-heure de dépassement, évitant ainsi une limitation de performance visible par l’utilisateur. C’est pourquoi les problèmes de saturation brève du CPU dans les environnements Beanstalk sont généralement résolus en activant le mode illimité plutôt qu’en passant à une famille optimisée pour le calcul, plus coûteuse. Il est important de réserver la série T aux charges de travail réellement irrégulières avec une moyenne faible : une utilisation CPU soutenue en mode standard épuise les crédits en quelques minutes.

La mise à l’échelle verticale (passer à une taille supérieure au sein de la même famille) est limitée par la plus grande instance disponible, impose un temps d’arrêt pour le changement, introduit un point de défaillance unique (single point of failure) et ne peut pas répartir la charge de travail sur plusieurs Zones de disponibilité. Dès que la charge varie de manière significative, la mise à l’échelle horizontale avec un groupe Auto Scaling est la bonne solution.

Les AMI de référence (« Golden AMI ») intègrent le code applicatif, l’environnement d’exécution et les dépendances dans le snapshot racine, ce qui permet des lancements rapides et déterministes — un point essentiel lorsqu’un groupe Auto Scaling réagit à un pic de charge. Le bootstrapping via les données utilisateur (user-data) à chaque lancement ajoute des minutes de latence au pire moment possible.

Choix de stockage : Instance Store vs EBS, Snapshots et Fast Snapshot Restore

Les instances offrent deux substrats de stockage : le stockage d’instance (NVMe éphémère attaché à l’hôte physique) et Amazon EBS (stockage en mode bloc attaché au réseau). Le stockage d’instance offre la latence la plus faible possible, mais ses données sont détruites lors d’un arrêt, d’une mise en veille prolongée (hibernate), d’une terminaison ou d’une défaillance matérielle. Le considérer comme un stockage durable est une erreur courante et dangereuse — il ne convient que pour l’espace de travail temporaire (scratch space), les tampons, les caches ou les données répliquées, comme un nœud de données HDFS dont les répliques existent sur d’autres nœuds. Les données durables doivent être sur EBS, sauvegardées par des snapshots stockés dans S3.

Les snapshots sont incrémentiels et, une fois créés, indépendants. Ainsi, la restauration d’un snapshot sur un nouveau volume n’affecte jamais la source. La manière canonique de dupliquer un grand jeu de données de production dans un environnement de test est de créer un snapshot du volume source et de créer de nouveaux volumes à partir de ce snapshot. Cependant, les volumes restaurés à partir de snapshots chargent les blocs à la demande depuis S3 (lazy-loading) lors de la première lecture, ce qui provoque une latence d’E/S significative jusqu’à ce que chaque bloc soit hydraté. Ce même chargement à la demande affecte les nouvelles instances lancées à partir d’AMI dont les snapshots racines sont volumineux — elles semblent lentes pendant plusieurs minutes après leur lancement.

EBS Fast Snapshot Restore (FSR) élimine cette pénalité. Activez FSR sur le snapshot pour les Zones de disponibilité où le groupe ASG lance des instances, et les volumes créés à partir de celui-ci fourniront immédiatement leurs performances provisionnées complètes :

aws ec2 enable-fast-snapshot-restores \
  --availability-zones us-east-1a us-east-1b \
  --source-snapshot-ids snap-0123456789abcdef0

Ceci est essentiel lorsque les événements de montée en charge horizontale doivent ajouter de la capacité en quelques secondes plutôt qu’en quelques minutes.

Mise en réseau améliorée avec ENA et EFA

Le débit réseau annoncé évolue avec la taille de l’instance, mais il n’est atteignable que si le pilote Elastic Network Adapter (ENA) est présent. ENA fournit une mise en réseau améliorée basée sur SR-IOV, supportant jusqu’à 200 Gbit/s sur les instances les plus récentes. Les AMI modernes (Amazon Linux 2, Ubuntu récent, Windows) sont livrées avec ENA activé ; vérifiez avec :

aws ec2 describe-instances --instance-ids i-0abc \
  --query 'Reservations[].Instances[].EnaSupport'

modinfo ena | grep version
ethtool -i eth0

Sans ENA, les instances se rabattent silencieusement sur un débit plus faible et une gigue plus élevée, compromettant toute conception à faible latence, quel que soit le choix du groupe de placement.

Pour les opérations collectives à l’échelle de la microseconde — CFD, modélisation météorologique, dynamique moléculaire, entraînement de grands modèles — ajoutez un Elastic Fabric Adapter (EFA). EFA expose un transport qui contourne le système d’exploitation (OS-bypass) via Libfabric à MPI et NCCL, évitant ainsi complètement la pile réseau du noyau. EFA n’apporte ses avantages qu’au sein d’un groupe de placement en cluster sur les types d’instances pris en charge (c7gn, hpc7a, p5), et nécessite le pilote EFA ainsi qu’une version compatible de MPI (Open MPI, Intel MPI) ou de NCCL.

aws ec2 create-placement-group --group-name hpc-cg --strategy cluster
aws ec2 run-instances --instance-type hpc7a.96xlarge \
  --placement GroupName=hpc-cg \
  --network-interfaces InterfaceType=efa,DeviceIndex=0,SubnetId=subnet-abc

Groupes de placement

Les groupes de placement (Placement groups) contrôlent la topologie physique des instances :

Un mauvais choix rend la fonctionnalité inutile. Un groupe de placement de type cluster ne peut pas s’étendre sur plusieurs AZ — il est intra-AZ par conception. Un groupe de type spread ne peut pas héberger une centaine de serveurs web en raison du plafond de sept instances par AZ. Le placement par partition, et non par spread, est l’outil approprié pour un cluster Kafka de 40 nœuds car il aligne le placement des répliques avec les domaines de pannes. Pour une haute disponibilité générale, ne limitez pas un ASG à un seul groupe de placement dans une seule AZ — répartissez l’ASG sur plusieurs AZ.

Pour l’analytique en streaming ou les charges de travail MPI nécessitant une latence minimale de nœud à nœud, la combinaison correcte est un groupe de placement de type cluster avec des instances activées pour ENA ; le cluster réduit le nombre de sauts (hops) et ENA fournit la capacité en paquets par seconde nécessaire pour concrétiser cet avantage de latence.

Auto Scaling Groups et Launch Templates

Un Auto Scaling group (ASG) est l’unité d’exécution qui maintient un nombre souhaité d’instances EC2 sur une ou plusieurs AZ, défini par trois entiers — MinSize, DesiredCapacity, MaxSize — et une liste de subnets. L’ASG lui-même ne décrit pas quoi lancer ; c’est la responsabilité d’un launch template, le remplaçant moderne des launch configurations. Les launch templates prennent en charge le versioning, les politiques d’instances mixtes, le mélange d’instances Spot/On-Demand, l’application d’IMDSv2, les réservations de capacité et les instances T en mode illimité. Un launch template référence une AMI, un ou plusieurs types d’instance, des groupes de sécurité, un profil d’instance IAM, des données utilisateur (user data) et des mappages de périphériques de stockage en mode bloc.

Le modèle canonique pour une application web stateless est AMI + Launch Template + ASG + ALB. L’AMI assure un démarrage rapide ; l’ALB (ou le NLB pour TCP/UDP) répartit le trafic et pilote les bilans de santé (health checks) ; l’ASG enregistre automatiquement les nouvelles instances dans le groupe cible et termine celles qui sont défectueuses. Un déploiement multi-AZ (au minimum deux AZ, trois pour les systèmes à quorum) est obligatoire — un ASG lié à un seul subnet ne peut pas survivre à une panne d’AZ car l’ASG lui-même ne peut pas lancer de remplacements tant que l’AZ est défaillante.

MyASG:
  Type: AWS::AutoScaling::AutoScalingGroup
  Properties:
    MinSize: 2
    MaxSize: 20
    DesiredCapacity: 4
    VPCZoneIdentifier: [subnet-a, subnet-b]
    TargetGroupARNs: [!Ref AppTargetGroup]
    LaunchTemplate:
      LaunchTemplateId: !Ref AppLT
      Version: !GetAtt AppLT.LatestVersionNumber
    HealthCheckType: ELB
    HealthCheckGracePeriod: 120

Politiques de scaling : Suivi de cible, par paliers, planifié, prédictif

Le scaling d’ASG comporte quatre modes, chacun résolvant un problème différent :

• Le suivi de cible (Target tracking) choisit une métrique et la maintient près d’un point de consigne (par ex., ASGAverageCPUUtilization = 50 %, ALBRequestCountPerTarget = 1000). Il s’auto-ajuste — AWS gère les alarmes et ajuste la vélocité à mesure que la métrique dévie. Ce devrait être le choix par défaut.
• Le scaling par paliers (Step scaling) ajoute ou supprime de la capacité par niveaux gradués en fonction de l’écart de la métrique par rapport à la plage, utile lorsque l’ampleur de la réaction doit être proportionnelle à la gravité de l’alarme.
• Le scaling simple (Simple scaling) est hérité : un seul ajustement par alarme, se bloque pendant la période de stabilisation (cooldown), et ne devrait pas être choisi pour les nouvelles conceptions.
• Le scaling planifié (Scheduled scaling) modifie MinSize/DesiredCapacity/MaxSize à des heures définies (type cron).
• Le scaling prédictif (Predictive scaling) utilise le machine learning sur jusqu’à 14 jours d’historique pour prévoir les 48 prochaines heures, pré-provisionnant la capacité avant la montée en charge.

Le scaling dynamique a un retard inhérent — il ne réagit qu’après qu’une métrique a dépassé un seuil, et les nouvelles instances ont ensuite besoin de plusieurs minutes pour démarrer, s’enregistrer et monter en température (warm up). Pour une application métier où tous les utilisateurs arrivent à 09h00 et subissent 2 à 3 heures de lenteur pendant que l’ASG rattrape son retard, le scaling dynamique seul n’est pas la bonne réponse. Superposez des actions planifiées en amont du pic pour augmenter MinSize et DesiredCapacity avant que la demande n’arrive :

ScheduledAction:
  AutoScalingGroupName: web-asg
  ScheduledActionName: pre-sale-warmup
  Recurrence: "0 8 * * *"
  MinSize: 20
  DesiredCapacity: 30
  MaxSize: 200

Laissez ensuite le suivi de cible absorber la variabilité résiduelle. Le scaling prédictif est le bon choix lorsque la forme du pic est stable mais que son timing exact varie d’un jour à l’autre. Pour des arrêts prévisibles hors production (environnements de dev éteints les nuits et week-ends), une action planifiée pour passer à desired=0, min=0 le vendredi soir et redémarrer le lundi matin est la solution la moins coûteuse en termes de gestion — l’ASG lui-même sert de moteur de planification, aucune ‘glue’ Lambda ou EventBridge n’est requise.

Le choix de la métrique est tout aussi important que le choix de la politique. Le CPU fonctionne pour les charges de travail web limitées par le CPU, mais pour des workers pilotés par un backlog qui consomment depuis SQS, vous devez scaler sur la profondeur de la file d’attente, pas sur le CPU : un worker bloqué en attente d’I/O peut afficher 10 % de CPU pendant que des millions de messages s’accumulent. Utilisez ApproximateNumberOfMessagesVisible par instance, exposé comme une métrique personnalisée ou via la cible intégrée SQSQueueBacklogPerInstance :

backlog_per_instance = messages_visible / running_instances
target = acceptable_latency_seconds / avg_processing_seconds_per_msg

TargetTrackingConfiguration:
  CustomizedMetricSpecification:
    MetricName: BacklogPerInstance
    Namespace: MyApp/Scaling
    Statistic: Average
  TargetValue: 100

De même, les niveaux HTTP sensibles à la latence devraient suivre TargetResponseTime ou RequestCountPerTarget ; les applications limitées par la mémoire, le disque ou la latence d’un service en aval devraient publier une métrique personnalisée qui reflète le véritable goulot d’étranglement. Scaler sur le CPU alors que le CPU n’est pas la contrainte produit exactement le mode de défaillance où les instances ne scalent jamais horizontalement (scale out), les files d’attente s’allongent sans limite et l’ALB renvoie des erreurs 5xx.

Vérifications d’état et hooks de cycle de vie

Par défaut, les ASG utilisent les vérifications d’état EC2, qui détectent une défaillance de l’hyperviseur mais pas une défaillance applicative. L’activation des vérifications d’état ELB sur l’ASG délègue la décision de remplacement à la sonde de niveau applicatif de l’équilibreur de charge, ce qui est essentiel lorsque le système d’exploitation fonctionne correctement mais que le processus est bloqué. Définissez HealthCheckGracePeriod sur une durée suffisante pour que les données utilisateur (user data) se terminent ; sinon, les nouvelles instances sont terminées en boucle au milieu de leur bootstrap.

Le choix de l’équilibreur de charge affecte la signification de « sain » :

Une application HTTP derrière un NLB effectuant uniquement des vérifications d’état TCP continuera de recevoir du trafic d’une instance qui accepte les connexions mais renvoie des erreurs 500. Passez à un ALB — ou configurez des vérifications d’état HTTP sur le NLB — pour restaurer une signalisation pertinente.

Les hooks de cycle de vie (lifecycle hooks) mettent en pause les instances dans l’état Pending:Wait ou Terminating:Wait pour permettre à une automatisation externe d’agir. Au lancement, un hook vous permet d’enregistrer l’instance auprès d’un système de gestion de configuration, de préchauffer les caches ou de récupérer des secrets avant que l’ALB n’envoie du trafic. À la terminaison, un hook vous permet de drainer les sessions, de vider les journaux et de désenregistrer l’instance d’un maillage de services (service mesh). Les hooks émettent des événements EventBridge ; les gestionnaires doivent appeler CompleteLifecycleAction, sinon le hook expire et adopte son comportement par défaut (CONTINUE ou ABANDON).

Pools préchauffés et hibernation

Le temps de démarrage à froid est un vrai problème pour les applications qui chargent de grands modèles, préchauffent des caches ou effectuent une compilation JIT avant de servir. Un pool préchauffé (warm pool) est une réserve d’instances pré-initialisées attachée à l’ASG : les instances se lancent, exécutent leur bootstrap, puis sont arrêtées, maintenues en exécution ou mises en hibernation, conservées dans le pool jusqu’à ce que l’ASG effectue un scale-out. Prendre une instance du pool permet d’éviter plusieurs minutes de démarrage.

L’hibernation suspend le système d’exploitation sur le volume racine EBS chiffré, de sorte que le tas (heap) JVM, les poids des modèles de ML et le cache de page du SE sont restaurés à la reprise. Prérequis : un volume racine chiffré assez grand pour contenir la RAM, une RAM d’instance ≤ 150 Go sur une famille prise en charge, et HibernationOptions.Configured = true au lancement. Un pool préchauffé avec PoolState: Hibernated combine les deux : les instances ne coûtent rien en termes de calcul lorsqu’elles sont arrêtées et reprennent en quelques secondes avec la mémoire déjà remplie. C’est le modèle correct lorsqu’une application « prend beaucoup de temps pour charger la mémoire avant de devenir productive ».

Récupération automatique pour les charges de travail non scalables

Toutes les charges de travail ne peuvent pas être mises à l’échelle horizontalement. Les applications héritées avec des licences liées à l’adresse MAC, des verrous basés sur des fichiers ou un état de session en mémoire sans stockage partagé ne peuvent pas s’exécuter sur plus d’une instance — le lancement de nœuds supplémentaires provoque une corruption des données ou des violations de licence. Pour celles-ci, la résilience provient de la récupération automatique, et non du scale-out.

Deux modèles fonctionnent. Une alarme CloudWatch sur StatusCheckFailed_System associée à l’action de récupération EC2 préserve l’ID de l’instance, l’IP privée, l’IP Elastic et les attachements EBS lors d’une défaillance de l’hôte sous-jacent. Encore plus simple : un ASG avec MinSize=MaxSize=1 s’étendant sur plusieurs AZ remplace une instance défaillante et, contrairement à l’action de récupération, peut survivre à une panne d’AZ — à condition que l’état soit externalisé hors du volume racine ou que l’AMI soit reconstructible.

Équilibreurs de charge et placement dans les subnets

L’ALB opère au niveau L7, termine les connexions HTTP/HTTPS, offre un routage basé sur l’hôte/le chemin/l’en-tête, et intègre HTTP/2, WebSockets, WAF/Cognito/OIDC. Le NLB opère au niveau L4, préserve l’IP du client, prend en charge les IP statiques et le TLS passthrough, PrivateLink, et supporte des millions de connexions par seconde. Le Gateway Load Balancer insère des appliances tierces (pare-feu, IDS) dans le chemin du trafic.

Le placement dans les subnets est là où les architectures échouent le plus souvent. Un ALB exposé sur Internet doit être attaché à des subnets publics — des subnets avec une route 0.0.0.0/0 vers une Internet Gateway — un par AZ où se trouvent les cibles. Les cibles elles-mêmes restent dans des subnets privés. Si l’ALB est placé dans des subnets privés, ou si les subnets « publics » n’ont pas de route par défaut vers une IGW, les clients subiront des délais d’attente de connexion (connection timeouts). La joignabilité des cibles exige que le groupe de sécurité de la cible autorise le trafic entrant depuis le groupe de sécurité de l’ALB sur le port cible ; aucune NAT n’est nécessaire entre l’ALB et les cibles dans le même VPC.

Client → IGW → ALB (public subnets, SG: allow 443 from 0.0.0.0/0)
              → Targets (private subnets, SG: allow 8080 from ALB-SG)

Activez les vérifications d’état ELB sur l’ASG afin que les cibles défaillantes soient remplacées, et non simplement désenregistrées. L’équilibrage de charge interzone (cross-zone load balancing) (par défaut sur l’ALB, en option sur le NLB) répartit uniformément les requêtes quel que soit le nombre d’instances par AZ. Route 53 doit résoudre vers l’ALB via un enregistrement d’alias (ou une politique de routage pondérée/par latence sur plusieurs ALB) — ne pointez jamais Route 53 vers les IP d’instances EC2 individuelles, car une instance défaillante continuerait de recevoir du trafic jusqu’à l’expiration du TTL et l’instance de remplacement de l’ASG aurait une IP différente.

Modèles d’achat et flottes d’instances mixtes

Le choix du modèle d’achat est le levier le plus important pour réduire les dépenses EC2, indépendamment du modèle d’architecture.

La stratégie rationnelle : charge de base sur des Reserved Instances ou un Savings Plan, pics sur On-Demand, travail tolérant aux pannes sur Spot. Dans un ASG, cela s’exprime par une politique d’instances mixtes :

MixedInstancesPolicy:
  LaunchTemplate:
    LaunchTemplateSpecification:
      LaunchTemplateId: lt-0abc123
      Version: $Latest
    Overrides:
      - InstanceType: m5.large
      - InstanceType: m5a.large
      - InstanceType: m6i.large
      - InstanceType: m6a.large
  InstancesDistribution:
    OnDemandBaseCapacity: 4          # covered by Savings Plan
    OnDemandPercentageAboveBaseCapacity: 20
    SpotAllocationStrategy: price-capacity-optimized

La diversification des types d’instances approfondit le pool Spot et réduit les interruptions corrélées. price-capacity-optimized (ou capacity-optimized) équilibre le prix avec la profondeur du pool afin que les instances soient moins susceptibles d’être récupérées.

Spot est approprié pour les charges de travail sans état, pouvant être sauvegardées (checkpointable), réessayées ou redondantes horizontalement : workers web derrière un ALB, tâches Batch avec relance automatique, exécuteurs Spark, runners CI. Il n’est pas approprié comme seule capacité pour les services critiques toujours actifs, les bases de données primaires avec état, ou les nœuds maîtres sans chemin de récupération — un préavis de deux minutes ne peut garantir un arrêt sécurisé, et la récupération corrélée à l’échelle de la flotte d’un type d’instance spécifique est un mode de défaillance réel. Lorsque l’exigence stipule « ne doit pas être interrompu », Spot est disqualifié.

Le piège inverse consiste à appliquer des RI ou des Savings Plans à des charges de travail réellement variables : vous payez l’engagement horaire, qu’il soit utilisé ou non. Ainsi, une charge de travail fonctionnant 40 heures par semaine avec un engagement de 168 heures gaspille 76 % de la réservation. Lorsque c’est la capacité elle-même — et non le prix — qui est la préoccupation (pic événementiel, reprise après sinistre), utilisez une On-Demand Capacity Reservation : une pure garantie de capacité au niveau d’une AZ aux tarifs On-Demand, combinable avec un Savings Plan pour obtenir la réduction.

Calcul (Compute) Serverless : Lambda et Fargate

Le Serverless déplace la gestion de la capacité vers la plateforme. Lambda convient aux tâches événementielles de courte durée : déclencheurs S3 ObjectCreated, DynamoDB Streams, consommateurs SQS à faible volume, backends API Gateway, logique de liaison (glue logic). La mémoire (128 Mo – 10 240 Mo) provisionne le CPU proportionnellement, donc augmenter la mémoire réduit souvent le coût en raccourcissant la durée. Des limites strictes définissent son champ d’application : exécution maximale de 15 minutes, 10 Go de mémoire, 10 Go dans /tmp, déploiement décompressé de 250 Mo (ou 10 Go via une image de conteneur), charge utile synchrone de 6 Mo. Utiliser Lambda pour un transcodage vidéo de 30 minutes, un ETL de plusieurs heures ou un entraînement GPU est une erreur d’architecture — la fonction expire en cours de tâche et la logique de relance ne fait que multiplier le gaspillage. Pour les chemins sensibles à la latence, atténuez les démarrages à froid (cold starts) et le temps d’initialisation des ENI attachées à un VPC avec la Provisioned Concurrency.

Fargate exécute des conteneurs sans gérer les hôtes EC2. C’est le bon choix lorsque les tâches dépassent 15 minutes, nécessitent des runtimes personnalisés ou s’intègrent à l’orchestration ECS/EKS mais que l’équipe ne veut pas gérer la capacité. Fargate est plus cher par vCPU-heure que EC2 Spot, donc lorsque l’utilisation en régime permanent est élevée et prévisible, un ASG à instances mixtes avec Spot sur ECS est moins coûteux. Pour un trafic en rafales ou imprévisible, la facturation à la seconde de Fargate l’emporte.

Pour l’orchestration de nombreuses fonctions Lambda, Step Functions est préférable à l’enchaînement via SNS/SQS car il offre un historique d’exécution visuel, une sémantique de relance, une gestion centralisée des erreurs et un état durable. Les workflows Standard sont facturés par transition d’état et peuvent durer jusqu’à un an ; les workflows Express sont optimisés pour le traitement d’événements à haut volume et de courte durée.

Pour la parallélisation (fan-out) de milliers de tâches conteneurisées paramétrées — génomique, Monte Carlo, ETL — AWS Batch gère la mise en file d’attente, la résolution des dépendances, les relances et le provisionnement sur des instances EC2 gérées, Spot ou Fargate. Les tâches font référence à une définition de tâche (conteneur + vCPU/mémoire + rôle IAM) et Batch les optimise (bin-packs) sur des instances de taille appropriée. Step Functions orchestre fréquemment Batch, Lambda et ECS au sein d’une seule machine à états.

Elastic Beanstalk

Beanstalk est un PaaS géré qui provisionne l’ALB, l’ASG, les instances EC2 et éventuellement RDS à partir d’un paquet applicatif. Il prend en charge les déploiements de type rolling, rolling-with-additional-batch, immutable et blue/green avec une intégration CloudWatch. Les politiques de mise à l’échelle sont exposées comme des options d’environnement (métrique, seuils, min/max). Comme Beanstalk utilise par défaut des types d’instances à capacité extensible (burstable), l’activation du mode T-unlimited est la solution simple pour une saturation brève du CPU. Les actions de mise à l’échelle planifiées s’attachent à l’ASG géré par Beanstalk comme n’importe quel autre. Choisissez Beanstalk lorsque l’équipe souhaite une topologie d’application web standard sans avoir à créer manuellement des modèles CloudFormation et lorsque les mises à jour progressives (rolling updates) et les paquets versionnés correspondent à la cadence de livraison.

Gestion de parc avec Systems Manager

Les modèles basés sur SSH et les bastions sont fragiles et coûteux à sécuriser. AWS Systems Manager les remplace. L’agent SSM (préinstallé sur Amazon Linux 2, Ubuntu, Windows) ainsi qu’un profil d’instance accordant AmazonSSMManagedInstanceCore sont tout ce qui est nécessaire.

• Run Command exécute des scripts shell/PowerShell sur des parcs d’instances identifiées par des tags, avec une sortie consolidée.
• Session Manager ouvre des shells interactifs via l’API AWS — pas de port 22 entrant, pas de bastion, authentification IAM complète, sessions journalisées dans S3 ou CloudWatch Logs.
• Patch Manager applique des correctifs de système d’exploitation selon un calendrier en utilisant des fenêtres de maintenance.

aws ssm send-command \
  --targets Key=tag:Env,Values=prod \
  --document-name AWS-RunShellScript \
  --parameters 'commands=["yum -y update"]'

Automatisation du démarrage/arrêt planifié

Pour les instances EC2 et RDS hors production qui doivent être arrêtées en dehors des heures de bureau, le modèle nécessitant peu de maintenance est EventBridge Scheduler → Lambda. Une règle cron (cron(0 19 ? * MON-FRI *)) invoque une fonction Lambda qui arrête les ressources taguées ; une seconde règle à 07:00 les démarre.

import boto3
ec2 = boto3.client('ec2'); rds = boto3.client('rds')

def handler(event, _):
    action = event['action']  # 'start' or 'stop'
    ids = [i['InstanceId'] for r in ec2.describe_instances(
        Filters=[{'Name':'tag:AutoStop','Values':['true']}]
    )['Reservations'] for i in r['Instances']]
    getattr(ec2, f'{action}_instances')(InstanceIds=ids)
    for db in rds.describe_db_instances()['DBInstances']:
        if any(t['Key']=='AutoStop' and t['Value']=='true' for t in db['TagList']):
            getattr(rds, f'{action}_db_instance')(DBInstanceIdentifier=db['DBInstanceIdentifier'])

Cette solution est serverless, n’a pas de parc à patcher et s’adapte en fonction des tags. La solution AWS Instance Scheduler fonctionne de manière équivalente. Une subtilité : une instance RDS arrêtée redémarre automatiquement après sept jours, donc la planification d’arrêt doit être récurrente pour l’arrêter à nouveau. Combiné avec des ASG dont les actions planifiées réduisent la capacité à zéro le week-end, le coût des heures d’inactivité approche de zéro.

Pièges réseau liés à la mise à l’échelle du calcul

Positionnement de la NAT Gateway. Une passerelle NAT réside dans une seule AZ. Un parc s’étendant sur trois AZ qui route tout son trafic sortant via une seule NAT dans us-east-1a paie des frais de transfert inter-AZ sur chaque paquet provenant de us-east-1b/us-east-1c, et perd complètement sa connectivité sortante en cas de dégradation de us-east-1a. Le modèle correct est d’avoir une passerelle NAT par AZ, avec la table de routage de chaque sous-réseau privé pointant vers la NAT de sa propre AZ. Cela localise le trafic et supprime le mode de défaillance lié à une seule AZ.

Instances NAT. Une seule instance NAT basée sur EC2 devient un goulot d’étranglement en termes de bande passante et de PPS (paquets par seconde) à mesure que le parc grandit, et constitue un SPOF (point de défaillance unique). Les NAT Gateways managées peuvent atteindre 100 Gbit/s par passerelle. Pour le trafic destiné aux services AWS, les VPC endpoints (Gateway pour S3/DynamoDB, Interface pour les autres) contournent entièrement la NAT, réduisant les coûts et éliminant le risque de saturation lors des événements de mise à l’échelle.

Pièges de conception récurrents

• Les ASG mono-AZ ne peuvent pas survivre à une panne d’AZ — attachez toujours des sous-réseaux d’au moins deux AZ (trois pour les systèmes à quorum), et maintenez MinSize ≥ 2.
• Partir du principe que toute charge de travail peut être mise à l’échelle horizontalement. Les applications qui conservent un état, à écriture unique ou avec des licences non clusterisables se comportent moins bien sous un ASG. Utilisez d’abord la récupération automatique ou refactorisez.
• La mise à l’échelle réactive pour des pics prévisibles produit le symptôme de « lenteur pendant les 2-3 premières heures ». Utilisez la mise à l’échelle planifiée ou prédictive pour préchauffer.
• Mettre à l’échelle sur le CPU alors que le CPU n’est pas la contrainte. Publiez une métrique qui reflète le véritable goulot d’étranglement — profondeur de la file d’attente, temps de réponse, nombre de connexions.
• Le Simple Scaling et les launch configurations sont obsolètes — préférez le target tracking et les launch templates.
• Les health checks TCP uniquement sur des applications HTTP laissent des instances défectueuses en rotation. Utilisez des vérifications HTTP (via un ALB, ou les vérifications en mode HTTP du NLB).
• Utiliser Spot pour des charges de travail avec état ou qui ne doivent pas être interrompues — Spot exige des workers remplaçables et capables de créer des points de contrôle.
• Utiliser des Reserved Instances ou des Savings Plans sur des charges de travail réellement variables — l’engagement non utilisé est un pur gaspillage ; réduisez plutôt les coûts avec le right-sizing et Spot.
• Faire pointer Route 53 vers des adresses IP d’EC2 individuelles — routez vers l’alias de l’ALB pour que le DNS reflète les changements du parc.
• Considérer le stockage d’instance comme durable — les données disparaissent à l’arrêt, à la terminaison ou en cas de défaillance de l’hôte.
• Ignorer la latence du chargement différé (lazy-load) après une restauration de snapshot ou le lancement d’une AMI — activez Fast Snapshot Restore dans les AZ cibles.

Tous les domaines · Conteneurs et orchestration →

Entraînez-vous sur ces questions → · Tests chronométrés sur ExamRoll.io →

Parcourir Amazon →