Amazon SAA-C03: Réseau et connectivité — Guide d'étude

By Laurynas Brazys · 16 July 2026 · #amazon #saa-c03 #certification #exam-prep #study-guide

Fait partie du AWS SAA-C03 — Guide d’étude complet. 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.

Conception de VPC et planification CIDR

Chaque VPC commence par un bloc CIDR, et le choix fait lors de la création a des conséquences en aval pour le peering, les attachements Transit Gateway et la connectivité hybride. Le CIDR principal doit être compris entre /16 et /28, choisi dans l’espace RFC 1918, et il ne doit pas chevaucher de réseau avec lequel vous prévoyez d’établir un peering, de router via un Transit Gateway, ou d’atteindre via Direct Connect ou un VPN. Les CIDR qui se chevauchent sont la cause la plus fréquente des conceptions hybrides défaillantes, car AWS ne peut pas router entre deux réseaux partageant le même espace d’adressage — le Transit Gateway acceptera l’attachement, mais la propagation échouera ou rejettera silencieusement le trafic (blackhole).

Lorsqu’un VPC est à court d’espace d’adressage, il n’est pas nécessaire de le reconstruire. Jusqu’à quatre blocs CIDR IPv4 secondaires peuvent être attachés (et des plages supplémentaires provenant d’un pool plus large pour un total par défaut de cinq, extensible via une augmentation de quota). Les blocs secondaires peuvent provenir de la même plage RFC 1918 ou de l’espace d’adressage partagé 100.64.0.0/10, ce qui est utile lorsque la plage 10.0.0.0/8 a été épuisée ou lorsqu’un espace NAT de niveau opérateur est nécessaire. Les CIDR secondaires vous permettent de découper de nouveaux sous-réseaux pour l’expansion — le réseau des pods EKS, un nouveau niveau applicatif (tier) — sans avoir à renuméroter les charges de travail existantes.

aws ec2 associate-vpc-cidr-block \
  --vpc-id vpc-0abc123 \
  --cidr-block 100.64.0.0/16

Une conception robuste réserve un /17 ou /18 pour la croissance future, aligne les limites des sous-réseaux sur les Zones de Disponibilité (un /20 par AZ et par niveau est un modèle courant), et laisse une marge de manœuvre pour les ENI consommées par les points de terminaison d’interface, les passerelles NAT et les load balancers.

Un VPC est une construction régionale partitionnée en sous-réseaux (subnets), chacun lié à une seule AZ. La distinction entre « public » et « privé » est purement une décision de routage : un sous-réseau public a une route 0.0.0.0/0 → igw-xxxx pointant vers une passerelle Internet (Internet Gateway), tandis qu’un sous-réseau privé n’a pas de route par défaut ou fait pointer 0.0.0.0/0 vers un dispositif NAT. Les instances dans un sous-réseau public ont également besoin d’une IP publique ou Élastique pour être joignables en entrée ; l’IGW effectue un NAT 1:1 entre l’IP privée et l’IP publique.

Passerelles NAT, instances NAT et sortie (Egress) IPv6

Pour un accès Internet IPv4 sortant uniquement depuis des sous-réseaux privés, les passerelles NAT (NAT gateways) sont la primitive appropriée. Une passerelle NAT gérée évolue automatiquement jusqu’à 45–100 Gbps, supporte 55 000 connexions simultanées par destination unique, est patchée par AWS et est hautement disponible au sein de son AZ. Les passerelles NAT sont facturées à l’heure et par Go traité.

Les instances NAT — des EC2 autogérées avec la vérification source/destination désactivée — sont obsolètes (legacy). Elles sont limitées par le débit d’une seule instance, doivent être scriptées pour le basculement (failover) et deviennent un goulot d’étranglement sous une charge soutenue. Elles ne sont appropriées que pour des besoins atypiques comme le filtrage personnalisé, et même dans ce cas, une appliance Gateway Load Balancer est généralement préférable.

Le modèle canonique à haute disponibilité est une passerelle NAT par AZ, chacune dans le sous-réseau public de cette AZ, avec une table de routage privée distincte par AZ dont la route par défaut pointe vers la passerelle NAT locale :

