Deploying IPv6-first EKS on AWS: what still doesn't work, and what it saves - isp6 Knowledge Base

Skip to content

BYOIP to Cloud

Reference Architectures

Strategy & Delivery

How We Built isp6

Cookie Policy

Deploying IPv6-first EKS on AWS: what still doesn't work, and what it saves

Field notes for platform and network engineers considering an IPv6-first deployment on AWS. Written by the team that runs the isp6 platform. Last updated: July 2026.

Since 1 February 2024, AWS charges $0.005 per hour for every public IPv4 address, about $3.65 a month, per address, across every service. For a conventional three-AZ EKS setup that adds up quietly: NAT gateway EIPs, load balancer addresses, the odd bastion. The charge made IPv6-first architectures financially interesting for the first time.

We had an additional motive. isp6 is a RIPE NCC LIR whose entire product is making IPv6 adoption easy, so running our own platform on IPv4 would have been embarrassing. We built our order-management platform as IPv6-first EKS, with each environment's VPC carrying a /56 from our own PA allocation via BYOIPv6, the same journey our members take. Our VPCs do still support IPv4, in roughly the way an office still supports a fax machine: we originally allocated /28s, the smallest subnets AWS permits, purely to maintain connectivity with legacy networks.

This is a field report on whether AWS can actually deliver IPv6 end-to-end in 2026. Short version: mostly, now, with a specific and shrinking list of exceptions, and one of our /28s didn't survive contact with the enemy.

The thesis: you are only as IPv6 as your least-capable dependency

Nothing about IPv6 on AWS fails loudly. What happens instead is that one dependency (a database engine, a payment API, a container registry) quietly refuses to speak anything but IPv4, and to reach it you keep a NAT gateway, and to keep a NAT gateway you keep IPv4 routes, addresses, and its bill. The interesting question is never "does AWS support IPv6?" It is "which of my dependencies drags IPv4 back in, and what does each one cost me?"

Here is our dependency-by-dependency answer, with dates, because several of these were fixed mid-flight.

What we built

EKS with ipFamily: ipv6: pods and services get IPv6 only, via VPC CNI prefix delegation (a /80 per node, a /128 per pod). Every pod has a globally unique address from our own RIPE allocation. IP exhaustion maths, secondary CIDRs, and custom networking cease to exist as concepts.

Egress-only internet gateway as the default egress path: free, stateful, outbound-only, no per-GB processing charge, and the pod's own address is preserved (no SNAT).

A single NAT gateway: not three, kept only as the legacy fallback for IPv4-only destinations.

Dual-stack interface endpoints for the AWS APIs the cluster needs (ECR, STS, KMS, Secrets Manager, SSM), with a security group that admits only IPv6 on 443, so any client that resolves the A record fails closed.

Dual-stack ALBs at the edge, and CloudFront for static content.

No RDS on the primary data path: the database tier is a managed service reached over PrivateLink. More on why below.

Three ways out of an IPv6-first VPC. The design goal is to keep everything on the top path (free and NAT-less) and treat the bottom one as a shrinking legacy liability.

The gaps, dated

There is no such thing as an IPv6-only EKS cluster. ipFamily: ipv6 means pods and services are IPv6-only; the nodes remain dual-stack, and every subnet you give EKS must still carry an IPv4 CIDR. The choice is irreversible at cluster creation, Nitro instances only, no Windows pods, no Outposts, no FSx for Lustre, no custom networking. On top of that, the VPC CNI chains a host-local plugin that hands each pod a non-routable IPv4 address from 169.254.172.0/22 and SNATs it to the node's IPv4 when a pod talks to an IPv4-only destination. This interop shim is why IPv6 EKS "just works", and why you never fully escape IPv4: your v4-only dependencies don't crash, they just silently take the NAT path, and you discover them in flow logs rather than stack traces.

RDS still cannot run without IPv4, anywhere. IPv6-only subnets are unsupported, and dual-stack mode requires an IPv4 CIDR on every subnet in the DB subnet group. Progress is real but slow: publicly accessible dual-stack databases shipped 31 October 2025, and IPv6 for VPC endpoints of the RDS service APIs only landed 30 January 2026. The common escape hatch is running the database tier off RDS entirely, using a managed datastore reached over PrivateLink (MongoDB Atlas is the canonical example) precisely because of this. Be clear-eyed about what that buys, though: PrivateLink interface endpoints themselves still require IPv4 today, so the hatch relocates the constraint to a different layer rather than deleting it. And we're not exempt: we still run an RDS instance for an internal tool, and that single instance is enough to pin IPv4 CIDRs onto its subnets regardless. The dependency only...