Two Networks, One 10.0.0.0/16: What Transit Gateway and Cloud WAN 1:1 NAT Actually Fixes

Every acquisition I have watched on the network side ends the same way. Legal closes on a Friday. By Monday someone has drawn a box around the two VPC estates, written “connect these” on the whiteboard, and then someone else reads out the CIDRs. Both sides picked 10.0.0.0/16, because of course they did.

On 23 October 2026 AWS announced that AWS Transit Gateway and AWS Cloud WAN now provide managed one-to-one NAT directly on their attachments. That is a genuine fix for a genuine problem. It is also a feature whose documentation is mostly about what you must get right around it, and that is the part worth reading.

The problem: the transit gateway cannot route to two of the same thing

A transit gateway builds its route tables from what attachments tell it. A VPC attachment tells it the VPC’s CIDR. Give it two identical CIDRs and the documentation is blunt: a transit gateway doesn’t support routing between VPCs with identical or overlapping CIDRs, and if you attach a VPC whose CIDR overlaps one already attached, the routes of the newly attached VPC are not propagated to the transit gateway route table.

So the second VPC attaches and its routes simply never appear. Nothing announces the failure; the destination just is not there. That is the nasty part.

AWS’s own framing of the cause is the one I would use in a design review: the overlap comes from mergers and acquisitions, partner integrations, multi-cloud connectivity and decentralised IP governance. Until now, per the 1:1 NAT documentation, two networks sharing RFC 1918 space could not talk over a shared transit gateway unless one of them was re-addressed or NAT appliances were deployed at multiple points. Renumbering is a project. Appliances are a fleet.

The challenge: translation is easy, routing is not

Network address translation is not hard. Doing it at a transit layer without breaking return paths is. If you translate on the way in and forget the way back, you get half-open conversations that look like a firewall bug. If you translate only one side, you get something subtler, which I will come back to, because it is the single most important sentence in the documentation.

First, what the feature is.

The solution: a rule on the attachment

AWS describes it as static, stateless network address translation at the transit layer, delivered as a Regional private NAT gateway embedded in your transit gateway. There is no NAT resource to deploy. You attach rules to attachments, and each rule is one CIDR-to-CIDR mapping.

The properties that matter:

• One rule, both directions. A rule maps an original CIDR to a NAT CIDR. Traffic arriving from the attachment with a source in the original CIDR is source-translated. Traffic sent to the attachment with a destination in the NAT CIDR is translated back. No reverse rule.
• Host bits are kept and ports are untouched. 10.10.100.0/24 mapped to 100.64.100.0/24 turns 10.10.100.5 into 100.64.100.5. The original and NAT CIDRs must have the same prefix length.
• Stateless. The mapping is decided by the rule alone: no ports, no session table, no port allocation. This is not NAPT. Because there is no state, other networks can also initiate connections to the NAT addresses.
• IPv4 only. IPv6 passes through untranslated.
• Constrained address space. NAT CIDRs must be RFC 1918 or the carrier-grade NAT range, 100.64.0.0/10, which RFC 6598 defines as the Shared Address Space.

Each rule carries a MatchSourceCidr and a NatCidr, a rule number from 1 to 32766 that identifies it (it is not a priority; rules cannot overlap, so an address matches at most one), and an attachment can hold up to 50 rules. The configuration is a single call, modify-transit-gateway-attachment-nat-configuration, and the rule set you supply replaces everything already on the attachment. Leave a rule out of the list and you have deleted it.

Why you must translate both sides

Now the sentence. The documentation walks through two VPCs, both 10.0.0.0/16, and says that translating only one side doesn’t work when the CIDRs are identical: the network without a rule would send replies to an address inside its own CIDR, and its VPC route table delivers that traffic locally instead of sending it to the transit gateway.

The announcement’s one-liner, translate one VPC’s addresses and connect immediately, is true as a headline and incomplete as a design. The recommended pattern is to give each overlapping network its own NAT CIDR. In AWS’s example VPC-A maps to 10.1.0.0/16 and VPC-B to 10.2.0.0/16:

Both VPCs keep 10.0.0.0/16. Each attachment translates to its own range, so the transit gateway sees two distinct prefixes.

Follow one packet. An instance at 10.0.0.5 in VPC-A sends to VPC-B’s NAT address 10.2.0.1. On arrival the VPC-A rule rewrites the source to 10.1.0.5. The transit gateway looks up 10.2.0.0/16, finds VPC-B, and VPC-B’s rule rewrites the destination back to 10.0.0.1. The reply runs the same steps in reverse. Each instance keeps its real address; each reaches the other at a translated one.

