3.3 - Stratégies de déploiement, AMI et launch templates
L'objectif 3.3 de l'AWS SysOps Administrator couvre le déploiement et la gestion de configuration. Tu prépares des images de référence en AMI, tu les copies et partages entre régions, et tu automatises des pipelines d'images durcies avec EC2 Image Builder. Les launch templates capturent les réglages et versions d'instance pour l'Auto Scaling et sont préférés aux launch configurations. Les stratégies de déploiement arbitrent interruption, coût et rapidité de rollback : all-at-once est rapide mais risqué, rolling et rolling avec lot additionnel remplacent les instances par vagues, immutable et blue-green créent de nouvelles instances puis basculent pour un rollback propre. Elastic Beanstalk expose ces politiques et les .ebextensions, et CodeDeploy décale le trafic par étapes canary ou linéaires pour Lambda et ECS. Attends-toi à des mises en situation sur la bonne stratégie de déploiement ou fonctionnalité de provisionnement.
Standardiser des images durcies = EC2 Image Builder. Rollback le plus propre = immutable ou blue-green (nouvelles instances, bascule). L'Auto Scaling veut un launch template, pas une launch configuration.
Questions d'entraînement
1. Dans CloudFormation, quel type de ressource définit une alarme CloudWatch sur une métrique ?
- AWS::CloudWatch::Alarm (bonne réponse)
- AWS::CloudWatch::CompositeMetricThresholdRule
- AWS::Logs::MetricAlarm
- AWS::AutoScaling::AlarmPolicy
AWS::CloudWatch::Alarm est le type de ressource pour les alarmes métriques et composites dans CloudFormation. Les autres noms ne sont pas de vrais types de ressources.
2. Vous voulez qu'un changement d'état d'alarme déclenche une fonction Lambda pour un traitement personnalisé. Quel service route l'événement de changement d'état vers Lambda ?
- Amazon EventBridge (bonne réponse)
- Amazon SNS livrant directement dans la console d'édition Lambda
- AWS Config enregistrant l'état comme un changement de conformité
- CloudTrail rejouant l'événement d'alarme directement vers la fonction
Les changements d'état d'alarme CloudWatch sont émis comme événements qu'EventBridge peut matcher via une règle et router vers une cible Lambda. SNS peut aussi invoquer Lambda, mais l'éditeur console n'est pas une cible ; Config et CloudTrail ne routent pas ces événements.
3. Dans CloudFormation vous créez un AWS::Logs::LogGroup. Quelle propriété définit la durée de conservation des événements ?
- ExpireEventsAfter, qui accepte une durée comme 30d
- L'attribut DeletionPolicy fixé à un nombre entier de jours
- RetentionInDays, mis à une valeur permise comme 14, 30 ou 90 (bonne réponse)
- Une référence KmsKeyId qui contrôle aussi en secret la durée des logs
RetentionInDays sur AWS::Logs::LogGroup n'accepte que des valeurs permises (1..3653) et contrôle l'expiration. ExpireEventsAfter n'existe pas, DeletionPolicy gère la suppression de la stack, et KmsKeyId ne fait que chiffrer.
4. Des serveurs on-premises doivent pousser des logs vers CloudWatch Logs. Quelle approche d'identifiants l'agent utilise-t-il là ?
- Les clés d'un IAM user dédié placées dans un fichier d'identifiants de l'agent (bonne réponse)
- L'instance profile EC2 automatiquement attaché aux machines on-prem
- Aucun identifiant, car le trafic on-prem vers CloudWatch est toujours de confiance
- Les clés du compte root copiées à la main sur chaque serveur on-premises
Hors EC2 il n'y a pas d'instance profile ; l'agent on-prem utilise donc les clés d'un IAM user dédié à moindre privilège dans un fichier d'identifiants (ou mieux, un rôle via activation hybride SSM). Les instance profiles sont propres à EC2, des identifiants sont toujours requis, et les clés root sont à proscrire.
5. Quand une alarme de canary se déclenche, vous voulez qu'un runbook redémarre automatiquement le service. Qu'exécute le runbook ?
- Un document Automation de Systems Manager (bonne réponse)
- Un widget texte de dashboard listant les étapes
- Une politique IAM attachée au rôle du canary
- Un metric filter transformant des logs en métrique
Un document Automation de Systems Manager définit les étapes du runbook (comme redémarrer un service) et peut être déclenché par l'alarme via EventBridge pour l'auto-remédiation. Un widget texte n'affiche que des consignes, une politique IAM accorde des droits, et un metric filter produit des métriques, aucun n'exécutant d'actions.
6. EventBridge Scheduler propose une 'flexible time window'. À quoi sert-elle ?
- Répartit les invocations dans une fenêtre pour lisser les pics (bonne réponse)
- Garantit que la cible s'exécute à la seconde exacte configurée, toujours
- Prolonge la rétention du schedule afin de pouvoir rejouer les événements plus tard
- Empêche le schedule de se déclencher hors des heures ouvrables normales
Une flexible time window permet à Scheduler de démarrer l'invocation à un moment aléatoire dans la fenêtre, lissant les pics de charge sur de nombreux schedules. Elle ne garantit pas la seconde exacte, ne prolonge pas la rétention et n'impose pas d'heures de bureau.