Private subnet AZ-a  → Route table A → 0.0.0.0/0 → NAT-GW-a (public subnet AZ-a)
Private subnet AZ-b  → Route table B → 0.0.0.0/0 → NAT-GW-b (public subnet AZ-b)
Private subnet AZ-c  → Route table C → 0.0.0.0/0 → NAT-GW-c (public subnet AZ-c)

Déployer une seule passerelle NAT partagée entre plusieurs AZ est un piège pour deux raisons. Premièrement, c’est un point de défaillance unique (single point of failure) : une panne d’AZ met hors service la sortie pour chaque sous-réseau privé. Deuxièmement, chaque paquet provenant d’instances dans d’autres AZ traverse une frontière d’AZ, entraînant des frais de transfert de données inter-AZ (actuellement 0,01 $/Go dans chaque sens) en plus du traitement par la passerelle NAT. Sur des charges de travail effectuant des centaines de To de trafic sortant, cela éclipse le coût des passerelles NAT supplémentaires. Une deuxième erreur de configuration fréquente consiste à placer la passerelle NAT elle-même dans un sous-réseau privé — elle n’a alors aucun chemin vers l’IGW et ne fonctionne pas.

Pour l’IPv6, le NAT n’est ni nécessaire ni disponible car chaque adresse IPv6 est routable mondialement. Pour autoriser uniquement le trafic IPv6 sortant tout en bloquant les connexions entrantes non sollicitées, attachez une passerelle Internet de sortie uniquement (egress-only internet gateway) et routez ::/0 vers elle depuis les sous-réseaux privés. Une IGW standard est bidirectionnelle et exposerait les instances.

Points de terminaison de VPC : Passerelle vs Interface

Les points de terminaison de VPC maintiennent le trafic entre votre VPC et les services AWS sur le réseau principal (backbone) d’AWS, évitant ainsi complètement Internet, les passerelles NAT et les passerelles Internet. Il existe deux implémentations fondamentalement différentes, et les confondre est l’une des erreurs d’architecture les plus courantes.

Les points de terminaison de passerelle n’existent que pour Amazon S3 et DynamoDB. Ils consistent en une entrée dans la table de routage — une liste de préfixes (par exemple pl-63a5400a pour S3 dans us-east-1) ciblant le point de terminaison lui-même. Il n’y a pas d’ENI, pas de changement de DNS, pas de coût horaire et pas de groupe de sécurité (l’accès est contrôlé par la table de routage et la politique du point de terminaison). Comme ils sont basés sur le routage, ils ne fonctionnent que pour les ressources à l’intérieur du VPC — les réseaux sur site accédant à S3 via Direct Connect ne peuvent pas les utiliser.

Les points de terminaison d’interface (AWS PrivateLink) sont des ENI avec des adresses IP privées placées dans vos sous-réseaux, facturées à l’heure par AZ et par Go. Ils fonctionnent pour presque tous les autres services — SQS, KMS, Secrets Manager, ECR, STS, SSM, SNS, et des centaines d’autres — ainsi que pour des services tiers publiés en tant que services de point de terminaison. Les points de terminaison d’interface prennent en charge le DNS privé, qui remplace le nom d’hôte public du service pour le résoudre en l’adresse IP privée du point de terminaison, de sorte que les SDK et les CLI ne nécessitent aucune modification de code. Comme ils sont adossés à des ENI, les groupes de sécurité s’appliquent.

S3Endpoint:
  Type: AWS::EC2::VPCEndpoint
  Properties:
    VpcId: !Ref VPC
    ServiceName: !Sub com.amazonaws.${AWS::Region}.s3
    VpcEndpointType: Gateway
    RouteTableIds: [!Ref PrivateRouteTableA, !Ref PrivateRouteTableB]
    PolicyDocument:
      Statement:
        - Effect: Allow
          Principal: "*"
          Action: ["s3:PutObject"]
          Resource: "arn:aws:s3:::example-bucket/*"
          Condition:
            StringEquals:
              aws:SourceVpce: !Ref S3Endpoint

SecretsManagerEndpoint:
  Type: AWS::EC2::VPCEndpoint
  Properties:
    VpcId: !Ref VPC
    ServiceName: !Sub com.amazonaws.${AWS::Region}.secretsmanager
    VpcEndpointType: Interface
    PrivateDnsEnabled: true
    SubnetIds: [!Ref PrivateSubnetA, !Ref PrivateSubnetB]
    SecurityGroupIds: [!Ref EndpointSG]