Notice what that implies for people. Nobody in VPC-A ever addresses VPC-B as 10.0.0.1. They use 10.2.0.1. Your DNS, your allow-lists and your runbooks now carry a second set of addresses for the same hosts. The renumbering project did not vanish; it shrank into a lookup table.

The routing, which is where it breaks

The NAT rule only translates. Packets must still arrive at the transit gateway, and replies must find their way back. How the NAT CIDR becomes reachable depends on the attachment type:

• VPC attachment: when the rule’s MatchSourceCidr exactly equals a VPC CIDR, the transit gateway replaces the propagated route for that CIDR with a route to the NAT CIDR. Rule matches a smaller piece, say a /24 inside a /16? The rule still translates, but no route is installed. You add a static route for the NAT CIDR yourself, or traffic to the NAT addresses, replies included, is never routed to the VPC attachment.
• Direct Connect gateway and BGP VPN: system routes are installed by default, and a route is active only while your network advertises something that overlaps the original CIDR. Otherwise its state is blackhole and traffic to the NAT CIDR is dropped. You can switch that off and advertise the NAT CIDR from your own BGP peers instead, which is what you want if you care about AS-path prepending for active/standby.
• Static VPN, static peering, Connect, VPN Concentrator: no system routes at all. Static routes, or your peers advertise them.

The translation is the same everywhere. Who installs the route to the translated range is not.

The routes the transit gateway installs have the route type system. For the same prefix, a system route ranks below a static route and above prefix list references and propagated routes, so a static route you created for a prefix still wins over a NAT route. Longest-prefix match applies first, as always.

What the console will not check for you

The documentation says it plainly: the transit gateway checks for overlap only between rules on the same attachment. It does not check other attachments, and it does not check your connected networks. Pick a NAT CIDR that collides with something already routed and longest-prefix match and route priority decide where traffic goes, “and might not reach the intended attachment”. AWS’s advice, which I would write on the whiteboard: reserve a dedicated block for NAT CIDRs, a slice of 100.64.0.0/10 for example, and give each overlapping network its own piece.

A few other edges, all from the same pages:

• Enabling NAT on a VPC attachment replaces the propagated route for the matched VPC CIDR. Other attachments that reached the VPC by its real addresses lose connectivity until they move to the NAT addresses.
• Enabling, changing or disabling NAT updates translation and routes separately, so traffic to the new NAT addresses can be dropped briefly. Do it in a maintenance window.
• A VPC attachment with appliance mode enabled cannot have NAT. Client VPN and Network Function attachments are unsupported. A Connect attachment and its transport attachment cannot both have NAT.
• Only the transit gateway owner can view or modify NAT configuration on a shared transit gateway, and the permissions are new: ec2:ModifyTransitGatewayAttachmentNatConfiguration and ec2:GetTransitGatewayAttachmentNatConfiguration. Describe* grants do not include the Get action.
• Security groups and network ACLs see the translated addresses. If VPC-A should accept traffic from a branch at 100.64.1.0/24, that is the range you write down, not the branch’s real one.

Cloud WAN, same idea, different shape

Cloud WAN gets the same feature with the same properties, applied in the core network. The part worth noting for multi-Region designs: source translation happens at the source attachment’s core network edge and destination translation at the destination attachment’s core network edge, including when the two attachments are in different Regions. Supported attachment types are VPC, Direct Connect gateway, Connect and Site-to-Site VPN. Transit gateway route table attachments and tunnel-less Connect are not. You also have to make sure your core network policy lets the NAT CIDRs propagate to the segments that need them, because Cloud WAN’s overlap check is equally local to the attachment.

The footprint: a smaller project, not no project

My judgement, after reading all of it:

Use it to buy time, and write down when the time runs out. For a merger, being able to connect on Monday instead of after a re-addressing programme is worth a lot. But the NAT CIDRs become permanent infrastructure the moment something depends on them. Put an expiry on the decision.

Treat the NAT range as a managed resource. A reserved block, an owner, and a register of which network got which slice. The service will not catch a collision across attachments. Your IPAM discipline will.

Do not mistake it for a firewall or a proxy. It is stateless and one-to-one. It hides internal addressing from partners, which AWS lists as a use case, but it filters nothing.

Test the failure you cannot see. A blackhole NAT route on a Direct Connect or BGP VPN attachment can look like a healthy attachment with a dead destination. Alarm on route state, and use the CloudWatch metrics and EventBridge events AWS says translated traffic is monitored through. Pricing is on the Amazon VPC pricing page; check it before you commit a design to it.

The deepest lesson is the old one. Overlapping address space was never a technical limit of the transit gateway. It was a planning failure that the transit gateway refused to hide. 1:1 NAT now lets you hide it, and that is exactly why somebody still has to own the plan.