AWS Solutions Architect — Conception d’architectures performantes : 70 questions d'entraînement

Step 1: Exigences & contraintes - Latence mondiale: livraison depuis des points de présence (POP) proches des utilisateurs. - Contenu mixte: contenu statique (S3) + contenu dynamique via ALB/EC2. - Sécurité TLS: terminus TLS au périmètre (meilleur pour performance et sécurité). - Résilience: basculement d’origine si une région primaire n’est pas disponible. - Coût opérationnel raisonnable.

Step 2: Raisonnement AWS pour la solution optimale - CloudFront offre un réseau mondial de POPs, réduction significative de la latence pour contenu statique et possibilité de mettre en cache des réponses dynamiques (si approprié). - CloudFront supporte des origin groups: vous pouvez configurer un origin principal (ALB régional, puis S3) et un origin secondaire pour le failover; cela permet de basculer automatiquement vers une autre origine en cas d’échec. - TLS est géré aisément via Certificates Manager (ACM) et CloudFront, avec termination TLS au edge, réduisant les RTT entre client et serveur. - CloudFront peut être configuré pour respecter les en-têtes Cache-Control venant des origines, et on peut utiliser Lambda@Edge/Functions@Edge pour manipuler les requêtes si nécessaire. - Coût opérationnel est raisonnable: CloudFront réduit le trafic direct vers ALB/S3, donc économies sur le transfert de données et sur la charge des instances.

Step 3: Mise en œuvre et considérations - Configurer CloudFront distributions pour pointer vers origin groups composés de l’ALB régional comme origin principal et d’un S3 (ou ALB d’une autre région) comme origin secondaire pour failover. - Activer HTTPS entre CloudFront et les origines; utiliser des certificats ACM pour la distribution et pour les ALB (ou l’option d’origins S3 privée si nécessité). - Définir des politiques de cache appropriées (Cache policy) et contrôler les en-têtes/params/cookies à transmettre; invalider ou versionner les objets statiques pour contrôle de cache. - Surveiller les métriques CloudFront/ALB et tester le basculement via origin group failover. Trap: misconception courant Beaucoup pensent que Route 53 latency-based routing seul suffit pour «distribution globale». Cela n’élimine pas la nécessité d’un CDN pour réduire latence entre le client et l’origine; sans CDN, chaque requête traverse la distance complète vers l’origine, augmentant latence et coût de transfert. Pourquoi chaque mauvaise réponse échoue - Option 2 (ALB + Route 53 sans CloudFront): Route 53 peut router la latence mais ne met pas en cache le contenu aux edge. Chaque requête atteint l’ALB/EC2 augmentant latence et coût. En outre, S3 en mode site web public ne fournit pas le même contrôle de TLS et d’optimisations HTTP/2/edge que CloudFront. - Option 3 (CDN tiers + HTTP/2 sans TLS vers origine): Utiliser un CDN tiers peut être viable, mais recommander de communiquer sans TLS between CDN and origin est une faille de sécurité (et souvent non supportée ou non recommandée pour des données sensibles). De plus, une intégration native AWS (CloudFront + ACM) réduit la complexité opérationnelle et permet des économies et une meilleure compatibilité avec origin groups pour failover. - Option 4 (S3 static site sans CDN): Servir tout depuis S3 supprime la capacité à servir le contenu dynamique efficacement et augmente la latence pour utilisateurs éloignés; S3 website endpoints ne supportent pas TLS via ACM et offrent moins de flexibilité pour le cache et la sécurité. Conclusion: choisir CloudFront devant des origin groups (ALB + S3) offre latence réduite, TLS au périmètre, mécanismes de failover d’origine et économie en réduisant le trafic direct vers les origines, répondant aux contraintes enterprise.

Step 1: Analyser le goulot d’étranglement. Les métriques montrent une latence élevée liée aux opérations de lecture et une utilisation CPU importante sur l’instance RDS, ce qui indique que la couche stockage/lecture est le point limitant pour les charges de travail en lecture intensives. Avant toute action, identifier les patterns de lecture (hot keys, fréquences, TTL possibles).

Step 2: Appliquer une solution de mise en cache. Implémenter Amazon ElastiCache (Redis ou Memcached) permet de stocker en mémoire les résultats des requêtes fréquentes et de servir ces réponses beaucoup plus rapidement que RDS. Le cache réduit le nombre de lectures IOPS/CPU sur RDS, améliore la latence applicative et peut être configuré avec expiration/invalidations appropriées pour garantir la cohérence. Pour les scénarios lecture-lourde, la mise en cache est souvent la solution la plus efficace au regard du coût/performances.

