Amazon DOP-C02: Réseau et livraison de contenu — Guide d'étude

By Laurynas Brazys · 4 August 2026 · #amazon #dop-c02 #certification #exam-prep #study-guide

Fait partie du AWS DevOps Engineer Professional DOP-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.

Vue d’ensemble

Le réseau et la distribution de contenu sur AWS couvrent les constructions VPC fondamentales, les choix d’interconnexion pour les topologies multi-comptes et hybrides, ainsi que les services en périphérie (edge) qui servent de façade, protègent et accélèrent les applications à l’échelle mondiale. La maîtrise de ces concepts exige de comprendre comment les paquets se déplacent dans un VPC (subnets, tables de routage, passerelles et filtrage), comment interconnecter les VPC et les réseaux sur site (peering, Transit Gateway, PrivateLink, Direct Connect, VPN), et comment distribuer et protéger le trafic en périphérie (CloudFront, AWS WAF, AWS Global Accelerator). Les points d’entrée applicatifs tels qu’Amazon API Gateway s’intègrent ensuite à ces primitives via des domaines personnalisés, des certificats et des types de points de terminaison.

Architecture VPC et contrôles de sécurité

Un VPC est un réseau régional, logiquement isolé, avec un ou plusieurs subnets dans chaque zone de disponibilité. Concevez les subnets en fonction des domaines de pannes et des fonctions : subnets publics pour les load balancers exposés sur Internet et les passerelles NAT ; subnets applicatifs privés pour les nœuds EC2/ECS/EKS ; et subnets de données privés pour les bases de données. Assignez des tables de routage distinctes par type de subnet pour maintenir une intention explicite et pour prendre en charge une conception de sortie zonale.

La connectivité Internet est fournie par une passerelle Internet (IGW) attachée au niveau du VPC. Un subnet devient « public » lorsque sa table de routage a une route par défaut vers l’IGW et que les ressources ont des adresses IP publiques ou des IP élastiques. Pour un accès Internet sortant uniquement depuis des subnets privés, utilisez des passerelles NAT. Placez une passerelle NAT par zone de disponibilité, routez chaque subnet privé vers la passerelle NAT de la même AZ, et désactivez le NAT inter-AZ pour éviter les points de défaillance uniques (single points of failure) et réduire les frais de traitement des données inter-AZ. Pour IPv6, les passerelles Internet de sortie uniquement (egress-only) fournissent une connectivité sortante uniquement, sans NAT.

Les tables de routage déterminent les prochains sauts (next hops) pour les préfixes de destination. Les cibles courantes incluent l’IGW, la passerelle NAT, les attachements de VPC peering, les attachements Transit Gateway et local. Gardez les tables de routage simples : une route par défaut pour la sortie (egress) et des routes explicites pour les interconnexions privées. Préférez les listes de préfixes pour référencer des destinations partagées entre les comptes et pour réduire les erreurs humaines.

Les groupes de sécurité et les ACL réseau (network ACLs) fournissent un filtrage réseau, mais avec des mécanismes différents :

Les groupes de sécurité sont à état (stateful), attachés aux ENI, et n’évaluent que les règles d’autorisation (allow). Le trafic retour est automatiquement autorisé. Ils prennent en charge les références à d’autres groupes de sécurité pour exprimer la topologie applicative de manière sécurisée.
Les ACL réseau sont sans état (stateless), appliqués à la frontière du subnet, évalués par ordre de règle avec des autorisations/refus (allow/deny) explicites pour le trafic entrant et sortant. Le trafic retour doit être explicitement autorisé. Utilisez les NACL avec parcimonie pour des refus globaux au niveau du subnet ou pour des modèles de conformité ; maintenez les plages de ports éphémères requises par vos systèmes d’exploitation et vos load balancers.

