AWS Transit Gateway Policy-Based Routing : le routage intelligent arrive !

Le routage réseau sur AWS a longtemps été contraint par une logique simple : le trafic est acheminé en fonction de l'adresse IP de destination. Point final. Pour les architectes réseau habitués aux fonctionnalités avancées des équipements on-premise (Cisco, Juniper, Palo Alto), cette limitation était frustrante. AWS vient de combler ce gap avec l'annonce de la disponibilité générale du Policy-Based Routing (PBR) sur AWS Transit Gateway.

Cette fonctionnalité, annoncée le 30 juillet 2026, permet désormais de prendre des décisions de routage basées sur une combinaison d'attributs : adresse IP source, adresse IP destination, ports, et protocole. C'est un changement fondamental dans la manière dont nous concevons les architectures réseau sur AWS.

Qu'est-ce que le Policy-Based Routing ?

Le Policy-Based Routing est un mécanisme qui permet de diriger le trafic réseau en fonction de politiques définies par l'administrateur, plutôt que de s'appuyer uniquement sur la table de routage classique basée sur la destination. En d'autres termes, vous pouvez désormais dire : « tout le trafic HTTPS provenant du subnet applicatif à destination du port 443 doit passer par mon appliance d'inspection, tandis que le trafic SSH de l'équipe opérations peut prendre un chemin direct ».

Sur AWS Transit Gateway, le PBR fonctionne avec un concept de policy table que vous associez à un attachement Transit Gateway. Dans cette table, vous définissez un ensemble ordonné de règles. Chaque règle classifie le trafic selon les critères suivants :

• Adresse IP source : d'où vient le trafic
• Adresse IP destination : où va le trafic
• Port source et destination : quel service est utilisé
• Protocole : TCP, UDP, ICMP, etc.

Les règles sont évaluées dans l'ordre avec une logique first-match-wins : la première règle qui correspond au trafic détermine vers quelle route table le paquet sera dirigé. Si aucune règle ne correspond, le trafic est silencieusement supprimé (implicit deny). Ce comportement, similaire à celui des Security Groups, impose de toujours prévoir une règle catch-all si vous souhaitez éviter les drops involontaires.

Pourquoi c'est un game-changer ?

Avant le PBR : la complexité architecturale

Avant cette annonce, les architectes réseau qui avaient besoin de diriger le trafic de manière granulaire devaient construire des architectures multi-VPC complexes avec des sauts de routage supplémentaires. Concrètement, cela signifiait :

• Multiplier les VPC d'inspection : un VPC dédié pour chaque type de trafic à inspecter différemment
• Ajouter des Gateway Load Balancers : pour distribuer le trafic vers des appliances tierces
• Créer des chaînes de routage : avec plusieurs Transit Gateway route tables interconnectées
• Gérer des coûts croissants : chaque saut supplémentaire génère des frais de traitement de données

Cette complexité se traduisait par une surcharge opérationnelle importante, des latences accrues, et un risque d'erreur de configuration élevé.

Avec le PBR : la simplicité retrouvée

Le PBR élimine une grande partie de cette complexité en étendant les capacités natives de routage du Transit Gateway. Plus besoin d'ajouter des couches intermédiaires : vous classifiez et dirigez le trafic directement au niveau du Transit Gateway, en une seule étape.

Cas d'usage concrets

Le PBR ouvre la porte à de nombreux scénarios que les équipes réseau et sécurité attendaient depuis longtemps.

Inspection sélective du trafic

C'est probablement le cas d'usage le plus demandé. Plutôt que de faire passer tout le trafic par AWS Network Firewall ou une appliance tierce (ce qui génère des coûts et de la latence), vous pouvez désormais ne router que le trafic sensible vers l'inspection. Par exemple :

• Le trafic à destination des bases de données (port 3306, 5432) passe par l'inspection
• Le trafic interne entre microservices sur des ports applicatifs connus peut contourner l'inspection
• Le trafic vers des destinations externes spécifiques est systématiquement inspecté

Routage basé sur la source pour la connectivité hybride

Pour les entreprises utilisant AWS Direct Connect et AWS VPN en parallèle, le PBR permet de diriger le trafic vers le bon chemin en fonction de sa source ou de son protocole :

• Le trafic critique (bases de données, ERP) emprunte le Direct Connect pour bénéficier de la latence faible et de la bande passante garantie
• Le trafic moins sensible (mises à jour, synchronisation) peut utiliser le VPN comme chemin secondaire
• Le basculement peut être géré de manière plus fine en fonction des applications

Isolation des environnements

