VPC : sous-réseaux, IGW et tables de routage

À la fin de ce tutoriel, vous aurez un VPC custom en ca-central-1 avec CIDR planifié, un subnet public, un subnet privé, une Internet Gateway, et des route tables qui séparent le trafic — base de toute archi Solutions Architect.

Niveau : Débutant → Intermédiaire · Temps estimé : 55–70 min · Versions testées : VPC Console/API 2026, AWS CLI v2 · Dernière vérification : 2026-09-11 · Region : ca-central-1

← Précédent : CloudFront + S3 · → Suivant : SG vs NACL · Hub : Démarrer avec AWS

Publish : HOLD

Prérequis

• Profil CLI lab, Region ca-central-1
• Notions AZ (EC2)
• Ne pas supprimer le VPC par défaut du compte (utile pour d’autres labs) — on crée un VPC lab dédié
• Budget d’alerte actif (surtout si vous créez une NAT plus tard — hors scope ici)

export AWS_PROFILE=lab
export AWS_DEFAULT_REGION=ca-central-1
# PowerShell : $env:AWS_PROFILE='lab'; $env:AWS_DEFAULT_REGION='ca-central-1'

Coût estimé lab (ca-central-1, 2026) : VPC / subnets / IGW / route tables = 0 USD. Une NAT Gateway = $$/heure + data → hors scope (ne pas créer « pour voir »). Pour labs SSM/S3, préférez des VPC endpoints. Une NAT oubliée reste le classique de facture surprise.

Ce que nous allons construire

Un VPC (Virtual Private Cloud) est votre réseau isolé dans AWS : vous choisissez le CIDR, découpez des subnets par AZ, et décidez qui a une route vers Internet. Ici on pose le squelette minimal d’une archi multi-tiers.

VPC lab-vpc  10.0.0.0/16
├── Subnet public  10.0.1.0/24  (ca-central-1a) + auto-assign public IP
├── Subnet privé   10.0.2.0/24  (ca-central-1a)
├── Internet Gateway igw-lab
├── RT public : 0.0.0.0/0 → IGW
└── RT privé  : locale seulement (pas de NAT dans ce lab)

(Schéma — alt : « VPC public/privé, IGW, route tables ».)

Rappel utile : un subnet n’est « public » ou « privé » que par sa route table (et éventuellement map-public-ip-on-launch). AWS ne pose pas d’étiquette magique — c’est votre design de routage qui fait la différence.

Étape 1 — CIDR et AZ (design rapide)

Règles : pas de chevauchement avec d’autres VPC que vous peererez ; /16→/24 laisse de la place pour d’autres AZ (10.0.3.0/24…). En pratique, réservez aussi des plages pour un futur peering (172.16.0.0/16, autre 10.x) afin d’éviter les collisions CIDR — cause n°1 d’échec de VPC Peering.

Repère examen SA : RFC1918 ; un subnet = une AZ ; /24 = confort lab. En ca-central-1 : typiquement ca-central-1a / 1b.

Listez une AZ :

AZ=$(aws ec2 describe-availability-zones   --region ca-central-1   --query 'AvailabilityZones[0].ZoneName' --output text)
echo "$AZ"

Étape 2 — Créer le VPC et les subnets

VPC_ID=$(aws ec2 create-vpc --cidr-block 10.0.0.0/16   --tag-specifications 'ResourceType=vpc,Tags=[{Key=Name,Value=lab-vpc}]'   --query Vpc.VpcId --output text)

aws ec2 modify-vpc-attribute --vpc-id "$VPC_ID" --enable-dns-support
aws ec2 modify-vpc-attribute --vpc-id "$VPC_ID" --enable-dns-hostnames

SUBNET_PUB=$(aws ec2 create-subnet --vpc-id "$VPC_ID"   --cidr-block 10.0.1.0/24 --availability-zone "$AZ"   --tag-specifications 'ResourceType=subnet,Tags=[{Key=Name,Value=lab-public-1a}]'   --query Subnet.SubnetId --output text)

SUBNET_PRIV=$(aws ec2 create-subnet --vpc-id "$VPC_ID"   --cidr-block 10.0.2.0/24 --availability-zone "$AZ"   --tag-specifications 'ResourceType=subnet,Tags=[{Key=Name,Value=lab-private-1a}]'   --query Subnet.SubnetId --output text)

