cloud-platformsConfirmedAWS rolls out 1:1 NAT support for Transit Gateway and Cloud WAN, enabling seamless communication between private networks with overlapping IP address ranges, a major boon for enterprise cloud connectivity.
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.
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.
For infrastructure-as-code workflows, support across CloudFormation, CLI, SDKs, and the Console means the feature can be incorporated into existing deployment pipelines without new tooling. The ability to define translation rules per attachment enables granular control: a single Transit Gateway can interconnect dozens of VPCs and VPNs, each with its own translation mapping, while non-overlapping attachments pass traffic natively. This granularity is valuable during phased migrations or merger integrations where only a subset of networks require translation at any given time.
Monitoring via CloudWatch metrics and EventBridge events provides observability hooks for alerting on translation errors, traffic volume anomalies, or attachment health changes. The announcement does not enumerate the specific metric namespaces or EventBridge event patterns, so teams will need to consult the updated documentation to build dashboards and automation. The absence of these details in the release notes is a gap that operators should validate during staging deployments.
The feature directly benefits three high-impact scenarios cited in the announcement: mergers and acquisitions, partner network connectivity over Site-to-Site VPN, and multi-cloud interconnect via Direct Connect or Transit Gateway Connect. In each case, the overlapping CIDR problem has historically been a blocker that delayed network integration by weeks or months. With 1:1 NAT on the attachment, the integration timeline collapses to the time required to define translation mappings and update routing — a change the announcement characterizes as minutes.
For multi-cloud architectures, the ability to translate on the AWS side of a Direct Connect or VPN attachment means the remote cloud or on-premises network does not need to implement complementary NAT. This asymmetry simplifies negotiations with partners or acquired entities that may lack NAT capability or operational maturity. However, the announcement does not confirm whether the translation preserves original source addresses for logging or security inspection on the remote side; if source IP preservation is required for compliance or threat detection, teams must verify whether the translated address or the original address appears in flow logs and security group evaluations.
Transit Gateway Connect attachments for SD-WAN appliances extend the benefit to branch-office and edge topologies where overlapping address space is common across independently managed sites. The SD-WAN appliance continues to advertise its local CIDR; the translation rule on the Connect attachment maps it to a non-overlapping range within the Transit Gateway route table. This pattern allows centralized address management without re-IPing branch networks. The practical limit will be the number of translation rules supported per attachment and per Transit Gateway — a quota not disclosed in the release.