AWS Solutions Architect — Conception d’architectures résilientes : 80 questions d'entraînement

Step 1: Déterminer les exigences RTO/RPO pour un contenu statique. Pour atteindre un RTO < 60s, il faut que la couche de distribution puisse basculer automatiquement et rapidement sans dépendre de changements DNS à longue durée de vie. Pour un RPO proche de zéro, les objets doivent être répliqués rapidement vers une région secondaire.

Step 2: Évaluer les services. Amazon CloudFront offre la possibilité d'Origin Failover (configuration d'une origine primaire et d'une origine secondaire) et effectue la bascule automatiquement au niveau du CDN sans attendre les TTL DNS. S3 Cross-Region Replication (CRR) réplique les objets du bucket primaire vers un bucket secondaire de façon asynchrone mais avec une latence généralement faible pour les nouveaux objets, assurant un RPO proche de zéro pour la plupart des cas d'usage. Ensemble, CloudFront + CRR minimise le RTO (basculement automatique, distribution globale) et maintient les objectifs de RPO.

Step 3: Considérations opérationnelles et coûts. Activez CRR et versioning sur les buckets, configurez CloudFront avec Origin Failover et conservez des politiques de sécurité adaptées (IAM, politique bucket, chiffrement). Le coût supplémentaire provient des requêtes CloudFront, du trafic inter-région pour CRR et du stockage supplémentaire dans le bucket secondaire. Toutefois, ce coût est souvent inférieur à celui d'un déploiement actif-actif en termes d'infrastructure. Trap: Une erreur fréquente est de penser que la réplication S3 est synchrone et garantie « zéro » RPO. CRR est asynchrone et peut présenter un léger délai ; pour la majorité des objets récents ce délai est faible, mais il n'est pas strictement synchrone. De plus, confondre failover DNS (Route 53) avec failover applicatif (CloudFront origin failover) conduit à des RTO plus élevés à cause de TTL DNS. Why each wrong answer fails: Option 1 (snapshots S3) ne tient pas : S3 n'utilise pas de « snapshots » comme RDS; restaurer objets ou compter sur backups manuels introduit un RTO élevé. Option 3 (Route 53 Failover DNS) est plus lent car le basculement dépend des TTL DNS et de la propagation; il peut dépasser 60s et n'est pas aussi transparent que CloudFront Origin Failover. Option 4 (deux sites actifs et DB synchronisée) offre un RTO faible mais engendre un coût significativement plus élevé et une complexité accrue pour synchroniser l'état; pour un site statique, c'est un surcoût inutile. Ainsi, CloudFront + S3 CRR avec Origin Failover offre le meilleur compromis RTO/RPO/coût pour du contenu statique.

Step 1 (AWS reasoning): Un Auto Scaling Group configuré pour utiliser subnets dans plusieurs AZs et avec une stratégie qui maintient la capacité minimale répartie garantit qu'une défaillance AZ ne supprime pas toute la capacité applicative. L'ASG recrée automatiquement des instances dans les AZ saines afin de respecter le SLA. Step 2 (AWS reasoning): Les Warm Pools (pools « chauds ») gardent des instances pré-lancées ou pré-initialisées prêtes à être jointes au groupe en quelques secondes, accélérant drastiquement le remplacement d'instances par rapport à l'initialisation standard. Cela réduit le temps où la capacité est insuffisante après une panne. Step 3 (AWS reasoning): Le scaling programmé est utile pour des patterns prévisibles mais ne remplace pas la capacité de répondre automatiquement à une panne AZ imprévue. De plus, désactiver les health checks ELB empêche le retrait automatique d'instances réellement défaillantes, ce qui dégrade la résilience et l'expérience utilisateur. Pourquoi chaque mauvais choix échoue: - Option 2 (Scaling programmé uniquement): Le scheduled scaling réagit à des patterns connus (par ex. heures de pointe) mais ne garantit pas la disponibilité en cas de défaillance AZ non planifiée ; il n'est pas conçu pour le remplacement rapide d'instances tombées. - Option 4 (Désactiver les health checks ELB): Cela empêche l'ELB/ASG de détecter et remplacer automatiquement des instances dégradées. Cela augmente le risque que le trafic soit envoyé vers des instances défaillantes, violant le SLA. Trap: common AWS exam misconception: Beaucoup confondent l'augmentation du nombre d'instances avec la résilience AZ. Avoir plus d'instances dans une seule AZ n'améliore pas la tolérance aux pannes multi-AZ. Un autre piège est de penser que la mise à l'échelle programmée remplace la nécessité d'une réponse automatique aux pannes ; elle ne traite pas les interruptions imprévues. Conclusion: Pour haute disponibilité et temps de remplacement très courts, combinez un ASG multi-AZ (capacité minimale répartie) et Warm Pools pour remplacer rapidement des instances endommagées et maintenir le SLA.

