Logo Teamwork
English

AWS Transit Gateway et Cloud WAN : le 1:1 NAT managé pour les CIDR qui se chevauchent

Published on
Authors
Version audio
Chargement...
AWS Transit Gateway et Cloud WAN 1:1 NAT - Guide Sylvain BRUAS


Il y a un problème que tous les architectes réseau sur AWS ont rencontré au moins une fois : deux réseaux qui doivent communiquer mais qui partagent la même plage d'adresses IP. Deux VPC en 10.0.0.0/16, un réseau partenaire en 192.168.0.0/16 identique au vôtre, une entreprise rachetée dont le plan d'adressage a été conçu sans se soucier du vôtre. Dans tous ces cas, la règle était immuable : Transit Gateway ne propage pas les routes d'un VPC dont le CIDR est identique ou chevauchant celui d'un autre VPC déjà attaché. Pas de route, pas de communication.

AWS vient d'annoncer, le 23 octobre 2026, que AWS Transit Gateway et AWS Cloud WAN supportent désormais le NAT un-pour-un (1:1 NAT) managé directement sur leurs attachements, via une intégration avec le Regional Private NAT Gateway. En clair : vous pouvez connecter des réseaux aux plages IP qui se chevauchent sans renuméroter ni l'un ni l'autre, sans déployer d'appliance NAT, et sans écrire la moindre règle de retour.

Le problème des CIDR qui se chevauchent

Avant de parler de la nouveauté, rappelons pourquoi c'est un problème aussi tenace. Le routage IP repose sur l'unicité des adresses. Si deux machines portent l'adresse 10.0.1.50, un routeur ne peut pas savoir à laquelle livrer un paquet destiné à 10.0.1.50. C'est pour cette raison que les VPC attachés à un même Transit Gateway ne peuvent avoir ni CIDR identiques ni chevauchants, que le VPC peering refuse les plages qui se recouvrent, et que le même blocage existe sur les autres clouds.

Ce blocage tombe au pire moment : lors d'une fusion-acquisition, lors de la connexion d'un réseau partenaire via AWS Site-to-Site VPN, en contexte multicloud, ou tout simplement quand des VPC provisionnés indépendamment doivent enfin se parler. Historiquement, les options étaient les suivantes :

  • Renuméroter l'un des réseaux : la solution la plus propre sur le papier, mais souvent impossible en production (interruptions, applications qui codent en dur des IP, dépendances multiples).
  • Déployer un Private NAT Gateway dans chaque VPC : c'est la solution recommandée de longue date par AWS, documentée dans le whitepaper Multi-VPC Network Infrastructure. Le Private NAT Gateway effectue un SNAT de l'adresse source chevauchante vers une plage unique, ce qui permet de router le trafic via Transit Gateway ou une virtual private gateway. Mais cela impliquait de gérer soi-même les subnets, les tables de routage, et souvent un équilibreur pour la direction retour (DNAT).
  • Monter une "Translation VPC" avec des instances NAT ou des appliances tierces : une solution fonctionnelle mais lourde.

Dans tous les cas, cela représentait de l'infrastructure à concevoir, à déployer et à maintenir, avec des règles de NAT source et destination à écrire et à tenir à jour. Le 1:1 NAT managé vise précisément à faire disparaître cette plomberie.

Ce qu'apporte le 1:1 NAT managé

