🌐 AWS VPC (Virtual Private Cloud)

10.2. Architecture EKS (Kubernetes) dans VPC

EKS (Elastic Kubernetes Service) a des exigences réseau spécifiques car il utilise le AWS VPC CNI (Container Network Interface).

Le Point Clé (VPC CNI) : Chaque Pod (Conteneur K8s) obtient une IP Privée (10.0.x.x) réelle, directement depuis le CIDR du Subnet où tourne le Nœud (EC2).

Architecture (Data Plane)

• Control Plane (Master K8s) : Géré par AWS (dans un VPC AWS). Vous ne le voyez pas.
• Data Plane (Nodes) : Instances EC2 (Worker Nodes) qui tournent (généralement) dans des Subnets Privés (subnet-private-app).
• Ingress (Entrée) : Un ALB (Ingress Controller) ou NLB (Service Type=LoadBalancer) est provisionné dans les Subnets Publics pour router le trafic vers les Pods (via leurs IPs 10.0.x.x).

Conséquences & Pièges (CIDR)

Épuisement (Exhaustion) des IPs : C'est le piège n°1 de EKS.

• (Scénario) Vous utilisez un Subnet /24 (251 IPs).
• Vous lancez 10 Nœuds (EC2) (ex: m5.large).
• Le CNI (par défaut) "réserve" 29 IPs (secondaires) sur chaque Nœud (EC2) (pour les Pods futurs).
• Calcul : 10 (Nœuds) * 29 (IPs/Nœud) = 290 IPs requises.
• Résultat : Le Subnet /24 (251 IPs) est saturé (plein). Le 10ème Nœud ne peut pas démarrer (Failed to allocate IP).

Bonne Pratique (EKS) : Toujours utiliser des Subnets très larges (ex: /20 (4091 IPs)) pour le Data Plane (Nœuds/Pods).

10.3. Architecture Serverless 100% Privée (VPC Endpoints)

Architecture "Zéro NAT Gateway" (Zéro coût NAT). Conçue pour une sécurité maximale où les Lambdas n'ont aucun accès Internet (ni Entrant, ni Sortant).

                    (Client Interne / VPN)
                    |
                    v
                    [ 🌐 Endpoint (Interface) API GW ] (IP Privée: 10.0.1.50)
                    |
                    v
                    [ 🔒 Subnet Privé (VPC) ]
                    |
                    +-- [ 🔥 Lambda (Fonction) ] (IP Privée: 10.0.1.x)
                    |
                    (Appel API 'dynamodb.put_item')
                    |
                    v
                    [ 🚪 Endpoint (Gateway) DynamoDB ] (Route Table)
                    |
                    v
                    [ 📦 Service DynamoDB (Public) ] (Accès via Backbone Privé AWS)
                

Composants Clés

• API Gateway (Privé) : L'API GW est configurée en mode "Private". La seule façon de l'appeler est via un VPC Endpoint (Interface) (vpce-xxx) (créant une ENI/IP privée dans le VPC).
• Lambda (VPC) : La fonction est attachée au Subnet Privé (subnet-private-a).
• Route Table (Privée) : La RT de subnet-private-a n'a AUCUNE route 0.0.0.0/0 (ni IGW, ni NAT). Elle est isolée.
• Endpoint (Gateway) : Pour que la Lambda (dans son isolement) puisse parler à DynamoDB (un service public), on ajoute un Endpoint (Gateway) pour dynamodb à la Route Table.
• Endpoint (Interface) : Si la Lambda doit aussi lire un secret (Bonne Pratique), on ajoute un Endpoint (Interface) pour Secrets Manager (créant une ENI 10.0.1.x).

Résultat : 100% du trafic (API -> Lambda -> DynamoDB -> Secrets Manager) reste privé (sur le réseau AWS) et n'utilise jamais Internet (IGW/NAT).

10.4. Architecture Hybride (Peering & TGW)

Comment gérer la connectivité dans une organisation (multi-comptes).

Scénario 1 : "Mesh" (Peering) (Pour < 5 VPCs)

Simple à mettre en place, mais devient ingérable (N*(N-1)/2).

                    [VPC-Prod (10.0/16)] <-- (Peering 1) --> [VPC-Dev (10.1/16)]
                    |                                      |
                    (Peering 3) ---------------------------+
                    |
                    [VPC-Shared (10.2/16)]
                

Scénario 2 : "Hub-and-Spoke" (TGW) (Standard > 5 VPCs)

Scalable, géré centralement, et transitif.

                    [VPC-Prod (10.0/16)] --<

                    [VPC-Dev (10.1/16)] ----<

                    [VPC-Shared (10.2/16)] --<--> [ 🚀 Transit Gateway (TGW) (Compte "Network") ]

                    [VPC-Logs (10.3/16)] ---<

                    [VPC-OnPrem (VPN/DX)] --<
                

Configuration (Routage TGW)

La magie du TGW est que chaque "Spoke" (VPC) n'a besoin que d'une seule route (simplifiée) :

Route Table (de VPC-Prod) :

• 10.0.0.0/16 -> local (Mon VPC)
• 0.0.0.0/0 -> nat-gw (Mon Internet)
• 10.0.0.0/8 -> tgw-123... (Tout le reste du réseau "Interne" (10.x), envoie-le au TGW).

Le TGW (Hub) s'occupe ensuite (via sa "Route Table TGW") de router le trafic vers le bon "Spoke" (ex: 10.1.0.0/16 -> Attachment-VPC-Dev).

10.5. Architecture Sécurisée (Compliance : PCI, HIPAA)

Cette architecture (parfois appelée "VPC d'Inspection") est conçue pour forcer tout le trafic (Nord-Sud et Est-West) à passer par un pare-feu (Firewall) d'inspection L7 (ex: Palo Alto, Fortinet) pour une analyse DPI (Deep Packet Inspection).

Architecture (TGW + GWLB)

                    (Internet)
                    |
                    v
                    [IGW] -> [VPC "Ingress" (Public)] -> [ ⚖️ Gateway Load Balancer (GWLB) ]
                    |
                    v
                    [ 🛡️ Firewall Fleet (ASG Palo Alto) ]
                    |
                    v
                    [ 🚀 Transit Gateway (TGW) ] <---------- (Trafic "Est-West" (VPC-A <-> VPC-B))
                    |
                    +---- [VPC-App-A (Privé)]
                    |
                    +---- [VPC-Data (Isolé)]
                

Composants Clés (Sécurité)

