Is 2025 going to be the year of broad IPv6 adoption? For AWS, it might just be. In the past months many services have gained IPv6 support, which paves the way for IPv6-only (and NAT Gateway free) VPC configurations.
In February 2024 (almost exactly a year ago at the time of writing) AWS started charging for the use of public IPv4 addresses. The cost is $0.005 per hour per IP address, or about $3.60 per month. This might not seem like a lot, but every ALB has three addresses, every NAT Gateway has one, every public EC2 instance or Fargate container has one, and so on. Multiply this by the number of AWS accounts in your organization, and it adds up. So much so that a migration to BYOIP was worth the investment for PostNL.
The reason AWS started charging for IPv4 is that the world is rapidly running out of public IPv4 addresses. By incurring a cost AWS hopes to stimulate customers to reduce their usage of the IPv4 address space. In their own words:
As you may know, IPv4 addresses are an increasingly scarce resource and the cost to acquire a single public IPv4 address has risen more than 300% over the past 5 years. This change reflects our own costs and is also intended to encourage you to be a bit more frugal with your use of public IPv4 addresses and to think about accelerating your adoption of IPv6 as a modernization and conservation measure.
The best and most effective way to avoid IPv4 (and by extension NAT Gateway, which is much pricier than the cost of IPv4 addresses alone) would be to migrate every service, EC2 instance, container, Lambda function, database, and everything else to IPv6-only networking. Obviously, if there are no IPv4 addresses in your VPC there will also be no charges for them. However, there is a catch. Quite an annoying one, in fact. And that’s that many AWS services depend on other AWS services, which are only reachable over IPv4. For example, you cannot spin up an ECS container without access to ECR and the ECS control plane. And these.. happen to be IPv4 only. The same applies to the SSM parameter store and many other services. For an up-to-date overview, see the great website AWS service endpoints by region and IPv6 support.
So AWS tells us to migrate to IPv6 and even charges for the use of the IPv4 address space – but they are also the ones preventing us from deploying pure IPv6 VPCs. I have written about this in frustration before, as have others (๐ check out this article by Apparent Order, it’s a great read).

But there is light at the end of the tunnel. I maintain aws-news.com and recently noticed a serious uptick in the number of AWS services announcing IPv6 support. For example:
- Amazon FSx now supports Internet Protocol Version 6 (IPv6) on FSx Service APIs, February 7, 2025
- AWS Health now supports Internet Protocol Version 6 (IPv6), January 28, 2025
- IPv6 compatibility for AWS Secrets Manager VPC Endpoints, December 27, 2024
- AWS CloudTrail now supports Internet Protocol Version 6 (IPv6), December 23, 2024
- AWS Backup now supports dual-stack (IPv4 and IPv6) environments, December 18, 2024
- Amazon EKS endpoints now support connectivity over Internet Protocol version 6 (IPv6), October 22, 2024
… and the list goes on. For a detailed overview of releases, search for “IPv6” on aws-news.com, or check the Apparent Order’s automatically updating overview. When we plot the IPv6 releases on a chart ranging from January 2020 to February 2025 the increased pace is immediately visible.

To be clear: there is still much work to be done. Apparent Order’s overview currently measures 59% of all endpoints are still IPv4-only, including tier 1 services like API Gateway, CodeBuild, ECR, ECS, ElastiCache, EventBridge, KMS, IAM, and many more. But the trajectory is clear; if AWS keeps up this pace, we might be able to launch our first IPv6-only networks in production by the end of the year. We can dream.
