Amazon SOA-C02: Réseaux et diffusion de contenu — Guide d'étude

By Laurynas Brazys · 2 August 2026 · #amazon #soa-c02 #certification #exam-prep #study-guide

Fait partie du AWS SysOps Administrator Associate SOA-C02 — Guide d’étude. Entraînez-vous avec des réponses vérifiées dans le centre d’examens Amazon, ou passez des tests chronométrés sur ExamRoll.io.

La section Réseau et diffusion de contenu couvre les fondations du VPC, les connexions hybrides, le DNS et le routage mondial, la mise en cache en périphérie avec CloudFront, et le cycle de vie des certificats TLS — tous essentiels pour la disponibilité, la sécurité et la performance. La maîtrise opérationnelle garantit que les charges de travail sont accessibles, résilientes aux pannes et sécurisées à la fois sur site (on-prem) et dans le cloud. Cette section se concentre sur les modèles de configuration pratiques, les exemples de CLI/console et les critères de décision que vous utiliserez en tant qu’administrateur SysOps pour la prise en charge des systèmes de production.

Conception du VPC, sous-réseaux, routage et connectivité

Concevez l’espace CIDR du VPC en prévision de la croissance future : allouez un VPC suffisamment grand (par exemple /16 ou /20 selon l’échelle) et divisez-le en sous-réseaux locaux à une AZ (10.0.0.0/24, 10.0.1.0/24 par AZ) pour éviter les dépendances inter-AZ. Créez des tables de routage explicites par type de sous-réseau : les sous-réseaux publics utilisent une route vers l’Internet Gateway (IGW) — par ex.,

undefined

; les sous-réseaux privés routent 0.0.0.0/0 vers une NAT Gateway dans la même AZ pour des coûts de sortie prévisibles et une latence plus faible.

Comprenez le comportement du NAT et les nuances du routage : une NAT Gateway/Instance effectue du NAT source pour les connexions IPv4 sortantes et exige que le trafic de retour suive la table de routage du sous-réseau pour repasser par le NAT. Pour l’IPv6, utilisez une passerelle Internet de sortie uniquement (egress-only internet gateway). Utilisez l’AWS CLI pour créer une NAT Gateway et associer une Elastic IP :

undefined

. Utilisez la propagation de route avec les attachements Transit Gateway ou VPN pour gérer automatiquement les routes dynamiques.

Les groupes de sécurité par rapport aux NACL et le flux de trafic doivent être configurés de manière intentionnelle : les groupes de sécurité sont stateful (vous autorisez le trafic entrant, le retour est automatique) et sont attachés aux ENI ; les NACL sont stateless et évalués par sous-réseau avec des règles ordonnées, vous devez donc autoriser à la fois les ports éphémères entrants et sortants. Exemples de commandes :

undefined

;

undefined

. Critères de décision : utilisez les groupes de sécurité pour le contrôle d’accès au niveau de l’instance et les NACL pour le filtrage de périmètre à haute performance et l’isolation entre comptes.

VPN, Direct Connect et réseau hybride

Sélectionnez la connectivité en fonction des besoins en bande passante, en latence et en résilience. Le VPN Site-to-Site fournit des tunnels IPsec chiffrés sur Internet et est rapide à déployer en utilisant

undefined

. Configurez deux tunnels VPN pour la haute disponibilité (HA) ; utilisez BGP pour le routage dynamique et la propagation de route via une Virtual Private Gateway ou une Transit Gateway. Utilisez AWS Managed VPN pour un déploiement rapide et comme solution de basculement (failover) pour Direct Connect.

Direct Connect offre une connectivité privée à large bande passante et à faible latence. Provisionnez une connexion (ou un LAG) avec la console Direct Connect et créez des interfaces virtuelles privées (VIF) vers les VPC via une Direct Connect Gateway pour un accès multi-régions. Utilisez BGP avec l’ASN approprié, et préférez une solution hybride DX + VPN : annoncez les préfixes critiques sur DX avec le VPN comme sauvegarde automatique. Critères de décision :

• Utilisez le VPN pour des besoins à court terme, une bande passante faible à moyenne, ou comme sauvegarde chiffrée basée sur Internet.
• Utilisez Direct Connect lorsque le débit élevé soutenu et la latence prévisible justifient les coûts de port et d’interconnexion.
• Utilisez Transit Gateway pour centraliser de nombreuses connexions VPC et sur site (on-prem) si vous avez besoin d’une architecture en étoile (hub-and-spoke) et d’une gestion de routage simplifiée.