• VPC "Inspection" : Un VPC centralisé (séparé) dont le seul rôle est d'héberger les appliances de sécurité (Firewalls).
• Gateway Load Balancer (GWLB) : Un Load Balancer (L3) spécial, conçu pour distribuer le trafic (de manière transparente) à une flotte (ASG) de Firewalls (VMs).
• Transit Gateway (TGW) : Le TGW est configuré pour forcer le routage.
  • Trafic Nord-Sud (Internet) : IGW -> GWLB/Firewall -> TGW -> VPC-App.
  • Trafic Est-West (Inter-VPC) : VPC-App-A -> TGW -> GWLB/Firewall -> TGW (re-route) -> VPC-App-B.
• Comptes (AWS Orgs) : (Bonne Pratique)
  • Compte-Network (possède TGW, GWLB, VPC-Inspection).
  • Compte-LogArchive (reçoit tous les VPC Flow Logs (chiffrés, S3 Object Lock)).
  • Compte-Prod-App-A (possède VPC-App-A).

9.2. Modèle Landing Zone (AWS Control Tower)

Une "Landing Zone" est l'architecture (le "plan") d'un environnement AWS multi-comptes (9.1), sécurisé, standardisé et prêt à l'emploi (pour la production).

AWS Control Tower est le service (PaaS) qui automatise la création (le "déploiement") de cette Landing Zone (via CloudFormation, IAM, AWS Orgs...).

Composants Clés d'une Landing Zone (via Control Tower)

• AWS Organizations (Multi-Compte) : Crée (automatiquement) l'arborescence des comptes (OUs - Organizational Units) :
  • OU=Core : Compte-LogArchive (Centralise tous les logs (CloudTrail, VPC Flow Logs)), Compte-Audit (Sécurité).
  • OU=Workloads : Compte-Dev, Compte-Prod...
