Amazon SAP-C02: Réseau et connectivité hybride — Guide d'étude

By Laurynas Brazys · 31 July 2026 · #amazon #sap-c02 #certification #exam-prep #study-guide

Fait partie du AWS Solutions Architect Professional SAP-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.

Architecture VPC et modèles de segmentation

La conception de la topologie VPC commence par la gestion du rayon d’impact et un routage prévisible. Pour les petits déploiements, un VPC unique avec plusieurs subnets et des groupes de sécurité stricts peut être efficace, mais à mesure que les équipes et les applications se développent, le modèle à VPC unique devient fragile : les quotas de ressources, la gouvernance inter-équipes et les « voisins bruyants » (noisy neighbors) augmentent le risque opérationnel. Le modèle multi-VPC par équipe ou compte par équipe améliore l’isolation et les frontières IAM ; utilisez AWS Organizations avec des comptes distincts pour les équipes et un compte de services partagés pour le DNS, la journalisation et l’identité. Pour la connectivité inter-VPC, le VPC peering est simple et à faible latence, mais il est non transitif et lourd à gérer à grande échelle. Transit Gateway (TGW) remplace le modèle du « VPC de transit » : il prend en charge des milliers d’attachements, centralise les tables de routage et simplifie les modèles multicast ou en étoile (hub-and-spoke). PrivateLink (Interface VPC Endpoints) permet une isolation au niveau du service sans exposer les services à Internet, ce qui est essentiel pour les microservices inter-comptes. Les pièges courants incluent le fait de se fier uniquement aux groupes de sécurité pour la segmentation (ils sont stateful et peu précis pour le filtrage est-ouest), d’oublier le comportement stateless des NACL, et de ne pas planifier l’allocation CIDR (les chevauchements entravent le peering et DX). Les décisions dépendent du compromis entre coût et facilité de gestion : TGW a des coûts d’attachement mais réduit la complexité de chaque peering ; l’isolation multi-comptes augmente la charge de gestion de la landing zone mais diminue le rayon d’impact. Documentez toujours le plan CIDR, les règles de propagation des routes et la propriété des services partagés pour éviter les dérives de configuration.

Connectivité hybride, routage et résilience

Les choix de connectivité hybride dépendent du débit, de la gigue (jitter), de la latence et de la cohérence de l’adressage public de sortie (egress). Les VIF privées AWS Direct Connect (DX) fournissent une bande passante déterministe et des coûts de sortie inférieurs à ceux d’un VPN Internet pour les flux importants et constants ; utilisez une Direct Connect Gateway pour couvrir plusieurs Régions ou pour vous attacher à un Transit Gateway pour un routage centralisé. Le Site-to-Site VPN (IPsec géré avec BGP) est utilisé pour une configuration rapide ou comme une sauvegarde résiliente pour DX ; configurez BGP avec les ASN et les priorités de route appropriés pour éviter le routage asymétrique. Les principaux pièges de routage sont le chevauchement des CIDR on-premise et cloud, une propagation incorrecte des routes dans TGW, et le fait de supposer un routage transitif à travers les VPC en peering. Le MTU et la fragmentation peuvent interrompre le trafic VPN — testez le Path MTU et ajustez le MSS sur les équipements. Pour le multi-région, envisagez des connexions DX actives/actives sur plusieurs sites ou une combinaison de DX avec un basculement (failover) sur VPN. Compromis : les liens DX dédiés coûtent plus cher mais réduisent la gigue et les frais de sortie ; le VPN est moins cher et plus simple mais moins stable à haut débit. Concevez une architecture pour un basculement prévisible avec deux tunnels indépendants, des connexions DX redondantes sur des sites distincts, et des tables de routage TGW explicites pour contrôler la sélection des chemins et les limites.

DNS, PrivateLink et modèles de connectivité des services

Le DNS est au cœur des réseaux hybrides et multi-comptes. Utilisez les zones hébergées privées (Private Hosted Zones) de Route 53 pour la résolution au niveau du VPC et les points de terminaison (endpoints) entrants/sortants du Route 53 Resolver pour permettre la redirection conditionnelle (conditional forwarding) entre les DNS on-premise et AWS. Cela prend en charge le DNS « split-horizon » où les noms internes se résolvent en adresses IP privées tandis que les enregistrements publics restent globaux. PrivateLink (interface endpoints) fournit une connectivité privée, basée sur des ENI, aux services AWS ou aux partenaires SaaS sans router le trafic sur l’Internet public ; cela contraste avec les Gateway Endpoints pour S3 et DynamoDB qui sont moins chers et utilisent des tables de routage plutôt que des ENI. PrivateLink évite d’exposer les services à des conflits de CIDR VPC et prend en charge les consommateurs inter-comptes avec des politiques d’acceptation de service. Les écueils courants incluent l’oubli d’associer les zones hébergées privées à tous les VPC consommateurs, la non-création de règles Route 53 Resolver pour les domaines on-premise, et la sous-estimation de la consommation d’adresses IP par ENI de point de terminaison. Critères de décision : préférez les Gateway endpoints pour un accès à haut débit à S3/DynamoDB afin d’éviter les coûts NAT ; utilisez les Interface endpoints lorsque vous avez besoin d’un accès privé à des points de terminaison d’API ou à des services tiers avec une sécurité plus stricte. Surveillez la latence DNS et définissez les TTL avec un processus de gestion des changements (change control) pour maîtriser le comportement de basculement.