Step 1: Déterminer les garanties requises — persistance, livraison au moins une fois (at-least-once), gestion des erreurs (DLQ) et résilience multi-AZ. Amazon SQS Standard est un service de file managée durable, hautement disponible et multi-AZ qui garantit au moins une livraison et permet de configurer une Dead-Letter Queue pour messages non traitables. EventBridge agit comme un bus d’événements géré avec mécanismes de retry et intégrations natives vers cibles (Lambda, SQS, SNS, etc.) et peut être configuré pour livrer vers une DLQ si la cible échoue.

Step 2: Architecturer pour la résilience — utiliser SQS pour découpler producteurs/consommateurs, configurer une DLQ pour isoler messages qui dépassent un nombre de tentatives, et employer EventBridge pour router des événements complexes, appliquer règles et gérer les retries automatiques. Les deux services sont managés, scalables et multi-AZ par défaut, ce qui réduit la charge opérationnelle.

Step 3: Opérations et compromis — SQS Standard autorise une latence très faible et des débits élevés ; il n’assure pas l’ordre strict (FIFO existe pour besoins d’ordre strict). EventBridge permet le routage par règle et la persistance temporaire pour la réémission. Coût : SQS facture par requêtes et volume, EventBridge par événement ; choisir selon volume et complexité logique. Sécurité : appliquer IAM, encryption (SSE-KMS), VPC endpoints si nécessaire. Trap: Penser que SNS seul garantit la durabilité et le stockage durable des messages — SNS est un service de pub/sub push qui n’offre pas par défaut une file durable côté consommateur ; si la cible est indisponible, les messages peuvent échouer sauf si on combine SNS avec SQS (fan-out vers des queues). De plus, SNS ne fournit pas DLQ native dans tous les cas sans SQS. Why each wrong answer fails: - Amazon SNS seul pour la distribution des messages : SNS est excellent pour la diffusion en fan-out et notifications push, mais il n’offre pas intrinsèquement le stockage durable côté consommateur et la gestion fine des réessais/DLQ (sauf si couplé à SQS ou Lambda). Pour garantir la persistance et la capacité de relire/inspecter des messages échoués, SNS seul est insuffisant. - Amazon MQ (broker managé compatible ActiveMQ) pour la compatibilité des applications existantes : Amazon MQ est utile si vous devez migrer une application existante basée sur JMS/AMQP et conserver la compatibilité du broker. C’est managé et durable, mais il représente souvent un coût et une complexité opérationnelle plus élevés qu’une solution native serverless (SQS/EventBridge) et n’offre pas la même simplicité de scalabilité serverless. Pour des architectures cloud-native recherchant scalabilité, faible opérationnel et intégrations managées, SQS/EventBridge sont préférables. Amazon MQ reste une bonne option seulement pour compatibilité d’existant. En résumé : SQS Standard + DLQ et EventBridge couvrent les besoins de durabilité, livraison au moins une fois, réessais gérés et isolation des messages problématiques, tout en offrant une solution managée, résiliente et scalable.

Step 1: Exigences AWS reasoning — Besoin de résilience en cas de panne d'une AZ et d'une capacité d'adaptation automatique à la charge (scaling horizontal). La solution doit aussi réduire la gestion opérationnelle pour l'entreprise.