Step 3: Mesurer et itérer. Après déploiement, surveiller les métriques ElastiCache (hit ratio, latence), RDS (CPU, IOPS), et l’application (temps de réponse). Ajuster la stratégie de TTL, taille de cache, et potentiellement combiner avec réplicas de lecture si des types de requêtes nécessitent encore l’accès direct à RDS. Trap: une confusion courante est de croire que les réplicas de lecture ou le scaling vertical résoudront immédiatement tous les problèmes de latence. Les réplicas aident à répartir les lectures mais ne suppriment pas les requêtes répétitives identiques; le cache élimine ces lectures répétées. Le scaling vertical augmente la capacité mais peut être coûteux et atteint ses limites. Multi-AZ améliore la disponibilité mais n’est pas conçu pour la répartition de charge lecture. Why each wrong answer fails: - Augmenter la taille de l'instance RDS (réponse 1) : Le scaling vertical augmente la CPU/mémoire mais coûte plus cher et n’élimine pas les accès redondants pour des données fréquemment lues; il peut atténuer temporairement le problème mais pas le résoudre de façon efficace en coût/latence. De plus, vertical scaling provoque des fenêtres de maintenance et n’est pas aussi élastique que des caches. - Ajouter des réplicas de lecture RDS (réponse 2) : Les read replicas répartissent la charge de lecture et conviennent pour certaines requêtes complexes, mais elles ne diminuent pas la latence pour les mêmes requêtes répétées (cache hits). Les read replicas impliquent une réplication asynchrone (légère latence de cohérence) et coût supplémentaire permanent. - Activer Multi-AZ pour RDS (réponse 4) : Multi-AZ est destiné à la haute disponibilité et bascule automatique en cas de panne; il ne répartit pas le trafic de lecture et n’améliore pas la latence utilisateur dans un scénario normal (il augmente souvent le coût sans bénéfice de performance pour les lectures). Conclusion: pour une application dont le goulot principal est la répétition de lectures sur RDS, la mise en place d’un cache en mémoire (ElastiCache) offre le meilleur compromis performances/coûts et réduit significativement la latence utilisateur.

Step 1: Identifier et séparer les responsabilités — Les actifs statiques doivent être servis depuis des emplacements proches des utilisateurs. CloudFront avec un bucket S3 comme origine permet d’offrir des copies au plus proche des utilisateurs (edge) ce qui réduit considérablement la latence et les coûts d’e/s vers l’origine.

Step 2: Réduire la pression sur la base de données — Pour les lectures fréquentes et les données de session, ElastiCache (Redis) fournit un cache mémoire rapide, réduisant les lectures directes vers RDS et améliorant la latence applicative. Redis peut aussi servir de magasin de sessions partagé et hautement disponible entre plusieurs instances.

Step 3: Combiner pour la résilience et le coût — CloudFront diminue la bande passante et le nombre de requêtes atteignant les serveurs d’origine ; ElastiCache réduit fortement la charge sur la base de données, ce qui permet d’éviter des montées en gamme coûteuses et d’obtenir une meilleure élasticité. Utiliser des TTLs pertinents et invalidations contrôlées vous aide à équilibrer cohérence et performance. Trap: Beaucoup de candidats pensent qu’augmenter simplement la taille de l’instance RDS ou activer les sessions collantes règle le problème. En réalité, le scale-up est coûteux et n’élimine pas la latence réseau pour les régions éloignées ; les sticky sessions créent des points de défaillance et empêchent un scaling horizontal propre. Why each wrong answer fails: - Déployer Amazon CloudFront avec un bucket S3 pour les actifs statiques et activer la mise en cache au niveau edge (Bonne réponse): réduit latence et coût d’origine, diminue le nombre de requêtes vers l’infrastructure centrale. - Activer les sessions collantes (sticky sessions) sur l’ALB et stocker les sessions localement sur chaque instance EC2 (Mauvaise réponse): Les sessions collantes empêchent l’équilibrage de charge efficace et nuisent à la résilience ; en cas de défaillance d’une instance, les sessions sont perdues ; ne réduit pas la latence réseau pour les utilisateurs distants. - Déployer Amazon ElastiCache (Redis) pour le caching des réponses fréquemment lues et sessions partagées (Bonne réponse): diminue les lectures RDS, accélère les réponses et permet de partager les sessions de façon résiliente. - Augmenter simplement la taille de l’instance RDS (scale-up) pour absorber la charge (Mauvaise réponse): Le scale-up peut résoudre temporairement un goulot d’étranglement, mais c’est coûteux, moins flexible, et n’améliore pas la latence des utilisateurs distants. Il ne résout pas le besoin de distribution géographique. En synthèse, la meilleure approche combine distribution de contenu (CloudFront) + cache mémoire proche de l’application (ElastiCache) pour réduire latence et charge sur la base de données tout en limitant les coûts additionnels et en améliorant la résilience.