La nouveauté consiste à exposer la capacité de NAT directement au niveau de l'attachement Transit Gateway ou Cloud WAN, en s'appuyant sur le Regional Private NAT Gateway. Concrètement, d'après l'annonce officielle :

  • Vous définissez des règles de translation d'adresses sur l'attachement : pour chaque CIDR source, vous indiquez la plage IP privée vers laquelle il doit être traduit. Vous choisissez donc une plage de destination qui ne chevauche aucun autre réseau.
  • La translation est appliquée automatiquement dans les deux sens. C'est le point clé : pas de règle de trafic retour à écrire séparément, contrairement à une configuration NAT manuelle où il fallait penser au SNAT comme au DNAT.
  • Aucune appliance NAT à déployer. AWS opère, met à l'échelle et gère la capacité de NAT dans le cadre de l'attachement.
  • La portée couvre plusieurs types de connectivité : la translation fonctionne à travers Amazon VPC, AWS Site-to-Site VPN, AWS Direct Connect, et les appliances SD-WAN connectées via Transit Gateway Connect (voir plus bas les types d'attachement exacts et les exclusions).
  • L'observabilité est intégrée : vous suivez le trafic traduit via des métriques Amazon CloudWatch.

L'exemple canonique donné par AWS est précisément celui de la fusion-acquisition : si vous rachetez une entreprise et que les deux VPC utilisent 10.0.0.0/16, vous traduisez les adresses de l'un vers une plage non chevauchante sur son attachement, et vous connectez les réseaux immédiatement.

Exemple pratique : deux VPC en 10.0.0.0/16 qui doivent communiquer

Prenons le scénario le plus courant. Vous avez deux VPC, hérités d'une acquisition, qui utilisent exactement le même CIDR :

  • VPC-A (votre réseau historique) : 10.0.0.0/16, avec un serveur applicatif en 10.0.1.50
  • VPC-B (le réseau racheté) : 10.0.0.0/16, avec une base de données en 10.0.1.50 elle aussi

Impossible de les attacher tels quels à un même Transit Gateway : les routes ne se propageraient pas. L'idée du 1:1 NAT est de donner à chaque VPC une identité réseau de substitution, une plage par laquelle l'autre côté va le joindre :

  • VPC-A sera vu par VPC-B comme étant en 100.64.0.0/16
  • VPC-B sera vu par VPC-A comme étant en 100.65.0.0/16

On utilise ici la plage 100.64.0.0/10 (RFC 6598, Carrier-Grade NAT), un choix classique pour les plages de translation car elle n'entre quasiment jamais en conflit avec les plans d'adressage privés RFC 1918 existants.

Le flux devient alors parfaitement déterministe :

VPC-A (10.0.0.0/16)                         VPC-B (10.0.0.0/16)
  app 10.0.1.50                               db  10.0.1.50
       │                                            │
       │  destination : 100.65.1.50                 │
       ▼                                            ▼
  [ attachement TGW A ]                      [ attachement TGW B ]
   SNAT 10.0.1.50 → 100.64.1.50               DNAT 100.65.1.50 → 10.0.1.50
       │                                            ▲
       └──────────────▶  Transit Gateway  ─────────┘
          (ne voit que des adresses 100.64.x / 100.65.x,
                     aucun chevauchement)

Du point de vue de l'application dans VPC-A, pour joindre la base de données, on ne cible pas 10.0.1.50 (qui existe aussi chez soi !) mais 100.65.1.50, l'adresse de substitution de VPC-B. Le Transit Gateway, lui, ne manipule que des adresses 100.64.x.x et 100.65.x.x : elles ne se chevauchent pas, donc le routage fonctionne. Chaque attachement applique le SNAT à l'aller et le DNAT au retour, automatiquement.

La configuration se fait en une seule opération par attachement : vous fournissez à la fois l'activation du NAT et le jeu de règles complet. Chaque règle associe un MatchSourceCidr (la plage source) à un NatCidr (la plage cible), identifiée par un RuleNumber unique (de 1 à 32766), avec un maximum de 50 règles par attachement. Côté Transit Gateway, la commande est modify-transit-gateway-attachment-nat-configuration.

Pour reprendre notre scénario (chaque VPC traduit vers sa propre plage de substitution), on configure une règle sur l'attachement de VPC-A :

# Sur l'attachement de VPC-A : 10.0.0.0/16 est vu de l'extérieur comme 100.64.0.0/16
aws ec2 modify-transit-gateway-attachment-nat-configuration \
    --transit-gateway-attachment-id tgw-attach-0123456789abcdef0 \
    --nat-gateway-support enable \
    --nat-gateway-rules '[
        {"RuleNumber":100,"MatchSourceCidr":"10.0.0.0/16","NatCidr":"100.64.0.0/16"}
    ]'

Et la règle symétrique sur l'attachement de VPC-B (MatchSourceCidr à 10.0.0.0/16, NatCidr à 100.65.0.0/16). Les changements sont appliqués de façon asynchrone ; l'attachement reste dans l'état available. On vérifie l'état des règles avec :

aws ec2 get-transit-gateway-attachment-nat-configuration \
    --transit-gateway-attachment-id tgw-attach-0123456789abcdef0

Il faut attendre que NatGatewaySupport soit enabled et que chaque règle passe à l'état activated.

Côté AWS Cloud WAN, les commandes diffèrent : c'est update-attachment-nat-configuration (service networkmanager), avec --nat-gateway-support ENABLE, et la lecture via list-attachment-nat-configurations. Pendant la mise à jour, l'attachement Cloud WAN passe par l'état UPDATING avant de revenir à AVAILABLE.

En AWS CloudFormation, la configuration vit dans une ressource dédiée, AWS::EC2::TransitGatewayAttachmentNatConfiguration (elle n'est pas exposée comme propriété d'un AWS::EC2::TransitGatewayVpcAttachment) :

Resources:
  VpcAttachmentNat:
    Type: AWS::EC2::TransitGatewayAttachmentNatConfiguration
    Properties:
      TransitGatewayAttachmentId: !Ref VpcAttachment
      NatGatewaySupport: enable
      NatGatewayRules:
        - RuleNumber: 100
          MatchSourceCidr: 10.0.0.0/16
          NatCidr: 100.64.0.0/16

