3.1 - Diffusion de contenu performante (CloudFront)
L'objectif 3.1 de l'AWS Solutions Architect Associate couvre la conception pour une diffusion de contenu et un réseau performants. Amazon CloudFront est le réseau de diffusion de contenu (CDN) qui met en cache le contenu statique et dynamique dans des emplacements de périphérie proches des utilisateurs, réduisant la latence et déchargeant l'origine - un site mondial servant surtout des ressources statiques obtient ainsi une latence plus basse partout. Quand un site CloudFront doit exécuter une logique personnalisée comme du routage A/B, la manipulation d'en-têtes ou de l'autorisation en périphérie, les fonctions Lambda@Edge exécutent ce code aux emplacements de périphérie. Tu dois aussi connaître Global Accelerator pour la performance TCP/UDP, les comportements de cache et les origines comme S3 et les répartiteurs. Attends-toi à des mises en situation demandant le bon service - CloudFront ou Lambda@Edge.
Cache en périphérie, latence mondiale plus basse = CloudFront (CDN). Logique personnalisée (A/B, auth) en périphérie = Lambda@Edge. Performance TCP/UDP sur le backbone AWS = Global Accelerator.
Questions d'entraînement
1. Quel service met en cache le contenu statique et dynamique dans des emplacements périphériques pour réduire la latence mondiale d'un site web ?
- Amazon Route 53
- Amazon CloudFront (bonne réponse)
- AWS Global Accelerator
- Elastic Load Balancing
CloudFront est un CDN qui met en cache le contenu dans des emplacements périphériques proches des utilisateurs, réduisant la latence et déchargeant l'origine. Global Accelerator améliore le chemin réseau mais ne met pas en cache.
2. Quelle fonction DynamoDB renvoie des lectures en cache en microsecondes sans changer le code de requête de l'application ?
- Index secondaire global
- Mode de capacité à la demande
- DynamoDB Accelerator (DAX) (bonne réponse)
- Time to Live (TTL)
DAX est un cache en mémoire devant DynamoDB offrant des lectures en microsecondes avec un client compatible API, donc le code change à peine. Les GSI ajoutent des schémas de requête ; le TTL expire les éléments.
3. Quel type de volume EBS est le meilleur choix polyvalent par défaut, équilibrant prix et performance pour la plupart des charges ?
- gp3 (SSD à usage général) (bonne réponse)
- io2 Block Express (IOPS provisionnées)
- sc1 (HDD froid)
- st1 (HDD optimisé pour le débit)
gp3 est le SSD polyvalent par défaut, avec un bon rapport prix/performance et des IOPS et un débit configurables indépendamment. io2 vise les bases critiques à fortes IOPS ; les HDD conviennent aux charges séquentielles.
4. Une base relationnelle est saturée par le trafic de lecture alors que les écritures restent légères. Quel changement met à l'échelle les lectures avec le moins de refonte applicative ?
- Basculer la base vers DynamoDB
- Ajouter des réplicas de lecture Amazon RDS (bonne réponse)
- Activer le Multi-AZ sur le primaire
- Déplacer la base sur un stockage d'instance
Les réplicas de lecture déchargent les requêtes de lecture vers une ou plusieurs copies asynchrones, mettant à l'échelle les lectures sans refondre l'appli. Le Multi-AZ vise la disponibilité, pas la montée en lecture ; DynamoDB est une migration plus lourde.
5. Une API à trafic imprévisible sur DynamoDB ne doit jamais être limitée et ne devrait pas nécessiter de planification de capacité. Quel mode de capacité convient ?
- Mode capacité à la demande (bonne réponse)
- Capacité provisionnée à unités fixes
- Provisionnée sans mise à l'échelle auto
- Capacité réservée achetée à l'avance
Le mode à la demande s'adapte instantanément au trafic et facture par requête, idéal pour des charges en pics ou inconnues sans planification de capacité. Les unités provisionnées fixes limitent en cas de dépassement ; la capacité réservée suppose un usage stable et prévisible.
6. Une application a besoin d'un routage HTTP par hôte et par chemin, avec support des redirections et de WebSocket. Quel répartiteur de charge utiliser ?
- Un Network Load Balancer opérant en couche 4 pour un débit TCP brut
- Un Gateway Load Balancer transférant le trafic vers des appliances virtuelles
- Un Classic Load Balancer conservé pour ses fonctions historiques en couche 7
- Un Application Load Balancer routant par hôte et par chemin en couche 7 (bonne réponse)
L'ALB est le répartiteur de couche 7 supportant le routage par hôte/chemin, les redirections HTTP, les règles d'en-tête/requête et WebSocket/HTTP2. NLB est en couche 4 ; GWLB sert aux appliances en ligne.