Step 1: Identifier les exigences — haute concurrence, très haut débit et faible latence pour jobs parallèles, souvent besoin d'une interface POSIX et de scalabilité en nombre de clients. Les choix doivent répondre simultanément à débit, IOPS, latence et persistance.

Step 2: Choisir les technologies adaptées — Amazon EFS mode Max I/O permet de scaler le nombre de threads et le throughput global pour des workloads massivement parallèles et multi‑AZ; le throughput provisioned aide pour des pics prévisibles. Amazon FSx for Lustre est conçu pour HPC : latence très faible, bande passante élevée, intégration native avec S3 pour workflows qui déplacent ou traitent de larges datasets. Combiner les deux selon profils de jobs (FSx pour jobs très intensifs et temporaires, EFS pour données partagées persistantes et multi‑AZ) est une solution d'entreprise robuste.

Step 3: Déployer et équilibrer coût/perf — pour FSx, gérer lifecycle (synchronisation avec S3) et considération coût pour stockage performant; pour EFS, choisir le mode (Max I/O), throughput (burst vs provisioned) et politiques de lifecycle pour réduire coût. Mesurer avec tests de charge et ajouter des métriques (CloudWatch) pour ajuster. Trap: penser que EBS partagé via export NFS résout le besoin de scalabilité — un seul EBS n'est pas conçu pour multi‑attach en lecture/écriture depuis plusieurs instances en production (exceptions: EBS Multi‑Attach pour Linux mais limitations et complexité). Autre erreur: monter S3 via FUSE pour simuler POSIX — entraîne latences élevées, incohérences e.g. renames, et n'est pas conseillé pour HPC. Pourquoi chaque réponse échoue ou réussit: - EFS Max I/O + throughput provisioned (Correct) : Scalable horizontalement, multi‑AZ, adapté aux très nombreux clients concurrents. Latence est supérieure à FSx pour Lustre mais offre durabilité et simplicité de gestion; coût modéré pour données persistantes. - FSx for Lustre (Correct) : Conçu pour HPC avec haut débit et faible latence; peut être lié à S3 pour ingestion/éjection de données; idéal pour jobs parallèles intensifs. Considérer coût et besoin de persist‑store si nécessaire. - Attacher un EBS et exporter en NFS (Incorrect) : EBS est attaché à une seule instance pour accès en lecture/écriture ; exporter via NFS crée un SPOF et limite la bande passante et résilience; EBS Multi‑Attach a des contraintes et n'est pas une solution simple pour un large cluster. - Monter S3 via FUSE (Incorrect) : S3 est un objet store non POSIX; FUSE introduit latences, problèmes de cohérence et mauvais comportement pour I/O intensif. Inadapté aux besoins HPC et CI qui exigent performance et cohérence. Trade‑offs: FSx offre performance brute (coût plus élevé, latence plus faible), EFS offre durabilité, multi‑AZ et facilité de gestion (coût variable selon throughput). Sécurité: chiffrage en transit et au repos, IAM, NFSv4 contrôles d'accès pour EFS/FSx. Résilience: EFS multi‑AZ natif; FSx gère snapshots et intégration S3 pour persistance des données.

Step 1: Évaluer les besoins — Distribution de contenu statique à grande échelle, exigences de latence globale et maîtrise des coûts sortants. S3 est performant pour le stockage, mais la distribution directe depuis une région unique impose des RTT élevés pour les utilisateurs éloignés et coûte plus cher en sortie réseau.