La logique des coûts est importante : tout trafic quittant un sous-réseau privé vers un service public AWS passe par défaut par une passerelle NAT à environ 0,045 $/Go. Pour une charge de travail conteneurisée envoyant 1 To par jour vers S3, la différence entre un chemin via une passerelle NAT et un point de terminaison de passerelle se chiffre en milliers de dollars par mois. Les points de terminaison d’interface sont rentables lorsqu’ils remplacent le trafic sortant via NAT à grande échelle ou lorsque la conformité interdit le routage par Internet.

Pièges : attacher un groupe de sécurité à un point de terminaison de passerelle (ils n’ont pas d’ENI) ; supposer qu’un point de terminaison de passerelle est accessible depuis un site sur site (ce n’est pas le cas — utilisez un point de terminaison d’interface ou le modèle hybride EC2 → point de terminaison de passerelle S3 → chemin DX séparé) ; désactiver le DNS privé sur un point de terminaison d’interface et s’attendre à ce que les appels SDK non modifiés fonctionnent (ils atteindront le point de terminaison public via Internet, rendant le point de terminaison totalement inutile) ; créer un point de terminaison de passerelle mais oublier d’associer la table de routage du sous-réseau privé (le trafic continue silencieusement d’utiliser le chemin public) ; essayer d’utiliser un point de terminaison de passerelle pour un service qui n’en a pas (KMS, par exemple) — seuls S3 et DynamoDB sont éligibles.

Connectivité inter-VPC : Appairage vs Transit Gateway

L’appairage de VPC est une connexion de couche 3 un-à-un et non transitive entre deux VPC, dans le même compte ou des comptes différents, dans la même région ou des régions différentes. Le trafic transite par le réseau principal d’AWS, il n’y a pas de goulot d’étranglement de bande passante, et il n’y a pas de frais horaires — vous ne payez que pour le transfert de données inter-AZ ou inter-régions. Deux propriétés limitent l’appairage : (1) il est non transitif — si A est appairé avec B et B est appairé avec C, A ne peut pas atteindre C via B ; et (2) les plages CIDR ne doivent pas se chevaucher. Connecter N VPC en maillage complet nécessite N(N-1)/2 appairages avec des modifications de table de routage dans les deux sens de chaque connexion ; pour 30 VPC, cela représente 435 appairages. S’attendre à ce que l’appairage puisse s’adapter à des centaines de VPC est un piège.

Transit Gateway (TGW) est un routeur cloud régional. Chaque VPC, VPN ou passerelle Direct Connect est un attachement, et les tables de routage du TGW contrôlent quel attachement peut atteindre quel préfixe. Cela transforme un maillage en O(n²) en O(n) attachements et permet des topologies hub-and-spoke où un VPC de sécurité héberge des pare-feu qui inspectent tout le trafic inter-VPC. TGW prend en charge le routage transitif, termine nativement les associations de passerelles VPN et Direct Connect, et peut être partagé au sein d’AWS Organizations via Resource Access Manager afin que les équipes réseau centrales contrôlent le routage tandis que les comptes de charge de travail possèdent les VPC. TGW ajoute des frais horaires par attachement et environ 0,02 $/Go traité.

Pour la connectivité inter-régions, l’appairage de TGW connecte des TGW dans différentes régions via le réseau mondial d’AWS avec un trafic chiffré — un TGW par région, appairé dans une conception en maillage ou en étoile (hub). Cela évite le problème en N au carré entre les régions que l’appairage de VPC inter-régions réintroduit.

L’hygiène de la table de routage est le tueur silencieux ici. Créer une connexion d’appairage ou un attachement TGW ne fait rien tant que des routes CIDR explicites ne sont pas ajoutées dans les tables de routage des sous-réseaux des deux VPC pointant vers la cible pcx- ou tgw-, et que les groupes de sécurité n’autorisent pas le trafic. Les échecs de connectivité silencieux sont presque toujours dus à une route manquante ou à un refus implicite dans un groupe de sécurité référençant le mauvais CIDR source.

Connectivité Hybride : Site-to-Site VPN vs. Direct Connect

