A field report prices the IPv4 tax on EKS: about $143 a month per environment
On August 14, 2026, a RIPE NCC member published a field report on an IPv6-first EKS deployment on AWS: roughly $143 a month per environment saved, against a dated list of dependencies still stuck on IPv4. Teams standing up a new cluster now have an objective criterion for choosing IPv6-first over dual-stack.
February 1, 2024. AWS began charging $0.005 per hour for every public IPv4 address, about $3.65 a month. August 14, 2026. Spiro Stathakis, founder of the LIR isp6, published on RIPE Labs the field report of an EKS cluster deployed IPv6-first. July 14, 2026. He checked his external dependencies and found that api.stripe.com and github.com still have no AAAA record.
The finding fits in one sentence: on AWS, IPv4 has become a silent tax, and a new cluster can escape it almost entirely — provided you accept that the failure, when it happens, makes no noise at all.
IPv4 is a silent tax
Since February 1, 2024, public IPv4 pricing has changed the arithmetic. A conventional EKS cluster across three availability zones quietly accumulates NAT gateways, elastic IP addresses, per-gigabyte NAT processing, and public IPv4 addresses on ALBs.
The field report lays out the numbers, at us-east-1 list prices over a 730-hour month. Three NAT gateways at $0.045/h: $98.55. Three NAT EIPs at $0.005/h: $10.95. NAT processing of about 500 GB at $0.045: $22.50. Public IPv4 on the ALBs: $10.95. Total: about $143 a month per environment.
IPv6-first drops that line to zero, or close to it. The cluster egresses through an egress-only Internet Gateway — free, no SNAT, and each pod keeps its own address. The only residual cost, $0 to $11, is the deliberate choice to keep public IPv4 at the edge to reach clients still on IPv4. The saving is real, but not automatic: it depends on your ability to shed the dependencies that drag IPv4 back in.
What still breaks, with dates
The post’s thesis is blunt: you are only as IPv6 as your least-capable dependency. Nothing fails loudly; a dependency simply refuses to speak anything but IPv4, and to reach it you keep a NAT gateway — and therefore routes, addresses, and its bill.
The first trap is structural. An EKS cluster with ipFamily: ipv6 gives you IPv6-only pods and services, but the nodes remain dual-stack and every subnet 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.
The VPC CNI then chains a host-local plugin that hands each pod a non-routable IPv4 address in 169.254.172.0/22 and SNATs it to the node’s IPv4 whenever a pod talks to an IPv4-only destination. That interop shim is why IPv6 “just works” — and why you only discover the residual IPv4 in flow logs.
The rest is a dated list, valuable because several locks came off mid-flight. RDS still cannot run without IPv4: IPv6-only subnets are unsupported, and dual-stack requires an IPv4 CIDR everywhere. Progress is slow — publicly accessible dual-stack databases on October 31, 2025, IPv6 on the RDS service API VPC endpoints on January 30, 2026. ECR was IPv4-only for years: dual-stack endpoints on May 2, 2025, PrivateLink on November 21, 2025. CloudFront learned to fetch over IPv6 on September 8, 2025, but excluding S3 and VPC origins.
The most insidious trap is AWS’s default DNS. Checked in July 2026: sts.eu-west-1.amazonaws.com has no AAAA record, while sts.eu-west-1.api.aws does. The SDKs default to the former, and AWS_USE_DUALSTACK_ENDPOINT is not on by default. Without an explicit opt-in, your “IPv6” workload’s AWS API calls run over IPv4.
The trap: failure is silent
This is the report’s most useful lesson. On IPv6, nothing breaks loudly; everything fails in silence. A dependency takes the NAT, an endpoint resolves to A instead of AAAA, a Happy Eyeballs client picks IPv4 without warning — and you find out in flow logs, not a stack trace.
Two examples make the point. The /28s did not survive: a /28 leaves only 11 usable addresses after AWS reserves five, and dual-stack endpoint ENIs plus node primary ENIs exhausted them. The team grew to /27 public and /26 private, grudgingly. Second case: dual-stack endpoints resolve to both A and AAAA, and Happy Eyeballs clients happily take the A. The countermeasure lives in the security group: IPv6-only ingress on 443, so any IPv4 attempt fails closed instead of silently succeeding.
The long tail, finally, is where the dream dies. Checked on July 14, 2026: api.stripe.com with no AAAA, github.com with no AAAA, an SMS gateway and two identity providers with no AAAA. By contrast, gitlab.com and Docker Hub resolve AAAA just fine. Every name on that list is a reason the single NAT gateway still exists.
Verdict
If you are standing up a new cluster, on Linux and Nitro, Kubernetes-native, with a datastore that speaks IPv6 or hides behind PrivateLink, IPv6-first is the correct default in 2026. The constraint list is finite, documented, and visibly shrinking: ECR, CloudFront origins, public RDS, and its APIs have all moved recently.
If you depend on an IPv4-only link — an exposed RDS, Stripe, GitHub, an identity partner — keep exactly one NAT gateway as a residual liability, not three, and treat it as debt that shrinks as your vendors add an AAAA.
Either way, instrument flow logs on day one. The failure mode of everything above is silence, not error: it is in the NAT flow logs that you will see which dependencies are still riding IPv4 behind your back.
References
- RIPE Labs — Deploying IPv6-first EKS on AWS: What Still Doesn’t Work, and What It Saves, August 14, 2026
- AWS — New AWS Public IPv4 Address Charge, February 1, 2024