Trafic sortant, conception NAT, contrôles de sécurité et pratiques opérationnelles

L’architecture du trafic sortant affecte les coûts, l’auditabilité et les intégrations avec des tiers. NAT Gateway fournit une sortie IPv4 gérée et hautement disponible pour les subnets privés avec une mise à l’échelle automatique par AZ ; les instances NAT sont moins chères pour une utilisation à faible débit mais exigent une maintenance opérationnelle et des scripts de basculement. La centralisation du trafic sortant via un VPC de sortie dédié attaché à un Transit Gateway impose des adresses IP sortantes cohérentes, des points d’inspection et des politiques simplifiées, mais introduit du routage en épingle à cheveux (hairpin routing) et des goulots d’étranglement potentiels de bande passante. Pour l’IPv6, utilisez une Egress-Only Internet Gateway. Remplacez les bastions SSH par AWS Systems Manager Session Manager pour l’audit et pour éliminer les informations d’identification publiques entrantes ; Session Manager fonctionne via l’agent SSM sans ouvrir de ports SSH. Pour un filtrage avancé et du DPI, déployez AWS Network Firewall ou des appliances tierces derrière le TGW. Compromis coût/performance : les NAT Gateways sont faciles à utiliser mais ajoutent des frais par Go — utilisez des points de terminaison VPC pour réduire le trafic sortant vers S3 et les coûts NAT. Les pièges opérationnels incluent le fait de ne pas activer les VPC Flow Logs pour le dépannage du trafic, de laisser des règles de sortie trop larges qui permettent l’exfiltration de données, et d’utiliser des SCP ou des politiques IAM qui bloquent involontairement les opérations de cycle de vie ; appliquez le moindre privilège et journalisez tout dans un compte central pour analyse.

Problème pratique : Acme Financial Services — Trafic sortant centralisé et prévisible pour la mise sur liste blanche par des tiers

Scénario : Acme Financial Services exécute plusieurs VPC applicatifs dans deux Régions AWS, connectés avec un Transit Gateway et à des datacenters sur site via Direct Connect et VPN. Plusieurs applications dans des comptes distincts doivent appeler une API partenaire qui n’accepte les requêtes que depuis un unique bloc CIDR public.

Défi : Fournir un chemin de sortie hautement disponible et auditable avec un unique bloc CIDR public prévisible pour tous les VPC applicatifs à travers les Régions, tout en minimisant la latence et la charge opérationnelle.

Approche recommandée :

1. Apportez un CIDR IPv4 public sur AWS en utilisant BYOIP (Bring Your Own IP) et allouez des Elastic IPs à partir de ce CIDR pour les utiliser comme adresses de sortie.
2. Construisez un VPC de sortie centralisé dans chaque Région avec des NAT Gateways dans plusieurs AZ ; associez les Elastic IPs BYOIP à ces NAT Gateways et attachez les VPC de sortie au Transit Gateway.
3. Mettez à jour les tables de routage du TGW pour que tous les VPC applicatifs routent 0.0.0.0/0 vers l’attachement du VPC de sortie, activez la propagation des routes et le basculement contrôlé par des bilans de santé (health-checked failover) entre les AZ ; configurez le routage sur site pour préférer la sortie locale si nécessaire.
4. Déployez Network Firewall ou un IDS géré dans le VPC de sortie pour le filtrage sortant, activez les VPC Flow Logs et les alarmes CloudWatch, et utilisez Route 53 Resolver pour tout besoin de redirection DNS.

Justification : La centralisation du trafic sortant via TGW et des NAT Gateways avec un espace IP fourni par BYOIP offre un CIDR prévisible pour la mise sur liste blanche tout en préservant la haute disponibilité et la surveillance centralisée. Cette approche équilibre la simplicité opérationnelle, les contrôles de sécurité et l’exigence du partenaire d’un unique CIDR public.

← Complexité organisationnelle et stratégie multi-comptes · Tous les domaines · Sécurité →

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

Parcourir Amazon →