Transit Gateway : hub réseau multi-VPC

À la fin de ce tutoriel, vous comprendrez le rôle d’un Transit Gateway (TGW) comme hub pour relier plusieurs VPC (et VPN/DX), vous saurez créer un TGW, y attacher deux VPC, et configurer routes / associations — avec un warning coût clair pour le lab ca-central-1.

Niveau : Intermédiaire · Temps estimé : 60 min (lecture + lab court) · Versions testées : TGW 2026, AWS CLI v2 · Dernière vérification : 2026-09-10 · Region : ca-central-1

Slug : aws-transit-gateway · Série : AWS Solutions Architect · Mot-clé SEO : AWS Transit Gateway

← Précédent : VPC Peering · → Suivant : ALB · Hub : Démarrer avec AWS

Prérequis

• Deux VPC CIDR disjoints (réutilisez le pattern du peering : 10.10.0.0/16 et 10.20.0.0/16)
• Subnets dans au moins deux AZ recommandés pour attachments haute dispo (lab : 1 AZ possible mais pas prod)
• Profil lab

Coût estimé : ATTENTION — TGW facture à l’heure par attachment + data processing.
Consigne lab : créez → validez describe → supprimez dans l’heure. Ne laissez jamais un TGW allumé « pour plus tard ».

export AWS_PROFILE=lab
export AWS_DEFAULT_REGION=ca-central-1

Ce que nous allons construire

        ┌──────── Transit Gateway ────────┐
VPC-A ──┤                                 ├── VPC-B
        │   route table TGW (associations)│
        └───────────── (VPN/DX later) ────┘

(Schéma — alt : « Hub TGW entre VPC-A et VPC-B ».)

Le TGW centralise le routage : chaque spoke (VPC, VPN, DX) s’attache une fois au hub. Les route tables TGW décident qui apprend quoi (association + propagation). Contrairement au peering : plus de mesh N², mais un coût d’attachment horaire à surveiller en lab ca-central-1.

Réutilisez deux VPC CIDR disjoints (10.10.0.0/16, 10.20.0.0/16) comme dans le tuto peering — subnets seulement, pas de NAT.

Étape 1 — Peering vs Transit Gateway

	Peering	Transit Gateway
Topologie	Mesh (N²)	Hub-and-spoke
Transitivité	Non	Oui via RT TGW
Scale	Quelques VPC	Dizaines / centaines
VPN/DX	Séparé	Attachments unifiés
Coût	Data surtout	Attachments horaires + data

Quand le design exam dit « 50 VPC dans l’orga » → TGW (souvent + RAM share), pas 1225 peerings.

Retenez : un TGW est régional. Multi-Region = TGW peering (hors lab minimal, cité en SA Pro). En Associate : hub-and-spoke + coût attachment.

Étape 2 — Créer le Transit Gateway

ASN Amazon side (64512 dans l’exemple) sert surtout aux attachments VPN BGP. Pour un lab VPC-only, la valeur par défaut convient.

TGW_ID=$(aws ec2 create-transit-gateway 
  --description "lab-tgw" 
  --tag-specifications 'ResourceType=transit-gateway,Tags=[{Key=Name,Value=lab-tgw}]' 
  --options AmazonSideAsn=64512,AutoAcceptSharedAttachments=disable,DefaultRouteTableAssociation=enable,DefaultRouteTablePropagation=enable,VpnEcmpSupport=enable,DnsSupport=enable 
  --query TransitGateway.TransitGatewayId --output text)

echo "$TGW_ID"
aws ec2 describe-transit-gateways --transit-gateway-ids "$TGW_ID" 
  --query 'TransitGateways[0].State'
# attendre available

Poller jusqu’à available (souvent 1–3 minutes) :

aws ec2 describe-transit-gateways --transit-gateway-ids "$TGW_ID"   --query 'TransitGateways[0].State' --output text

Notez l’ID tgw-… et le tag Name=lab-tgw : en Cost Explorer, ce nom aide à retrouver un attachment oublié.

Étape 3 — Attachments VPC

Chaque attachment référence des subnets (idéalement un par AZ) dans le VPC spoke.

# Exemple — remplacez VPC_A, SUB_A1 (et SUB_A2 si 2 AZ)
# VPC_A=... ; SUB_A1=... ; VPC_B=... ; SUB_B1=...

ATT_A=$(aws ec2 create-transit-gateway-vpc-attachment 
  --transit-gateway-id "$TGW_ID" 
  --vpc-id "$VPC_A" 
  --subnet-ids "$SUB_A1" 
  --tag-specifications 'ResourceType=transit-gateway-attachment,Tags=[{Key=Name,Value=lab-att-a}]' 
  --query TransitGatewayVpcAttachment.TransitGatewayAttachmentId --output text)