Le PBR permet d'isoler les environnements de production et de développement dans des domaines de routage séparés, limitant ainsi les mouvements latéraux. Même si deux environnements partagent des plages IP similaires ou des attachements communs, les règles PBR garantissent que le trafic de développement ne peut jamais atteindre les ressources de production, et inversement.

Configuration et mise en place

Contrainte fondamentale : policy table OU route table, jamais les deux

C'est le point le plus important à comprendre avant de se lancer : un attachement Transit Gateway ne peut être associé qu'à une policy table OU à une route table, jamais aux deux simultanément. Il n'existe aucun mode hybride. Concrètement :

• Si votre attachement VPC est actuellement associé à une route table classique, vous devez d'abord dissocier cette route table avant de pouvoir associer une policy table
• Pendant la fenêtre de dissociation/association, le trafic de cet attachement sera interrompu
• Une policy table vide (sans aucune règle) entraîne le drop de tout le trafic entrant sur cet attachement — c'est l'implicit deny

Cette exclusivité signifie que le PBR remplace complètement la logique de routage classique pour un attachement donné. C'est un choix architectural binaire par attachement.

Les étapes de mise en place

La configuration du PBR se fait en quatre étapes :

1. Créer les route tables cibles : chaque règle PBR pointe vers une route table TGW qui contient les routes effectives
2. Créer une policy table : vous définissez une table de politiques associée à votre Transit Gateway
3. Définir les règles : vous créez un ensemble ordonné de règles (numérotées de 1 à 50 000) avec les critères de classification et la route table cible
4. Dissocier la route table existante puis associer la policy table à l'attachement

Le PBR est configurable via la Console AWS, l'AWS CLI, et les SDK AWS. Les commandes CLI dédiées (create-transit-gateway-policy-table, create-transit-gateway-policy-table-entry, associate-transit-gateway-policy-table) sont disponibles dès maintenant.

Exemple concret : filtrage HTTP/HTTPS et SSH

Voici un exemple complet de mise en place via AWS CLI, qui implémente le scénario décrit en introduction : le trafic HTTPS est inspecté, le trafic SSH prend un chemin direct.

# 1. Créer la policy table
aws ec2 create-transit-gateway-policy-table \
  --transit-gateway-id tgw-0bc994abffEXAMPLE \
  --tag-specifications 'ResourceType=transit-gateway-policy-table,Tags=[{Key=Name,Value=app-security-policy}]'
# Retourne : tgw-ptb-0ca78a549EXAMPLE

# 2. Règle 100 : trafic HTTPS (port 443) du subnet applicatif → inspection firewall
aws ec2 create-transit-gateway-policy-table-entry \
  --transit-gateway-policy-table-id tgw-ptb-0ca78a549EXAMPLE \
  --policy-rule-number 100 \
  --policy-rule '{"SourceCidrBlock":"10.1.10.0/24","Protocol":"6","DestinationPortRange":"443"}' \
  --target-route-table-id tgw-rtb-0a823edbdeEXAMPLE

# 3. Règle 200 : trafic HTTP (port 80) → même inspection
aws ec2 create-transit-gateway-policy-table-entry \
  --transit-gateway-policy-table-id tgw-ptb-0ca78a549EXAMPLE \
  --policy-rule-number 200 \
  --policy-rule '{"SourceCidrBlock":"10.1.10.0/24","Protocol":"6","DestinationPortRange":"80"}' \
  --target-route-table-id tgw-rtb-0a823edbdeEXAMPLE

# 4. Règle 300 : trafic SSH (port 22) de l'équipe ops → routage direct (pas d'inspection)
#    Ne matche que si ce trafic entre bien par l'attachement associé à la policy table
aws ec2 create-transit-gateway-policy-table-entry \
  --transit-gateway-policy-table-id tgw-ptb-0ca78a549EXAMPLE \
  --policy-rule-number 300 \
  --policy-rule '{"SourceCidrBlock":"10.1.50.0/24","Protocol":"6","DestinationPortRange":"22"}' \
  --target-route-table-id tgw-rtb-0b91f2c3d4EXAMPLE

# 5. Règle 40000 : catch-all → routage par défaut (évite l'implicit deny)
#    Un policy-rule vide matche tout : toutes les conditions valent * par défaut
aws ec2 create-transit-gateway-policy-table-entry \
  --transit-gateway-policy-table-id tgw-ptb-0ca78a549EXAMPLE \
  --policy-rule-number 40000 \
  --policy-rule '{}' \
  --target-route-table-id tgw-rtb-0f5e4d3c2bEXAMPLE

# 6. Vérifier les entries avant de basculer l'attachement
aws ec2 get-transit-gateway-policy-table-entries \
  --transit-gateway-policy-table-id tgw-ptb-0ca78a549EXAMPLE

