Since AWS began charging $0.005 per hour for every public IPv4 address in February 2024—roughly $3.65 monthly per address across all services—IPv6-first infrastructure became financially compelling for the first time. A standard three-availability-zone EKS deployment with NAT gateways, load balancer addresses, and bastion hosts accumulates these charges quickly.

For isp6, a RIPE NCC member LIR whose entire business centers on making IPv6adoption straightforward, running their own platform on IPv4 would have undermined their mission. They built their order-management system as IPv6-first EKS, with each environment's VPC receiving a /56 from their own provider-aggregated allocation via BYOIPv6—the same path their members follow. IPv4 support remains in place, but only as a legacy fallback, much like an office maintaining a fax machine. They originally allocated /28 subnets, the smallest AWS permits, solely to preserve connectivity with older networks.

This field report examines whether AWS can deliver genuine IPv6 end-to-end in 2026. The short answer: mostly yes, now, with a specific and shrinking list of exceptions—though one /28 subnet did not survive the implementation.

The core principle: IPv6 adoption is limited by the least-capable dependency

IPv6 failures on AWS rarely announce themselves loudly. Instead, a single dependency—a database engine, a payment API, a container registry—quietly refuses to speak anything other than IPv4. To reach it, you maintain a NAT gateway, which in turn requires IPv4 routes and addresses, perpetuating the monthly bill. The meaningful question is never "does AWS support IPv6?" but rather "which of my dependencies forces IPv4 back in, and what does each one cost?"

Architecture built

  • EKS with ipFamily: ipv6, where pods and services receive only IPv6 addresses via VPC CNI prefix delegation—a /80 per node, a /128 per pod. Every pod holds a globally routable address from the team's own RIPE allocation. IP exhaustion calculations, secondary CIDRs, and custom networking become irrelevant.
  • Egress-only Internet gateway as the primary egress route: free, stateful, outbound-only, with no per-gigabyte processing charge, and the pod's own address is preserved without SNAT.
  • A single NAT gateway retained solely as a legacy fallback for IPv4-only destinations—not three.
  • Dual-stack interface endpoints for required AWS APIs (ECR, STS, KMS, Secrets Manager, SSM), with security groups permitting only IPv6 on port 443, so clients resolving the A record fail safely.
  • Dual-stack Application Load Balancers at the edge and CloudFront for static content.
  • No RDS on the primary data path; the database tier uses a managed service reached over PrivateLink.

Documented gaps and their resolution dates

An IPv6-only EKS cluster does not exist. Setting ipFamily: ipv6 makes pods and services IPv6-only, but nodes remain dual-stack, and every subnet provided to EKS must still carry an IPv4 CIDR. This choice cannot be reversed after cluster creation and excludes Windows pods, Outposts, FSx for Lustre, and custom networking. The VPC CNI includes a host-local plugin that assigns each pod a non-routable IPv4 address from 169.254.172.0/22 and SNATs it to the node's IPv4 when communicating with IPv4-only destinations. This interoperability layer is why IPv6 EKS functions reliably, and why IPv4 never fully disappears: IPv4-only dependencies do not crash; they silently take the NAT path, discoverable only through flow logs rather than error messages.

RDS cannot operate 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 exists but moves slowly: publicly accessible dual-stack databases arrived on 31 October 2025, and IPv6 for VPC endpoints of RDS service APIs only landed on 30 January 2026. The common workaround is abandoning RDS entirely and using a managed datastore reached over PrivateLink—MongoDB Atlas being the standard example—precisely because of this constraint. However, PrivateLink interface endpoints themselves still require IPv4 today, relocating rather than eliminating the constraint. The isp6 team still runs an RDS instance for an internal tool, and that single instance alone is sufficient to pin IPv4 CIDRs onto its subnets. A dependency only needs to appear once.

ECR remained IPv4-only for years until May 2025. Dual-stack endpoints arrived on 2 May 2025, and PrivateLink support followed on 21 November 2025. Before that date, every image pull on an "IPv6" cluster silently rode the CNI's IPv4 shim. Dual-stack remains opt-in, and the default registry hostnames still resolve to IPv4.

