On 23 October 2026, AWS announced that AWS Transit Gateway and AWS Cloud WAN now support 1:1 NAT. In plain terms, you can now connect two private networks that use the same IP address ranges without renumbering either of them, without running your own NAT appliances and without writing return-traffic rules.
If you have ever tried to connect an acquired company’s AWS account, a partner’s network or a VPC that a different team built years ago, you know how often this goes wrong. Everyone picked 10.0.0.0/16, and suddenly nothing can talk to anything. This guide explains how Transit Gateway 1:1 NAT works, where it fits, the rules you need to follow and a practical rollout plan.
Why Overlapping CIDRs Have Been So Painful
Until now, a transit gateway simply could not route between networks that share address space. The Transit Gateway VPC attachment documentation is clear: if you attach a VPC whose CIDR is identical to, or overlaps with, a VPC that is already attached, the routes for the new VPC are not propagated to the transit gateway route table.
AWS lists the usual causes in its announcement: mergers and acquisitions, partner networks connected over AWS Site-to-Site VPN, multicloud connectivity and VPCs that were provisioned independently. The traditional fixes were either re-addressing one of the networks, which is slow and risky, or deploying and managing NAT appliances at several points in the network.
What Is Transit Gateway 1:1 NAT?
According to the AWS Transit Gateway 1:1 NAT documentation, the feature provides static, stateless address translation at the transit layer, delivered as a Regional private NAT gateway embedded directly in your transit gateway. There is no separate NAT appliance or NAT gateway resource to deploy.
You define CIDR-to-CIDR mappings on each attachment. Each address in the original CIDR always maps to the same position in the NAT CIDR, so if 10.10.100.0/24 is mapped to 100.64.100.0/24, then 10.10.100.5 becomes 100.64.100.5. The key properties are:
- Bidirectional rules: one rule handles source NAT for traffic leaving the attachment and destination NAT for traffic coming back, so you never write a reverse rule.
- Stateless: there is no session state and no port translation. Return traffic is translated automatically, and other networks can also start connections to the NAT addresses.
- Equal prefix lengths: the original and NAT CIDRs must be the same size, and host bits are preserved.
- IPv4 only: IPv6 traffic passes through untranslated.
The same capability is available in AWS Cloud WAN, where translation happens at the core network edge of each attachment, including when the two attachments are in different Regions. AWS says 1:1 NAT is available in all commercial Regions where Transit Gateway and Cloud WAN operate, and the announcement points to the Amazon VPC pricing page for charges, so check there before you budget.
Where It Helps
AWS documents three main use cases:
- Overlapping IP addresses after acquisitions, partner integrations, multicloud links or decentralized IP planning across teams.
- IP obfuscation: partners and other business units see only translated addresses, so your internal addressing stays hidden.
- IPv4 exhaustion: NAT CIDRs can come from the carrier-grade NAT range (100.64.0.0/10), which extends your usable address space without renumbering.
On Transit Gateway, supported attachment types include VPC, Direct Connect gateway, Site-to-Site VPN, Connect, peering and VPN Concentrator. You cannot enable NAT on a VPC attachment that has appliance mode turned on, so check your inspection VPC design first.
How Translation Works for Two Identical VPCs
The How 1:1 NAT works guide walks through the most common scenario: VPC-A and VPC-B both use 10.0.0.0/16. The recommended pattern is to give each overlapping network its own NAT range:
- VPC-A attachment: 10.0.0.0/16 translated to 10.1.0.0/16
- VPC-B attachment: 10.0.0.0/16 translated to 10.2.0.0/16
An instance in VPC-A at 10.0.0.5 sends traffic to 10.2.0.1. The transit gateway rewrites the source to 10.1.0.5, routes the packet to VPC-B, and rewrites the destination back to 10.0.0.1. Replies follow the same path in reverse. Each instance keeps its real address, and all translation happens inside the transit gateway.
One important detail: translating only one side does not work when the CIDRs are identical. The network without a rule would try to reply to an address inside its own range, and its VPC route table would deliver that traffic locally instead of sending it to the transit gateway.
A Practical Rollout Plan
Based on the configuration guide, here is how we would approach a first deployment.
1. Reserve a dedicated NAT address block
AWS recommends reserving a block for NAT CIDRs, for example part of 100.64.0.0/10, and giving each overlapping network its own slice. NAT CIDRs must be RFC 1918 or CGNAT ranges and must not be used anywhere else on the transit gateway or in your connected networks. The transit gateway only checks for overlap between rules on the same attachment, so this planning is your responsibility.
2. Check ownership and permissions
Only the transit gateway owner can view or change NAT configuration. You need the IAM permissions ec2:ModifyTransitGatewayAttachmentNatConfiguration and ec2:GetTransitGatewayAttachmentNatConfiguration; AWS notes that ec2:Describe* grants do not include the Get action.
3. Tell every consumer about the new addresses first
On a VPC attachment, enabling NAT replaces the propagated route for each matched VPC CIDR with a route to its NAT CIDR. Any attachment that reaches the VPC by its real addresses loses connectivity, so update those peers before you save.
4. Add the rules
In the VPC console, open Transit gateway attachments, select the attachment and choose Manage 1:1 NAT. You can add up to 50 rules per attachment. The same change can be made with a single CLI call:
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":"10.1.0.0/16"}]'Be careful: the rule list you supply replaces all existing rules on the attachment. For infrastructure as code, CloudFormation provides the AWS::EC2::TransitGatewayAttachmentNatConfiguration resource.
5. Fix routes and security groups
Each VPC’s route tables must send the other network’s NAT CIDR to the transit gateway, and security groups and network ACLs must allow traffic from the translated ranges. For static VPN, static peering and Connect attachments, NAT routes are not installed automatically, so add static routes or advertise the NAT CIDRs from your network.
6. Verify and monitor
Changes apply asynchronously while the attachment stays available. Run get-transit-gateway-attachment-nat-configuration until every rule shows activated, then watch the CloudWatch metrics and EventBridge events AWS provides for translated traffic.
Network changes like this are easiest when your VPC design and IP plan are documented. Our AWS VPC services team helps with address planning and Transit Gateway design, and our AWS migration services cover the merger and data-centre connectivity projects where overlapping ranges show up most.
Frequently Asked Questions
Do I need to deploy a NAT gateway or appliance for Transit Gateway 1:1 NAT?
No. The NAT capability is embedded in the transit gateway or Cloud WAN core network. You only define rules on each attachment, and AWS operates and scales the translation.
Can I translate only one of two identical VPCs?
Not reliably. AWS recommends giving each overlapping network its own unique NAT CIDR, because a VPC delivers traffic for addresses inside its own range locally instead of sending it to the transit gateway.
Does 1:1 NAT support IPv6?
No. It is IPv4 only, and IPv6 traffic passes through untranslated.
Is it available in the Mumbai and Hyderabad Regions?
AWS says 1:1 NAT is offered in all AWS commercial Regions where Transit Gateway and Cloud WAN operate. Confirm availability in the console for your Region before planning a production change.
Need Help Connecting Overlapping Networks?
Shanav Technologies helps startups and growing businesses design clean, scalable AWS networks, from VPC and Transit Gateway architecture to post-acquisition integration and hybrid connectivity. If overlapping IP ranges are blocking a migration or a partner integration, talk to our team and we will help you plan a safe, low-downtime rollout.