La distinction entre filtrage à état et sans état est importante pour le dépannage. Si les deux sont utilisés, les deux doivent autoriser le flux. Activez les VPC Flow Logs vers CloudWatch Logs ou S3 pour analyser le trafic accepté/refusé et pour valider la posture de sécurité.

Connectivité inter-VPC et hybride

Le VPC peering connecte deux VPC de manière privée, sans point de défaillance unique et sans goulot d’étranglement de bande passante, mais il est non transitif et requiert des blocs CIDR qui ne se chevauchent pas. Chaque VPC doit ajouter des routes statiques pour le pair via l’attachement de peering. Les références de groupes de sécurité entre VPC pairés ne sont pas prises en charge ; filtrez avec les CIDR. Le peering inter-régional est disponible et chiffré par défaut.

AWS Transit Gateway (TGW) simplifie la mise à l’échelle et la segmentation du réseau. Il agit comme un hub régional pour les VPC et les attachements hybrides, prend en charge le routage transitif et peut atteindre des dizaines de Gbps par attachement. Utilisez les tables de routage du TGW pour implémenter la segmentation (par ex., dev vs prod vs services partagés) et pour contrôler la propagation et l’association. Les attachements incluent les VPC, les VPN Site-to-Site, et Direct Connect via une VIF de transit et une Direct Connect Gateway. Pour une sortie centralisée (egress), attachez un VPC de sortie et propagez/partagez sélectivement les routes. Planifiez pour le multi-région en connectant les TGW avec un peering inter-régional.

AWS PrivateLink fournit un accès privé de niveau 4 (L4), initié par le consommateur, à des services à travers les frontières de VPC/compte/région sans exposer les subnets du fournisseur ni nécessiter de routage. Le fournisseur de services place un NLB devant des points de terminaison ; les consommateurs créent des points de terminaison d’interface VPC dans leurs VPC avec des adresses IP privées et des noms DNS assignés. PrivateLink n’est pas transitif et ne prend en charge que le TCP. Utilisez PrivateLink pour publier des services internes ou pour consommer des services AWS de manière privée. Préférez PrivateLink au peering/TGW lorsque vous avez besoin d’une exposition au niveau du service, d’une consommation basée sur le DNS ou d’une isolation plus stricte du producteur.

La connectivité hybride combine souvent Direct Connect (DX) et le VPN Site-to-Site. Direct Connect fournit une bande passante dédiée, privée et constante avec des ports de 1/10 Gbps (et des capacités hébergées). Utilisez BGP pour le routage dynamique et le basculement (failover). Types d’interfaces virtuelles (VIF) :

VIF privée : joignabilité par IP privée vers des VPC via une passerelle privée virtuelle (VGW) ou via un Transit Gateway avec une VIF de transit.
VIF publique : joignabilité par IP publique vers les services publics AWS ; annoncez vos préfixes publics ; AWS annonce ses préfixes publics mondiaux.
VIF de transit : connecte une Direct Connect gateway à un ou plusieurs TGW pour une connectivité multi-VPC/multi-région évolutive. Concevez la redondance en utilisant deux connexions DX physiques dans des emplacements et sur des équipements DX distincts, avec des LAG séparés si nécessaire, et des routeurs doubles sur site. Ajoutez un VPN de secours (VPN sur Internet vers VGW ou TGW) avec BGP pour que les routes basculent automatiquement lorsque les sessions BGP de DX tombent. Pour le VPN, utilisez deux tunnels par connexion pour la haute disponibilité ; préférez BGP aux routes statiques ; validez les CIDR internes du tunnel et la sécurité.

Réseaux Edge, Sécurité et Accélération

Amazon CloudFront est un CDN mondial qui accélère le contenu statique et dynamique grâce à la mise en cache en périphérie (edge) et à des chemins réseau optimisés. Une distribution définit :