Step 2: Capabilités des services — Un Auto Scaling Group (ASG) répartit automatiquement les instances EC2 sur plusieurs subnets (AZs) si configuré correctement et peut lancer/terminer des instances selon des politiques de scaling. Un Application Load Balancer (ALB) distribue le trafic HTTP/HTTPS sur les instances saines, effectue des vérifications de santé, et peut diriger le trafic vers d'autres AZs en cas de panne. AWS gère le service, ce qui réduit l'opérationnel.

Step 3: Mise en œuvre et trade-offs — Déployer l'ASG avec des subnets dans au moins trois AZs améliore la résilience régionale; configurer des probes de santé ALB + lifecycle hooks permet un remplacement propre des instances. Performance: scaling horizontal permet de gérer des pointes; coût: plus d'instances mais optimisation possible via policies et instance types. Sécurité: utiliser des groupes de sécurité et IAM pour limiter l'accès. Trap: croire qu'un Elastic IP ou un seul grand serveur résout la disponibilité est une erreur — un Elastic IP lié à une instance ne protège pas contre la panne d'AZ, et vertical scaling cause des limites et une fenêtre d'indisponibilité lors des montées en charge. Why each wrong answer fails: - Provisionner des instances EC2 avec Elastic IPs par AZ et configurer un script de surveillance personnalisé: solution très manuelle. Les Elastic IPs ne gèrent pas la distribution de charge ni la santé des instances. Le script personnalisé augmente la charge opérationnelle et risque d'être moins fiable que les services managés; pas d'out-of-the-box autoscaling ni de gestion fine des probes. - Déployer un seul grand EC2 dans une AZ et augmenter sa taille (vertical scaling) pendant les pics: vertical scaling ne protège pas contre la défaillance d'une AZ et provoque des interruptions lors des changements d'instance. Cela ne satisfait pas l'exigence de haute disponibilité multi-AZ. - Utiliser des tâches ECS Fargate dans une seule AZ avec un Network Load Balancer: exécuter dans une seule AZ ne répond pas au besoin de résilience multi-AZ. Bien que Fargate réduise l'opérationnel, la contrainte "une seule AZ" casse la tolérance aux pannes. De plus, NLB n'offre pas les mêmes capacités de routage HTTP que l'ALB. Conclusion: L'association ALB + Auto Scaling across AZs est le modèle managé recommandé pour une couche web stateless résiliente et élastique, minimisant la gestion tout en maximisant disponibilité et scalabilité.

Étape 1 (Step 1): Comprendre le comportement natif d'Auto Scaling. Un Auto Scaling Group peut être configuré avec plusieurs sous-réseaux (chacun mappé à une AZ) ; lorsque c'est fait, ASG tente de répartir les instances sur ces AZ. En outre, lorsqu'un ALB est associé, l'ASG peut utiliser les vérifications de santé de l'ALB pour détecter les instances non-saines et les remplacer. Étape 2 (Step 2): Implémentation pour résilience AZ. Pour garantir qu'une AZ qui devient indisponible ne provoque pas une perte de capacité durable, vous devez lister explicitement les sous-réseaux des deux AZs dans la configuration de l'ASG. L'ASG lancera des instances dans l'autre AZ selon la capacité demandée. Lier l'ASG à un ALB avec health checks améliorés assure que seules les instances en bonne santé reçoivent le trafic et déclenchent remplacement si nécessaire. Étape 3 (Step 3): Surveillance et tests. Activer la répartition dans les métriques (AZRebalance) et surveiller les alarms CloudWatch ; tester la panne d'AZ (failover planifié) pour vérifier que l'ASG rééquilibre la capacité et que l'ALB cible correctement les instances saines. Trap: Penser qu'il suffit de définir la capacité désirée dans l'ASG en une seule AZ ou de compter sur des scripts externes est une erreur fréquente. ASG ne va pas «deviner» où vous souhaitez les instances si vous ne fournissez pas les sous-réseaux et ne dépend pas d'un mécanisme appelé 'Auto Placement' pour répartir correctement la charge multi-AZ sans configuration. Pourquoi chaque mauvaise réponse échoue: 2) Déployer l'ASG dans une seule AZ et compter sur des politiques programmées nécessite une intervention manuelle ou des scripts externes pour recréer la capacité dans une autre AZ, augmentant la RTO et le risque d'erreur. 3) Laisser l'ASG sans spécifier d'AZ n'est pas une bonne pratique : l'ASG exige des sous-réseaux lors de sa création pour le placement multi-AZ ; 'EC2 Auto Placement' n'est pas un remplacement pour la configuration explicite des sous-réseaux. 4) Les lifecycle hooks servent à gérer des actions avant/après le lancement ou la terminaison (scripts d'initialisation, drain d'app), mais n'assurent pas la répartition initiale ni le basculement automatique entre AZ ; ils complètent le processus plutôt que de le remplacer. Conclusion: Configurer l'ASG avec sous-réseaux dans les deux AZ et attacher un ALB (utiliser ses vérifications de santé) est la méthode gérée et recommandée pour assurer distribution et basculement automatique de la capacité multi-AZ.