• Gouvernance (Guardrails / SCP) : Applique des Service Control Policies (SCPs) (le "pare-feu" IAM de l'organisation).
  • (Ex: Règle "Preventive" : Interdit (Deny) à tous les comptes (même Root) de désactiver CloudTrail ou de rendre un bucket S3 public).
• Réseau Centralisé (Optionnel) : Provisionne (souvent) un Compte "Network" qui héberge le Transit Gateway (TGW) (5.4) et les NAT Gateways (3.2) partagés (optimisation des coûts (8.3)).

9.3. Choix des CIDR & Design Réseau (Planification)

(La décision la plus importante) : Vous ne pouvez pas modifier le CIDR (ex: 10.0.0.0/16) d'un VPC après sa création (sans le détruire et le recréer).

Règle 1 : Ne pas utiliser les CIDR "évidents"

(Mauvaise Pratique) : Ne jamais utiliser 192.168.0.0/16 ou 192.168.1.0/24 (utilisés par 99% des Box Internet/VPNs). Ne pas utiliser 172.31.0.0/16 (utilisé par le "Default VPC").

(Risque) : Chevauchement (Overlapping). Le jour où vous connectez un VPN (Bureau/Maison) (qui utilise 192.168.1.0/24) à votre VPC (192.168.1.0/24) -> Échec total du routage.

Règle 2 : Utiliser le bloc 10.0.0.0/8 (et planifier)

(Bonne Pratique) : Utiliser le bloc 10.x.x.x (RFC1918) et allouer des /16 (65k IPs) (même s'ils sont "grands", ils ne coûtent pas plus cher).

Exemple de Plan d'Adressage (IPAM) :

(Résultat) : Aucun chevauchement. Tous ces réseaux peuvent être interconnectés (via TGW/Peering) sans conflit de routage.

9.4. Subdivision Logique (Subnets)

Une fois le CIDR du VPC (ex: 10.1.0.0/16) choisi (9.3), il faut le "découper" (subnet) intelligemment.

Architecture Multi-Tiers (Couches) & Multi-AZ

L'architecture standard (Bonne Pratique) utilise (au minimum) 6 Subnets (répartis sur 2 ou 3 AZs) pour isoler les "Tiers" (Couches) applicatifs.

Exemple (VPC 10.1.0.0/16) :

(Flux Sécurisé) : (Internet) -> (Subnet-Public / ALB) -> (Subnet-App / EC2) -> (Subnet-Data / RDS).

9.5. Mise en Place d’un Réseau Hybride Sécurisé

Connecter votre VPC (AWS) à votre Datacenter (On-Premise).

Option 1 : Site-to-Site VPN (Standard)

• Comment : Tunnel IPSec (chiffré) passant sur Internet.
• Composants : (AWS) Virtual Private Gateway (VGW) (attaché au VPC) ou TGW. (On-Prem) Customer Gateway (CGW) (votre routeur/firewall).
• Redondance : AWS provisionne 2 Tunnels (vers 2 Endpoints AWS) par défaut (pour la HA).
• Routage : BGP (Dynamique) (recommandé) ou Statique.
• Usage : Standard, PME, Dev/Test, Backup de DX.

Option 2 : Direct Connect (DX) (Haute Performance)

• Comment : Connexion physique (Fibre Optique) privée (non-chiffrée) hors Internet.
• Composants : (On-Prem) Fibre (louée chez un Partenaire : Equinix, Orange...) vers un "Point de Présence (DX Location)" AWS. (AWS) Direct Connect Gateway.
• Vitesse : Garantie / Statique (1 Gbps, 10 Gbps...).
• Usage : Production, workloads (gros volumes, faible latence), migration BDD.

Exemple d'Architecture (DX + VPN Backup)

                    [ Datacenter (On-Prem) ]
                    |         |
                    | (Fibre) | (Internet)
                    | (DX)    | (VPN Backup)
                    |         |
                    [ TGW (AWS) ] <-- (Route BGP (DX) Prio 100, Route BGP (VPN) Prio 200)
                    |
                    +---- [ VPC-Prod ]
                    +---- [ VPC-Dev ]
                    

(Flux) : Le trafic (BGP) passe (normalement) par Direct Connect (Prio 100). Si la fibre (DX) tombe, BGP (automatiquement) bascule le trafic sur le VPN (Backup) (Prio 200).

8.2. Éléments Payants (Les "Services" & le "Trafic")

Les coûts proviennent des services managés (PaaS) qui tournent "sur" le réseau, et du trafic (Data Transfer) qui le traverse.

Services Managés (Facturés $/Heure)

Trafic (Data Transfer) (Le Coût "Caché")

• (Gratuit) Trafic Entrant (Ingress) depuis Internet.
• (Gratuit) Trafic Interne (MÊME AZ) (ex: EC2-App (AZ-A) -> RDS-Master (AZ-A)).
• (PAYANT) Trafic Sortant (Egress) vers Internet (via IGW ou NAT). (Facturé $0.09/GB après le Free Tier).
• (PAYANT - Le Piège) Trafic Inter-AZ (Cross-AZ).
  • (ex: EC2-App (AZ-A) -> RDS-Standby (AZ-B) (lors de Multi-AZ)).
  • (Coûte $0.01/GB (Entrant) + $0.01/GB (Sortant)).

8.3. Stratégies d'Optimisation (FinOps)

1. Minimiser le Trafic NAT Gateway (Le Tueur n°1)

Le coût $/GB (Data Processed) du NAT GW est votre principal ennemi. Chaque apt-get update, pip install, ou git pull (sur une EC2 privée) coûte de l'argent.

• Solution A (Endpoints) : Si le trafic est vers S3 ou DynamoDB, utilisez un VPC Endpoint (Gateway) (8.1). C'est GRATUIT et le trafic (S3) ne passe plus par le NAT.
• Solution B (Endpoints Interface) : Si le trafic est vers KMS, ECR, Secrets Manager, utilisez un VPC Endpoint (Interface) (8.2). C'est payant ($/Heure), mais (souvent) moins cher que le $/GB du NAT.
• Solution C (Mirror) : Pour les patchs (apt) ou libs (pypi, npm), déployez un proxy/mirror (ex: Artifactory, Nexus) dans le VPC (sur une EC2) pour mettre en cache les dépendances.

2. Centraliser la Sortie (Transit Gateway)

(Mauvaise Pratique) : Avoir 10 VPCs (Dev, Test, Prod,...) et déployer 10 NAT Gateways (HA Multi-AZ = 20-30 NAT GWs). (Coût horaire $/Heure massif).

(Bonne Pratique) :

1. Créer 1 VPC "Egress" (Sortie) centralisé (qui contient 1 (ou 2 pour HA) NAT GW).
2. Créer 1 Transit Gateway (TGW).
3. Attacher les 10 VPCs (Dev, Test...) + le VPC "Egress" au TGW.
4. Configurer le routage (0.0.0.0/0) des 10 VPCs pour pointer vers le TGW, qui route vers le VPC "Egress" (NAT).
5. (Résultat) : 10 VPCs partagent 1 (ou 2) NAT GW.

3. Planifier les CIDR (Éviter l'Overlap)

Si VPC-A (10.0.0.0/16) et VPC-B (10.0.0.0/16) (overlap) doivent communiquer :

(Mauvaise Solution) : Impossible de "Peerer". Il faut mettre des NATs des deux côtés pour masquer les IPs. (Complexe, coûteux, casse la performance).

(Bonne Solution) : Planifier (à l'avance) : VPC-A = 10.0.0.0/16, VPC-B = 10.1.0.0/16. (Permet un Peering (ou TGW) simple et gratuit).

7.2. VPC Flow Logs (Analyse Réseau Détaillée)

Les "Flow Logs" sont un enregistrement (log) de tous les flux IP (métadonnées) qui tentent d'entrer ou de sortir de vos interfaces réseau (ENI), Subnets, ou du VPC entier.

Format du Log : (Compte, ENI, SrcIP, DstIP, SrcPort, DstPort, Protocole, Action, Status)

Débogage de Connexions (EC2 -> RDS)

Problème : Mon EC2-App (10.0.1.50) n'arrive pas (Timeout) à joindre RDS (10.0.10.100) sur le port 5432.

Analyse (via Logs Insights (7.1)) :

                    fields action, srcAddr, dstAddr, dstPort
                    | filter (srcAddr = '10.0.1.50' AND dstAddr = '10.0.10.100' AND dstPort = 5432)
                

Interprétation des Résultats (Action)

7.3. VPC Reachability Analyzer (Test de Chemin Statique)

C'est un outil de simulation (analyse statique). Il ne teste pas (Live) le réseau, il lit (analyse) vos configurations (SG, NACL, Routes, Peering...) pour prédire (mathématiquement) si un chemin est "joignable" (reachable).

Fonctionnement

Vous créez une "Analyse" :

• Source : ex: Instance i-ec2-app (ou eni-xxxx)
• Destination : ex: Instance i-rds-db (ou eni-yyyy)
• Port (Optionnel) : TCP 5432

Résultat (Diagnostic)

Après 30 secondes, l'outil répond :

Résultat 1 : Reachable (Joignable)
-> (L'outil trace le chemin complet (Route Table, SG In/Out, NACL In/Out) et confirme que tout est OK).

Résultat 2 : Not Reachable (Non Joignable)
-> (L'outil identifie le point de blocage exact) :

                    (Exemple de blocage SG)
                    "Analyse: Échec.
                    Composant: Security Group (sg-12345-db) (Attaché à eni-yyyy)
                    Cause: La règle Inbound (Entrante) ne contient pas de 'Allow' pour le Port 5432 (Source: sg-67890-app)."
                

                    (Exemple de blocage Routage)
                    "Analyse: Échec.
                    Composant: Route Table (rtb-abcde-private) (Attachée à subnet-app)
                    Cause: Aucune route trouvée pour la Destination 10.1.0.0/16 (VPC Peering)."
                

Usage : C'est le meilleur outil pour débugger (sans tcpdump) pourquoi 2 ressources ne communiquent pas.

7.4. Network Access Analyzer (Audit de Risque Global)

C'est un outil d'audit (Compliance) global, (basé sur la même technologie (Zelkova) que le Reachability Analyzer (7.3)).

Il ne teste pas (Source -> Dest) (1:1), il teste (Internet -> Toutes les Ressources) (N:N).

Question (Analyse)

Il répond à la question : "Dans tout mon compte AWS (tous VPCs, SGs, NACLs, Routes, IGWs...), quelles sont les ressources (privées) qui sont (potentiellement) accessibles involontairement depuis Internet ?"

Fonctionnement

1. Vous définissez un "Network Access Scope" (ex: "Trouver tout accès (0.0.0.0/0) à mes ressources (Type=RDS)").
2. Vous lancez l'analyse.
3. L'outil (analyse statique) calcule tous les chemins réseau possibles depuis l'IGW vers vos ressources.

Résultat (Findings / Constatations)

L'outil produit un rapport (Finding) pour chaque exposition involontaire trouvée :

(Exemple de Finding / Alerte) :

                    "Finding: Accès Public (Port 3389/RDP)
                    Ressource: Instance EC2 (i-windows-server)
                    Chemin d'Accès:
                    [Internet Gateway (igw-abc)]
                    -> [Route Table (rtb-public) (Route 0.0.0.0/0)]
                    -> [NACL (nacl-default) (Rule 100 Allow All)]
                    -> [Security Group (sg-temp-dev) (Rule Inbound Allow 3389 (Source: 0.0.0.0/0))]"
                

Usage : Outil indispensable (CIS, PCI) pour les Audits de Sécurité et pour trouver les "Shadow IT" (ex: un Dev qui ouvre RDP/SSH (Source: 0.0.0.0/0) "juste 5 minutes" et oublie).

7.5. Erreurs Courantes (Common Misconfigurations)

1. Mauvaises Routes (Routage)

• Erreur : Mettre une EC2/RDS (Privée) dans un Subnet Public (un Subnet dont la Route Table (2.4) pointe (0.0.0.0/0) vers l'IGW).
  Risque : Si quelqu'un (erreur) attache une EIP (3.5) à cette BDD, elle est exposée sur Internet.
• Erreur : Oublier d'ajouter la route (0.0.0.0/0 -> NAT GW) à la Route Table Privée.
  Symptôme : L'EC2 (Privée) ne peut pas faire apt-get update (Timeout).

2. Security Groups (SG) Trop Permissifs

• Erreur : (Admin) sg-app (EC2) (Inbound: Allow 22 (SSH) Source: 0.0.0.0/0).
  Risque : Attaques Brute Force (SSH) (depuis le monde entier).
  Solution : Source: Mon_IP_Bureau/32 (ou mieux : pas de SSH, utiliser SSM Session Manager).
• Erreur : (Dev) sg-db (RDS) (Inbound: Allow 5432 Source: 0.0.0.0/0).
  Risque : Attaques Brute Force (BDD) (si RDS dans Subnet Public).
• Erreur : (Dev) sg-db (RDS) (Inbound: Allow 5432 Source: 10.0.0.0/16 (VPC CIDR)).
  Risque : Moins grave, mais (Violation Least Privilege) autorise l'EC2 "Marketing" (10.0.30.x) à scanner/attaquer la BDD (10.0.10.x).
  Solution : Source: sg-app (ID du SG applicatif (6.2)).

3. CIDR Overlapping (Chevauchement)

• Erreur : Créer VPC-A (10.0.0.0/16) et VPC-B (10.0.0.0/16).
  Conséquence : Routage impossible. Vous ne pourrez jamais connecter (Peering (5.3)) ces 2 VPCs.

6.2. Techniques "Least Privilege" (Moindre Privilège) pour SG

Le principe du "moindre privilège" (Least Privilege) signifie n'autoriser que ce qui est strictement nécessaire. Les SGs (Stateful, Allow-only) sont l'outil parfait pour cela.

Bonne Pratique : Référencer par SG-ID (pas par CIDR)

(Mauvaise Pratique) : Si sg-app (10.0.10.0/24) doit parler à sg-db (10.0.20.0/24), ne mettez pas (Source: 10.0.10.0/24) dans sg-db. (Si une EC2 "pirate" démarre dans 10.0.10.0/24, elle peut parler à la BDD).

(Bonne Pratique) : Utilisez l'ID du SG comme Source.

Règle (Inbound) pour sg-db (RDS PostgreSQL) :

Réseau d'Administration Isolé (Bastion / Jump Host)

Ne jamais autoriser SSH (Port 22) ou RDP (Port 3389) (Source: 0.0.0.0/0) sur vos instances privées.

Architecture (Bastion) :

• 1. sg-bastion (attaché à l'EC2 "Bastion" dans un Subnet Public)
  • Inbound : Allow Port 22 (Source: Mon_IP_Bureau/32)
• 2. sg-app-prive (attaché à l'EC2 "App" dans un Subnet Privé)
  • Inbound : Allow Port 22 (Source: sg-bastion)

Flux : (Admin) -> SSH (sg-bastion) -> Rebond SSH (ssh -J ...) -> (sg-app-prive). (L'instance privée n'est jamais exposée).

6.3. NACL : Cas d'Usage (Quand l'utiliser ?)

Les SGs (6.2) (Stateful) sont plus faciles à gérer et devraient être votre outil principal. Les NACL (Stateless) sont un outil "brut" (niveau Subnet) utile pour des cas spécifiques.

Cas d'Usage 1 : Blacklisting (Liste Noire) Explicite

Vous subissez une attaque (ex: scan de ports) depuis une IP spécifique (1.2.3.4). Vous voulez la bloquer immédiatement (au niveau du Subnet) avant qu'elle n'atteigne vos SGs.

Règle (Inbound) nacl-public :

(Flux) : Le trafic (1.2.3.4) "match" la Règle 100 (Deny) et est bloqué (drop). Le trafic (80.1.2.3) "match" la Règle 200 (Allow) et passe (au SG).

Cas d'Usage 2 : Protection Complémentaire (Subnet Privé)

Paranoïa (Bonne Pratique) : Votre subnet-db (isolé) ne doit jamais parler à Internet. Un admin (fatigué) pourrait (par erreur) attacher le mauvais SG ("Allow All") à la BDD RDS.

Le NACL (attaché au subnet-db) sert de "backstop" (garde-fou) en n'autorisant que le trafic local.

Règle (Inbound/Outbound) nacl-db :

• 100: Allow (Source/Dest: 10.0.0.0/16 (VPC CIDR))
• *: Deny (Défaut)

(Résultat) : Même si le SG (de RDS) est Allow All (0.0.0.0/0), le NACL (du Subnet) bloquera tout trafic (REJECT) qui ne vient pas de 10.0.0.0/16.

6.4. VPC Flow Logs (Analyse & Détection)

C'est l'outil (optionnel) de Monitoring (Audit) réseau. Il capture (loggue) les métadonnées (IPs, Ports, Protocole, Paquets, Action) de tout le trafic IP (entrant/sortant) du VPC.

Destination : CloudWatch Logs ou S3

• CloudWatch Logs : (Recommandé pour Debug) Permet d'utiliser CloudWatch Logs Insights (requêtes "SQL-like") pour filtrer (en temps réel) le trafic.
• S3 (Format Parquet) : (Recommandé pour Archive/SIEM) Stockage long-terme (moins cher). Permet d'utiliser AWS Athena (SQL) pour des analyses complexes (ex: "Top Talkers" sur 3 mois).

Analyse (Détection des Anomalies)

Flow Logs est la source n°1 pour détecter les problèmes de sécurité (visibilité).

Exemple 1 (Debug) : "Mon App (10.0.1.50) ne joint pas RDS (10.0.2.100:5432)"

Requête (Logs Insights) :

                    fields @timestamp, srcAddr, dstAddr, dstPort, action, logStatus
                    | filter (srcAddr = '10.0.1.50' and dstAddr = '10.0.2.100')
                    | sort @timestamp desc
                

Résultat : ... 10.0.1.50 10.0.2.100 5432 REJECT OK
Analyse : REJECT = C'est le Security Group (SG) qui bloque (Défaut Deny). (Si REJECT venait d'une NACL, le logStatus serait DENY).

Exemple 2 (SIEM) : "Détecter un Scan de Port"

Requête (Athena/SIEM) :

                    -- (Trouver les IPs sources qui ont le plus de "REJECTs" (SG) ou "DENYs" (NACL))
                    SELECT srcAddr, count(*) AS Rejects
                    FROM vpc_flow_logs
                    WHERE action = 'REJECT'
                    GROUP BY srcAddr
                    ORDER BY Rejects DESC
                    LIMIT 10;
                

6.5. DNS & Réseau Interne (Route 53 Resolver)

Le DNS (Domain Name System) est un composant critique du VPC, géré (automatiquement) par Route 53 Resolver.

Le DNS "Magique" (.2) (AmazonProvidedDNS)

Par défaut (DHCP (3.4)), chaque instance (EC2/Lambda) dans votre VPC (CIDR 10.0.0.0/16) est configurée pour utiliser le serveur DNS 10.0.0.2.

Ce "Resolver" (.2) est "Split-Horizon" (intelligent) :

• 1. Résolution Publique : (ping google.com) -> .2 -> (Résout IP Publique).
• 2. Résolution Privée (Noms EC2) : (ping ip-10-0-1-50.eu-west-3...) -> .2 -> (Résout IP Privée 10.0.1.50).

Isolation DNS (Route 53 Private Hosted Zones)

Vous pouvez (via Route 53) créer une zone DNS (ex: mon-app.interne) et l'attacher à votre VPC.

Résultat : Seules les instances dans ce VPC peuvent résoudre ces noms.

• (EC2-App) ping db.mon-app.interne -> (Resolver .2) -> (Résout IP Privée 10.0.10.100 (le RDS)).
• (PC Bureau) ping db.mon-app.interne -> (Erreur DNS NXDOMAIN) (La zone n'existe pas sur Internet).

Réseau Hybride (Resolver Endpoints)

Si vous avez un VPN/DX (3.6) vers On-Premise (ex: Active Directory (AD) à 192.168.1.10).

• Endpoint INBOUND : (IP 10.0.x.x) Permet à votre AD (On-Prem) de "forwarder" (transférer) les requêtes (.internal) au Resolver (VPC) (.2).
• Endpoint OUTBOUND : (IP 10.0.x.x) Permet à votre Resolver (VPC) (.2) de "forwarder" (transférer) les requêtes (.mon-entreprise.local) à votre AD (On-Prem).

5.2. Routage vers Internet (Sortie)

Cas 1 : Via Internet Gateway (IGW) (Subnets Publics)

Pour les ressources (ex: Load Balancer, Bastion) qui doivent être bidirectionnelles (Entrant + Sortant).

• Composant : Internet Gateway (IGW) (attaché au VPC).
• Ressource : Doit avoir une IP Publique (ou EIP).
• Route Table (Publique) : Doit avoir la "route par défaut" :

                    Destination:  0.0.0.0/0
                    Target:       igw-12345...
                

Cas 2 : Via NAT Gateway (Subnets Privés)

Pour les ressources (ex: EC2-App, Lambda) qui doivent (uniquement) sortir (Egress) sur Internet (ex: apt-get update, API Stripe), mais jamais être jointes (Ingress) depuis Internet.

• Composant : NAT Gateway (PaaS) (placé dans un Subnet Public).
• Ressource : N'a (et ne doit avoir) aucune IP Publique.
• Route Table (Privée) : Doit avoir la "route par défaut" :

                    Destination:  0.0.0.0/0
                    Target:       nat-12345...
                

5.3. VPC Peering (Connexion 1:1)

Le VPC Peering est une connexion réseau 1-pour-1 (point-à-point) qui permet de router le trafic entre deux VPCs (en utilisant leurs IPs privées), comme s'ils étaient sur le même réseau.

Cas d'Usage Typiques

• Connecter VPC-Prod (10.0.0.0/16) et VPC-Dev (10.1.0.0/16).
• Connecter votre VPC-Prod au VPC-Partenaire (Cross-Account).

Pré-requis : Les plages CIDR des 2 VPCs ne doivent pas se chevaucher (overlap).

Limitations : Le "Transitive Routing" (Interdit)

Le Piège : Le Peering n'est PAS transitif. (Pas de "saut" de routage).

Scénario :

(VPC-A) <--- (Peering 1) ---> (VPC-B) <--- (Peering 2) ---> (VPC-C)

• (A) peut parler à (B).
• (C) peut parler à (B).
• (A) NE PEUT PAS parler à (C) (en "passant par" B).

Conséquence : Si vous avez 10 VPCs, vous devez créer 45 connexions de peering (n*(n-1)/2) (c'est le "mesh" (maillage) ingérable).

5.4. Transit Gateway (TGW) - Le Hub Réseau

Le TGW est la solution (PaaS, scalable) au problème du Peering (5.3). C'est un Routeur Cloud (Hub) managé par AWS.

Modèle "Hub-and-Spoke" (Étoile)

Au lieu de connecter 10 VPCs (Spokes) entre eux (45 peerings), vous connectez les 10 VPCs 1 seule fois (10 "Attachments") au TGW (Hub).

                    (VPC-A) ---<
                    (VPC-B) ---<
                    (VPC-C) ---<---> [ 🚀 Transit Gateway (HUB) ] <---> (VPN/DX On-Premise)
                    (VPC-D) ---<
                    (VPC-E) ---<
                

Avantages vs VPC Peering

• Routage Transitif : OUI. (A) peut parler à (C) (en passant par le TGW, qui route le trafic).
• Scalabilité (Simplification) : Extrême. (Pour ajouter VPC-F, il suffit de l'attacher 1 fois au TGW).
• Multi-Compte (RAM) : Vous pouvez créer 1 TGW (Compte Réseau) et le partager (via RAM) avec 100 autres comptes (Comptes Applicatifs) de votre AWS Organization.
• Point Central (Hybride) : Le TGW sert aussi de "hub" pour attacher vos connexions VPN (3.6) ou Direct Connect (3.6) On-Premise.

5.5. AWS PrivateLink (VPC Endpoint Services)

PrivateLink est différent du Peering/TGW. Il ne connecte pas 2 réseaux. Il publie (expose) 1 Service (Applicatif) privé d'un VPC (Provider) vers un autre VPC (Consumer), sans routage, sans overlap, sans IGW/NAT.

Architecture (Provider / Consumer)

1. Côté "Provider" (VPC-A : 10.0.0.0/16) (Vous, le "SaaS")

• Vous avez une API (EC2) (IP Privée 10.0.1.50).
• Vous placez un Network Load Balancer (NLB) (privé) devant.
• Vous créez un "Endpoint Service" (PrivateLink) et vous le liez au NLB.
• Vous "Whitelistez" (Autorisez) l'ID du Compte AWS du "Consumer".

2. Côté "Consumer" (VPC-B : 10.0.0.0/16) (Votre Client)

• (Note : Le CIDR (10.0...) chevauche (overlap) celui du Provider !).
• Votre client crée un "Endpoint (Interface)" vers votre "Endpoint Service".
• (AWS) Place une ENI (Carte Réseau) (avec une IP Privée 10.0.80.10) dans le Subnet du client.

Résultat (Magique)

• Le Client (Consumer) (dans VPC-B) fait un appel API vers 10.0.80.10 (son IP locale).
• AWS (via PrivateLink) "téléporte" (encapsule) ce trafic (via le backbone AWS privé) vers le NLB (Provider) (dans VPC-A).

Avantages : Sécurité Maximale (Unidirectionnel, pas de routage), Aucun conflit d'IP (Overlap OK), Pas d'IGW/NAT/Peering.

3.2. NAT Gateway (Accès Sortant Uniquement)

Le NAT Gateway est un service (PaaS) qui permet aux ressources (EC2, Lambda...) dans un Subnet Privé (isolé) d'initier des connexions sortantes vers Internet (ex: apt-get update, git pull, appel API externe), tout en bloquant les connexions entrantes (initiées depuis Internet).

Configuration (Routage)

1. Vous placez le NAT Gateway (PaaS) dans un Subnet Public (il a besoin d'une EIP).
2. Vous modifiez la Route Table du Subnet Privé.

                    # (Dans la Route Table du Subnet PRIVÉ)
                    Destination:  0.0.0.0/0
                    Target:       nat-12345... (L'ID du NAT Gateway)
                

NAT Gateway (PaaS) vs NAT Instance (IaaS)

(HA Multi-AZ) : Pour une vraie résilience, vous devez provisionner 1 NAT Gateway par AZ (nat-a, nat-b...) et configurer les Route Tables (privées) de chaque AZ pour qu'elles utilisent leur NAT GW local (évite les frais de trafic Inter-AZ).

3.3. VPC Endpoints (Accès Privé aux Services AWS)

Problème : Une EC2 (dans un Subnet Privé) doit appeler l'API de S3 ou de Secrets Manager. Ces API sont (par défaut) publiques (sur Internet).

Solution (Lente/Chère) : Ajouter un NAT Gateway (3.2) (payant) pour que l'EC2 puisse sortir sur Internet et re-rentrer chez AWS.

Solution (Moderne/Sécurisée) : Utiliser un VPC Endpoint. Le trafic ne quitte jamais le réseau privé d'AWS.

Types d'Endpoints

Avantages : Sécurité (le trafic ne va pas sur Internet), Performance (latence plus faible), Coût (économise les frais de Data Processing du NAT GW).

3.4. DHCP Options Set

Le "DHCP Options Set" est un ensemble de configurations réseau (DHCP) que votre VPC (et son serveur DNS) "pousse" (distribue) à toutes les instances (EC2, etc.) qui démarrent à l'intérieur.

Configuration (Défaut vs Custom)

Quand vous créez un VPC, AWS lui attache un "DHCP Options Set" par défaut :

• domain-name-servers : AmazonProvidedDNS. C'est le serveur DNS magique d'AWS (situé à l'IP .2 de votre CIDR, ex: 10.0.0.2). Il résout les noms publics (google.com) et les noms privés (ip-10-0-1-50.eu-west-3.compute.internal).
• domain-name : eu-west-3.compute.internal (Suffixe DNS).
• ntp-servers : Amazon Time Sync Service (Serveur de temps).

Cas d'Usage (Custom)

Vous créez un "DHCP Options Set" custom si vous avez un réseau hybride (3.6) (ex: VPN vers On-Premise) et que vous avez besoin que vos EC2 (Cloud) :

• Utilisent votre Propre Serveur DNS (On-Premise) (ex: un Active Directory à 192.168.1.10) pour résoudre serveur-interne.mon-entreprise.local.
• (Dans ce cas, vous créez un Set avec domain-name-servers = 192.168.1.10, AmazonProvidedDNS).

3.5. Elastic IP (EIP)

Une Adresse IP Élastique (EIP) est une adresse IPv4 publique statique (fixe) que vous "allouez" (réservez) dans votre compte AWS.

IP Publique (Éphémère) vs Elastic IP (Statique)

• IP Publique (Auto-assign) : (Éphémère) Assignée au démarrage (Start) de l'EC2. Perdue (libérée) à l'arrêt (Stop). (Problème pour les DNS).
• Elastic IP (Statique) : (Fixe) Vous l'associez (manuellement) à l'EC2. Elle survit à l'arrêt (Stop), au redémarrage (Reboot), et même à la suppression (Terminate) (elle redevient "non-associée").

Cas d'Usage

• 1. NAT Gateway (3.2) : (Obligatoire) Un NAT Gateway nécessite 1 EIP pour fonctionner (c'est son IP de sortie fixe).
• 2. Serveur (Legacy) Statique : (ex: Un Bastion (hôte SSH) ou un vieux serveur (S)FTP) dont l'IP doit être fixe (pour être mise en "Whitelist" (liste blanche) chez un partenaire).

Bonnes Pratiques (Limiter au maximum)

(Anti-Pattern) : N'utilisez jamais d'EIPs pour vos serveurs Web (Frontend). (Ce n'est pas scalable et ce n'est pas "Haute Disponibilité" (HA)).

(Bonne Pratique) : Mettez vos serveurs Web (EC2) dans un Subnet Privé (sans EIP), et placez un Application Load Balancer (ALB) (qui, lui, a une IP publique/DNS) dans le Subnet Public (devant).

(Piège de Coût) : Une EIP est GRATUITE si elle est attachée à une instance EC2 Running. Une EIP non-attachée (ou attachée à une instance Stopped) est facturée (cher) (pour éviter la pénurie d'IPv4).

3.6. Réseaux Hybrides (VPN & Direct Connect)

Ce sont les 2 méthodes (Réseau Hybride) pour connecter votre Data Center (Bureau / On-Premise) (ex: 192.168.1.0/24) à votre VPC (AWS) (ex: 10.0.0.0/16).

1. Site-to-Site VPN (Connexion Chiffrée)

• Transport : Internet (Public).
• Technologie : IPSec (Tunnel chiffré).
• AWS (Hub) : Virtual Private Gateway (VGW) (Legacy) ou Transit Gateway (TGW) (Moderne).
• On-Premise (Hub) : Customer Gateway (CGW) (Routeur/Firewall (Cisco, Fortinet...)).
• Vitesse : Limitée (ex: ~1.25 Gbps). Dépend de votre FAI (Internet).
• Coût : Faible (Payé $/Heure (Connexion VPN) + Data Transfer).
• Usage : Dev/Test, PME, Backups, Redondance (Backup) de Direct Connect.

2. AWS Direct Connect (DX) (Connexion Privée)

• Transport : Fibre Optique (Privée) (Dédiée). (Vous (via Partenaire: Equinix, Orange...) tirez une fibre de votre DC (On-Prem) vers un "DX Location" (Point de Présence AWS)).
• Technologie : VLANs (802.1q). (Non chiffré par défaut, car privé. Peut être combiné avec VPN (IPSec) pour chiffrement).
• Vitesse : Garantie (Dédiée : 1 Gbps, 10 Gbps, 100 Gbps).
• Latence : Très basse, stable (pas d'Internet).
• Coût : Élevé (Facturé au Port/Heure (ex: 10Gbps = $2.20/h) + Coût Opérateur (Equinix)).
• Usage : Production (Gros volumes), migration BDD (Oracle), workloads sensibles (latence).

Routage BGP

Les deux (VPN et DX) utilisent BGP (Border Gateway Protocol) (Dynamique) ou (Routes Statiques) pour échanger (annoncer) les routes entre AWS et On-Premise. (ex: Le routeur On-Prem annonce "Je possède 192.168.1.0/24" au VGW/TGW).

2.2. Subnets (Sous-réseaux)

Un Subnet est une "tranche" (partition) du CIDR de votre VPC. C'est la "salle" (dans votre Datacenter VPC) où vous placez vos ressources (EC2, RDS...).

Règle Fondamentale : Un Subnet "vit" entièrement dans 1 seule Availability Zone (AZ).

Subnet Public vs Privé vs Isolé

La distinction (Public/Privé) ne dépend pas du Subnet lui-même, mais de la Route Table (2.4) qui lui est attachée.

• 1. Subnet Public : La Route Table a une route 0.0.0.0/0 (Internet) vers un Internet Gateway (IGW).
  • Usage : Ressources qui doivent être jointes depuis Internet (Load Balancers (ALB), Bastions SSH, NAT Gateways).
• 2. Subnet Privé (NAT) : La Route Table n'a pas de route vers l'IGW. Elle a (généralement) une route 0.0.0.0/0 vers un NAT Gateway.
  • Usage : Ressources qui ne doivent pas être jointes depuis Internet, mais qui doivent accéder à Internet (Sortie) (pour apt update, APIs externes, etc.). (Ex: EC2 (Web App), Lambda (VPC)).
• 3. Subnet Isolé (Privé) : La Route Table n'a pas de route vers IGW ni NAT GW. (Seule la route local existe).
  • Usage : Sécurité maximale. Ressources qui ne doivent jamais voir Internet (ni Entrée, ni Sortie). (Ex: Bases de données RDS, ElastiCache). (Utilise des VPC Endpoints (privés) pour parler aux API AWS).

Bonne Construction (Haute Disponibilité - HA)

Pour la résilience (2.3), une architecture de production doit (au minimum) utiliser 2 AZs.

Exemple (VPC 10.0.0.0/16) :

• subnet-public-a (AZ-a) : 10.0.1.0/24
• subnet-public-b (AZ-b) : 10.0.2.0/24
• subnet-private-a (AZ-a) : 10.0.10.0/24
• subnet-private-b (AZ-b) : 10.0.11.0/24

2.3. Availability Zones (AZ) & Résilience

Définition : Qu'est-ce qu'une AZ ?

Une Availability Zone (AZ) est (au minimum) un Datacenter (physique, bâtiment) complet, avec sa propre alimentation, son propre refroidissement, et son propre réseau (fibre). Les AZs (d'une Région) sont séparées (ex: 10-100km) pour résister aux pannes (incendie, inondation, coupure électrique...).

Pourquoi répartir les Subnets (2.2) ?

Pour la Haute Disponibilité (HA) / Tolérance aux pannes.

Scénario d'Architecture Multi-AZ

Mauvaise Architecture (Single-AZ) :

• ALB (Load Balancer) -> (dans subnet-public-a)
• EC2-App1, EC2-App2 -> (dans subnet-private-a)
• Panne : Si l'AZ-a (Datacenter) prend feu -> 100% de l'application (ALB + EC2s) est HORS LIGNE.

Bonne Architecture (Multi-AZ) :

• ALB -> (activé sur subnet-public-a ET subnet-public-b)
• EC2-App1 -> (dans subnet-private-a (AZ-a))
• EC2-App2 -> (dans subnet-private-b (AZ-b))
• Panne : Si l'AZ-a prend feu -> (EC2-App1 est mort).
• Résultat : L'ALB (qui tourne toujours en AZ-b) détecte la panne (Health Check) et envoie 100% du trafic (automatiquement) vers EC2-App2 (en AZ-b).
• (Downtime : Zéro).

2.4. Route Tables (Le "GPS" du Subnet)

La Route Table (RT) est le routeur virtuel (le "GPS") qui est attaché à un Subnet (2.2). Elle détermine où envoyer le trafic réseau.

La Route "Locale" (Immuable)

Toute RT (même vide) contient toujours 1 route (immuable) :

Destination: 10.0.0.0/16 (Le CIDR du VPC)
                    Target:      local
                

Rôle : Permet à toutes les ressources (EC2, RDS...) dans le VPC de se parler (communication interne), peu importe leur Subnet (Public ou Privé).

Exemples de Tables (Publique vs Privée)

Exemple : rt-public (Table de Route Publique)

Exemple : rt-private (Table de Route Privée)

2.5. Network ACL (NACL) - Le Pare-feu "Stateless"

C'est le pare-feu (optionnel) qui opère au niveau du Subnet (2.2). Il filtre tout le trafic (entrant/sortant) du Subnet.

Caractéristiques Clés (Stateless)

• Niveau : Subnet. (Le "garde" à l'entrée du bâtiment).
• Règles : Allow ET Deny. (Utile pour "blacklister" (Deny) une IP d'attaquant).
• Évaluation : Par Numéro (ex: 100, 200...). La 1ère règle qui "match" gagne.
• État : STATELESS (Amnésique).
  • (Le Piège) Si vous autorisez (Inbound) le Port 80 (HTTP), vous devez aussi autoriser (Outbound) les ports "éphémères" (1024-65535) (le trafic de réponse).

Exemple Règle (Inbound)

(Bonne Pratique) : Les NACL (par défaut) autorisent tout. Il est (souvent) recommandé de les laisser ainsi, et de gérer 99% de la sécurité via les Security Groups (2.6) (qui sont Stateful et plus faciles à gérer).

2.6. Security Groups (SG) - Le Pare-feu "Stateful"

C'est le pare-feu principal (le plus important) qui opère au niveau de l'Instance (ENI) (ex: EC2, RDS).

Caractéristiques Clés (Stateful)

• Niveau : Instance (ENI). (La "porte" du bureau).
• Règles : Allow uniquement.
• Défaut : Deny All (Tout est bloqué, sauf ce qui est autorisé (Whitelist)).
• État : STATEFUL (Contextuel).
  • (La Force) Si vous autorisez (Inbound) le Port 80, le trafic de réponse (Outbound) (sur port éphémère) est automatiquement autorisé (le SG "se souvient" de la connexion).

Bonnes Pratiques (Segmenter par Service)

Ne pas créer 1 "gros" SG (sg-prod) qui autorise (Inbound) 80, 443, 22, 5432, 3306...

(Segmenter) :

• sg-alb (Load Balancer) :
  • Inbound : Allow 80, 443 (Source: 0.0.0.0/0)
• sg-app (EC2/Django) :
  • Inbound : Allow 80 (Source: sg-alb), Allow 22 (Source: MyIP)
• sg-db (RDS/Postgres) :
  • Inbound : Allow 5432 (Source: sg-app)

(Règle d'Or) : Toujours utiliser des ID de SG (sg-xxxx) comme Source (plutôt que des IPs/CIDR) pour lier les services (ex: App -> DB).

1. Contrôle Total du Réseau

Vous (et non AWS) définissez l'architecture réseau de A à Z :

• Adressage IP (CIDR) : Vous choisissez vos plages d'IP privées (ex: 10.0.0.0/16) pour éviter les conflits (overlap) avec votre réseau d'entreprise (On-Premise).
• Sous-réseaux (Subnets) : Vous décidez de la taille et de la topologie (ex: /24 par AZ).
• Routage (Route Tables) : Vous contrôlez exactement comment le trafic circule (ex: ce Subnet va sur Internet (via IGW), cet autre va sur le NAT, cet autre va au VPN).

2. Sécurité Renforcée & Isolation (Firewalling)

Par défaut, un VPC (custom) est une "boîte noire" (Deny All). Vous utilisez des pare-feux (gratuits) pour ouvrir (en Whitelist) ce qui est nécessaire :

• Security Groups (SG) : Le pare-feu Stateful (intelligent) au niveau de l'instance (EC2/RDS). (ex: "Autoriser Port 80 depuis l'ALB").
• Network ACLs (NACL) : Le pare-feu Stateless (brut) au niveau du Subnet. (ex: "Bloquer (Deny) cette IP d'attaquant (1.2.3.4/32) pour tout le Subnet").

3. Architecture Multi-Tiers (Multi-Tier)

C'est le cas d'usage standard. Isoler vos "couches" applicatives pour la sécurité "Zero Trust".

                    (Internet)
                    |
                    v
                    [ 🌐 Subnet Public (eu-west-3a) ]  (Route -> IGW)
                    |
                    +-- [ ⚖️ Application Load Balancer (ALB) ]
                    |
                    (Trafic Port 80/443)
                    |
                    v
                    [ 🔒 Subnet Privé (eu-west-3a) ]  (Route -> NAT GW)
                    |
                    +-- [ 💻 EC2 Web Server (Django/Node.js) ]
                    |   (Security Group 'sg-app' : Autorise Port 80 depuis 'sg-alb')
                    |
                    (Trafic Port 5432)
                    |
                    v
                    [ 🔑 Subnet Privé "Data" (eu-west-3a) ] (Route -> NAT GW)
                    |
                    +-- [ 🐘 RDS Database (PostgreSQL) ]
                    (Security Group 'sg-db' : Autorise Port 5432 depuis 'sg-app')
                

Résultat : La base de données (RDS) est inaccessible depuis Internet. Seul le serveur (sg-app) peut lui parler.

Services "Dans" le VPC (Ressources privées)

Ces services dépendent du VPC pour leur isolation et leur adressage IP :

• EC2 (Compute) : Le service de base. Vit dans un Subnet.
• RDS / ElastiCache (Bases de données) : Vivent dans un "DB Subnet Group" (un ensemble de Subnets privés).
• ELB (Load Balancing) : L'ALB/NLB est placé dans des Subnets (généralement Publics).
• EFS (Stockage Fichier) : Place des "Mount Targets" (ENI) dans vos Subnets.
• Lambda (Mode VPC) : Place des "Hyperplane ENI" (cartes réseau) dans vos Subnets pour accéder à RDS/ElastiCache.

Services "Autour" du VPC (Services de gestion)

Ces services (souvent Globaux ou Régionaux) interagissent avec le VPC :

• IAM (Sécurité) : (Global) Gère les permissions. (ex: "Qui a le droit de modifier le VPC ?", "Quel Rôle l'EC2 (dans le VPC) peut-elle assumer ?").
• CloudWatch (Monitoring) : (Régional) Observe le VPC. (ex: Métriques (CPU/RAM) des EC2/RDS, Métriques du NAT GW (Trafic), et surtout VPC Flow Logs (logs de tout le trafic IP)).
• Route 53 (DNS) : (Global/Régional) Résout les noms.
  • Public Hosted Zone : (ex: monsite.com -> IP Publique de l'ALB).
  • Private Hosted Zone : (DNS privé interne au VPC) (ex: db.prod.local -> 10.0.10.50 (IP Privée RDS)).

Services "Externes" (Services AWS Publics)

Ces services (Régionaux) vivent sur le réseau public d'AWS, en dehors de votre VPC.

• S3, DynamoDB, SQS, SNS, Secrets Manager...
• (Accès) : Par défaut, une EC2 (dans un Subnet Privé) doit passer par un NAT Gateway (payant) pour les appeler (via Internet).
• (Accès Privé) : La "Bonne Pratique" est d'utiliser des VPC Endpoints (Gateway ou Interface) pour y accéder via le réseau privé d'AWS (sans NAT/IGW).