AWS to start charging for IPv4 usage, but critical services don't support IPv6
Amazon Web Services’ plan to start charging for public IPv4 addresses is prompting scrutiny of both its pricing and its incomplete IPv6 support across key services. Commenters note that while other cloud providers already bill for IPv4 and address space has real market value, AWS’s move will push many users to rethink architectures, bastion hosts, NAT, and private endpoints — often trading one set of costs for another. Much of the debate centers on why IPv6 adoption remains slow despite long-standing support in hardware and operating systems, with recurring concerns about migration complexity, privacy, and dual-stack operational overhead.
AWS IPv4 Charge and Cloud Pricing Context
- Many see the new IPv4 “conservation charge” as a straightforward price hike, timed now that IPv4 addresses have resale value.
- Some argue the per‑IP price is not outrageous relative to market lease rates and AWS’s utilization constraints, others see it as rent‑seeking given IPs’ origins as a public good.
- Several note most major clouds already charge for IPv4; some smaller providers still bundle it for free or cheaper, making AWS look expensive.
IPv6 Support Gaps in AWS and Other Clouds
- Commenters highlight that key AWS services still lack full IPv6 or IPv6‑only support (e.g., ALB, many public endpoints).
- Similar gaps are reported in Azure and GCP managed services and networking (managed databases, GKE, peering, Cloud NAT).
- This undermines AWS’s suggestion that customers “accelerate IPv6 adoption,” since you often can’t go IPv6‑only in practice.
Transition Complexity: IPv6 vs IPv4 and “v4.1” Ideas
- Strong debate over whether IPv6’s design (ND, SLAAC, RAs, ULAs, link‑local, no NAT by default) made adoption unnecessarily hard vs. an inevitable cost of enlarging the address space.
- Some argue IPv6 could have been “IPv4 with bigger addresses,” or an IPv4.1 that preserves existing v4 addresses, easing rollout. Others counter that any header and structure change produces the same dual‑stack, translation, and tunneling complexity.
- Comparisons are drawn to Python 2→3: long transition, need for compatibility layers, but no easy alternative.
NAT, Security, and Privacy Debates
- One side views NAT as a de‑facto, easy, default‑deny security layer and sees IPv6’s end‑to‑end model as a privacy and safety regression.
- The other side stresses NAT is not a security mechanism, that proper firewalls are still required, and that IPv6 with default‑deny firewalls offers equivalent or better security while avoiding NAT’s P2P and protocol breakage.
- Claims that IPv6 is a “privacy nightmare” are contested; others argue IPv6 can be more resistant to scanning.
Workarounds to Reduce Public IPv4 Usage
- Suggested mitigations include: SSH bastions, SSM/Session Manager, EC2 instance‑connect, NAT gateways/instances, PrivateLink/VPC endpoints, NAT64 gateways, and offloading to services like CloudFront or other providers.
- Some report successfully removing most public IPv4s; others note endpoint pricing and architectural lock‑in can offset IPv4 savings.
Market Dynamics, Inertia, and Psychology
- Several commenters see institutional inertia, lack of clear business benefit, entrenched IPv4 ownership, and user expectations as primary blockers to IPv6.
- There is disagreement over whether IPv4 will ever truly be shut off; some predict eventual IPv6‑only networks, others think big IPv4 holders and industrial systems will stall that indefinitely.