Le choix entre Site-to-Site VPN et Direct Connect est un compromis entre la rapidité de déploiement et le chiffrement intégré d’une part, et une faible latence constante, une bande passante dédiée et un débit prévisible d’autre part.

Le Site-to-Site VPN établit deux tunnels IPsec entre une passerelle client (routeur sur site) et soit une Virtual Private Gateway, soit un Transit Gateway. Chaque tunnel est plafonné à environ 1,25 Gbit/s. Le trafic est chiffré au niveau de la couche réseau, répondant aux exigences de chiffrement aux couches réseau et session lorsqu’il est combiné avec TLS. Il transite par l’internet public, la latence et la gigue sont donc variables, mais il est disponible en quelques minutes et coûte quelques centimes par heure. Utilisez-le lorsqu’une connectivité est requise immédiatement, lorsque la bande passante est modeste, ou comme chemin de secours.

Direct Connect (DX) fournit une connexion fibre dédiée (1, 10 ou 100 Gbit/s) depuis un routeur sur site vers un emplacement AWS Direct Connect. Il contourne l’internet public, offrant une latence constante et un débit plus élevé. La tarification de sortie (egress) de DX est nettement inférieure à celle de la sortie internet, ce qui est important lors du transfert de centaines de gigaoctets par jour. La mise en service prend des semaines — interconnexions (cross-connects), LOA, configuration BGP.

Deux pièges dominent ici. Premièrement, Direct Connect seul ne chiffre pas le trafic. Un circuit privé n’est pas un canal protégé par cryptographie. Pour satisfaire une exigence de chiffrement sur DX, superposez un VPN Site-to-Site, ou utilisez MACsec pour le chiffrement de couche 2 sur les ports dédiés compatibles. Deuxièmement, une connexion DX brute ne route pas d’elle-même vers plusieurs VPC. Une VIF privée se connecte à une seule Virtual Private Gateway attachée à un seul VPC. Pour atteindre de nombreux VPC — en particulier entre plusieurs comptes et Régions — utilisez une Direct Connect Gateway associée à un Transit Gateway via une VIF de transit, et attachez chaque VPC au TGW :

On-prem router ── DX ── Transit VIF ── DX Gateway ── TGW ── VPC-Prod
                                                        ├── VPC-Dev
                                                        └── Inspection VPC (GWLB)

Le modèle de production canonique utilise deux connexions DX sur deux emplacements DX se terminant sur des routeurs clients distincts, avec un VPN Site-to-Site comme basculement (failover) BGP automatique — le BGP AS-path prepending ou le MED dirige le trafic vers DX tant qu’il est actif ; en cas de défaillance, BGP retire les routes DX et le VPN prend le relais.

Load Balancers : ALB, NLB et GWLB

L’ALB est de couche 7 et comprend la sémantique HTTP — routage par hôte et par chemin, WebSockets, redirections, sessions persistantes basées sur les cookies. C’est le mauvais outil pour tout ce qui n’est pas HTTP : MQTT, TCP brut, syslog sur UDP, SMTP. L’ALB utilise un adressage basé sur le DNS avec des adresses IP qui changent dans le temps ; on ne peut pas lui assigner d’Elastic IPs. Lorsque les clients doivent autoriser (whitelist) des IP de destination, un ALB seul est inadapté — utilisez un NLB avec des EIP, ou placez un Global Accelerator avec ses deux IP anycast statiques devant l’ALB. « Il suffit de résoudre le DNS de l’ALB une fois et de figer les IP dans les règles de pare-feu » est un piège : AWS les modifie sans préavis.

Le NLB est de couche 4 et peut gérer des millions de flux par seconde. Il préserve par défaut la véritable IP source du client (les cibles voient le vrai client), permet d’assigner une Elastic IP statique par AZ, et gère les charges de travail TCP/UDP à haut débit. Historiquement, le NLB ne prenait pas en charge les groupes de sécurité sur le load balancer lui-même — les CIDR des clients devaient être autorisés directement sur le SG de la cible. AWS a ajouté des groupes de sécurité optionnels pour le NLB en 2023, mais de nombreuses architectures supposent encore le comportement classique.

Le modèle canonique exposé publiquement est :

