2.1 - Choisir les services de calcul, stockage et données

1. Une équipe veut des déploiements blue/green pour un service ECS afin qu'une mauvaise version soit annulée en secondes sans redémarrage en place. Quel service orchestre ce basculement ?

• AWS Systems Manager Run Command poussant des scripts sur chaque tâche
• AWS CodeDeploy avec un groupe de déploiement blue/green ECS (bonne réponse)
• Les lifecycle hooks d'Amazon EC2 Auto Scaling qui suspendent les lancements
• Les règles AWS Config exécutant des remédiations automatiques

CodeDeploy pilote les déploiements blue/green ECS : il monte un nouveau task set, bascule le trafic via le load balancer, et peut annuler instantanément en rebasculant. Run Command exécute des scripts, les hooks ASG suspendent les événements de scaling, et Config remédie aux dérives de conformité.

2. Une flotte web sans état sur EC2 doit maintenir l'utilisation CPU moyenne autour de 50 % pendant que le trafic monte et descend au fil de la journée, le groupe ajustant sa capacité de lui-même. Quelle politique d'Auto Scaling répond le plus simplement à ce besoin ?

• Une politique de target tracking sur l'utilisation CPU moyenne (bonne réponse)
• Un jeu de politiques de step scaling avec plusieurs seuils d'alarme CloudWatch réglés manuellement
• Une action planifiée qui ajoute des instances chaque matin et les retire la nuit
• Une politique de simple scaling avec un cooldown fixe après chaque ajustement

Le target tracking maintient une métrique choisie (ici le CPU) à une valeur cible en calculant automatiquement la capacité nécessaire, comme un thermostat. Le step scaling exige des seuils réglés à la main, les actions planifiées ne conviennent qu'à des horaires connus, et le simple scaling réagit une alarme à la fois avec des cooldowns.

3. Une application connaît chaque jour ouvré à 09h00 une hausse de trafic brutale et récurrente, et la mise à l'échelle réactive seule la laisse sous-provisionnée durant les premières minutes le temps que les nouvelles instances démarrent. Qu'est-ce qui supprime le mieux ce trou de démarrage matinal ?

• Baisser la valeur du target tracking pour que le groupe réagisse plus tôt au CPU
• Agrandir le type d'instance pour qu'il en faille moins au pic
• Activer le predictive scaling pour pré-provisionner la capacité avant la hausse prévue (bonne réponse)
• Raccourcir la période de grâce des health checks pour que les instances entrent en service plus vite

Le predictive scaling applique un modèle d'apprentissage aux historiques pour lancer la capacité avant une hausse récurrente, comblant le délai de démarrage que les politiques réactives ne peuvent éviter. Baisser la cible réagit toujours après l'arrivée de la charge, de plus grosses instances démarrent quand même, et une grâce plus courte risque de router vers des instances non prêtes.

4. Un Auto Scaling group d'instances EC2 avec un démarrage applicatif long et lourd monte en charge trop lentement lors des pics, et l'équipe a aussi besoin que chaque instance soit drainée proprement avant la fin pour que le travail en cours se termine. Quelles DEUX fonctionnalités traitent ces problèmes ? (Choisissez DEUX réponses.)

• Augmenter la taille maximale du groupe pour que plus d'instances puissent finir par se lancer
• Un warm pool d'instances pré-initialisées maintenues prêtes à servir lors d'un pic (bonne réponse)
• Un lifecycle hook de terminaison qui retarde l'arrêt jusqu'au drainage des connexions (bonne réponse)
• Un cooldown par défaut plus court pour enchaîner les actions de mise à l'échelle

Un warm pool garde des instances déjà démarrées pour qu'elles entrent en service en quelques secondes lors d'un pic, et un lifecycle hook de terminaison suspend l'arrêt pour que les requêtes en cours se drainent avant le retrait de l'instance. Augmenter la taille max n'accélère pas chaque lancement, et un cooldown plus court ne fait que déclencher les actions plus souvent sans régler le démarrage lent ni la terminaison brutale.

5. Une application web stocke l'état de session utilisateur en mémoire sur chaque instance EC2, si bien que la réduction d'échelle pendant les périodes calmes déconnecte les utilisateurs quand leur instance se termine. Quelle est la meilleure conception pour laisser le tier se mettre à l'échelle librement sans perdre les sessions ?

• Activer les sticky sessions sur le load balancer pour qu'un utilisateur revienne toujours sur la même instance
• Augmenter le cooldown de scale-in pour que les instances soient terminées beaucoup moins souvent
• Prendre des AMI fréquentes de chaque instance pour restaurer la mémoire de session après terminaison
• Stocker l'état de session dans Amazon ElastiCache afin que les instances deviennent sans état (bonne réponse)

Externaliser l'état de session vers ElastiCache (Redis) rend les instances sans état, donc n'importe quelle instance peut servir n'importe quel utilisateur et la réduction d'échelle ne perd jamais de session. Les sticky sessions lient toujours un utilisateur à une instance susceptible d'être terminée, des cooldowns plus longs ne font que retarder le problème, et les AMI ne restaurent pas les sessions vivantes en mémoire.

6. Un cluster de gestion de contenu sous Linux a besoin d'un système de fichiers POSIX partagé, monté en lecture-écriture par des centaines d'instances EC2 sur plusieurs zones de disponibilité, avec une capacité qui s'ajuste automatiquement. Quel service convient ?

• Amazon Elastic File System (EFS) (bonne réponse)
• Un volume Amazon EBS io2 attaché à la flotte
• Amazon FSx for Windows File Server
• Un bucket S3 monté via un pilote FUSE tiers

EFS est un système de fichiers NFS géré et élastique que de nombreuses instances Linux sur plusieurs AZ peuvent monter en lecture-écriture simultanément, croissant automatiquement. EBS s'attache à peu d'instances dans une AZ, FSx for Windows sert des charges SMB/Windows, et un montage FUSE de S3 n'est pas un vrai système POSIX.