IAM : ces opérations exigent les permissions ec2:ModifyTransitGatewayAttachmentNatConfiguration et ec2:GetTransitGatewayAttachmentNatConfiguration. Attention, un ec2:Describe* ne couvre pas l'action Get. Sur un Transit Gateway ou un core network partagé, seul le compte propriétaire peut voir ou modifier la configuration NAT.

Une fois les règles en place, vérifiez le bon fonctionnement en observant les métriques de trafic traduit dans CloudWatch, plutôt qu'en vous fiant uniquement à un ping qui pourrait réussir pour de mauvaises raisons.

Limites et points d'attention

C'est la partie la plus importante de cet article. Le 1:1 NAT managé est une très bonne nouvelle opérationnelle, mais la translation d'adresses garde ses contraintes propres. Voici ce qu'il faut garder en tête.

C'est un NAT statique et sans état, pas un NAT Gateway classique

C'est le point le plus souvent mal compris. Malgré le nom commercial « Private NAT Gateway », le 1:1 NAT de Transit Gateway et Cloud WAN est un NAT statique et sans état (static, stateless), qui ne se comporte pas comme le NAT Gateway dynamique que vous connaissez pour la sortie Internet :

  • Pas de translation de port (pas de NAPT). Chaque adresse de la plage source est associée de façon déterministe à la même position dans la plage cible : les host bits sont conservés. Si 10.10.100.0/24 est mappé vers 100.64.100.0/24, alors 10.10.100.5 devient toujours 100.64.100.5.
  • Pas d'état de session, pas d'allocation de port. La translation ne dépend que de la règle. Il n'y a donc ni limite de ~55 000 connexions simultanées par IP, ni métrique ErrorPortAllocation, ni épuisement de ports — ces notions appartiennent au NAT Gateway dynamique et ne s'appliquent pas ici.
  • La connexion peut être initiée des deux côtés. Comme chaque adresse cible mappe exactement une adresse source, un autre réseau peut lui aussi ouvrir des connexions vers les adresses traduites, pas seulement recevoir des réponses.
  • IPv4 uniquement. IPv6 n'est pas traduit : le trafic IPv6 traverse sans modification.

La contrepartie de ce mapping 1:1 strict, c'est qu'il consomme autant d'espace d'adressage que le réseau source : plage cible de même longueur de préfixe (un /16 source exige un /16 cible), en RFC 1918 ou CGNAT (RFC 6598). C'est là que se situe le vrai coût du modèle, pas dans une limite de connexions.

Le NAT casse la traçabilité des adresses

Dès lors que vous traduisez les adresses, les logs, les Security Groups et les outils d'audit côté distant ne voient plus les vraies IP source mais les adresses de substitution. Cela complique :

  • l'analyse post-incident (corréler un flux à une machine précise demande de connaître la table de translation),
  • les règles de filtrage basées sur l'IP source,
  • toute conformité qui exige de tracer l'identité réseau réelle d'un flux.

Les plages de substitution sont de la dette d'adressage

Vous consommez de nouvelles plages IP (le 100.64.0.0/10 dans notre exemple) qu'il faut gérer, documenter et réserver à l'échelle de l'organisation. Mal géré, vous ne faites que déplacer le problème de planification d'adressage, pas le résoudre.

Une dépendance et un point d'attention FinOps

La capacité est facturée via le Regional Private NAT Gateway : reportez-vous à la tarification Amazon VPC pour les coûts horaires et le traitement de données. Activer le NAT sur un attachement ajoute un coût horaire et un coût de traitement de données ; côté Cloud WAN, la facturation se fait au niveau du core network. Comme pour les NAT Gateway régionales, la mise à l'échelle automatique sur plusieurs zones de disponibilité peut faire grimper la facture si vous n'y prêtez pas attention.

Tous les types d'attachement ne sont pas supportés

La « portée large » annoncée mérite d'être précisée. D'après la documentation Transit Gateway, le 1:1 NAT est supporté sur les attachements VPC, Direct Connect gateway, Site-to-Site VPN (y compris Private IP VPN), Connect, peering intra-Région et inter-Région, et VPN Concentrator. En revanche, il n'est pas supporté sur le peering Cloud WAN, les route table attachments, Network Function et Client VPN. Deux incompatibilités à retenir également :

  • vous ne pouvez pas activer le NAT sur un attachement VPC qui a le mode appliance activé (il faut désactiver l'un pour activer l'autre) ;
  • un attachement Connect et son attachement de transport ne peuvent pas avoir le NAT activé tous les deux.

Attention au routage lors de l'activation