ALB security group:
  Inbound:  TCP 443 from 0.0.0.0/0 (or specific CIDRs)
  Outbound: TCP <backend-port> to backend SG

Backend instance security group:
  Inbound:  TCP <app-port> from ALB security group (source = sg-alb)
  Inbound:  TCP <health-check-port> from ALB security group

Référencer le groupe de sécurité de l’ALB comme source sur le backend — plutôt qu’un CIDR — est le modèle du moindre privilège et couvre automatiquement le trafic des bilans de santé (health checks), qui provient des ENI de l’ALB. L’ALB lui-même se trouve dans des sous-réseaux publics dans au moins deux AZ (avec des routes vers l’IGW) ; les cibles se trouvent dans des sous-réseaux privés. Placer un ALB exposé à internet dans un sous-réseau privé est une erreur de configuration classique — l’enregistrement de la cible réussit mais les clients ne peuvent pas l’atteindre.

Le Gateway Load Balancer (GWLB) est spécialement conçu pour l’insertion transparente d’appliances virtuelles tierces (pare-feu, IDS/IPS, DPI). Il opère à la couche 3, transférant tous les protocoles IP en utilisant l’encapsulation GENEVE sur le port UDP 6081. Le trafic atteint le GWLB via un point de terminaison GWLB (GWLBe) — un point de terminaison d’interface qui se trouve dans un sous-réseau et apparaît dans les tables de routage comme une cible :

Destination: 0.0.0.0/0
Target:      vpce-0abc123... (GWLB endpoint)

Le point de terminaison transfère les paquets via PrivateLink au GWLB, qui répartit la charge sur la flotte d’appliances en utilisant la persistance de flux (flow stickiness) afin que les deux directions d’un flux atteignent la même appliance. Dans une architecture d’inspection en étoile (hub-and-spoke), les VPC satellites (spokes) s’attachent à un TGW dont les tables de routage forcent le trafic est-ouest à passer par le VPC d’inspection (contenant le GWLB et les appliances) avant d’atteindre les VPC de destination. L’inspection du trafic entrant (ingress) utilise des tables de routage de périphérie (edge route tables) qui redirigent d’abord le trafic de l’IGW vers la couche web (web-tier) via le GWLBe :

IGW → (edge route table) → GWLBe → GWLB (inspection VPC)
    → firewall appliances → GWLB → GWLBe → web subnet

C’est la bonne réponse pour une inspection centralisée et multi-comptes — les solutions maison avec EC2, les bidouillages de tables de routage personnalisées et les scripts de basculement ne font que réinventer ce que le GWLB fournit nativement.

PrivateLink pour les services du consommateur vers le fournisseur

Au-delà de la prise en charge des points de terminaison d’interface pour les services AWS, PrivateLink permet une connectivité privée aux services publiés par des tiers ou d’autres comptes AWS. Le fournisseur place son service derrière un NLB et crée un service de point de terminaison de VPC. Les consommateurs créent des points de terminaison d’interface dans leurs propres VPC qui le ciblent.

La règle de directionnalité critique est la suivante : la connexion est toujours initiée depuis le consommateur vers le fournisseur. Le fournisseur ne peut pas initier de connexions vers le VPC du consommateur. Le trafic ne transite jamais par Internet, seul le service cible spécifique est joignable (et non l’ensemble du VPC du fournisseur, comme avec le peering), et aucun problème de chevauchement de CIDR ne se pose car seules les adresses IP des points de terminaison sont exposées de chaque côté. C’est la réponse canonique pour un modèle d’accès SaaS ou à une base de données d’un fournisseur où le VPC du consommateur n’a ni IGW, ni VPN, ni Direct Connect. Le peering de VPC expose des plages CIDR entières et nécessite des adresses IP qui ne se chevauchent pas ; un attachement TGW route de manière large ; une API publique sur Internet n’est pas privée.

Global Accelerator et Route 53

AWS Global Accelerator attribue deux adresses IPv4 anycast statiques annoncées depuis les emplacements périphériques (edge locations) d’AWS dans le monde entier. Le trafic client entre par l’emplacement périphérique le plus proche et transite par le backbone AWS jusqu’au point de terminaison régional sain le plus proche (ALB, NLB, EIP ou EC2). Cela résout deux problèmes à la fois : des adresses IP statiques devant les ALB (corrigeant le problème de mise sur liste blanche), et une gigue/latence réduite pour les utilisateurs distribués mondialement en court-circuitant l’Internet public. Il accélère le trafic TCP/UDP non cachable vers des origines où CloudFront (qui met en cache le contenu) n’est pas applicable.