Origines : S3, origines personnalisées (ALB/NLB/EC2/API Gateway), ou groupes d’origines pour le basculement (failover). Activez Origin Shield pour une couche de cache intermédiaire supplémentaire afin de réduire la charge sur l’origine.
Comportements : routage vers les origines basé sur le chemin et la méthode, politiques de cache et de requête d’origine (transfert d’en-têtes/cookies/requêtes), politiques de protocole du visualiseur (HTTP→HTTPS), compression, URL/cookies signés, et hooks de fonction (CloudFront Functions pour les requêtes légères du visualiseur ; Lambda@Edge pour la manipulation des requêtes/réponses).
Mise en cache : ajustez les TTL via les politiques de cache, ne faites varier les clés que sur les dimensions nécessaires, et utilisez les politiques de requête d’origine pour minimiser la fragmentation du cache. Pour les API, évitez de transférer les en-têtes/cookies/requêtes inutiles. Utilisez le chiffrement au niveau du champ (field-level encryption) si nécessaire.
Invalidation : émettez des invalidations pour les chemins modifiés ou utilisez des clés d’objet versionnées pour des mises à jour de cache sans interruption de service. Automatisez les invalidations après le déploiement pour les ressources non versionnées.

AWS WAF protège les applications au niveau de la couche 7 (L7). Une Web ACL contient des règles et des groupes de règles évalués en séquence, avec une action par défaut. Utilisez les AWS Managed Rules pour les protections de base (par ex., CommonRuleSet, WordPress, SQLi/XSS), et des groupes de règles de partenaires sélectionnés si nécessaire. Ajoutez des règles personnalisées en utilisant des déclarations de correspondance (match statements) (ensemble d’IP, en-tête, URI, corps JSON, correspondance d’étiquette), et combinez-les avec des opérateurs logiques. Les règles basées sur le débit (rate-based rules) limitent les clients qui dépassent un taux de requêtes configuré dans une fenêtre de temps, avec en option des déclarations de restriction de portée (scope-down statements) pour cibler des chemins ou des en-têtes spécifiques. Associez les Web ACLs aux distributions CloudFront, aux Application Load Balancers, à API Gateway (REST/HTTP) et à AppSync. Surveillez la capacité (WCU), activez les journaux échantillonnés vers CloudWatch Logs ou Kinesis Data Firehose, et utilisez les actions CAPTCHA/Challenge pour atténuer les bots sans bloquer le trafic légitime.

AWS Global Accelerator fournit des adresses IP anycast statiques qui servent de façade aux points de terminaison (endpoints) régionaux et accélère le trafic TCP/UDP sur le réseau mondial d’AWS. Il fonctionne aux couches 4/7 (L4/7) avec un routage basé sur l’état de santé (health-based routing) et un basculement rapide. Configurez :

Groupes de points de terminaison (Endpoint groups) par Région avec des vérifications de l’état de santé (health checks) et des poids (weights).
Sélecteurs de trafic (Traffic dials) pour contrôler le pourcentage de trafic envoyé à une Région (par ex., 1 % en canary ou 0 % pendant la maintenance) indépendamment des poids des points de terminaison. Les points de terminaison pris en charge incluent les ALB, NLB, les instances EC2 et les Elastic IPs. Utilisez Global Accelerator pour les protocoles non-HTTP, sensibles à la latence, avec état (stateful), ou lorsque des adresses IP statiques et un basculement déterministe sont requis. CloudFront reste le choix principal pour la mise en cache HTTP/S et l’exécution de fonctions en périphérie (edge) ; les deux services sont complémentaires.

Façades d’API : Domaines, certificats et stratégie de points de terminaison

Amazon API Gateway fournit des API REST et HTTP avec trois types de points de terminaison :