Default AWS endpoint hostnames present an IPv4 trap. As of July 2026, sts.eu-west-1.amazonaws.com has no AAAA record; sts.eu-west-1.api.aws does. SDKs default to the former, and AWS_USE_DUALSTACK_ENDPOINT is not enabled by default. Without per-client opt-in or forced dual-stack VPC endpoints, an "IPv6" workload's AWS API calls travel over IPv4.

CloudFront gained IPv6 fetching capability in September 2025, with one major exception: IPv6 origins shipped on 8 September 2025 but explicitly exclude S3 and VPC origins. For static sites matching this pattern, CloudFront speaks IPv6 to viewers while communicating IPv4 with the S3 bucket behind it.

Internet-facing ALBs consume public IPv4 addresses unless explicitly disabled. A dual-stack ALB holds a public IPv4 per availability zone, each billed since February 2024. The dualstack-without-public-ipv4 option has existed since May 2024 and eliminates this charge. The isp6 team deliberately does not use it: their customers are, by definition, people transitioning to IPv6. Their rule is to spend IPv4 money only at the edge, where it provides reach, never inside the VPC, where it provides nothing.

Beyond these documented issues lies a longer tail where the vision falters. On 14 July 2026, the team checked external dependencies: api.stripe.com has no AAAA record. github.com has no AAAA record in 2026. Their SMS gateway and both identity-verification vendors lack AAAA records, with two sitting behind CloudFront distributions where IPv6 remains an unticked checkbox. (GitLab.com and Docker Hub do resolve AAAA correctly.) Amazon MQ offers no IPv6 support either, which is why the team runs RabbitMQ in-cluster as a StatefulSet instead. Every name on that list is a reason their single NAT gateway still exists.

Cost savings

Reference configuration: three availability zones, high availability, private nodes, one Internet-facing ALB. US East 1 list prices at 730 hours per month. Data transfer costs are excluded because they are identical across both protocols. Pricing changes frequently; these figures are indicative and should be verified against current VPC pricing.

Practical challenges encountered

  • The /28 subnets did not survive. The team sized IPv4 subnets at /28 as a statement of intent. A /28 provides 11 usable addresses after AWS reserves five, but dual-stack interface endpoint ENIs plus node primary ENIs consumed them. The team grew to /27 public and /26 private, reluctantly.
  • Dual-stack endpoints resolve to both A and AAAA records, and Happy Eyeballs clients will happily select the A record. The team enforces IPv6 at the security group level, with IPv6-only ingress on port 443, so IPv4 attempts fail safely rather than silently succeeding. (Setting ip_address_type = "ipv6" on an endpoint would be cleaner, but AWS only permits it on IPv6-only subnets, which EKS cannot use.)
  • ipFamily is permanent. Changing this decision requires a new cluster and workload migration.
  • Not every AWS API has caught up regionally: the ec2messages endpoint would not accept an IPv6 address type in their region, so they run Session Manager on ssm and ssmmessages alone.
  • Managed add-on services lag the core platform. Amazon MQ's missing IPv6 support drove the self-hosted RabbitMQ decision more than any Kubernetes preference.
  • Observability must support IPv6 from day one, because the failure mode of these gaps is silence, not errors. NAT flow logs revealed which dependencies were quietly on the IPv4 path.

Is IPv6-first EKS worth it in 2026?

Yes, within a precise scope. For greenfield deployments running Linux on Nitro, Kubernetes-native workloads, and datastores that either support IPv6 or hide behind PrivateLink, IPv6-first EKS is the correct default in 2026. The constraint list is finite, documented above, and visibly shrinking: ECR, CloudFront origins, public RDS, and RDS service APIs all improved between April 2025 and January 2026. Savings reach approximately $130 or more per environment monthly at small scale, with higher savings at NAT-heavy scale, and you permanently exit the IPv4 scarcity-management business: no more custom networking, secondary CIDRs, or overlapping RFC 1918 peering archaeology. The team came for the eliminated NAT bill; they stayed because address planning stopped being a job.

If Windows pods, Outposts, an RDS-centered architecture, or revenue flowing through IPv4-only SaaS APIs are required, proceed with clear eyes: you will run that NAT gateway regardless, so implement a minimal dual-stack VPC and capture the interoperability wins without pursuing purity. The protocol awards no style points. But revisit this list in a year. Every gap documented here has a shorter life expectancy than your cluster.