ATT_B=$(aws ec2 create-transit-gateway-vpc-attachment 
  --transit-gateway-id "$TGW_ID" 
  --vpc-id "$VPC_B" 
  --subnet-ids "$SUB_B1" 
  --tag-specifications 'ResourceType=transit-gateway-attachment,Tags=[{Key=Name,Value=lab-att-b}]' 
  --query TransitGatewayVpcAttachment.TransitGatewayAttachmentId --output text)

aws ec2 describe-transit-gateway-vpc-attachments 
  --transit-gateway-attachment-ids "$ATT_A" "$ATT_B" 
  --query 'TransitGatewayVpcAttachments[].{Id:TransitGatewayAttachmentId,State:State}'

Attendez available (quelques minutes). Un subnet d’attachment héberge une ENI gérée par AWS : ne le confondez pas avec un subnet « appli » ordinaire. En prod : un subnet d’attachment par AZ pour la résilience ; en lab mono-AZ, un seul subnet suffit pour valider le flux.

Si create-transit-gateway-vpc-attachment échoue : vérifiez CIDR disjoints, quotas TGW, et que le subnet appartient bien au VPC indiqué.

Étape 4 — Routes côté VPC (vers le TGW)

Dans la route table de chaque subnet qui doit parler au pair :

# VPC-A → CIDR de B via TGW
aws ec2 create-route --route-table-id "$RT_A" 
  --destination-cidr-block 10.20.0.0/16 
  --transit-gateway-id "$TGW_ID"

# VPC-B → CIDR de A via TGW
aws ec2 create-route --route-table-id "$RT_B" 
  --destination-cidr-block 10.10.0.0/16 
  --transit-gateway-id "$TGW_ID"

Sans ces routes VPC, l’attachment peut être available et le hub « prêt », mais les instances n’envoient jamais le trafic spoke vers le TGW — même symptôme que le peering sans create-route.

Si plusieurs RT dans un VPC (public/privé), ajoutez la route sur chaque RT qui doit joindre l’autre spoke.

Étape 5 — Route tables TGW (concepts)

Avec les options par défaut (DefaultRouteTableAssociation/Propagation = enable) :

• Les attachments sont associés à la RT TGW par défaut
• Les routes des CIDR VPC propagées apparaissent dans cette RT
• A peut joindre B sans peering direct

Pour une isolation (prod) : RT TGW séparées (prod vs shared vs inspect), associations manuelles, propagations filtrées — pattern « inspection VPC » avec firewall.

aws ec2 describe-transit-gateway-route-tables   --filters Name=transit-gateway-id,Values="$TGW_ID"

Lister les routes apprises (une fois les attachments available) :

TGW_RT=$(aws ec2 describe-transit-gateway-route-tables   --filters Name=transit-gateway-id,Values="$TGW_ID"   --query 'TransitGatewayRouteTables[0].TransitGatewayRouteTableId' --output text)
aws ec2 search-transit-gateway-routes   --transit-gateway-route-table-id "$TGW_RT"   --filters Name=type,Values=propagated

Association = « cet attachment utilise cette RT pour router ». Propagation = « cet attachment annonce son CIDR dans cette RT ». Les séparer permet un spoke qui envoie vers un inspection VPC sans apprendre toutes les routes des autres spokes.

Étape 6 — Shared services & RAM (aperçu)

En organisation AWS : le compte Network owner crée le TGW, le partage via RAM (Resource Access Manager) aux comptes app, qui créent leurs attachments dans leurs propres comptes. Le hub reste centralisé ; la facturation attachment suit souvent le compte qui attache. Hors lab solo, mais très fréquent en SA Pro / designs entreprise (shared services : DNS, AD, inspection).

En examen : « partager un TGW avec des comptes membres » → RAM + attachments VPC, pas une toile de peerings cross-account.

Appliance mode / inspection (aperçu)

En designs avancés, une RT TGW envoie le trafic vers un inspection VPC (AWS Network Firewall / appliance 3rd party en mode appliance) avant la sortie Internet ou entre segments. Association ≠ propagation : un spoke peut être associé à une RT « isolation » sans apprendre toutes les routes. Retenez le vocabulaire pour l’oral SA ; le lab minimal n’active pas l’inspection.

Attachments VPN / Direct Connect se branchent sur le même TGW : un seul hub pour cloud + on-prem. Ne créez pas de VPN attachment « pour voir » en lab — coût et complexité inutiles.

Scénario examen classique

« Connecter 30 VPC de l’organisation avec routage flexible et un VPN on-prem » → Transit Gateway (souvent partagé via RAM), pas 435 peerings.
« Deux VPC seulement, même compte, budget lab » → VPC Peering suffit.
« Attachment available mais pas de trafic » → routes VPC vers tgw-… manquantes, ou RT TGW sans propagation.
« Facture inattendue après un workshop » → attachments / TGW non supprimés (coût horaire).