Step 1: Identifier les besoins techniques — basculement multi-région automatique, vérification d’état (health checks), et optimisation de la latence et de la résilience réseau. Route 53 répond au besoin de routage DNS, santé et basculement logique. AWS Global Accelerator fournit un plan de contrôle réseau global qui oriente le trafic utilisateur vers la région la plus saine et la plus performante via le backbone AWS, réduisant la latence et accélérant le basculement.

Step 2: Combiner les services correctement — Route 53 est le point d’entrée DNS capable d’effectuer des health checks actifs et de basculer des enregistrements vers une région de secours. Global Accelerator s’intègre avec des endpoints régionaux (ALB, NLB, EC2, IP) et propose une détection d’état côté réseau avec basculement rapide grâce à l’utilisation des Anycast et du réseau AWS. Ensemble, Route 53 gère la logique DNS et la hiérarchie de routage tandis que Global Accelerator optimise la connectivité et réduit la dépendance aux routes Internet publiques.

Step 3: Considérations coût/perf/sécurité — Global Accelerator ajoute un coût (fixe + données) mais réduit la latence et le temps de basculement. Route 53 est peu coûteux et fournit des health checks granulaires. Sécurité : utiliser TLS sur les endpoints (ALB/NLB) et restreindre les accès via WAF, Security Groups et IAM. Tester fréquemment les basculements et mesurer la RTO/RPO pour ajuster la configuration. Trap: Une confusion fréquente est de penser que CloudFront ou un ALB seul gère le basculement multi-région au même niveau que un service réseau global; CloudFront améliore la distribution de contenu et ALB gère le trafic régional au niveau application, mais aucun de ces services ne remplace la logique de routage DNS multi-région et la gestion réseau globale fournie par Route 53 + Global Accelerator pour les besoins indiqués. Why each wrong answer fails: - Amazon CloudFront configuré avec origin failover entre buckets/régions : CloudFront fournit une excellente mise en cache globale et un mécanisme d'origin failover (basculer vers un origin secondaire si le primaire échoue), mais sa force est la distribution de contenu statique et la mise en cache ; il ne remplace pas la gestion DNS multi-région complète ni l’optimisation réseau de couche 4/7 pour des applications dynamiques. CloudFront peut aussi cacher des états et complexifier le debug. Pour une application dynamique multi-région nécessitant basculement réseau et routage global, CloudFront seul est insuffisant. - Un Application Load Balancer (ALB) dans chaque région avec DNS managé local : Un ALB est nécessaire pour la répartition de charge au niveau applicatif au sein d’une région/AZ et doit être utilisé, mais il n’assure pas le routage et le basculement multi-région autonome. L’ALB est dépendant du DNS pour rediriger entre régions ; sans un composant global (Route 53/Global Accelerator) le basculement multi-région est lent ou manuel. De plus, l’ALB ne gère pas l’optimisation réseau côté utilisateur final comme Global Accelerator. Résumé opérationnel : utilisez Route 53 pour la logique DNS basée sur l’état et la stratégie de routage et Global Accelerator pour la résilience et la performance réseau globale. ALB et CloudFront restent des composants complémentaires selon la nature de l’application (dynamique vs statique), mais ne remplacent pas la combinaison Route 53 + Global Accelerator pour le cas donné.

