Amazon CLF-C02: Réseau et distribution de contenu — Guide d'étude

By Laurynas Brazys · 28 July 2026 · #amazon #clf-c02 #certification #exam-prep #study-guide

Fait partie du AWS Cloud Practitioner CLF-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.

Principes fondamentaux et modèles de conception des VPC

Un Virtual Private Cloud (VPC) est la construction réseau fondamentale : il définit l’espace d’adressage IP, les sous-réseaux, les tables de routage et les passerelles qui déterminent comment les ressources communiquent en interne et avec Internet. Une bonne conception de VPC segmente les charges de travail en sous-réseaux publics pour les services exposés à Internet et en sous-réseaux privés pour les couches applicatives et de données, avec des tables de routage qui contrôlent le trafic nord-sud. Une Internet Gateway (IGW) permet l’accès Internet IPv4 pour les sous-réseaux publics, tandis qu’une NAT Gateway ou une instance NAT fournit un accès Internet sortant pour les sous-réseaux privés ; la NAT Gateway est gérée et s’adapte automatiquement, mais entraîne des frais horaires et par Go traité, alors que les instances NAT nécessitent l’application de correctifs et une planification de la capacité. La propagation des routes, les routes explicites et l’utilisation de passerelles Internet de sortie uniquement (egress-only) pour IPv6 sont des concepts fondamentaux. Les points de terminaison VPC (VPC endpoints) — points de terminaison de passerelle pour S3 et DynamoDB et points de terminaison d’interface (PrivateLink) pour de nombreuses API AWS — vous permettent d’éviter la sortie vers Internet et de réduire les coûts de transfert de données. Les pièges courants pour les praticiens incluent des tables de routage mal configurées qui isolent les sous-réseaux, une surutilisation des instances NAT et un manque d’architecture pour la redondance au niveau des zones de disponibilité (AZ) ; assurez-vous que les tables de routage, les IGW/NAT et les placements tenant compte de l’état de santé éliminent les points de défaillance uniques tout en gardant à l’esprit les coûts de transfert de données et les performances. Tenez compte des modèles de tarification EC2 (à la demande, instances réservées, Savings Plans) lors du dimensionnement correct des ressources de calcul entre les AZ pour maîtriser les coûts tout en atteignant les objectifs de disponibilité.

Connectivité hybride et réseau mondial

La connexion d’environnements sur site à AWS nécessite des compromis entre le coût, la latence, la redondance et la complexité opérationnelle. Les VPN Site-to-Site sont rapides à déployer et chiffrés sur Internet, adaptés à une bande passante faible à modérée ou comme solution de secours. AWS Direct Connect fournit une liaison privée, prévisible et à faible latence, facturée à l’heure de port plus le transfert de données ; il convient aux charges de travail stables à haut débit mais nécessite l’approvisionnement d’un circuit et une colocation. Transit Gateway simplifie la connectivité multi-VPC et hybride en centralisant le routage et en s’adaptant mieux que de nombreuses liaisons d’appairage VPC, bien qu’il ajoute des frais par attachement et par Go ; l’appairage VPC (VPC peering) reste utile pour une connectivité VPC point à point à faible latence sans routage transitif. Utilisez des connexions DX redondantes acheminées via différents emplacements ou combinez DX avec un VPN pour la résilience. Route 53 prend en charge les politiques DNS mondiales (latence, géolocalisation, basculement) pour diriger les utilisateurs et fournir des bilans de santé (health checks). Les critères de décision pour les praticiens dépendent de la prévisibilité de la bande passante, des SLA requis et du coût : préférez Direct Connect pour un trafic sortant élevé et constant et Transit Gateway pour de nombreux VPC afin d’éviter la complexité de l’appairage en N^2, mais prévoyez un budget pour les frais de port DX et les attachements Transit Gateway.

Diffusion de contenu et gestion du trafic mondial

Amazon CloudFront est un réseau de diffusion de contenu (CDN) mondial et sans serveur (serverless) dont le but principal est de mettre en cache le contenu statique et dynamique dans des emplacements périphériques (edge locations) pour réduire la latence et la charge sur l’origine. CloudFront prend en charge HTTP(s) et s’intègre avec S3, ALB, API Gateway et des origines personnalisées, et peut exécuter du code en périphérie via Lambda@Edge ou des fonctions rapides via CloudFront Functions. S3 Transfer Acceleration exploite spécifiquement les emplacements périphériques et le réseau principal (backbone) d’AWS pour accélérer les téléversements vers S3 depuis des clients distants et est facturé par Go et par région. AWS Global Accelerator fournit des adresses IP anycast statiques et optimise le trafic TCP/UDP sur le réseau mondial d’AWS pour les applications non HTTP ou sensibles à la latence ; il ne met pas en cache le contenu. Choisissez CloudFront lorsque la mise en cache et le délestage de l’origine génèrent des gains de coût et de performance ; choisissez Global Accelerator lorsque vous avez besoin d’un routage déterministe et optimisé pour TCP/UDP et d’une adresse IP d’entrée fixe. Les différences de tarification sont importantes : CloudFront facture par requête et par Go avec des remises par paliers, et Global Accelerator facture des frais horaires pour l’accélérateur plus le transfert de données. Un piège courant est de s’attendre à ce que Global Accelerator fournisse une mise en cache — utilisez-le pour le routage et le basculement, et CloudFront pour la mise en cache.