Route 53 résout un problème différent : l’aiguillage du trafic au niveau DNS. Global Accelerator affecte le plan de données (data plane) lui-même ; Route 53 n’affecte que la résolution DNS, après quoi la connexion TCP va là où se trouve l’adresse IP résolue. Les deux sont fréquemment combinés : un alias Route 53 pointe vers un Global Accelerator qui se trouve devant des ALB régionaux.

Politiques de routage de Route 53 :

La latence et la géolocalisation sont souvent confondues : la latence minimise le RTT perçu par l’utilisateur ; la géolocalisation impose la résidence des données indépendamment de la latence. Le basculement multi-Région nécessite des vérifications de l’état (health checks) sur le primaire. Les enregistrements d’alias sont spécifiques à AWS, se résolvent directement en points de terminaison ALB, NLB, CloudFront, site web S3 et API Gateway sans frais de requête, et — contrairement aux CNAMEs — fonctionnent à l’apex de la zone.

Route 53 Resolver répond aux requêtes DNS à l’intérieur d’un VPC via l’adresse .2 (base du CIDR du VPC + 2). Pour le DNS hybride, les points de terminaison entrants (inbound) permettent aux résolveurs sur site (on-premises) d’interroger des zones hébergées privées dans AWS ; les points de terminaison sortants (outbound) avec des règles de redirection permettent aux ressources du VPC de résoudre des noms sur site. Sans cela, les instances EC2 ne peuvent pas résoudre corp.internal et les serveurs sur site ne peuvent pas résoudre db.prod.internal — une rupture subtile qui n’apparaît que lorsque les applications commencent des recherches inter-environnements. Les points de terminaison d’interface nécessitent l’option Activer le DNS privé (Enable Private DNS) pour que les appels SDK atteignent l’ENI du point de terminaison ; sans cela, les appels atteignent toujours le point de terminaison public via Internet, ce qui va à l’encontre de l’objectif visé.

Groupes de sécurité, NACL et moindre privilège

Les groupes de sécurité sont stateful — le trafic de retour est automatiquement autorisé — et agissent au niveau de l’ENI. Les NACL sont stateless et agissent à la frontière du sous-réseau. Toute règle TCP dans une NACL nécessite une règle explicite entrante et sortante ; comme les clients choisissent un port source dans la plage éphémère, la règle pour le trafic de retour doit autoriser les ports 1024–65535 (Linux utilise 32768–60999 par défaut ; la plage plus large couvre Windows et d’autres piles). L’oubli de la règle de retour pour les ports éphémères est une cause classique de connexions qui complètent le SYN mais restent bloquées en attente de réponse.

Pour le moindre privilège entre les niveaux (tiers), les règles des groupes de sécurité devraient référencer d’autres ID de groupes de sécurité, et non des blocs CIDR. Cela s’adapte à l’Auto Scaling et évite les listes blanches d’IP fragiles :

sg-web:  ingress 443 from 0.0.0.0/0
sg-app:  ingress 8080 from sg-web
sg-db:   ingress 3306 from sg-app

Les NACL sont un contrôle grossier du périmètre de l’impact (blast radius), pas un substitut aux groupes de sécurité. Restreindre les NACL pour une « défense en profondeur » sans modifier les groupes de sécurité en conséquence interrompt fréquemment les flux sortants initiés, tels que les mises à jour yum/apt via une passerelle NAT, car le trafic de retour stateless est silencieusement rejeté. Les tables de routage déterminent en fin de compte l’atteignabilité : même un groupe de sécurité permissif ne peut pas acheminer le trafic si la table de routage ne contient pas d’entrée pour la destination, et inversement, un point de terminaison de passerelle n’est efficace que si la route de la liste de préfixes S3 est réellement installée dans les tables de routage des sous-réseaux qui hébergent le workload.

Référence pour la prise de décision

← Transfert et migration de données · Tous les domaines · Distribution de contenu →

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

Parcourir Amazon →