Running out of 10.0.0.0/8: IPv6 adoption patterns on AWS

Why 10.0.0.0/8 runs out

RFC 1918 gives every organization on Earth the same three private ranges: 10.0.0.0/8, 172.16.0.0/12, and 192.168.0.0/16, roughly 17.9 million addresses in total. That sounds bottomless until you watch how large AWS estates actually consume it. Every VPC that needs to route to another VPC, over peering or a Transit Gateway, must have a CIDR that overlaps with nothing else in the routing domain. Teams request /16s to be safe, container platforms burn a private IP per pod, every region and environment (dev, staging, prod) multiplies the allocations, and each acquisition arrives with a network that started from the exact same 10.0.0.0/8. AWS's own IPv6 whitepaper names the drivers plainly: public IPv4 exhaustion, private IPv4 scarcity within large-scale networks, and the need to serve IPv6-only clients.

The ANS-C01 toolbox has ways to live with overlap: PrivateLink presents a service through an endpoint without routing to the provider's CIDR at all, NAT can rewrite one side of a conflicting pair, and Transit Gateway route tables can keep overlapping domains isolated from each other. All of these treat the symptom. The pattern this study covers treats the cause: give workloads addresses from a space so large that overlap stops being a design constraint. An Amazon-provided IPv6 VPC CIDR is a /56 of globally unique address space, each subnet takes a /64, and two VPCs never collide because the ranges are allocated from Amazon's pool rather than from a shared private range everyone reuses.

AWS frames adoption around three tenets: re-evaluate your network controls, because IPv6 removes NAT from the perimeter story; design for scale, because a bigger address space does not excuse skipping allocation planning; and phase the adoption, because IPv4 and IPv6 coexist cleanly for as long as you need. That last tenet is why the pattern below has two stages: dual-stack first, IPv6-only where it pays off.

The traffic path, from dual-stack retrofit to IPv6-only escape hatch

Stage one is retrofitting an existing IPv4 VPC to dual-stack, and the VPC user guide lays it out as four moves. Associate an IPv6 CIDR with the VPC (Amazon-provided, IPAM-allocated, or BYOIP), then a /64 from it with each subnet; AWS adds the IPv6 local route to every route table automatically. Then update routing for internet-bound traffic: public subnets get ::/0 pointing at the internet gateway, private subnets get ::/0 pointing at an egress-only internet gateway, because NAT gateways do not carry IPv6 traffic and the EIGW is what preserves outbound-only semantics without translation. Then update security groups and any custom NACLs, since a rule allowing 0.0.0.0/0 says nothing about ::/0 and IPv6 traffic needs its own explicit rules. Finally, assign IPv6 addresses to instances. IPv4 and IPv6 now operate side by side and independently, and you cannot turn IPv4 off in a dual-stack subnet.

Dual-stack keeps compatibility but does not save a single IPv4 address, because every host still holds one. The escape hatch is the IPv6-only subnet, where workloads carry no IPv4 at all, and the interesting question becomes how those hosts reach the IPv4-only world that still surrounds them. That is the NAT64 and DNS64 path, and it is worth walking packet by packet.

First, the workload asks the Route 53 Resolver for a name. With DNS64 enabled on the subnet, the Resolver checks the answer: if an AAAA record exists, it returns it unchanged and the connection runs native IPv6 end to end. If the destination only has an A record, the Resolver synthesizes an IPv6 address by prepending the well-known RFC 6052 prefix 64:ff9b::/96 to the IPv4 address. Second, the workload sends packets to that synthesized address, and the subnet's route table, which carries a 64:ff9b::/96 route pointing at a NAT gateway, steers them there. Third, the NAT gateway recognizes the prefix, strips it to recover the real IPv4 destination, and rewrites the source to its own private IPv4 address, which the internet gateway translates to the gateway's Elastic IP on the way out. Fourth, response packets come back to the NAT gateway, which reverses the whole thing: it swaps its own address back for the host's IPv6 address and prepends 64:ff9b::/96 to the IPv4 source, and the packet rides the local route home. NAT64 is not a feature you switch on; it is automatically available on every NAT gateway, while DNS64 is a per-subnet attribute you enable explicitly.

The same machinery reaches on-premises IPv4 services. A Route 53 Resolver outbound endpoint with IPv4 addresses forwards queries to on-prem DNS over IPv4, and when the answer comes back with only an A record, the Resolver synthesizes the 64:ff9b::/96 form for the DNS64-enabled subnet. Data then flows through the NAT gateway toward a virtual private gateway or Transit Gateway instead of the internet gateway. Transit Gateway itself supports IPv6 across attachments, peering, associations, propagations, and routing, so the interior of a multi-VPC network can go dual-stack without changing the hub-and-spoke shape.

What this teaches for the exam

For task 1.6, this pattern is the strategic answer to IP overlap questions. When a scenario describes merged companies with colliding 10.0.0.0/8 allocations or an organization that has genuinely exhausted its RFC 1918 plan, weigh the tactical fixes (PrivateLink for service-to-service access without routing, NAT for one-sided rewrites, isolated Transit Gateway route tables) against the structural fix of IPv6 addressing, where Amazon-provided /56 blocks are globally unique and cannot overlap. Know the allocation shape cold: /56 per VPC, /64 per subnet, and IPAM or BYOIP when the organization wants to plan or bring its own space. Also remember the hard boundary the docs draw: there is no migration path from an IPv4-only subnet to an IPv6-only subnet, so IPv6-only is a choice made at subnet creation, not a conversion.

For task 2.2, the implementation details are exactly what scenario questions probe. Public dual-stack subnets route ::/0 to the internet gateway; private ones route ::/0 to an egress-only internet gateway, and the EIGW exists precisely because NAT gateways do not handle IPv6 egress the way they handle IPv4. A route table cannot point ::/0 at both an IGW and an EIGW at once. Security groups and NACLs need explicit IPv6 rules, because associating an IPv6 CIDR only auto-updates rules you never modified. For IPv6-only subnets, the checklist on the workload subnet is two routes plus one attribute: 64:ff9b::/96 to the NAT gateway, ::/0 to the EIGW or IGW, and enable-dns64 on the subnet itself, while the NAT gateway sits in a separate public subnet whose route table sends 0.0.0.0/0 to the IGW.

The distractor patterns write themselves. An answer that sends an IPv6-only host's traffic to a NAT gateway via ::/0 is wrong; only the 64:ff9b::/96 prefix belongs there. An answer that reaches an on-prem IPv4-only service from an IPv6-only subnet without both DNS64 and a translation hop is wrong. And an answer that claims you can disable IPv4 on an existing VPC to reclaim addresses is wrong, because IPv4 remains mandatory on the VPC; the savings come from placing new workloads in IPv6-only subnets. If you can trace the four-step NAT64 packet walk from the diagram, you can eliminate most wrong choices on sight.