Optimisé pour l’Edge (API REST uniquement) : API Gateway crée et gère une distribution CloudFront ; optimal pour les clients mondiaux avec une terminaison TLS aux emplacements périphériques (edge locations). Les certificats de domaine personnalisé doivent être dans us-east-1 (N. Virginia) via ACM.
Régional : pour les clients dans la même Région ou lorsque vous souhaitez placer votre propre distribution CloudFront ou Global Accelerator devant API Gateway. Les certificats de domaine personnalisé doivent être dans la même Région que l’API.
Privé : accessible uniquement depuis vos VPC via des points de terminaison d’interface VPC ; aucun chemin d’accès public par Internet.

Les domaines personnalisés unifient le routage et le TLS entre les étapes (stages) et les API. Utilisez les mappages de chemins de base (base path mappings) pour mapper les chemins vers les étapes. Stockez les certificats dans ACM ; choisissez RSA/ECDSA en fonction du support client. Pour les points de terminaison optimisés pour l’Edge, demandez/importez le certificat dans us-east-1. Pour les points de terminaison régionaux, demandez/importez-le dans la Région. Appliquez des politiques TLS qui correspondent à votre posture de conformité. Intégrez avec WAF en associant une web ACL directement aux API régionales ou en protégeant la distribution CloudFront qui se trouve devant l’API. Pour des API mondiales à latence minimale avec une mise en cache avancée et une normalisation des en-têtes, placez une distribution CloudFront devant une API régionale, utilisez le contrôle d’accès à l’origine (origin access control) et les requêtes signées si nécessaire, et ajustez les politiques de cache et de requête d’origine pour éviter le gonflement du cache (cache bloat). Combinez avec les autorisateurs Lambda ou Amazon Cognito pour l’authentification et utilisez la limitation (throttling) et les plans d’utilisation (usage plans) pour protéger les backends en plus des règles basées sur le débit (rate-based rules) de WAF.

Scénario de problème pratique

Shopify déploie un nouveau microservice de paiement mondial pour servir les commerçants du monde entier. Exigences : trafic est-ouest privé entre les microservices répartis sur plus de 20 comptes, aucune exposition publique pour les API internes, faible latence déterministe pour les utilisateurs finaux lors du paiement, protections L7 robustes avec limitation de débit adaptative, et connectivité hybride résiliente vers les moteurs de risque sur site (on-premises).

Approche étape par étape :

Segmentez le réseau avec une conception Transit Gateway en étoile (hub-and-spoke)

Créez un compte de réseau centralisé avec un AWS Transit Gateway régional. Attachez tous les VPC de charge de travail (spokes) de chaque compte via des attachements TGW partagés avec RAM. Utilisez plusieurs tables de routage TGW pour appliquer la segmentation (prod vs services partagés vs dev) et ne propager que les routes nécessaires.
Pourquoi TGW : Met à l’échelle le routage transitif et simplifie la gestion des routes par rapport à un maillage complet de peerings ; prend en charge les attachements hybrides.

Publiez les microservices internes avec AWS PrivateLink

Dans chaque VPC producteur, placez un NLB devant les groupes cibles des microservices internes et créez un service de point de terminaison VPC. Dans les VPC consommateurs, créez des points de terminaison d’interface pour ces services et activez le DNS privé spécifique au point de terminaison.
Pourquoi PrivateLink : Connectivité au niveau du service, uniquement TCP, non transitive et sans exposition de route ; les producteurs restent isolés et n’ont pas besoin d’autorisations SG entrantes pour des blocs CIDR entiers.

Établissez une connectivité hybride redondante avec Direct Connect et VPN

Provisionnez deux connexions Direct Connect de 10 Gbit/s dans des emplacements DX distincts, terminées sur des routeurs sur site séparés. Créez une Direct Connect Gateway avec une VIF de transit (Transit VIF) vers le TGW. Configurez BGP des deux côtés avec des ASN distincts et des politiques MED/local-pref. Ajoutez un attachement Site-to-Site VPN au TGW comme sauvegarde avec deux tunnels, avec BGP activé.
Pourquoi ce mélange : DX fournit une bande passante déterministe et une gigue (jitter) plus faible ; BGP plus une sauvegarde VPN offrent un basculement automatique et une haute disponibilité.