Sur un attachement VPC, activer le NAT remplace la route propagée pour chaque CIDR de VPC qu'une règle recouvre exactement par une route vers le NatCidr. Conséquence directe : les autres attachements qui joignaient ce VPC par ses vraies adresses perdent la connectivité. Il faut donc mettre à jour ces pairs pour qu'ils utilisent les adresses traduites avant d'activer le NAT, sous peine de coupure.

Pourquoi c'est un plan B, pas un design à adopter par défaut

Soyons très clairs sur l'intention : cette fonctionnalité est un filet de sécurité, pas une cible d'architecture. Elle est conçue pour les situations où vous n'avez pas le choix.

Le bon réflexe d'architecture reste, dans l'ordre :

  1. Planifier l'adressage en amont. Un plan IP cohérent à l'échelle de l'organisation (IPAM, plages réservées par environnement et par région) évite purement et simplement le problème. AWS liste la renumérotation comme la solution de référence quand elle est possible.
  2. Renuméroter le réseau le plus petit / le plus récent quand c'est encore faisable, c'est-à-dire avant que la production ne verrouille les adresses.
  3. Envisager PrivateLink lorsque le besoin est de publier un service précis plutôt que de router un réseau entier : PrivateLink rend un service joignable sans aucune route entre les deux réseaux, ce qui évite complètement la question du chevauchement et réduit la surface d'exposition.
  4. N'utiliser le 1:1 NAT que lorsque les options précédentes sont impraticables : fusion-acquisition avec des réseaux figés, connexion d'un partenaire dont vous ne contrôlez pas l'adressage, intégration multicloud sous contrainte de délai.

Le mérite de cette annonce est de rendre ce plan B beaucoup moins douloureux : fini le déploiement d'appliances, la gestion manuelle du SNAT/DNAT et les règles de retour oubliées. Mais un plan B rendu confortable reste un plan B. Y recourir par défaut, c'est accepter d'empiler de la translation d'adresses, de la dette d'adressage et de la complexité d'audit sur toute votre architecture — exactement ce qu'une bonne planification IP vous aurait épargné.

Bonnes pratiques

  • Documentez chaque règle de translation comme une donnée d'architecture de premier ordre : CIDR source, plage cible, sens, et raison métier. La table de translation devient une pièce critique pour tout diagnostic.
  • Réservez des plages de substitution dédiées (typiquement en 100.64.0.0/10) et gérez-les dans votre IPAM pour éviter de recréer un chevauchement… entre plages de translation.
  • Surveillez dès le premier jour les métriques CloudWatch de trafic traduit et câblez des événements EventBridge sur les changements d'état des attachements et des règles.
  • Vérifiez l'activation réelle des règles après chaque modification : l'application est asynchrone, attendez que NatGatewaySupport soit enabled et que chaque règle passe à activated (ou que l'attachement Cloud WAN revienne à AVAILABLE) avant de conclure.
  • Mettez à jour les pairs avant d'activer : sur un attachement VPC, l'activation remplace la route vers le CIDR réel par celle vers le NatCidr ; prévenez la coupure en basculant les autres réseaux sur les adresses traduites au préalable.
  • Validez les deux sens explicitement : la translation bidirectionnelle automatique est pratique, mais testez aussi bien le flux aller que le flux retour, et depuis les deux VPC.
  • Traitez-le comme temporaire quand c'est possible : si le chevauchement vient d'une acquisition, planifiez en parallèle une renumérotation à terme plutôt que de pérenniser la translation.
  • Limitez le périmètre : ne traduisez que les flux qui en ont réellement besoin, pas des réseaux entiers « au cas où ».

Disponibilité

D'après l'annonce, le 1:1 NAT via Regional Private NAT Gateway est proposé sur AWS Transit Gateway et AWS Cloud WAN dans toutes les régions commerciales AWS où ces services sont disponibles. Pour la tarification, voir la page Amazon VPC pricing.

Conclusion

Le 1:1 NAT managé sur Transit Gateway et Cloud WAN supprime une des corvées les plus classiques du réseau AWS : faire communiquer des réseaux aux adresses qui se chevauchent sans y passer des jours à bâtir et maintenir de la plomberie NAT. AWS prend en charge l'opération, la mise à l'échelle et la translation bidirectionnelle, ce qui est un vrai gain quand le chevauchement est subi plutôt que choisi.

La meilleure réponse au chevauchement de CIDR reste de ne jamais le créer, par une planification d'adressage rigoureuse. Quand le mal est fait — fusion, partenaire, multicloud sous contrainte — cette fonctionnalité est l'outil idéal pour débloquer la situation rapidement et proprement. Voyez-la comme une roue de secours de qualité : indispensable à avoir, mais ce n'est pas avec elle qu'on conçoit la voiture.

Sources

Partager cet article

XBlueskyReddit