Sécurité réseau, observabilité et contrôles opérationnels

La sécurité réseau dans AWS est multicouche : les groupes de sécurité (security groups) sont des pare-feu avec état (stateful) au niveau de l’instance qui contrôlent le trafic entrant/sortant autorisé ; les listes de contrôle d’accès réseau (network ACLs) sont des contrôles sans état (stateless) au niveau du sous-réseau pour un filtrage grossier. AWS Network Firewall et les règles WAF gérées protègent contre les menaces protocolaires et applicatives, tandis qu’AWS Shield protège contre les attaques DDoS — Shield Standard est automatique, Shield Advanced ajoute des protections et une récupération des coûts. Les journaux de flux VPC (VPC Flow Logs) capturent les métadonnées du trafic pour le dépannage et l’audit, et la centralisation des journaux dans CloudWatch Logs ou S3 facilite la réponse aux incidents et la conformité. Utilisez PrivateLink et les points de terminaison VPC (VPC endpoints) pour minimiser l’exposition publique des API sensibles, et appliquez le principe de moindre privilège avec les politiques de point de terminaison et IAM. Les contrôles opérationnels incluent les bilans de santé (health checks) avec ELB et Auto Scaling pour maintenir des flottes EC2 saines, et les bilans de santé Route 53 pour le basculement DNS (DNS failover). Les pièges typiques incluent des groupes de sécurité trop permissifs, le fait de se fier aux NACL comme défense principale, la négligence des journaux de flux ou du WAF pour les charges de travail web, et des frais de transfert de données inattendus lors du franchissement de zones de disponibilité (AZ) ou de l’utilisation de la sortie Internet (internet egress). Concevez une défense en profondeur, activez l’observabilité dès le début, et modélisez les coûts pour le trafic NAT/egress et inter-AZ.

Problème pratique : Scénario d’utilisation

Scénario : AcmeRetail exploite un VPC sur trois zones de disponibilité (AZ) avec une couche applicative sur EC2 derrière un Application Load Balancer, S3 pour les ressources statiques, et un centre de données hérité (legacy) connecté à AWS. Ils ont besoin d’une latence plus faible pour leurs clients mondiaux, d’une connectivité sur site (on-prem) sécurisée pour le traitement des commandes, et de coûts de transfert prévisibles pour d’importantes sauvegardes nocturnes.

Défi : Réduire la latence pour les utilisateurs mondiaux pour le contenu statique et dynamique, sécuriser et stabiliser la connectivité sur site pour des sauvegardes à haut débit, et minimiser les frais de sortie (egress) imprévus.

Approche recommandée :

1. Déployer Amazon CloudFront avec S3 et l’ALB comme origines pour mettre en cache les ressources statiques et accélérer les réponses dynamiques, en activant Origin Shield et Lambda@Edge pour le routage basé sur les en-têtes.
2. Provisionner AWS Direct Connect avec des liaisons redondantes et utiliser un Transit Gateway pour centraliser le routage entre les VPC et la passerelle Direct Connect ; conserver le VPN Site-to-Site comme solution de basculement (failover).
3. Configurer des points de terminaison VPC (de type passerelle pour S3, de type interface si nécessaire) pour router les sauvegardes vers S3 via le réseau principal (backbone) d’AWS et éviter les frais de sortie vers l’Internet public.
4. Mettre en œuvre le routage basé sur la latence (latency routing) et les bilans de santé de Route 53, activer les VPC Flow Logs, le WAF sur l’ALB, et utiliser des groupes Auto Scaling avec les bilans de santé de l’ELB pour maintenir une capacité EC2 saine.

Justification : La mise en cache en périphérie (edge caching) via CloudFront réduit la latence et la charge sur l’origine ; Direct Connect associé à Transit Gateway offre une bande passante prévisible et un routage centralisé pour le trafic de sauvegarde hybride ; les points de terminaison et un routage approprié minimisent la sortie Internet et les coûts, tandis que l’observabilité et les services de sécurité gérés assurent la résilience opérationnelle et une défense en profondeur.

← Services de base de données essentiels · Tous les domaines · Sécurité →

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

Parcourir Amazon →