Is AWS really ready for IPv6?

I had already read about AWS's plan to charge for public IPv4 addresses, and I must say I was thrilled. It seemed like a brilliant move to nudge the community toward embracing IPv6, a change I was genuinely excited about.

Want to avoid costs for IPv4? Switch to IPv6!

A fellow FinOps practitioner asked about this new IPv4 charge, and my genuine reaction was: you could switch to IPv6, tweak your configuration a little, how hard can it be?

AWS's own blog posts portrayed this shift as a positive step, encouraging users to be more mindful of their public IPv4 address usage and urging them to consider adopting IPv6 as a modernization measure. To me, it sounded like a win-win situation.

So I suggested looking into IPv6-only workloads as a solution to avoid the costs for public IPv4 addresses. In fact, most browsers and clients support IPv6 using the Happy Eyeballs algorithm, then it's just a matter of creating a plan to change configuration in a smart way to avoid service degradation or failure, and obviously have a backup plan if anything goes wrong.

Sorry, AWS isn't ready for IPv6 only workloads.

My enthusiasm took a hit when I discovered that, while many AWS services support IPv6, not even half of them offer IPv6-only support. I went on discussing the possibilities and alternatives on reddit and was pointed in the direction of an article that offered a different perspective. You can cut costs by reduce your usage of public IPv4 addresses, but you cannot avoid them altogether. It's practically impossible to run IPv6 only workloads. As the article points out, AWS services are still heavily reliant on IPv4. This revelation was a bit of a letdown, considering the promising move towards IPv6 adoption.

Cost optimization strategies

You will be charged for every public IPv4. So, there are a couple of main strategies you can follow.

Bring your own IP addresses

Similarly to BYOL, you can also bring your own public IP addresses to avoid the extra charge.

Remove unused Elastic IP addresses

This is an often overlooked cost factor, and you should look into it anyways, because it's already incurring costs. Elastic IP addresses are static addresses you can use for dynamic workloads, so you don't have to constantly reconfigure your client or DNS setup. They are still free of charge when attached to an EC2 instance or network device, but AWS charges for each Elastic IP address that is not in use. There are some tools such as Cloudfix that can fix this automatically, otherwise you can build your own custom script to fix this.

Consolidate load balancers

A common side effect of using Cloudformation templates or Terraform modules, or using Kubernetes ingress controllers that create a load balancer for each service. A single load balancer can handle many URLs and services, so the solution is to adapt your IaC templates and configuration to use one load balancer per VPC.

Managed NAT Gateways

Until now, you could circumvent the costs of public NAT Gateways by using public IPv4 addresses on your EC2 instances. I wouldn't recommend it for plenty of reasons, but you still find this setup in the wild. Now, with the public IPv4 addresses getting charged in February 2024, this strategy might be reviewed. It will only be cheaper if you don't use more than 10 public addresses per availability zone.

Conclusion

As an AWS superfan, I truly appreciate the platform's capabilities and its role in shaping the future of cloud computing. However, I couldn't help but share the disappointment expressed in the article. I'm all for charging for public IPv4 addresses to drive the adoption of IPv6, but give us the possibility to run IPv6-only workloads as well. In the meantime, I gathered some ideas on how to reduce the oncoming additional charges.