Step 2: Mettre en place la solution CDN — Amazon CloudFront, en tant que CDN global, met en cache le contenu aux edge locations proches des utilisateurs. Cela réduit significativement la latence perçue et diminue le nombre d'octets servis depuis le bucket S3 (réduisant le coût de sortie S3). Configurer des TTLs appropriés, invalidations et politiques d'en-têtes permet d'optimiser le cache et la cohérence.

Step 3: Optimiser coûts et sécurité — CloudFront propose des tarifs de transfert sortant souvent inférieurs et permet d'appliquer des fonctionnalités additionnelles (compressions, HTTP/2, signed URLs, WAF, OAI/OAC pour restreindre l'accès au bucket). Mesurer les hit ratios et ajuster les TTL pour maximiser les hits au cache. Trap: confondre Transfer Acceleration et CDN. Transfer Acceleration améliore la vitesse d'upload vers S3 en utilisant le réseau CloudFront comme point d'entrée mais ne remplace pas un CDN pour la distribution globale et le caching des reads. Beaucoup pensent que Transfer Acceleration résout la latence de distribution globale, ce qui est incorrect. Why each wrong answer fails: - Activer S3 Transfer Acceleration pour tous les buckets servant le contenu statique : Transfer Acceleration est optimisé pour accélérer les uploads vers S3 via les edge locations ; il n'est pas conçu pour la distribution en lecture à grande échelle et n'offre pas le caching et les optimisations que CloudFront propose pour les utilisateurs finaux. - Servir directement depuis S3 et optimiser les noms de préfixe pour augmenter le débit : S3 supporte des niveaux élevés de requêtes et n'exige plus de sharding de préfixe pour le débit, mais servir directement depuis S3 depuis une seule région crée de la latence pour les utilisateurs distants et des coûts sortants plus élevés sans bénéfice de mise en cache. - Créer des buckets S3 dans plusieurs régions et router les utilisateurs vers le bucket le plus proche : Cette approche augmente considérablement la complexité (réplication inter‑régionale, cohérence, coût de réplication) et reste moins efficace que CloudFront pour la mise en cache aux edge et la réduction des coûts sortants. Conclusion: CloudFront devant S3 est la meilleure option pour réduire latence globale et coûts de transfert pour la distribution massive de contenu statique.

Step 1: Sécurité et contraintes d'accès. Pour des objets confidentiels, il faut empêcher l'accès direct au bucket S3 depuis Internet et s'assurer que seul CloudFront (la couche de distribution) puisse récupérer les objets depuis S3. Il faut aussi pouvoir auditer les accès et appliquer des contrôles d'identité et chiffrement.

Step 2: Choix AWS et justification technique. Origin Access Control (OAC) est la méthode récente recommandée par AWS pour permettre à CloudFront d'accéder à un bucket S3 privé en utilisant des signataires sous-jacents (signatures v4) et en conservant le chiffrement côté serveur. En rendant le bucket privé et en ajoutant une politique de bucket qui n'autorise que la principale identifiée par l'OAC, on garantit que les objets ne sont pas accessibles directement via des URLs S3 publiques. Cela permet en outre d'activer la journalisation CloudFront/CloudTrail pour l'audit et d'utiliser des Signed URLs/Cookies pour contrôler l'accès utilisateur final.

