Une équipe plateforme commence avec deux VPC — production et un VPC de services partagés pour le bastion, Prometheus et les miroirs de paquets — appairés. Six mois plus tard ils ont un VPC séparé par unité d’affaires, plus dev, recette et un sandbox pour l’équipe data. Cela fait six VPC, et un peering en maillage complet serait 6 × 5 ÷ 2 = 15 connexions de peering, chacune avec sa propre entrée de table de routage de chaque côté. L’équipe a créé les peerings un par un et les tables de routage ont maintenant 35 entrées chacune, dont aucune clairement nommée. Le dernier peering avait un chevauchement de CIDR et a échoué silencieusement. Le bon mouvement était un Transit Gateway il y a six mois. Voici la migration qui y arrive sans un trimestre supplémentaire de plomberie accumulée.

Ce qui se passe

Un Transit Gateway (TGW) est un hub réseau régional. Les VPC s’y attachent une fois, et TGW gère le routage entre chaque VPC attaché, le réseau on-prem et le Direct Connect gateway. Le problème du maillage complet de peering disparaît — chaque VPC a une seule attache vers le TGW, et le TGW a une table de routage qui décide quels VPC peuvent atteindre quels autres VPC. Le modèle de coût est horaire par attache plus au GB de données traitées ; pour une organisation avec 5 VPC ou plus, le coût par attache est bien en dessous de ce que vous paieriez pour le transfert inter-AZ et la charge opérationnelle d’exploiter un maillage de peering.

La seule chose que TGW donne et que le peering ne donne pas, c’est le routage transitif. Avec le peering, si VPC A est appairé à VPC B et B est appairé à C, le trafic de A ne peut pas atteindre C — le peering est non-transitif par conception. Avec TGW, A peut atteindre C si la table de routage TGW l’autorise. C’est la propriété qui rend possibles les conceptions en étoile : le VPC de services partagés tient le bastion, le miroir de paquets, le forwarder centralisé de logs, et chaque VPC rayon le route vers à travers le hub.

L’autre chose que TGW donne, c’est le partage multi-comptes via AWS Resource Access Manager (RAM). Un compte central de réseau possède le TGW. Les autres comptes de l’organisation reçoivent le TGW comme ressource partagée et peuvent y attacher leurs propres VPC. La table de routage reste dans le compte réseau, ce qui veut dire que l’équipe réseau contrôle qui peut atteindre qui — les comptes applicatifs peuvent déployer leurs VPC mais ne peuvent pas accidentellement router dans le VPC d’une autre équipe.

Direct Connect s’attache à TGW via un Direct Connect Gateway. Le réseau on-prem apparaît comme un autre rayon dans la table de routage TGW, et la règle pour savoir quels CIDR on-prem sont joignables depuis quels VPC vit dans la même table de routage TGW que vous gérez déjà. L’alternative — un VPN à chaque VPC, ou une virtual interface Direct Connect par VPC — est le bordel opérationnel que TGW a été conçu pour remplacer.

Comment vérifier

Le point de décision : est-ce que TGW gagne sa place pour cette organisation ? La règle empirique :

2–3 VPC qui ont besoin d’un maillage complet : le peering VPC convient. 3 peerings, tables de routage gérables.
4 VPC en étoile (un VPC de services partagés + 3 rayons) : le peering tient encore, 3 peerings, mais la douleur du routage transitif commence.
5 VPC ou plus OU exigence multi-comptes OU implication Direct Connect / VPN : TGW.

Inspectez le compte de peerings existants et les chevauchements :

# Compter les peerings actifs dans la région
aws ec2 describe-vpc-peering-connections \
  --filters Name=status-code,Values=active \
  --query 'length(VpcPeeringConnections)'

# Lister les CIDR par VPC pour repérer les chevauchements avant TGW
aws ec2 describe-vpcs \
  --query 'Vpcs[].[VpcId,CidrBlock,Tags[?Key==`Name`]|[0].Value]' \
  --output table

Deux VPC partageant un bloc CIDR ne peuvent pas tous deux s’attacher à un TGW — cela doit être corrigé avant la migration, soit en réadressant un VPC, soit en utilisant la capacité de route statique du TGW avec traduction CIDR (un bricolage, pas un plan à long terme).

La correction

La procédure pour déployer TGW pour une organisation à 6 VPC répartis sur 3 comptes :

Décider quel compte possède le TGW. Placez-le dans le compte réseau (ou le compte de services partagés s’il n’y a pas de compte réseau dédié). Ce compte possède le TGW, les tables de routage et le partage RAM. Les comptes applicatifs ne possèdent que leurs attaches et leurs propres tables de routage VPC.
Créer le TGW avec les défauts sensés désactivés. Le comportement par défaut est d’auto-associer chaque nouvelle attache à la table de routage par défaut et de propager les routes automatiquement. C’est pratique pour une mise en place mono-environnement et dangereux pour une multi-environnements — un nouveau VPC sandbox s’attache et a immédiatement des routes vers la production.
```
aws ec2 create-transit-gateway \
  --description "TGW régional principal" \
  --options "AmazonSideAsn=64512,AutoAcceptSharedAttachments=disable,DefaultRouteTableAssociation=disable,DefaultRouteTablePropagation=disable,VpnEcmpSupport=enable,DnsSupport=enable"
```
Créer des tables de routage par environnement sur le TGW. Le motif est une table de routage par zone de sécurité. Pour cette organisation : tgw-rt-shared-services, tgw-rt-production, tgw-rt-non-production, tgw-rt-on-prem. Chaque table de routage tient les règles qui définissent quelles attaches peuvent router vers quelles autres attaches.
```
aws ec2 create-transit-gateway-route-table \
  --transit-gateway-id tgw-0123456789abcdef0 \
  --tag-specifications 'ResourceType=transit-gateway-route-table,Tags=[{Key=Name,Value=tgw-rt-production}]'
```