Liste de contrôle opérationnelle : confirmez que les sessions BGP sont actives, assurez la propagation des tables de routage (pour TGW, utilisez

undefined

), et testez le basculement en désactivant un tunnel ou en modifiant les chemins BGP.

DNS Route 53, bilans de santé et stratégies de routage

Route 53 est à la fois un DNS faisant autorité et un plan de contrôle de routage. Implémentez des bilans de santé (health checks) pour les points de terminaison (endpoints) (HTTP/HTTPS/TCP) et associez-les à des enregistrements de basculement (failover) ou pondérés (weighted). Exemple : créez un enregistrement de basculement avec des types d’enregistrements primaire/secondaire sur la console Route 53 ou utilisez

undefined

avec une stratégie de routage Failover et un HealthCheckId. Utilisez l’ajustement du TTL en fonction du SLA de basculement attendu — un TTL bas (30-60s) pour un basculement actif, plus long (300s+) pour les points de terminaison stables.

Choisissez la stratégie de routage en fonction de l’objectif :

• Simple : renvoie une seule valeur ; à utiliser pour les points de terminaison non critiques ou uniques.
• Basculement (Failover) : primaire/secondaire avec bilans de santé pour la gestion des sinistres.
• Pondérée (Weighted) : répartition progressive du trafic pour les déploiements blue/green ou canary.
• Basée sur la latence (Latency-based) : achemine les utilisateurs vers la région ayant la plus faible latence.
• Géolocalisation/Géoproximité (Geolocation/geoproximity) : pour se conformer à la résidence des données ou pour du contenu ciblé.

Points de décision :

• Pour une application mondiale avec des régions en actif-actif et des ELB : utilisez des enregistrements Alias pointant vers les ALB/ELB pour éviter des frais supplémentaires et tirer parti de la santé des points de terminaison.
• Pour les migrations planifiées ou la mise en forme du trafic (traffic shaping) : utilisez des enregistrements pondérés (Weighted) et modifiez les poids de manière incrémentielle via la CLI (

undefined

).

• Pour une récupération rapide après des pannes de centre de données : utilisez le routage de basculement (Failover) avec des TTL bas et des bilans de santé robustes.

CDN CloudFront, stratégies de mise en cache et invalidation

CloudFront accélère la diffusion de contenu en le mettant en cache dans des emplacements périphériques (edge locations) et en réduisant la charge sur l’origine. Configurez les comportements de cache (Cache Behaviors) par modèle de chemin (path pattern) ; contrôlez la mise en cache à l’aide des en-têtes Cache-Control et Expires provenant de l’origine ou surchargez-les via les valeurs transférées (Forwarded Values) et les TTL minimum/maximum dans les paramètres de la distribution. Utilisez Origin Shield pour réduire la charge sur l’origine provenant de plusieurs emplacements périphériques.

Stratégies de cache clés :

• Ressources statiques : TTL longs, utilisez le fingerprinting (versionnement d’objets) pour que l’invalidation ne soit pas nécessaire.
• Contenu dynamique : définissez Cache-Control: no-cache ou un TTL minimal et utilisez Lambda@Edge ou une politique de cache (Cache Policy) pour mettre en cache sélectivement en fonction des en-têtes/cookies.
• API : envisagez un cache régional (API Gateway + CloudFront) avec des TTL courts.

Modèles d’invalidation et de gestion :

• Utilisez aws cloudfront create-invalidation --distribution-id E123 --paths "/index.html" ou "/*" pour une suppression immédiate ; notez les coûts d’invalidation pour les modèles larges.
• Préférez le versionnement d’objets (changement de nom de fichier ou versionnement par chaîne de requête) pour éviter les invalidations fréquentes.
• Assurez la configuration de l’origine : une origine S3 doit être verrouillée avec Origin Access Control (OAC) ou OAI pour que seul CloudFront puisse lire ; pour une origine ALB, assurez-vous que les vérifications de santé (health checks) et les paramètres d’adhérence (stickiness) sont alignés sur le comportement de CloudFront.

Certificats TLS, ACM et cycle de vie des certificats

Utilisez AWS Certificate Manager (ACM) pour provisionner des certificats pour ELB, CloudFront et API Gateway. Demandez des certificats publics avec aws acm request-certificate --domain-name example.com --validation-method DNS pour une validation DNS, ce qui permet un renouvellement automatisé. Important : CloudFront requiert des certificats ACM dans la région us-east-1 ; les services régionaux (ALB, API Gateway regional) requièrent des certificats dans la région cible.