aws ec2 modify-subnet-attribute --subnet-id "$SUBNET_PUB" --map-public-ip-on-launch

echo "VPC=$VPC_ID PUB=$SUBNET_PUB PRIV=$SUBNET_PRIV"

DNS hostnames + support : nécessaires pour des noms publics/EC2 corrects. Sans enable-dns-hostnames, une instance avec IP publique n’obtient pas de hostname DNS AWS (ec2-…compute.amazonaws.com), ce qui complique SSH, scripts et intégrations.

Chaque subnet vit dans une seule AZ. Les IPs « AWS reserved » réduisent légèrement le /24 utilisable — normal. Taggez toujours Name= pour la lisibilité console.

Étape 3 — Internet Gateway

IGW_ID=$(aws ec2 create-internet-gateway   --tag-specifications 'ResourceType=internet-gateway,Tags=[{Key=Name,Value=lab-igw}]'   --query InternetGateway.InternetGatewayId --output text)

aws ec2 attach-internet-gateway --internet-gateway-id "$IGW_ID" --vpc-id "$VPC_ID"

Sans IGW, aucun trafic IPv4 public entrant/sortant depuis le VPC (hors endpoints). L’IGW est hautement disponible et scalée par AWS : une seule IGW par VPC suffit ; on l’attache puis on pointe les routes 0.0.0.0/0 vers elle. Attacher sans route (ou l’inverse) ne donne pas Internet — les deux sont obligatoires.

Étape 4 — Tables de routage

Chaque VPC a une route table principale (main) avec la route locale implicite (10.0.0.0/16 → local). On crée des RT custom pour séparer clairement public et privé, plutôt que de modifier la main RT au hasard.

RT_PUB=$(aws ec2 create-route-table --vpc-id "$VPC_ID"   --tag-specifications 'ResourceType=route-table,Tags=[{Key=Name,Value=lab-rt-public}]'   --query RouteTable.RouteTableId --output text)

aws ec2 create-route --route-table-id "$RT_PUB"   --destination-cidr-block 0.0.0.0/0 --gateway-id "$IGW_ID"

aws ec2 associate-route-table --route-table-id "$RT_PUB" --subnet-id "$SUBNET_PUB"

RT_PRIV=$(aws ec2 create-route-table --vpc-id "$VPC_ID"   --tag-specifications 'ResourceType=route-table,Tags=[{Key=Name,Value=lab-rt-private}]'   --query RouteTable.RouteTableId --output text)

aws ec2 associate-route-table --route-table-id "$RT_PRIV" --subnet-id "$SUBNET_PRIV"

Le subnet privé n’a que la route locale 10.0.0.0/16 — pas d’Internet. Pour yum/SSM plus tard : VPC endpoints ou NAT (coût). La route la plus spécifique gagne ; 0.0.0.0/0 est le filet « tout le reste » vers l’IGW (public) ou absente (privé). Sans association explicite, un subnet retombe sur la main RT — évitez d’y coller Internet.

Étape 5 — Test minimal (option EC2)

Lancez une micro EC2 dans SUBNET_PUB avec SG SSH/SSM : elle reçoit une IP publique et sort via IGW.
Une EC2 dans SUBNET_PRIV : pas d’IP publique, pas de route 0.0.0.0/0 — ping Internet échoue (attendu).

aws ec2 describe-route-tables --route-table-ids "$RT_PUB" "$RT_PRIV"   --query 'RouteTables[].{Name:Tags[?Key==`Name`].Value|[0],Routes:Routes}'

Si le test public échoue : vérifiez IGW attached, association RT↔subnet, map-public-ip-on-launch, et SG. Le routage seul ne remplace pas les Security Groups (SG vs NACL).

VPC par défaut vs VPC custom

Le Default VPC (/16 + subnet public par AZ) permet de démarrer vite (labs EC2 précoces). En archi réelle / examen « design », on préfère un VPC custom : CIDR choisi, séparation public/privé, pas d’exposition par défaut. Ne supprimez le default VPC que si vous savez pourquoi (certains workshops le demandent — sinon gardez-le).