Partager le TGW via RAM au reste de l’organisation. Les comptes applicatifs reçoivent la ressource TGW et peuvent y attacher leurs VPC :

aws ram create-resource-share \
  --name tgw-share \
  --resource-arns arn:aws:ec2:us-east-1:111122223333:transit-gateway/tgw-0123456789abcdef0 \
  --principals arn:aws:organizations::111122223333:organization/o-aaaaaaaaaa \
  --allow-external-principals

Attacher chaque VPC. Dans le compte de chaque VPC, créer une attache TGW :
```
aws ec2 create-transit-gateway-vpc-attachment \
  --transit-gateway-id tgw-0123456789abcdef0 \
  --vpc-id vpc-prodaaaaaaaaaaa \
  --subnet-ids subnet-prod-1a subnet-prod-1b subnet-prod-1c
```
La sélection de sous-réseaux est d’un sous-réseau par AZ. AWS déploie une ENI TGW dans chaque sous-réseau choisi — utilisez un /28 dédié par AZ pour ces ENI (taillez dans la plage réservée du VPC). L’ENI TGW ne route pas le trafic client toute seule ; c’est le chemin entre le routage local du VPC et le routage régional du TGW.

Associer et propager par environnement. Chaque attache s’associe à une table de routage (celle qui décide ce que cette attache voit) et se propage dans les tables de routage qui devraient apprendre le CIDR du VPC de cette attache. Pour la production :

aws ec2 associate-transit-gateway-route-table \
  --transit-gateway-attachment-id tgw-attach-prodaaaaaaaa \
  --transit-gateway-route-table-id tgw-rtb-production

# La production voit les services partagés
aws ec2 enable-transit-gateway-route-table-propagation \
  --transit-gateway-route-table-id tgw-rtb-production \
  --transit-gateway-attachment-id tgw-attach-sharedservicesa

# Les services partagés voient la production (et les autres rayons)
aws ec2 enable-transit-gateway-route-table-propagation \
  --transit-gateway-route-table-id tgw-rtb-shared-services \
  --transit-gateway-attachment-id tgw-attach-prodaaaaaaaa

Le motif : les services partagés sont joignables depuis chaque environnement ; les environnements ne sont PAS joignables entre eux. La production ne peut pas atteindre la non-production ; la recette ne peut pas atteindre le sandbox ; le sandbox ne peut rien atteindre sauf les services partagés pour le miroir de paquets et le bastion.

Mettre à jour les tables de routage VPC pour envoyer le trafic distant au TGW. Dans chaque VPC, la table de routage du sous-réseau privé a besoin d’une route pour les CIDR des autres VPC (ou une route résumée) pointant sur l’attache TGW :
```
aws ec2 create-route \
  --route-table-id rtb-prod-private-1a \
  --destination-cidr-block 10.0.0.0/8 \
  --transit-gateway-id tgw-0123456789abcdef0
```
La propre table de routage du TGW décide ensuite quelle destination est joignable depuis cette attache.
Attacher on-prem (le cas échéant). Un Direct Connect Gateway s’associe au TGW ; les CIDR on-prem se propagent via BGP. La table de routage des services partagés reçoit la propagation on-prem ; la table de routage de production la reçoit si la production a besoin de joignabilité on-prem.

La migration du peering vers TGW se fait un VPC à la fois. L’ordre : attacher d’abord tous les VPC au TGW, avec les tables de routage câblées mais les routes au niveau VPC pointant toujours sur l’ancien peering. Puis retourner la table de routage d’un VPC pour envoyer les CIDR distants au TGW, surveiller deux jours, et supprimer les peerings vers ce VPC. Répéter. Le maillage de peering se dissout rayon par rayon.

L’erreur à éviter : activer les drapeaux default-association et default-propagation sur le TGW. Ils paraissent pratiques le jour un et finissent avec le VPC sandbox ayant une route vers la production par accident. Désactivez-les et exigez que chaque association soit explicite.

L’autre règle qu’on tient : les tables de routage TGW sont de l’infrastructure-as-code, point. La décision « qui peut router vers qui » compte autant que les politiques IAM, et aws ec2 create-route depuis une session console est la même erreur qu’éditer une politique IAM à la main.

Pour l’alternative quand vous n’avez besoin que d’accès au niveau service (pas de joignabilité au niveau VPC), voir Peering VPC vs PrivateLink. Pour le plan de sous-réseaux sous-jacent, voir Conception de sous-réseaux multi-AZ.

Stack Harbor conçoit et audite les topologies VPC en production dans le cadre de Gestion AWS et des Environnements infogérés en continu. Si votre maillage de peering a dépassé le seuil de lisibilité, commencez par une consultation d’infrastructure.