IPv6 in the Cloud

Address abundance changes the model

A cloud customer typically receives a /56 IPv6 prefix per VPC — that's about 4.7 × 10^21 addresses. For comparison, an IPv4 /16 VPC has ~65k addresses. The scarcity that shaped IPv4 networking — NAT, private ranges, CIDR planning across peerings — simply doesn't exist for IPv6.

Practical consequences:

• Every instance can have a globally unique public IPv6 address.
• No need for NAT — outbound goes direct.
• No CIDR overlap concerns between VPCs, peers, or on-prem networks (each gets a unique provider-assigned prefix).
• Subnets can be arbitrarily large (typically /64 each, the minimum for IPv6 autoconfiguration).

Dual-stack as the default mode

Most production cloud deployments run dual-stack: instances have both IPv4 and IPv6 addresses, subnets carry both protocols. Applications can prefer IPv6 (which is RFC behavior with Happy Eyeballs) and fall back to IPv4 when IPv6 is unavailable.

For an instance with both, connections to dual-stack destinations use IPv6; connections to IPv4-only destinations use IPv4 transparently. Most modern operating systems and language runtimes handle this with no code changes.

The egress-only internet gateway

For private workloads that need outbound internet but no inbound, NAT served the dual purpose in IPv4 of translation and unsolicited-inbound blocking. IPv6 doesn't need translation; it needs only the firewall behavior. The egress-only internet gateway:

• Allows IPv6 instances to initiate outbound connections to the IPv6 internet.
• Allows return traffic on those connections (stateful).
• Drops unsolicited inbound from the internet.
• Does no address translation — the instance's IPv6 address is its globally-routable address.

Conceptually it does the NAT gateway's security job without the translation overhead and without the per-GB processing charge that NAT gateways carry.

IPv6 subnet sizing

IPv6 conventions are very different from IPv4. The standard subnet size is /64 — about 18 quintillion addresses. You don't size subnets for the number of hosts; you give every subnet a /64 because that's what RFC standards expect for autoconfiguration.

A /56 VPC has 256 possible /64 subnets, which is more than any cloud deployment needs. CIDR planning becomes: pick how to organize the /64s (per AZ, per service, per environment) rather than worry about running out.

IPv6 in security groups and NACLs

Security groups and NACLs support IPv6 as a separate rule class. You write:

• IPv4 inbound rule allowing 0.0.0.0/0 to port 443.
• IPv6 inbound rule allowing ::/0 to port 443.

These are independent. Forgetting the IPv6 rule means traffic arrives over IPv6 and gets dropped, which can be a confusing bug if the IPv4 path works. Audit security groups and NACLs explicitly for both protocols when enabling dual-stack.

IPv6-only subnets

For workloads where you control all the endpoints (internal microservices, container clusters), IPv6-only subnets are increasingly viable. Benefits: no IPv4 address consumption, no NAT, simpler routing. The catch: anything that needs to reach IPv4-only services (some legacy SaaS, certain third-party APIs, partner networks) requires translation.

Cloud providers offer NAT64 (network address translation between IPv6 and IPv4) with DNS64 (DNS responses that synthesize AAAA records pointing to NAT64 endpoints when only A records exist). The combination lets IPv6-only instances transparently reach IPv4-only destinations. The cost is a NAT64 gateway in the path; the benefit is no IPv4 anywhere in your VPC.

Pricing implications

Cloud providers have started charging for IPv4 public addresses. AWS introduced per-hour charges for public IPv4. The cost adds up at scale: a fleet of 1000 instances with public IPv4 addresses pays a meaningful monthly bill purely for the addresses.

IPv6 addresses are not metered the same way — abundance means the provider doesn't have a scarcity to bill for. For new deployments, IPv6 is the cost-efficient choice; existing deployments are gradually migrating.

What still requires IPv4

• Connections to IPv4-only external services (a significant fraction of the public internet, especially API providers).
• Some PaaS / managed services may be IPv4-only or limited in IPv6 support.
• Site-to-site VPN to on-prem networks that are IPv4-only.
• Some monitoring and observability tools.

Until the entire long tail of services supports IPv6, dual-stack with selective IPv6-only subnets is the most practical pattern.

DNS for dual-stack

For services to be reachable over both protocols, DNS must return both A (IPv4) and AAAA (IPv6) records. Cloud load balancers in dual-stack mode get both. Self-managed services need both DNS records explicitly published.

Client behavior: modern clients use Happy Eyeballs (RFC 8305) to try IPv6 and IPv4 concurrently and use whichever connects first. The user-perceived behavior is "fastest path wins."

Migration patterns

• Greenfield: dual-stack from day one, IPv6-only where possible.
• Brownfield: add IPv6 to existing VPCs, run dual-stack, gradually migrate workloads to IPv6 preference, eventually retire IPv4 for internal traffic.
• Edge first: enable IPv6 on user-facing load balancers and DNS first to capture cost benefit; expand to internal workloads later.

Frequently Asked Questions

How does IPv6 in cloud differ from IPv4?

Address abundance changes the model. Every cloud VPC gets a /56 or /48 prefix — billions of addresses — so there's no shortage and no NAT. Each instance can have a globally-unique public IPv6 address. The default mode for the cloud is dual-stack: both IPv4 and IPv6 on the same subnets and instances, with applications choosing per connection.

Do I need NAT for IPv6?

No. NAT exists in IPv4 because of address scarcity — many private addresses share one public address. IPv6 has no scarcity, so NAT is not needed and not generally supported by cloud providers. Outbound-only access uses an Egress-Only Internet Gateway (the IPv6 equivalent), which allows outbound connections but blocks unsolicited inbound.

What is an egress-only internet gateway?

The IPv6 equivalent of the NAT gateway's role: allows instances with IPv6 addresses to initiate outbound connections to the IPv6 internet while blocking inbound connections from outside. Unlike a NAT gateway, it does no address translation (the instance's address is its globally-routable address) — it just enforces a stateful firewall rule that drops unsolicited inbound.

Can I run IPv6-only in the cloud?

Yes, for many use cases. IPv6-only subnets avoid IPv4 address consumption entirely. The catch: many external services (third-party APIs, partners, customers) are IPv4-only. Cloud providers offer NAT64 / DNS64 services that let IPv6-only instances reach IPv4-only destinations transparently. Pure IPv6-only is increasingly viable but requires planning for the IPv4 dependencies that still exist.

Why adopt IPv6 in cloud?

Three reasons. First, IPv4 in cloud is increasingly expensive as IPv4 addresses become a metered resource. Second, IPv6 simplifies architecture by removing NAT, NAT gateways, and CIDR conflict planning. Third, large-scale deployments (Kubernetes, IoT) run out of IPv4 space within the VPC; IPv6 makes that scarcity disappear.