Étape 6 — NAT Gateway : pourquoi on ne le crée pas ici

Pour la certif : NAT dans subnet public, route privée 0.0.0.0/0 → nat-…. Ne le laissez jamais allumé « pour demain ». En lab SSM/S3, préférez des interface/gateway endpoints.

Multi-AZ (prochaine brique)

En prod vous dupliquez public/privé dans ca-central-1b (10.0.3.0/24, 10.0.4.0/24). Un ALB span plusieurs AZ ; une base RDS Multi-AZ aussi. Ce lab mono-AZ suffit pour comprendre IGW + RT ; le tuto ALB réutilisera le pattern. Convention courante : pairs impairs = public, pairs = privé — l’important est la lisibilité du plan d’adressage.

Étape 7 — Vérification

aws ec2 describe-vpcs --vpc-ids "$VPC_ID" --region ca-central-1
aws ec2 describe-subnets --filters Name=vpc-id,Values="$VPC_ID"
aws ec2 describe-internet-gateways --filters Name=attachment.vpc-id,Values="$VPC_ID"

Checklist : VPC /16 · 2 subnets · IGW attached · RT public → IGW · RT privé sans IGW · tags Name · DNS support + hostnames · Region ca-central-1.

Nettoyage

Ordre typique (dépendances d’abord) : détacher/supprimer IGW → disassocier puis supprimer RT custom → supprimer subnets → supprimer VPC. La main route table part avec le VPC ; ne la supprimez pas à la main.

aws ec2 detach-internet-gateway --internet-gateway-id "$IGW_ID" --vpc-id "$VPC_ID"
aws ec2 delete-internet-gateway --internet-gateway-id "$IGW_ID"

# Disassociate + delete route tables custom (pas la main RT)
# Puis delete subnets, puis VPC — console « delete VPC » aide si dépendances

aws ec2 delete-subnet --subnet-id "$SUBNET_PUB"
aws ec2 delete-subnet --subnet-id "$SUBNET_PRIV"
# delete-route-table pour RT_PUB / RT_PRIV après disassociation
aws ec2 delete-vpc --vpc-id "$VPC_ID"

Contrôle anti-facture : describe-vpcs filtré Name=lab-vpc + describe-nat-gateways (liste vide). Gardez ce VPC s’il sert aux tutos SG/NACL, peering, ALB — sinon détruisez-le. Vérifiez qu’aucune NAT n’a été créée par erreur.

Erreurs fréquentes

Lab bonus (5 min) — prouver public vs privé

1. Lancez une micro EC2 dans SUBNET_PUB avec SSM : curl -s --max-time 5 https://checkip.amazonaws.com → OK (IGW).
2. Même test depuis SUBNET_PRIV (pas d’IP publique) → timeout (attendu sans NAT/endpoint).

Ce mini-lab ancre : même VPC, deux destinées selon la route table — cœur du design SA.

Quiz (5 questions)

1. Une route 0.0.0.0/0 → IGW sur un subnet signifie surtout : – A. Subnet isolé
– B. Trafic Internet IPv4 via Internet Gateway (subnet public typique)
– C. Obligatoirement une NAT

2. Un subnet privé sans NAT ni endpoint : – A. Accède à S3 public facilement
– B. N’a pas de route Internet par défaut
– C. Est illégal dans AWS

3. Pourquoi activer DNS hostnames sur le VPC ? – A. Pour facturer moins
– B. Pour des noms DNS utiles (EC2/public hostnames)
– C. Pour remplacer Route 53

4. Un subnet AWS est toujours lié à : – A. Plusieurs Regions
– B. Une seule Availability Zone
– C. Un Transit Gateway obligatoire

5. Où place-t-on une NAT Gateway pour la sortie des subnets privés ? – A. Dans un subnet privé uniquement
– B. Dans un subnet public (route privée → nat-…)
– C. En dehors de tout VPC

Réponses : 1‑B · 2‑B · 3‑B · 4‑B · 5‑B

Pour aller plus loin

• VPC
• Route tables
• NAT Gateway
• Prochains tutos : SG vs NACL · VPC Peering · ALB

Maillage série AWS (P1)