Step 1: Examiner les contraintes — microservices sans état, besoin de tolérance aux pannes multi-AZ et scalabilité sans gérer d’instances. Fargate est un mode serverless compute pour ECS ; il est conçu pour laisser AWS gérer l'infrastructure. L’ALB fournit le routage HTTP/HTTPS, l’équilibrage entre tâches réparties sur plusieurs subnets/AZ et les health checks qui permettent d’éviter d’envoyer du trafic vers des tâches défaillantes.

Step 2: Intégrer l’auto-scaling du service — ECS Service Auto Scaling ajuste dynamiquement le nombre de tâches Fargate en fonction des métriques (CPU, mémoire, ou basées sur Application/CloudWatch/Target Tracking). Cela fournit la capacité d’absorber les pics et de maintenir la performance. De plus, configurer la distribution de tâches sur plusieurs subnets/AZ garantit que la charge est tolérante aux pannes d’une AZ.

Step 3: Trade-offs et opérations — L’utilisation d’ALB + Fargate + Service Auto Scaling minimise l’opérationnel mais a un coût supérieur à l’exécution sur EC2 spot/ASG. Toutefois pour la résilience et la rapidité de reprise, c’est un compromis acceptable. Tester des scénarios de défaillance (soumission de tâches, drain de tâches, pertes d’AZ) et définir des politiques d’auto-scaling adéquates pour éviter oscillations. Sécurité : utiliser Security Groups, IAM rôles de tâches et chiffrement des secrets via AWS Secrets Manager. Trap: Penser que Spot est toujours bon pour la résilience — les instances Spot offrent un faible coût mais peuvent être récupérées rapidement par AWS, ce qui les rend inadaptées comme seule stratégie pour assurer la haute disponibilité d’applications critiques sans mécanismes de récupération supérieurs. Why each wrong answer fails: - Lancer les tâches sur des Auto Scaling Groups EC2 Spot pour réduire les coûts : Cela implique de gérer EC2 (mode EC2 pour ECS), ce qui va à l’encontre du besoin « sans gérer des serveurs ». De plus, Spot est préemptible ; bien qu’on puisse construire une architecture tolérante en combinant Spot et On-Demand, pour un service critique et sans état Fargate + ALB + auto-scaling est plus simple et plus résilient. Spot peut être utilisé comme optimisation de coût si vous acceptez les interruptions. - Utiliser des instances EC2 dédiées pour chaque microservice afin d'isoler les pannes : Cela augmente la complexité opérationnelle, le coût et réduit l’efficacité d’utilisation des ressources. L’isolation au niveau EC2 n’est pas nécessaire pour des services sans état et conteneurisés ; la bonne approche est de tirer parti d’un orchestrateur (ECS) et de Fargate pour isoler les workloads par tâche/service et utiliser des security groups, IAM et network policies pour la sécurité. De plus, dédier des instances pour chaque microservice réduit la résilience globale si vous n’équilibrez pas correctement la charge entre AZs. En conclusion : ALB + ECS Service Auto Scaling (Fargate) fournissent une solution managée, tolérante aux pannes et scalant automatiquement sans gestion de serveurs, ce qui correspond précisément aux exigences.

Step 1: Comprendre l’exigence L’application est sans état — donc les instances peuvent être ajoutées/supprimées sans perte d’intégrité applicative — et doit tolérer la perte de toute AZ. L’objectif est haute disponibilité, faible latence et automatisation de la montée en charge.

Step 2: Raisonnement AWS et sélection de la solution Un Auto Scaling Group (ASG) configuré pour répartir les instances sur plusieurs AZ, couplé à un Application Load Balancer, offre une solution standard AWS pour haute disponibilité : ALB gère la distribution de trafic, effectue health checks et retire automatiquement les instances défectueuses ; ASG ajuste la capacité selon des politiques (CPU, requests, target tracking). La répartition multi-AZ assure que si une AZ tombe, le trafic est redirigé vers les instances saines dans les autres AZ, réduisant fortement le RTO.