Modèles de validation et de rotation :

• La validation DNS automatise le renouvellement et est la méthode préférée pour la production ; créez des enregistrements CNAME dans Route 53 via la console ou avec aws route53 change-resource-record-sets.
• Pour les certificats manuels ou importés, utilisez aws acm import-certificate et suivez l’expiration avec aws acm list-certificates --certificate-statuses ISSUED.
• Effectuez la rotation des certificats en déployant le nouveau certificat à côté de l’ancien (ajoutez-le à l’ALB ou à la distribution CloudFront), vérifiez le trafic, puis supprimez l’ancien certificat avant son expiration.

Critères de décision : utilisez ACM pour les certificats publics attachés aux points de terminaison gérés par AWS. N’utilisez des certificats importés que lorsque des autorités de certification (CA) privées ou des ancres de confiance externes sont requises.

Pièges courants et critères de décision

• Règles de groupe de sécurité ou de table de routage incorrectes rendant les instances inaccessibles — vérifiez les règles entrantes et sortantes du groupe de sécurité et les entrées 0.0.0.0/0 de la table de routage ; rappelez-vous que les groupes de sécurité sont stateful, tandis que les NACL sont stateless et nécessitent des autorisations explicites pour les ports éphémères.
• TTL DNS mal configurés provoquant un routage obsolète après un basculement — définissez les TTL en fonction des fenêtres de basculement (TTL courts pour un basculement actif) et testez le basculement avec les vérifications de santé activées.
• Négliger la configuration de l’origine CloudFront et l’OAC/OAI — verrouillez les origines S3 pour que les buckets ne soient pas publics et assurez-vous que l’identité d’origine de CloudFront peut lire les objets.
• Se fier à Direct Connect sans sauvegarde VPN — concevez toujours une architecture hybride DX + VPN pour la résilience et validez le comportement de basculement BGP.
• Placer les passerelles NAT (NAT Gateways) dans une seule AZ — créez des passerelles NAT par AZ pour éviter les chemins de données inter-AZ et une défaillance de la sortie dans une seule AZ.
• Oublier les règles de région d’ACM pour CloudFront — demandez les certificats publics dans us-east-1 pour CloudFront ; les services fédérés ou régionaux nécessitent des certificats régionaux.

Problème pratique : Scénario d’utilisation

AcmePayments exploite une application de paiement mondiale avec des ALB régionaux, un site statique hébergé sur S3 et un datacenter sur site (on-prem) nécessitant des liens à haut débit pour les transactions. Ils ont besoin d’une latence prévisible, d’une distribution sécurisée pour le contenu statique et d’un basculement rapide en cas de dégradation d’une région.

1. Concevez des VPC avec des sous-réseaux publics et privés locaux à chaque AZ ; déployez des NAT Gateways par AZ et configurez les tables de routage pour que les sous-réseaux privés sortent via la NAT locale.
2. Provisionnez une connexion Direct Connect avec une VIF privée vers la région la plus proche et configurez un VPN Site-to-Site redondant comme basculement automatique en utilisant BGP avec une propagation de route appropriée vers un Transit Gateway.
3. Utilisez le routage basé sur la latence (latency-based routing) de Route 53 pour les ALB avec des vérifications de santé et des TTL bas pour les points de terminaison critiques ; implémentez des enregistrements pondérés (weighted records) pour des tests de basculement progressifs.
4. Déployez CloudFront pour le site statique avec une origine S3 sécurisée par Origin Access Control et définissez des TTL longs ainsi qu’un versionnement d’objets pour éviter l’invalidation ; utilisez Lambda@Edge pour la manipulation d’en-têtes requise.
5. Demandez des certificats ACM via la validation DNS (dans us-east-1 pour CloudFront) et déployez les nouveaux certificats à côté des certificats existants pour une rotation de type bleu/vert (blue/green), puis supprimez les anciens avant leur expiration.

Justification : ces étapes isolent les domaines de défaillance, fournissent un routage mondial à faible latence, sécurisent et mettent en cache les ressources statiques en périphérie, et garantissent que le cycle de vie des certificats est automatisé et non perturbateur — s’alignant sur les meilleures pratiques en matière de disponibilité opérationnelle et de sécurité.

← Sécurité · Tous les domaines · Stockage et gestion des données →

Entraînez-vous sur ces questions → · Tests chronométrés sur ExamRoll.io →

Parcourir Amazon →