Originally published on PkLavc.
Confirmed facts
AWS announced on 2026-10-23 that AWS Transit Gateway and AWS Cloud WAN now support managed one-to-one (1:1) Network Address Translation (NAT) directly on their attachments. The capability integrates with Regional Private NAT Gateway and is available in all AWS commercial regions where Transit Gateway and Cloud WAN operate.
1:1 NAT enables private networks with overlapping Classless Inter-Domain Routing (CIDR) blocks to communicate without renumbering either network, deploying a separate NAT appliance, or writing explicit return-traffic rules.
Customers define address-translation rules on a Transit Gateway or Cloud WAN attachment, specifying the private IP range each source CIDR translates to.
Translation applies automatically in both directions across Amazon VPC, AWS Site-to-Site VPN, AWS Direct Connect, and SD-WAN appliances connected through Transit Gateway Connect.
AWS operates, scales, and manages the NAT capability as part of the attachment; no separate NAT appliance is deployed by the customer.
Configuration is supported via the AWS Management Console, AWS Command Line Interface (CLI), AWS SDKs, and AWS CloudFormation.
Translated traffic can be monitored through Amazon CloudWatch metrics and Amazon EventBridge events.
Pricing follows the Amazon VPC pricing model; the announcement directs users to the VPC pricing page for details.
Documentation references include the AWS Transit Gateway and AWS Cloud WAN product pages and their respective developer guides.
Technical analysis
The introduction of managed 1:1 NAT on Transit Gateway and Cloud WAN attachments addresses a long-standing architectural constraint in enterprise cloud networking: the inability to interconnect private networks that share overlapping RFC 1918 address space. Historically, this scenario forced organizations into one of three undesirable paths — manual IP renumbering (high risk, high effort), deployment and maintenance of third-party NAT appliances (operational overhead, scaling limits), or complex policy-based routing with asymmetric return-path handling (fragile, difficult to audit). By embedding 1:1 NAT directly into the attachment plane, AWS eliminates the need for any of these workarounds for the supported attachment types.
From an operational perspective, the feature shifts NAT state management from customer-run instances or virtual appliances to a fully managed, regionally scoped service. The announcement confirms that translation is applied automatically in both directions with no separate return-traffic rule, which implies symmetric NAT behavior handled by the control plane. This design reduces the surface area for misconfiguration — a common source of connectivity failures in hybrid and multi-cloud environments — because the same attachment configuration governs both ingress and egress translation.
The integration with Regional Private NAT Gateway suggests that the underlying data plane leverages the same managed NAT infrastructure used for outbound internet connectivity, but repurposed for inter-attachment translation. This has practical consequences for throughput and availability: customers inherit the horizontal scaling and zonal resilience characteristics of the Regional Private NAT Gateway without provisioning capacity explicitly. However, the announcement does not disclose per-attachment throughput limits, latency overhead, or whether translation occurs at the network layer (L3) or includes port-level mapping (L4). These parameters would affect capacity planning for high-throughput workloads such as data replication or real-time analytics across merged VPCs.
Continue reading: Full technical article on PkLavc
Explore more technology articles: PkLavc Tech Blog
Telegram: https://t.me/PkLavcTech
Discord: https://discord.gg/zder5EZRK
Top comments (0)