Step 3: Implémentation et compromis Configurer l’ASG avec au moins deux AZ et une stratégie de répartition équilibrée; activer les health checks ALB pour que l’ASG remplace rapidement les instances défaillantes. Pour minimiser la perte de sessions (bien que l’app soit sans état), utiliser une couche de persistence externe si nécessaire (par ex. DynamoDB/ElastiCache). Considérer coût et limites régionales (quotas d’instances) lors de la conception. Trap: on confond souvent AZ et région — placer toutes les instances dans une AZ unique crée un point de défaillance unique, même si un load balancer est présent. Pourquoi chaque mauvaise réponse échoue Option 2 (une seule grande instance + Route 53 failover) : failover Route 53 est lent et complexe pour maintenir l’état et les sessions ; une seule instance est un SPOF (single point of failure). Option 3 (ASG dans une seule AZ) : réduit la tolérance aux pannes; en cas de panne AZ, tout le service est indisponible. Option 4 (ELB Classic avec sticky sessions dans une AZ) : sticky sessions empêchent une bonne élasticité et résilience (stickiness peut maintenir la charge sur des instances qui échouent) et l’ELB Classic est moins adapté aux architectures modernes; de plus, l’hébergement dans une seule AZ reste un SPOF. Ainsi, ASG multi-AZ + ALB est la solution équilibrée pour disponibilité, performance et scalabilité.

Step 1: Interprétation des exigences RTO < 15 minutes et RPO ~ 1 minute pour une perte de région impliquent qu’il faut une réplication cross-region avec une latence très faible (presque en temps réel) et la capacité de basculer ou rediriger le trafic rapidement vers la région secondaire.

Step 2: Raisonnement AWS pour la sélection Amazon Aurora Global Database est conçu pour la réplication inter-région à faible latence en utilisant la réplication physique (conçue pour une latence typiquement inférieure à une seconde dans de nombreux cas d’usage). Elle permet d’avoir des clusters en lecture dans une région secondaire (réplicas en lecture) et des mécanismes de bascule documentés et automatisables. Aurora réduit le RPO au minimum et, avec un runbook et l’automatisation (scripts, AWS Lambda, Route 53 failover), permet d’atteindre un RTO faible.

Step 3: Détails de l’implémentation et compromis Déployer Aurora Global Database avec la région primaire et au moins une région secondaire. Mettre en place des playbooks testés, automatisation pour promotion et mise à jour des endpoints (par exemple via Route 53, ou arriver à écrire une logique d’orchestration). Coût : réplicas et trafic inter-région ont un coût ; complexité opérationnelle accrue par rapport à Multi-AZ simple. Tester les coupures régionales régulièrement. Trap: confondre Read Replica cross-region asynchrone et une solution quasi-synchrone — les replicas cross-region classiques RDS sont asynchrones et peuvent avoir des lags imprévisibles ; cela n’assure pas un RPO de ~1 minute. Pourquoi chaque mauvaise réponse échoue Option 2 (snapshots toutes les minutes) : RDS n’offre pas de snapshot toutes les minutes en pratique — même si possible via outils tiers, la restauration à partir d’un snapshot vers une nouvelle région prend du temps (heures), donc RTO >> 15 min. Option 3 (Read Replica cross-region) : la réplication est asynchrone — le délai peut dépasser 1 minute; la promotion manuelle ajoute du temps et du risque, donc ne garantit pas RTO/RPO requis. Option 4 (RDS Multi-AZ seulement) : Multi-AZ protège contre la perte d’une AZ mais pas contre la perte d’une région entière ; la réplication est locale, donc en cas de panne régionale vous perdez la disponibilité. Ainsi Aurora Global Database est la meilleure option native AWS pour ces contraintes strictes.

