2.7 - Stratégies de déploiement et services spécialisés
L'objectif 2.7 de l'AWS Solutions Architect Professional couvre les stratégies de déploiement et les services spécialisés. Tu bascules une part du trafic Lambda vers une nouvelle version avec une configuration canary AWS CodeDeploy sur l'alias et un rollback automatique en cas d'erreurs, et le deployment circuit breaker ECS stoppe et inverse automatiquement un déploiement raté. Les cibles spécialisées comptent : Amazon MSK garde les API et connecteurs Kafka inchangés, Amazon Timestream stocke des milliards de relevés de séries temporelles avec un cycle de vie automatique vers un stockage moins cher, des clusters EMR transitoires avec des task nodes Spot exécutent à bas coût les jobs big-data interruptibles, et DynamoDB Streams déclenche une Lambda d'analytique en quelques secondes après un changement. AWS Budgets alerte avant que la dépense ne franchisse un seuil, l'embarquement QuickSight avec row-level security et namespaces isole chaque locataire SaaS, la Cross-Region Replication standard avec RTC seulement sur les objets à SLA strict équilibre le coût, et un Network Load Balancer donne des IP statiques, une latence ultra-basse et des IP source préservées sur du TCP brut. Attends-toi à des mises en situation sur un déploiement canary, un déclencheur de série temporelle ou de streaming, ou des tableaux de bord multi-locataires, et à choisir la bonne stratégie ou le bon service.
Bascule progressive du trafic avec rollback auto sur Lambda = canary CodeDeploy sur l'alias. Stopper et inverser auto un déploiement ECS raté = deployment circuit breaker avec rollback. Réagir en quelques secondes à un changement d'item DynamoDB = déclencheur DynamoDB Streams.
Questions d'entraînement
1. Un système événementiel doit diffuser un même événement à plusieurs consommateurs indépendants, chacun avec ses propres reprises et dead-letter, et ajouter de nouveaux consommateurs sans toucher aux producteurs. Que doit utiliser l'architecte ?
- Une unique file SQS que tous les consommateurs interrogent
- Un fan-out SNS (ou EventBridge) vers une file SQS par consommateur (bonne réponse)
- Un flux Kinesis à un seul shard lu par tous les consommateurs
- Une invocation Lambda directe du producteur vers chaque consommateur
Un fan-out SNS ou EventBridge vers une file SQS dédiée par consommateur découple producteurs et consommateurs : chaque file a ses reprises et sa DLQ, et de nouveaux abonnés s'ajoutent sans modifier les producteurs. Une file partagée fait se disputer les messages ; l'invocation directe couple le producteur à chaque consommateur.
2. Une équipe déploie une fonction Lambda derrière un alias et veut que chaque version bascule 10 % du trafic vers la nouvelle version pendant dix minutes, puis le reste, avec un rollback automatique si les erreurs augmentent. Quelle approche fournit ce déploiement canary ?
- Publier une nouvelle version et repointer l'alias dessus d'un seul coup
- AWS CodeDeploy avec une configuration de bascule de trafic canary sur l'alias Lambda (bonne réponse)
- Déployer le nouveau code sur $LATEST pour que les clients l'appellent immédiatement
- Créer une deuxième fonction et répartir le trafic avec un enregistrement pondéré Route 53
CodeDeploy bascule un pourcentage pondéré du trafic de l'alias vers la nouvelle version selon un calendrier canary ou linéaire et fait un rollback automatique sur alarme CloudWatch, ce qui correspond exactement à un déploiement 10 % puis le reste. Repointer l'alias d'un coup est une bascule brutale, $LATEST contourne la bascule contrôlée, et la pondération Route 53 est grossière au niveau DNS et non liée aux alarmes Lambda.
3. Une API critique pour le chiffre d'affaires sur ECS derrière un Application Load Balancer doit tester une nouvelle version sur une petite fraction d'utilisateurs réels avant la mise en service complète, en gardant l'ancienne version instantanément disponible pour un rollback. L'équipe veut le style de déploiement le plus sûr. Lequel convient le mieux ?
- Une mise à jour rolling qui remplace les tâches en place quelques-unes à la fois
- Un redémarrage en place de toutes les tâches après le push de la nouvelle image
- Blue/green avec CodeDeploy basculant un pourcentage canary entre deux target groups (bonne réponse)
- Un basculement unique du listener ALB vers un service tout neuf sans fraction de test
Le blue/green avec CodeDeploy exécute la nouvelle version dans un target group séparé, bascule une fraction canary du trafic réel pour la valider, et fait un rollback instantané en rebasculant vers l'ancien groupe intact. Le rolling et le redémarrage en place mutent la version active (pas de rollback instantané), et un basculement unique du listener saute complètement le test canary.
4. Un tier web EC2 géré par Elastic Beanstalk doit déployer de nouvelles versions sans interruption et garantir qu'un déploiement en échec ne laisse aucune instance partiellement mise à jour mélangeant ancien et nouveau code. Quelle politique de déploiement répond à cela ?
- Le déploiement immutable, qui lance un nouveau jeu d'instances et ne bascule qu'en cas de succès (bonne réponse)
- Le déploiement all-at-once, qui met à jour toutes les instances du groupe simultanément
- Le déploiement rolling, qui met à jour les instances par petits lots en place
- Le rolling avec lot supplémentaire, mettant à jour les instances existantes après en avoir ajouté un lot
Le déploiement immutable lance un jeu parallèle d'instances neuves avec la nouvelle version et ne bascule le trafic que si elles passent les health checks, donc un échec est jeté sans instances de versions mélangées. All-at-once cause une interruption, et les deux variantes rolling mettent à jour les instances existantes en place, risquant une flotte mélangée ou partiellement mise à jour en cas d'échec.
5. Un déploiement rolling ECS derrière un ALB laisse parfois tourner une nouvelle version défectueuse parce que des tâches en échec passent le health check basique du conteneur mais renvoient des erreurs aux utilisateurs, et personne ne fait le rollback rapidement. Quelle fonctionnalité ECS arrête et inverse automatiquement un tel déploiement défaillant ?
- Un pourcentage minimum de tâches saines ECS plus élevé pour garder plus d'anciennes tâches actives
- Une surveillance manuelle des tableaux de bord CloudWatch pendant chaque fenêtre de déploiement
- Un Lambda planifié qui redéploie la définition de tâche précédente chaque nuit
- Le deployment circuit breaker ECS avec rollback lié aux health checks en échec (bonne réponse)
Le deployment circuit breaker ECS surveille les health checks pendant un déploiement rolling et, en cas d'échecs répétés, arrête et revient automatiquement au dernier task set sain sans action humaine. Un pourcentage minimum de tâches saines plus élevé ne fait que maintenir la capacité, la surveillance manuelle n'est pas automatique, et un redéploiement nocturne est bien trop lent pour protéger un déploiement en cours.
6. Un cluster Aurora MySQL sert une charge de reporting à forte lecture dont le trafic varie fortement sur la journée. L'équipe veut que la capacité de lecture croisse et décroisse automatiquement sans gérer manuellement le nombre de réplicas. Que faut-il configurer ?
- Aurora Auto Scaling des Aurora Replicas piloté par une métrique cible (bonne réponse)
- Un unique très grand Aurora Replica dimensionné manuellement pour couvrir tout le pic quotidien
- Des tables DynamoDB on-demand reproduisant les requêtes de reporting
- Aurora Global Database avec une Région secondaire pour les rapports
Aurora Auto Scaling ajoute et retire des Aurora Replicas automatiquement selon une métrique cible comme le CPU moyen ou les connexions, ajustant la capacité à la charge de lecture variable. Un réplica fixe et grand surpaie aux creux, DynamoDB n'est pas relationnel pour ces requêtes, et Global Database vise le multi-Région, pas la mise à l'échelle locale.