Step 3: Opérations, conformité et performance. L'approche OAC réduit la surface d'attaque et centralise la politique d'accès via CloudFront. Elle permet d'appliquer WAF et des mécanismes d'authentification au niveau de CloudFront et d'assurer un audit fin via les logs. En termes de performance, CloudFront mettra en cache le contenu aux PoP, réduisant les hits vers S3 et améliorant la latence utilisateur. Trap: un piège fréquent est de continuer à utiliser les Origin Access Identity (OAI) historiques ou de croire qu'un bucket public + URLs signées est suffisant. OAI est obsolète au profit d'OAC qui supporte mieux les signatures v4 et l'intégration moderne. Why each wrong answer fails: Option 2 (bucket public + URLs signées): Rendre le bucket public accroît la surface d'attaque — même si vous utilisez URLs signées, une mauvaise configuration peut exposer des objets. De plus, il est plus difficile d'appliquer et d'auditer des politiques centralisées et de combiner avec d'autres contrôles CloudFront (WAF, geographic restrictions). Ceci est moins sécurisé que l'approche privée + OAC. Option 3 (OAI): Bien que OAI ait historiquement permis de restreindre l'accès, AWS a introduit OAC comme méthode recommandée avec meilleurs supports de signature et fonctionnalités modernes. OAI reste une méthode héritée et n'offre pas toutes les améliorations d'OAC (par ex. meilleure prise en charge Signature V4 et future feature parity). Dans un nouveau déploiement, OAC est préféré. Option 4 (API Gateway devant S3): Utiliser API Gateway pour servir directement des objets S3 implique plus de coûts et d'opérations (API Gateway n'est pas optimisé pour livrer de gros objets binaires fréquents) et perd l'avantage du caching mondial de CloudFront ; cela augmente aussi la latence pour des utilisateurs globaux et la charge de calcul pour vérifier les tokens. Conclusion: Utiliser CloudFront + OAC + bucket S3 privé est la combinaison la plus sécurisée, performante et auditable pour délivrer du contenu privé depuis S3.

Step 1: Analyser les exigences — l'application est stateless (donc facile à scaler) et connaît des pics imprévisibles; coût en dehors des pics doit rester bas, et un court délai pour ajouter de la capacité est tolérable.

Step 2: Comparer les options de calcul — EC2 Auto Scaling permet d'utiliser des instances optimisées coût/performance (comme M6g basées sur Graviton) et d'ajuster la flotte avec des stratégies (scheduled, target tracking) tout en conservant un contrôle fin sur le mélange On-Demand/Reserved/Spot.

Step 3: Architecturer pour résilience et coût — placer l'ALB devant le groupe Auto Scaling pour rediriger et répartir la charge, utiliser des instances Graviton pour réduire le TCO, et configurer des warm pools ou un petit minimum d'instances pour réduire le cold-start impact. Trap: Penser que serverless est toujours le plus économique — Lambda peut être coûteux pour des applications toujours sollicitées et comporte des limites fonctionnelles (durée, gestion des connexions longues). Pourquoi chaque mauvaise réponse échoue: Option 2 (Lambda + API Gateway) — avantage en scalabilité mais peut engendrer un coût plus élevé pour trafic constant et des cold starts/limitations sur connexions longues; pas idéal si l'application nécessite des optimisations bas niveau ou runtimes particuliers. Option 3 (T3 burstable) — les instances T3 peuvent être efficaces pour des charges baselines faibles avec bursts, mais en cas de pics soutenus elles seront throttlées; pas adaptées à des pics imprévisibles importantes. Option 4 (ECS Fargate) — Fargate élimine la gestion d'infrastructure, mais son coût par vCPU/mémoire est généralement supérieur à EC2, et pour de fortes variations de trafic les économies offertes par Graviton sur EC2 sont significatives. Conclusion: Auto Scaling avec M6g donne un bon compromis coût/perf/resilience pour une entreprise avec pics imprévisibles et tolérance aux délais de montée en charge.

Step 1: Évaluer la cause des coûts élevés — invalidations fréquentes et TTL courts entraînent beaucoup de demandes vers l’origine et coûts d’invalidation CloudFront; cela provoque aussi une charge backend importante durant les périodes de mise à jour.

Step 2: Mettre en place des mécanismes pour réduire les hits sur l’origine — Origin Shield est une couche supplémentaire de cache régional proposée par CloudFront qui agit comme un cache centralisé pour une région, réduisant la probabilité que plusieurs edge locations interrogent directement l’origine simultanément. Cela diminue la charge sur l’origine et améliore le hit ratio global.

Step 3: Repenser la stratégie de déploiement de contenu — Utiliser le fingerprinting (versioning dans le nom de fichier) des assets statiques permet d’appliquer des TTL longs et d’éviter les invalidations globales : lorsqu’un asset change, le nom change, la nouvelle version est servie, et l’ancienne peut être évincée naturellement. Compléter par invalidations sélectives (ou purge d’objets par version) pour les cas rares où l’on doit remplacer un asset sans changer son nom. Trap: Un piège courant est d’augmenter uniformément les TTL pour réduire les invalidations. Bien que cela réduise la charge d’origine, cela peut empêcher la propagation rapide des correctifs ou des changements de contenu critique et compromettre l’expérience utilisateur si le contenu obsolète persiste. La meilleure pratique est de combiner le versioning/fingerprinting et TTL longs. Why each wrong answer fails: - Activer Origin Shield dans CloudFront pour réduire le nombre d’appels simultanés vers l’origine et améliorer le taux de cache au niveau regional — Correct. Origin Shield centralise les requêtes d’edge vers un cache régional unique, réduisant les requêtes répétées vers l’origine et améliorant la résilience sous pics de trafic. - Augmenter de manière arbitraire le TTL des objets CloudFront à 30 jours pour tous les contenus afin de minimiser les invalidations — Incorrect. Mettre un TTL très long globalement peut empêcher la distribution rapide de corrections ou de contenu mis à jour et créer des incohérences pour l’utilisateur. Sans versioning/fingerprinting, les changements nécessiteront des invalidations coûteuses ou laisseront l’utilisateur avec du contenu périmé. Une approche mixte (fingerprinting + TTL longs) est préférable. - Adopter la stratégie de fingerprinting des assets et utiliser des invalidations sélectives ou la purge par version plutôt que des invalidations globales fréquentes — Correct. Le fingerprinting permet des TTL longs et évite les invalidations massives; les invalidations deviennent rares et ciblées, réduisant coûts et charge. - Remplacer CloudFront par des EC2 reverse proxies répartis géographiquement pour contrôler plus finement le cache et les invalidations — Incorrect et non recommandé. Gérer votre propre réseau de reverse proxies engendre une complexité opérationnelle, un coût et un overhead (scaling, sécurité, monitoring) bien supérieurs à ceux d’un service managé comme CloudFront. CloudFront offre des fonctionnalités avancées (Regional Edge Caches, Origin Shield, fonctions edge) et une échelle difficile à reproduire avec des EC2. Résumé: Combinez Origin Shield pour réduire la pression directe sur l’origine et adoptez le fingerprinting/versioning des assets pour permettre des TTL longs et des déploiements rapides sans invalidations globales coûteuses. Evitez d’augmenter arbitrairement les TTL sans stratégie de versioning et n’essayez pas de remplacer un CDN managé par une solution homebrew coûteuse.

Step 1: Séparer les patterns lecture/écriture — Les lectures massives doivent être traitées différemment des écritures. La création de Read Replicas permet de scinder la charge de lecture vers des instances optimisées pour la lecture, réduisant la latence de réponse pour les opérations SELECT.

Step 2: Introduire un cache en mémoire pour les points chauds — Mettre en place ElastiCache (Redis) permet de servir les données très fréquemment lues depuis la mémoire, ce qui supprime la latence disque et réduit drastiquement le nombre de requêtes sur RDS. Utilisez des TTLs et stratégies d’invalidation cohérentes pour maintenir la cohérence des données.

Step 3: Combiner pour scalabilité et résilience — En utilisant à la fois des Read Replicas et ElastiCache, vous obtenez une approche à plusieurs couches: cache mémoire pour hits rapides et réplicas pour répartir les lectures restantes. Ceci permet de limiter les coûts par rapport à un scale-up permanent et offre une meilleure élasticité pendant les pics. Trap: Certains pensent que CloudFront peut être utilisé pour cacher des requêtes SQL ou qu’un simple scale-up (plus de CPU/IOPS) suffira. CloudFront est un CDN orienté HTTP/HTTPS et ne plate-forme pas directement des requêtes base de données ; augmenter la taille d’un seul nœud RDS peut aider momentanément mais ne résout pas la contrainte d’échelle horizontale. Why each wrong answer fails: - Créer des Read Replicas (Aurora/MySQL) et configurer l’application pour diriger les lectures vers ces réplicas (Bonne réponse): Répartit les lectures et réduit la latence en ajoutant de la capacité de lecture horizontale. - Placer Amazon CloudFront entre l’application et RDS pour cacher les requêtes SQL fréquemment exécutées (Mauvaise réponse): CloudFront opère au niveau HTTP/HTTPS et ne sait pas interpréter ou cacher des requêtes SQL ; il ne peut pas réduire la charge directe sur RDS pour des appels DB internes. - Déployer Amazon ElastiCache (Redis) comme couche de cache pour les lectures fréquentes et données peu changeantes (Bonne réponse): Fournit des réponses très rapides en mémoire et réduit fortement la charge de la base relationnelle. - Augmenter la taille et IOPS du stockage RDS et configurer le multi-AZ uniquement pour tolérance aux pannes (Mauvaise réponse): Augmenter ressources peut retarder le problème mais reste coûteux et n’offre pas une mise à l’échelle horizontale des lectures ; multi-AZ améliore la disponibilité mais n’améliore pas directement la capacité de lecture (les lectures sur l’instance secondaire peuvent être possibles, mais le scaling de lecture est mieux géré par des read replicas dédiés). Ainsi, la combinaison de read replicas et d’un cache mémoire est la stratégie la plus efficace pour réduire la latence de lecture sans refondre l’application.

Step 1: Analyse des exigences - CPU‑intensive: nécessite forte capacité CPU soutenue. - Performance constante: pas de variabilité ni de comportement burstable. - Licences x86: l’application ou les binaires ne sont pas testés sur ARM. - Échelle et résilience: montée/descente automatique selon la charge.

Step 2: Raisonnement AWS sur le choix d’instance - Les familles C6i sont optimisées pour le calcul et fournissent des performances CPU prévisibles pour des charges soutenues. Elles sont basées sur des processeurs Intel/AMD x86, garantissant la compatibilité binaire/licences attendue. - Auto Scaling sur des C6i permet d’augmenter la capacité tout en gardant la même famille d’instances pour la consistance des performances et la conformité des licences. - Les variantes Graviton (C6g) offrent souvent un meilleur rapport coût/performance, mais elles sont basées sur ARM; si vous avez des dépendances x86 (licences, binaires non recompilés), migrer vers ARM introduit risque de non‑compatibilité, coût de migration et audit des licences.

Step 3: Mise en œuvre pratique et considérations - Déployer un ASG (Auto Scaling Group) avec instances C6i derrière un ALB pour distribution de charge; configurer Health Checks et Scaling Policies basées sur métriques CPU/Application. - Réserver ou utiliser Savings Plans si la charge est prévisible pour réduire coûts (prévoir engagements selon politique financière). - Monitoring via CloudWatch et profilage applicatif pour ajuster taille d’instance (c6i.large -> c6i.2xlarge etc.) afin d’optimiser coût vs. performance. Trap: misconception courant Les candidats confondent coûts unitaires plus faibles (ex. Graviton) avec la meilleure option opérationnelle: un meilleur coût/perf n’est utile que si l’architecture, les licences et la compatibilité le permettent; forcer ARM sans vérification peut briser des applications et violer des accords de licence. Pourquoi chaque mauvaise réponse échoue - Option 1 (T3/T4g burstable): Ces instances sont conçues pour charges variables et reposent sur des crédits de CPU pour performancer en burst. Pour une charge CPU‑intensive et constante, les crédits seront épuisés rapidement, conduisant à une dégradation de performance — donc inadéquat. - Option 3 (C6g Graviton ARM): Excellente option coût/perf pour charges compatibles ARM. Cependant, l’énoncé précise une contrainte de licences liées à x86 ; sans recompilation et validation des licences, C6g expose au risque d’incompatibilité et de non‑conformité. En entreprise critique, on préfère éviter ce risque sans plan de migration. - Option 4 (AWS Lambda): Lambda est conçu pour exécuter fonctions courte durée et scale-out automatique, mais présente des limites pour workloads CPU‑intensifs soutenus (coût potentiellement plus élevé par unité de CPU, limites de durée d’exécution, d’environnement d’exécution et de contrôle des versions binaires/licences). Les contraintes de licences x86 et le besoin de performance constante rendent Lambda inadapté. Conclusion: Les instances C6i fournissent le bon profil pour CPU soutenu, compatibilité x86 et prévisibilité — combinées à Auto Scaling et réservations/savings plans pour optimiser coûts, elles satisfont exigences enterprise.

Step 1: Profil des accès — de nombreuses petites opérations de métadonnées (création/suppression) exigent faible latence et forte consistance POSIX. Le volume doit être accessible simultanément par plusieurs tâches/instances dans différentes AZs.

Step 2: Analyser les options EFS/FSx/EBS — Amazon EFS fournit un système de fichiers partagé POSIX natif et multi-AZ (si configuré) ; le mode General Purpose est optimisé pour la latence (meilleure pour les opérations de métadonnées et l’IOPS par fichier). Le mode Max I/O permet d'augmenter le parallélisme et le débit global mais au prix d'une latence plus élevée pour les opérations individuelles, donc moins bon pour de nombreuses petites opérations. FSx for Lustre est optimisé pour throughput élevé et accès séquentiels (workloads HPC/ML), pas forcément pour la latence de métadonnées/RW POSIX multi-client à faible latence. Les volumes EBS sont dédiés à une instance et ne prennent pas en charge l'accès multi-attach (sauf io2 multi-attach avec contraintes), rendant la synchronisation manuelle risquée et opérationnellement coûteuse.

Step 3: Choix et mise en œuvre — déployer Amazon EFS en mode General Purpose avec throughput automatique ou provisionné si nécessaire ; activer les performances par point de montage, configurer les politiques de sécurité (VPC, NFS monté via VPC endpoints si nécessaire), et monitorer CloudWatch pour latence et throughput. Si le workload évolue vers des grands transferts en parallèle, réévaluer le mode Max I/O pour les ensembles de données spécifiques. Trap: Beaucoup pensent que Max I/O est toujours supérieur car il augmente le débit global ; en réalité, Max I/O augmente la latence pour les petites opérations et pénalise les workloads avec de nombreuses opérations de métadonnées. Pourquoi les mauvaises réponses échouent: - EFS Max I/O (option 2) : améliore le débit agrégé pour un grand nombre de clients, mais augmente la latence par opération — mauvais pour de nombreuses petites opérations de métadonnées nécessitant une faible latence. - FSx for Lustre (option 3) : excellent pour les workloads à haut débit séquentiel (ML/HPC) et peut être monté POSIX, mais il est souvent sans réplication multi-AZ native et n'est pas optimisé pour des milliers d'opérations de métadonnées à faible latence ; l'intégration avec S3 est meilleure pour données saisonnières et couches de données massives plutôt que pour petits fichiers POSIX fréquemment modifiés. - Volumes EBS + rsync (option 4) : architecture complexe, coûteuse en réseau et en opérations, difficile à maintenir la consistance entre instances, et non scalable pour des milliers de tâches ; en outre, EBS n'est pas conçu pour être partagé simultanément entre de nombreux consommateurs. Conclusion : EFS en General Purpose fournit le bon compromis latence/consistance/accès multi-AZ pour des microservices basés sur de nombreuses opérations de métadonnées.

Step 1: Analyser l'exigence — accès rare (quelques fois par trimestre) mais récupération doit être immédiate (latence millisecondes). L'objectif est minimiser coût de stockage tout en garantissant accès instantané quand nécessaire.

Step 2: Comparer classes S3 — S3 Standard : très performant, mais coûteux pour des données rarement accédées. S3 Intelligent-Tiering : automatise le mouvement entre classes en fonction de l'accès, mais ses couches plus froides (Archive Instant/Deep Archive Access) peuvent ne pas offrir l'accès milliseconde pour la couche la moins coûteuse. S3 Glacier Deep Archive : très économique, mais les récupérations prennent des heures (pas acceptable). S3 Glacier Instant Retrieval : spécialement conçu pour données rarement accédées mais nécessitant un accès immédiat ; il permet un coût de stockage inférieur à Standard tout en offrant latence d'accès très basse.

Step 3: Recommandation d'implémentation — stocker les objets dans S3 Glacier Instant Retrieval et utiliser des politiques de cycle de vie pour migrer automatiquement depuis Standard si des objets ne sont plus fréquemment accédés ; configurer les contrôles de coût et surveillance d'accès via S3 metrics/AWS Cost Explorer. Trap: Penser que Glacier = lenteur systématique — Glacier a plusieurs classes, et Glacier Instant Retrieval offre l'accès instantané; beaucoup confondent Deep Archive (très lent) et Glacier Instant Retrieval. Pourquoi chaque mauvais choix échoue: S3 Standard — fournit haute disponibilité et faible latence mais coûte bien plus pour des pétaoctets d'archive rarement accédés; S3 Intelligent-Tiering — peut être une bonne option si l'accès est imprévisible, mais pour accès clairement rare et besoin d'accès instantané garanti, Glacier Instant Retrieval est plus optimisé en coût; S3 Glacier Deep Archive — le plus économique pour archivage longue durée mais les temps de récupération (heures) ne respectent pas l'exigence d'accès quasi instantané. Remarques additionnelles: vérifier le modèle de coût (coût de stockage vs coût de récupération), envisager la combinaison de règles de cycle de vie et le chiffrement côté serveur pour la conformité. Pour de larges volumes où l'accès est déterminé comme rare mais occasionnellement critique et immédiat, Glacier Instant Retrieval est le meilleur compromis coût/performance.