Step 1 (AWS reasoning): Pour obtenir un RTO faible au niveau régional, le déploiement actif‑actif dans deux régions est la meilleure approche : les deux régions servent le trafic simultanément et Route 53 (latency-based routing ou failover routing avec health checks) peut diriger le trafic vers la région saine en cas de problème, limitant la perte de service. Step 2 (AWS reasoning): DynamoDB Global Tables fournit une réplication multi‑région active‑active gérée, avec une cohérence éventuelle mais conçue pour les lectures/écritures multi‑région et pour une bascule sans restauration manuelle. Pour des applications conçues pour la cohérence éventuelle, Global Tables simplifie la réplication et réduit le RTO. Step 3 (AWS reasoning): Les solutions qui reposent sur snapshots ou réplication asynchrone avec promotion manuelle entraînent des délais (RTO élevé) et un risque de perte de données (RPO) car elles requièrent des opérations manuelles ou des délais de synchronisation. Pour un SLA exigeant disponibilité continue et basculement automatisé, active‑active + Global Tables est supérieure. Pourquoi chaque mauvais choix échoue: - Option 2 (Unique région + snapshots S3): La restauration depuis snapshots SPAWN dans une autre région est une opération longue et propice aux erreurs — RTO très élevé et RPO dépendant de la fréquence des snapshots. Ceci est inadapté si vous avez besoin d'une disponibilité continue. - Option 4 (RDS asynchrone cross‑region + promotion manuelle): La réplication asynchrone implique un risque de perte de données récentes et la promotion manuelle ajoute du délai et de la complexité. Elle peut faire partie d'une stratégie DR, mais n'est pas idéale pour un RTO faible et un basculement automatique. Trap: common AWS exam misconception: Un piège fréquent est de croire que la réplication cross‑region asynchrone (read replica) suffit pour un basculement automatique rapide; ce n'est pas vrai — elle introduit généralement un RPO et nécessite souvent une promotion manuelle. De plus, penser que Route 53 seul suffit sans une architecture active‑active sous‑jacente est une erreur : DNS peut rediriger mais si la région cible n'est pas prête, l'utilisateur subira des interruptions. Conclusion: Pour résilience multi‑région avec RTO faible, combinez un déploiement actif‑actif dans plusieurs régions avec Route 53 pour le routage/failover et utilisez DynamoDB Global Tables pour la réplication des données en lecture/écriture multi‑région.

Step 1: Identifier le besoin principal — la question spécifie résilience, minimum d’administration et zéro perte de données. Pour RDS, Multi-AZ fournit une réplication synchrone (ou proche de synchrone selon le moteur) à une instance standby dans une autre AZ, et RDS gère automatiquement la détection de panne et la bascule.

Step 2: Comparer les options sur les critères résilience, RTO/RPO, gestion et coûts. Multi-AZ minimise l’intervention opérationnelle (service managé), offre un RPO très faible et met en place une bascule automatique (RTO faible). Les Read Replicas sont asynchrones (RPO > 0) et conçues pour monter en charge en lecture plutôt que pour la haute disponibilité. Les snapshots et la restauration cross-région sont bons pour la reprise après sinistre (DR) mais imposent des RTO/RPO élevés et une gestion manuelle pour la restauration. Exécuter MySQL sur EC2 pousse la responsabilité d’implémenter la réplication, la surveillance et la bascule sur l’équipe, ce qui contredit l’exigence de faible administration.