Lab bonus (5–8 min) — valider puis détruire

1. Créez TGW + 2 attachments + routes VPC (étapes 2–4).
2. describe-transit-gateway-vpc-attachments → les deux à available ; search-transit-gateway-routes montre les CIDR propagés.
3. Enchaînez immédiatement le nettoyage (section suivante) : delete routes → attachments → TGW. Vérifiez describe-transit-gateways vide pour lab-tgw.

Objectif pédagogique : voir le hub et ancrer le réflexe anti-facture — plus important ici que de laisser tourner pour un ping optionnel.

Étape 7 — Vérification

aws ec2 describe-transit-gateways --transit-gateway-ids "$TGW_ID"
aws ec2 describe-transit-gateway-vpc-attachments 
  --filters Name=transit-gateway-id,Values="$TGW_ID"

Checklist : TGW available · 2 attachments available · routes VPC vers TGW · vous savez citer le coût attachment.

Nettoyage (prioritaire)

Ordre typique :

# 1. Delete routes VPC vers TGW
# 2. Delete VPC attachments (attendre deleted)
aws ec2 delete-transit-gateway-vpc-attachment --transit-gateway-attachment-id "$ATT_A"
aws ec2 delete-transit-gateway-vpc-attachment --transit-gateway-attachment-id "$ATT_B"
# 3. Delete TGW
aws ec2 delete-transit-gateway --transit-gateway-id "$TGW_ID"
# 4. Delete VPC lab si créés seulement pour ce tuto

Vérifiez Billing → Free tier / Cost Explorer → Transit Gateway le lendemain.

Checklist lab anti-facture

1. Minuteur 45–60 min dès create-transit-gateway.
2. Tags Name=lab-tgw + DeleteAfter=YYYY-MM-DD.
3. Pas de VPN attachment « pour tester » sans besoin.
4. Cost Explorer → filtre Transit Gateway le lendemain.
5. Si doute : console VPC → Transit gateways → vérifier qu’il n’en reste zéro.

Les peerings restent souvent le meilleur choix pour deux VPC de lab ; réservez TGW aux designs hub réels ou aux questions d’examen.

Erreurs fréquentes

Symptôme	Cause	Correction
Attachment pending	Subnet/AZ / quotas	Attendre ; 1 subnet/AZ max rules
Pas de connectivité	Routes VPC ou RT TGW	Routes bilatérales + propagation
Facture surprise	Attachments oubliés	Delete attachments + TGW
Confusion peering	Espérer mesh gratuit	TGW = hub payant
Routes TGW absentes	Propagation / association off	Enable defaults ou associer/propager à la main
DependencyViolation delete TGW	Attachments encore présents	Delete attachments, attendre deleted, puis TGW

Coût : ordre de grandeur (examen)

Sans chiffres exacts (ils changent) : vous payez par attachment-heure même sans trafic, plus le volume de data traité par le TGW. C’est pour ça que les labs TGW doivent être éphémères. Consultez la page pricing officielle le jour J ; en oral SA, citez « attachment hourly + data processing », pas un montant inventé.

En ca-central-1 : deux attachments oubliés une nuit coûtent plus cher qu’un peering pour le même scénario 2 VPC.

Quiz (5 questions)

1. Le principal avantage TGW vs peering mesh : – A. Toujours gratuit
– B. Hub-and-spoke scalable / routes transitives via RT TGW
– C. Remplace IAM

2. Sans route 10.20.0.0/16 → TGW dans VPC-A : – A. L’attachment suffit
– B. VPC-A n’envoie pas le trafic spoke vers le hub
– C. S3 casse

3. Première action après un lab TGW réussi : – A. Laisser tourner pour les métriques
– B. Supprimer attachments + TGW
– C. Activer NAT sur tous les subnets

4. Partager un TGW avec d’autres comptes de l’Organisation : – A. Dupliquer le TGW dans chaque compte
– B. AWS RAM + attachments dans les comptes spokes
– C. Un Security Group cross-account suffit

5. Différence clé association vs propagation sur une RT TGW : – A. Aucune — synonymes
– B. Association = RT utilisée pour router ; propagation = CIDR annoncé dans la RT
– C. Propagation remplace les Security Groups

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

Pour aller plus loin

• Transit Gateway
• TGW pricing
• TGW route tables
• Share TGW with RAM
• Précédent lab simple : VPC Peering

Maillage série AWS (P1)

← Précédent	VPC Peering
→ Suivant	ALB équilibrage
Aussi	VPC fondations

---

Retour parcours AWS — hub de la série et leçons sœurs.