# 7. Dissocier la route table existante de l'attachement source
#    Un attachement ne peut être associé qu'à une route table OU une policy table
aws ec2 disassociate-transit-gateway-route-table \
  --transit-gateway-attachment-id tgw-attach-0def6EXAMPLE \
  --transit-gateway-route-table-id tgw-rtb-0c7d8e9f01EXAMPLE

# 8. Attendre la fin de la dissociation : associer trop tôt fait échouer la requête
while :; do
  STATE=$(aws ec2 get-transit-gateway-route-table-associations \
    --transit-gateway-route-table-id tgw-rtb-0c7d8e9f01EXAMPLE \
    --filters "Name=transit-gateway-attachment-id,Values=tgw-attach-0def6EXAMPLE" \
    --query 'Associations[0].State' --output text)
  # "None" : l'association a disparu de la liste
  if [ "$STATE" = "None" ] || [ "$STATE" = "disassociated" ]; then
    break
  fi
  sleep 5
done

# 9. Associer la policy table à l'attachement
aws ec2 associate-transit-gateway-policy-table \
  --transit-gateway-policy-table-id tgw-ptb-0ca78a549EXAMPLE \
  --transit-gateway-attachment-id tgw-attach-0def6EXAMPLE

# 10. Confirmer l'association
aws ec2 get-transit-gateway-policy-table-associations \
  --transit-gateway-policy-table-id tgw-ptb-0ca78a549EXAMPLE

Avec cette configuration, le trafic est traité comme suit :

• Paquet TCP:443 depuis 10.1.10.x → inspecté par le firewall (règle 100)
• Paquet TCP:80 depuis 10.1.10.x → inspecté par le firewall (règle 200)
• Paquet TCP:22 depuis 10.1.50.x → routage direct sans inspection (règle 300)
• Tout autre trafic → routage par défaut (règle 40000 catch-all)

Considérations et bonnes pratiques

Comme toute fonctionnalité réseau avancée, le PBR nécessite une approche structurée :

• Commencez simple : déployez d'abord une ou deux règles sur un attachement non-critique pour valider le comportement
• Documentez vos politiques : la logique first-match-wins peut devenir complexe avec de nombreuses règles. Maintenez une documentation claire de l'ordre et de l'intention de chaque règle
• Surveillez les métriques : utilisez Amazon CloudWatch pour monitorer les hits sur chaque règle et identifier les règles inutilisées. La métrique PacketDropCountNoPolicy vous alerte quand du trafic est droppé faute de règle correspondante
• Prévoyez toujours une règle catch-all : sauf si vous souhaitez explicitement un comportement Zero Trust (deny-all), ajoutez une règle à numéro élevé (ex: 40000) qui capture le trafic restant
• Laissez des gaps entre les numéros de règle : utilisez 100, 200, 300… pour pouvoir insérer de nouvelles règles sans tout renuméroter
• Testez les scénarios de basculement : validez que vos règles PBR se comportent correctement en cas de panne d'un attachement cible
• Attention au BGP : associer une policy table à un attachement VPN (Site-to-Site) ou Connect stoppe les advertisements BGP vers le peer. Direct Connect n'est pas affecté (utilise la liste allowed-prefixes)

Impact sur la latence réseau

Une question légitime : le PBR ajoute-t-il de la latence au transit du trafic ?

La réponse est non. L'évaluation des règles PBR s'effectue au niveau du plan de données du Transit Gateway, au même point de décision que la table de routage classique. Il n'y a pas de saut réseau supplémentaire, pas de composant intermédiaire ajouté dans le chemin. La décision est prise « en ligne » lors du transit du paquet.

En réalité, le PBR peut même réduire la latence globale de votre architecture :

• Avant le PBR : pour inspecter sélectivement le trafic, il fallait tout envoyer vers un VPC d'inspection (un saut supplémentaire) puis filtrer au niveau de l'appliance. Même le trafic « propre » subissait la traversée.
• Avec le PBR : seul le trafic qui nécessite effectivement une inspection est dirigé vers l'appliance. Le reste prend le chemin direct, économisant un ou plusieurs sauts réseau.

Les quotas de bande passante ne sont pas impactés non plus : chaque attachement VPC conserve sa capacité de 100 Gbps par Availability Zone dans chaque direction.

Limites et quotas

Comme tout service AWS, le PBR a ses limites qu'il faut connaître avant de concevoir votre architecture :

Autres contraintes importantes :