Exposez le service de paiement public avec AWS Global Accelerator

Créez un accélérateur avec deux écouteurs (listeners) (80/443 → 443). Définissez des groupes de points de terminaison dans us-east-1 et eu-west-1, chacun pointant vers des ALB pour le service de paiement. Réglez les cadrans de trafic (traffic dials) à 50/50 pour le régime permanent et activez les vérifications de l’état (health checks) sur les points de terminaison de santé de l’ALB. Activez l’affinité client (client affinity) si l’épinglage de session (session pinning) est requis.
Pourquoi Global Accelerator : Adresses IP statiques Anycast, basculement régional rapide et optimisation TCP pour des flux de paiement avec état (stateful) à faible latence.

Protégez en périphérie avec CloudFront et AWS WAF

Placez CloudFront devant l’API Gateway régionale (pour les GET idempotents et les actifs statiques) et directement devant les ALB servant du contenu dynamique pouvant bénéficier de la normalisation des en-têtes et du déchargement TLS (TLS offload). Configurez les politiques de cache pour restreindre la variance aux en-têtes/requêtes nécessaires, activez Origin Shield pour réduire la charge sur l’origine, et automatisez les invalidations pour les actifs non versionnés.
Attachez une web ACL AWS WAF à CloudFront avec les règles gérées par AWS (AWS Managed Rules), un groupe de règles personnalisé pour le filtrage de la logique métier, et une règle basée sur le débit (rate-based rule) avec une déclaration de portée réduite (scope-down statement) sur les chemins de paiement. Activez CAPTCHA pour les pics suspects et consignez les journaux dans Kinesis Data Firehose pour l’analyse.
Pourquoi CloudFront + WAF : Terminaison TLS mondiale, mise en cache là où c’est sûr, contrôles L7 en périphérie et absorption des attaques DDoS via AWS Shield.

Exposez les API avec des domaines personnalisés et un TLS robuste

Utilisez des points de terminaison régionaux API Gateway pour les méthodes d’API à forte écriture, protégés derrière CloudFront. Créez des domaines personnalisés dans ACM par Région, appliquez des politiques TLS strictes et mappez les chemins de base vers les étapes (stages). Pour les API d’administration internes, déployez des API privées et accédez-y via des points de terminaison d’interface VPC ; associez des groupes de sécurité du moindre privilège.
Pourquoi cette séparation : Les points de terminaison régionaux plus CloudFront offrent de la flexibilité avec des contrôles en périphérie ; les API privées gardent les surfaces internes hors d’Internet.

Verrouillez les VPC avec des contrôles en couches

Appliquez des groupes de sécurité (security groups) avec état (stateful) basés sur le moindre privilège, en référençant les SG des producteurs/consommateurs lorsque c’est possible. Gardez les NACL simples (tout autoriser) sauf pour des refus ciblés de sous-réseaux nécessaires à la conformité. Activez les VPC Flow Logs avec des filtres de métriques CloudWatch pour détecter les sources anormales. Placez une passerelle NAT (NAT gateway) par AZ et routez les sous-réseaux privés vers la NAT locale pour éviter les dépendances inter-AZ.
Pourquoi des contrôles en couches : Les SG gèrent la plupart des intentions avec le suivi des connexions ; les NACL fournissent des garde-fous grossiers ; la NAT zonale améliore la résilience et les coûts.

Cette conception fournit une connectivité est-ouest privée et segmentée (Transit Gateway + PrivateLink), des chemins hybrides nord-sud résilients (DX + VPN avec BGP), un point d’entrée public mondialement accéléré et protégé (Global Accelerator + CloudFront + WAF), et des contrôles opérationnels alignés sur les meilleures pratiques AWS pour le routage, les passerelles et le filtrage VPC.

← Stockage · Tous les domaines · Systems Manager →

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