IPv6 in AWS: it’s decided by routing and security groups, not the address

Why now: IPv4 costs money

Since February 1, 2024, AWS charges $0.005 per hour for every public IPv4 address — attached or idle, on an instance, a NAT gateway, a load balancer, an RDS endpoint, anything. That is about $3.60 a month per address. On one box it is a rounding error; across a fleet of thousands of ENIs, NAT gateways, and load balancers it is a real line item, and it only climbs as IPv4 gets scarcer — the market price of an address is up more than 300% in five years. IPv6 addresses are free. That one line turned IPv6 from “someday” into “this quarter.” The second driver is quieter: large orgs run out of RFC 1918 space (all of 10.0.0.0/8 is 16 million addresses) and hit overlapping-CIDR pain in every merger and peering; IPv6’s practically unbounded space deletes that whole class of problem.

The whole model in one VPC

Everything IPv6 does inside a VPC fits in one diagram. You get one Amazon-provided /56 and carve it into /64 subnets — always a /64, that is the AWS unit. Three kinds of subnet, distinguished only by where their default route points: a public subnet routes ::/0 to an internet gateway; a private-egress subnet routes ::/0 to an egress-only internet gateway; and an IPv6-only subnet adds a 64:ff9b::/96 route to a NAT gateway so it can still reach IPv4. A dual-stack load balancer sits at the edge for IPv4 clients. Hold this picture — the next five sections each grey out everything but one part of it.

1 · There is no private range

In IPv4 you learned that 10.x / 172.16.x / 192.168.x are private and everything else is public — the address told you the reach. IPv6 in AWS throws that away. Every address AWS hands out is a GUA (Globally Unique Address): globally routable, unique, with no NAT in front of it. There is no “private IPv6 range you use everywhere” (the protocol has ULA, fd00::/8, but AWS VPC addressing is GUA). So the address no longer tells you whether something is reachable. Reachability is decided by two things: the route table and the security group. Same instance, same address — public or private depending only on where ::/0 points and what the SG allows.

2 · Public vs private is a routing decision

With no NAT and no private range, what makes a subnet public? One route. Point ::/0 at an internet gateway and the subnet is public — inbound and outbound. This is the surprise that bites hardest: an IPv6 instance there is reachable from the internet the moment it boots, with no “assign public IP” toggle to forget and no NAT to sit behind. Public-by-default.

For outbound-only — the classic “private instances that need to reach the internet” — point ::/0 at an egress-only internet gateway. It is stateful: return traffic for connections the instance opened is allowed; new inbound is dropped. This is the IPv6 stand-in for the NAT gateway’s job, with one critical difference: it does no address translation. The instance keeps its own GUA; the egress-only gateway only enforces direction. (It is also free, where a NAT gateway is not.) Point ::/0 at nothing and the subnet is isolated.

3 · IPv6-only still needs IPv4 — via DNS64 and NAT64

An IPv6-only subnet has no IPv4 at all — the smallest possible blast radius for address exhaustion. But much of the internet, and a few AWS endpoints, are still IPv4-only, and an IPv6-only host cannot speak to them directly. Two features bridge the gap. DNS64, enabled per subnet on the Route 53 Resolver, watches DNS answers: when a name has only an A record, the resolver synthesizes an AAAA by prefixing the well-known 64:ff9b::/96 to the IPv4 address. The host now has an IPv6 address to send to. NAT64 does the translation: traffic to a 64:ff9b::/96 address is routed to a NAT gateway, which swaps IPv6 for IPv4 on the way out. NAT64 is automatic on every NAT gateway — nothing to enable; you just add the route. The honest seam: the NAT gateway still uses a public IPv4 (billable) — but one shared address for the whole subnet, not one per instance.

4 · Security groups don’t carry over

This is the quiet one. Security groups and network ACLs are per-address-family: your existing IPv4 rules do nothing for IPv6, and the default security group has no ::/0 allow. That fails in both directions. Fail-closed: you turn on IPv6, the service simply does not answer over it because no rule permits it, and you lose an afternoon before remembering SGs are family-specific. Fail-open: you add a broad ::/0 allow to “make it work,” and because IPv6 is public-by-default you have just exposed more than you meant to. The rule is blunt: every IPv4 rule that should also apply to IPv6 must be written again for IPv6, and audited in both families. NACLs too — a custom NACL written for IPv4 silently drops IPv6 unless you add ::/0 entries.

Dual-stack or IPv6-only? Pick per subnet

Two ways to run a subnet. Dual-stack (both IPv4 and IPv6) is the safe migration path: everything keeps working, you add AAAA records and IPv6 routes alongside the IPv4 ones. But you still pay for public IPv4 and still consume RFC 1918 space — you have added IPv6, not solved either driver. IPv6-only actually solves cost and exhaustion, but it demands that every workload, AMI, and agent in the subnet is IPv6-capable (some old software binds IPv4-only), plus DNS64/NAT64 for the IPv4 world. EC2 on Nitro, EKS (IPv6 cluster mode, prefix mode, Nitro-only; security-groups-for-pods since 2023), and ECS (IPv6-only GA September 2025) all support it. The rule: dual-stack to migrate safely; go IPv6-only on new, exhaustion-sensitive fleets you control — large EKS/ECS estates — and keep a dual-stack load balancer at the public edge, because too much of the client internet is still IPv4 to make your front door IPv6-only. The edge LB translates IPv4 clients to your IPv6 backends.

The migration order

The order matters because one step — routing — is what makes things reachable. Do it after security, never before.

Where it bites

IPv6 in AWS is less a new protocol to learn than a set of IPv4 reflexes to un-learn. Keep one rule in front: the address tells you nothing — the route table and the security group decide everything. Get those two right, and the rest is just choosing where to stop paying for IPv4.