Step 3: Recommandation d’implémentation — activer Multi-AZ sur l’instance RDS existante (ou migrer vers une instance RDS Multi-AZ), combiner avec des instances d’application réparties sur plusieurs AZ derrière un ALB pour assurer la disponibilité du front-end. Adapter une stratégie de sauvegarde et éventuellement des réplicas en lecture pour scalabilité en lecture, mais conserver Multi-AZ pour la HA primaire. Trap: Confusion fréquente — beaucoup confondent Read Replica et Multi-AZ. Les read replicas sont asynchrones et ne garantissent pas zéro perte de données si elles sont promues après une panne; elles ne fournissent pas automatiquement une bascule transparente. Multi-AZ est le mécanisme conçu pour la haute disponibilité managée. Why each wrong answer fails: - Option 2 (Créer un Read Replica et le promouvoir) : Les read replicas sont asynchrones ; promotion demande intervention et peut entraîner une perte de données récente. Pas de bascule automatique gérée pour HA critique. - Option 3 (Snapshots cross-région toutes les 5 minutes) : Les snapshots RDS ne peuvent pas être pris toutes les 5 minutes sans coûts élevés et même ainsi la restauration est une opération manuelle/lente — RTO et RPO inacceptables pour une appli critique. - Option 4 (MySQL sur EC2 avec cluster maître/esclave) : Implique gestion complète par l’équipe (patching, failover, monitoring), augmente la complexité opérationnelle et les risques humains ; contraire à l’exigence de services managés et de faible administration. Trade-offs: Multi-AZ a un coût supérieur à une instance simple mais réduit le coût d’exploitation humain et le risque d’interruption. Pour les besoins de montée en charge en lecture, ajouter des read replicas (séparément) est pertinent ; pour la récupération régionale, envisager réplicas cross-région ou sauvegardes cross-région.

Step 1: Comprendre les besoins fonctionnels. L'application nécessite un stockage de fichiers partagé accessible concurrentiellement par des serveurs dans plusieurs AZ, disponibilité multi‑AZ, et montée en charge transparente. Le stockage doit être managé pour réduire l'effort opérationnel.

Step 2: Comparer les options managées. Amazon EFS est un système de fichiers réseau NFSv4 managé, conçu pour être accessible depuis plusieurs AZ via des mount targets ; il offre une tolérance aux pannes multi‑AZ, mise à l'échelle automatique du throughput et du stockage et des modes de performance (Bursting, Provisioned). FSx for Lustre est optimisé pour workloads HPC et latence/IOPS fortes pour calcul intensif mais peut ne pas fournir le même comportement POSIX pour toutes les applications, et sa configuration multi‑AZ a des particularités. EBS est attaché à une seule instance/AZ (pas partageable). Déployer un NFS sur EC2 ajoute une charge opérationnelle et un point de défaillance.

Step 3: Choisir EFS et configurer les meilleures pratiques. Déployer des mount targets dans chaque AZ, choisir le mode de performance adapté, chiffrer les données côté serveur ou SSE‑S3 (selon option) et appliquer des politiques IAM/FSx access control via NFS. Surveiller coûts (EFS peut être plus cher que EBS pour certains profils) et optimiser lifecycle ou Infrequent Access si utile. Trap: Penser qu'EBS peut être partagé entre instances comme EFS. EBS est conçu pour attachement à une seule instance à la fois (sauf EBS Multi‑Attach qui a des contraintes et n'est pas un remplacement pour un système de fichiers NFS partagé classique). On confond souvent FSx (très performant) avec EFS (généraliste et managé pour partage). Why each wrong answer fails: - Attacher un volume EBS à chaque instance et synchroniser les fichiers manuellement : EBS n'est pas conçu pour le montage simultané par plusieurs instances dans différentes AZs ; synchronisation manuelle ajoute complexité, latence et risques de cohérence, et nécessite des outils/gestion pour la réplication et la résolution de conflits. - Déployer un serveur NFS sur une instance EC2 avec un EBS pour le stockage et répliquer entre AZs : Cette approche crée un point de défaillance (le serveur NFS), augmente l'opérationnel (patching, scaling, failover), et la réplication entre AZs est complexe à gérer et coûteuse. Ce n'est pas une solution managée et tolérante aux pannes par défaut. - Utiliser Amazon FSx for Lustre sans monter des points dans chaque AZ : FSx for Lustre est optimisé pour workloads HPC/à haute performance et peut nécessiter des architectures spécifiques ; il n'est pas toujours le choix approprié pour une application web ayant besoin d'un partage POSIX multi‑AZ managé et durable. De plus, « sans monter des points dans chaque AZ » indique une mauvaise configuration qui ne résoudrait pas la tolérance multi‑AZ. Conclusion : Pour un système de fichiers partagé, managé, accessible depuis plusieurs AZs et tolérant aux pannes, Amazon EFS est la solution appropriée, en tenant compte des choix de performance/coût et en configurant mount targets et politiques de sécurité adéquates.