• Exclusivité absolue : un attachement est associé à une policy table OU une route table, jamais les deux
• Pas de PBR sur les peering Cloud WAN : seules les entries system-managed (gérées par Cloud WAN) s'appliquent sur ces attachements
• Ports limités à TCP/UDP : le filtrage par port ne fonctionne que pour les protocoles TCP (6) et UDP (17). Pour ICMP, GRE ou « Any », les ports sont automatiquement à *
• Policy table vide = blackhole : associer une policy table sans aucune règle à un attachement provoque le drop silencieux de tout le trafic
• Route table référencée non supprimable : une route table utilisée comme cible par une policy entry ne peut pas être supprimée tant que la référence existe

Migration : passer d'une route table au PBR sans coupure

La migration vers le PBR est la question qui préoccupe le plus les équipes réseau en production. Soyons clairs : il existe une micro-interruption inévitable lors du basculement, car la dissociation de la route table et l'association de la policy table ne sont pas atomiques.

Voici la stratégie recommandée pour minimiser l'impact :

Approche progressive (recommandée)

1. Préparez tout en amont : créez la policy table, définissez toutes les règles, et créez les route tables cibles avec les routes nécessaires — tout cela sans aucun impact sur le trafic existant
2. Commencez par un attachement non-critique : choisissez un VPC de développement ou de test pour valider le comportement
3. Incluez une règle catch-all qui réplique le comportement actuel : votre règle à numéro élevé doit pointer vers une route table qui reproduit exactement le routage actuel. Ainsi, même si vos règles spécifiques ont un bug, le trafic continue de transiter
4. Planifiez une fenêtre de maintenance : la dissociation de la route table suivie de l'association de la policy table prend généralement quelques secondes, mais prévoyez 30 à 60 secondes de micro-coupure potentielle
5. Basculez : dissociez la route table, puis associez immédiatement la policy table
6. Validez : vérifiez les flux avec GetTransitGatewayPolicyTableEntries et surveillez la métrique PacketDropCountNoPolicy
7. Itérez : une fois validé, répétez sur les attachements de production

Ce qui se passe pendant la bascule

[Route table associée] ──dissociation──▶ [Aucune association] ──association──▶ [Policy table associée]
                                              │
                                    Trafic droppé pendant
                                    cette fenêtre (secondes)

Pendant la fenêtre où l'attachement n'a ni route table ni policy table, le trafic entrant est droppé. Les connexions TCP établies seront coupées et devront être ré-établies. Pour les protocoles stateless (UDP, ICMP), la reprise est transparente dès que la policy table est active.

Stratégies de mitigation

• Applications tolérantes : la plupart des applications avec des mécanismes de retry (HTTP, gRPC) survivent à une interruption de quelques secondes sans impact utilisateur visible
• Trafic critique : pour les flux qui ne tolèrent aucune perte, envisagez un schéma de migration par duplication d'attachement — créez un second attachement VPC (dans un subnet dédié), migrez-le vers PBR, puis basculez le trafic applicatif vers ce nouveau subnet
• DNS failover : si vous avez un mécanisme de failover DNS (Route 53 health checks), vous pouvez basculer le trafic temporairement vers un chemin alternatif le temps de la migration
• Coordination multi-AZ : migrez un AZ à la fois si votre architecture le permet (attachements distincts par AZ)

Rollback

En cas de problème, le rollback est simple : dissociez la policy table et réassociez l'ancienne route table. La même micro-interruption s'applique dans l'autre sens. C'est pourquoi il est essentiel de ne pas supprimer l'ancienne route table tant que la migration n'est pas validée en production.

Disponibilité et tarification

Le Policy-Based Routing pour AWS Transit Gateway est disponible dans toutes les régions commerciales AWS où Transit Gateway est disponible. Point important : le PBR n'engendre aucun coût supplémentaire au-delà des frais standard de Transit Gateway (frais par attachement + frais de traitement de données). Il n'y a pas de tarification par règle ni par évaluation. C'est une excellente nouvelle car cela signifie que l'adoption ne sera pas freinée par des considérations budgétaires.

Conclusion

Pour les architectes réseau et les équipes sécurité, c'est une fonctionnalité qui va simplifier considérablement les architectures existantes tout en ouvrant de nouvelles possibilités.

Mon conseil : si vous avez aujourd'hui des architectures multi-VPC complexes uniquement pour gérer du routage conditionnel, c'est le moment de revoir votre design. Le PBR peut potentiellement vous permettre de réduire le nombre de composants intermédiaires, diminuer la latence, et simplifier vos opérations quotidiennes.

Commencez par identifier vos flux de trafic les plus critiques qui nécessitent un traitement différencié, puis testez le PBR sur un périmètre restreint avant de l'étendre à l'ensemble de votre organisation.