It’s been a few months since AWS announced “a new charge for public IPv4 addresses [...] whether attached to a service or not”. In their usual way, they’ve given a very small-looking number and left the rest of us to do the maths. The price we’re talking about is $0.005 per address per hour, which multiplies out to over US$40 a year.
This news is interesting to us for a few reasons. One reason is that, unlike a lot of things to do with AWS prices, it’s easy to understand.
AWS customers simply cannot leave IPv4 behind today, or any time soon. And by making money from IPv4, AWS has given itself one less reason to help people onto IPv6.
Any discussion of AWS costs can easily get lost in wonkery and obscure details. It’s a complicated set of services with a complicated pricing model. This makes it hard to answer big questions, like:
Does AWS offer value for money?
As technology improves, are more gains going to AWS customers or shareholders?
What does today’s behaviour tell us about what AWS might be like in the future?
These questions matter because some very smart companies are leaving the cloud. They’re getting away from complicated, expensive infrastructure and running on dedicated hardware or Virtual Servers (VPS) instead. It’s been a serious money-saver from some businesses, and we want you to be able to work out whether it would make sense for your company. The more you know about all the ways that AWS bills can get out of hand, the better.
AWS controls over 100 million IPv4 addresses and about half of them are available for allocation. In the (admittedly unlikely) event of every possible address being fully allocated, AWS would bring home an extra US$2.4B or so in a year. That’s a lot of half-cents.
So let’s dig into this one simple piece of IPv4 news and see where the thread takes us.
Amazon’s justification for new IPv4 charges
Sometimes putting a price on something can make sense. AWS argued that their move would have two positive effects:
Help deal with the problem of IPv4 scarcity.
Nudge AWS customers along in the adoption of IPv6, “as a modernization and conservation measure”.
That they’ll also make more money is just an unintended consequence, apparently.
The problem of IPv4 scarcity is real enough. That’s why one of the most prominent and usually reliable critics of AWS pricing, Corey Quinn, isn’t upset. “I’m absolutely here for it”, he wrote (while a white flag billowed over his shoulder, we presume). He thinks that this new cost will be “a good thing, once we navigate the rocky transition period to relearn how networking economically works in AWS”.
Relearn how networking economically works in AWS! As a company with our own history of struggling to control AWS costs, take it from us: That’s quite a big “if”.
Can AWS customers actually avoid new charges by switching over to IPv6? That’s the trick. In reality the “modernization” path from IPv4 to IPv6 is somewhere between perilous and nonexistent.
The impossibility of IPv6 adoption in AWS
A mostly-anonymous and very smart blogger on neveragain.de (also known as @apparentorder on Twitter/X) has done some useful analysis here. The whole thread is worth reading, but it boils down to this:
What annoys me most – there is virtually no way to avoid the IPv4 tax because most of AWS actively ignored IPv6 for years.
— Apparent Order (@apparentorder) July 30, 2023
Most importantly, a *lot* of AWS API endpoints do not support IPv6.
API Gateway endpoints (invoke) do not support IPv6.
🧵↕️
AWS customers simply cannot leave IPv4 behind today, or any time soon. And by making money from IPv4, AWS has given itself one less reason to help people onto IPv6.
Neveragain has also put together this helpful table of AWS service endpoints by region and IPv6 support. You can only adopt IPv6 if your service supports it. So if AWS really is keen on nudging its customers to modernise, this table will show us wide-ranging support for IPv6. Right?
Wrong.
This table updates daily. When we published this article it contained over 6,000 active service API/region combinations. In total:
3% offer IPv6 by default
4% support IPv6 via "dualstack"
91% are IPv4 only
What “Dualstack” really means is more work
As you can see in that figure above, AWS has more widespread support for “dualstack” than for IPv6 by default.
Dualstack means that either IPv4 or IPv6 can be used at a given endpoint. This sounds good - and to be fair it’s not bad. But dualstack is far from a silver bullet, because there is always configuration work to do. As a lot of developers have already written, this isn’t easy. Take the workhorse of AWS, EC2 instances, as an example.
Jan Schaumann, who blogs as Netmeister, says that “Even basic dualstack support for EC2 instances requires the creation of a VPC and a number of configuration steps that are not trivial for novice users to implement.”
The 4sysops guide to assigning an IPv6 address to an EC2 instance (dual stack), by Michael Pietroforte, begins: “The procedure to assign an IPv6 address to an EC2 in AWS is amazingly complicated.”
You get the point. IPv6 is very much a work-in-progress for AWS, so it takes a lot of effort to free up IPv4 addresses with dualstack services. It’s more efficient to shrug, stick with IPv4, and just send a bit more money to AWS.
Even if you do go through with it, dualstack doesn't always mean that you’ll avoid IPv4. Take Elastic Load Balancers (ELB), which work across multiple availability zones (three zones are usually recommended), each with its own IP address. Every time your load balancer communicates with a target that’s using IPv4, it will do the same. Dualstack makes no difference.
By Neveragain’s calculation, in their article AWS: Cannot Escape IPv4, three IPv4 addresses will soon add more than 50% to the cost of an ELB. This is essentially unavoidable.
A few other observations from the same article:
Trying to configure core services like API Gateway, Lambda, ECS or App Runner into IPv6-only subnets makes them either sternly refuse those subnets or throw comically sad error messages like ‘Not enough IP space available’.
Most AWS services, when configured into a dualstack subnet, happily ignore that the subnet has IPv6 configured; they can connect to IPv4 targets only.
Almost no AWS API can be used from a VPC without public IPv4 addresses. Running an innocent
aws s3 lsfrom an EC2 instance will fail.
There are third parties, like Cloudflare, that can essentially translate IP addresses between IPv4 and IPv6 before they hit an AWS stack. These types of solutions can be a useful way to work around complicated dualstack configurations, but they don't work for every use case, are not free, and they add complexity to any architecture.
Better ways for AWS to deal with IPv4 scarcity
AWS’s talk of solving IPv4 scarcity is not credible as long as the services themselves aren’t up to the task. If AWS was genuine about freeing up IPv4 addresses, they wouldn’t start with a new fee.
They’d work on the architectural issues that make IPv4 a requirement for so many functional uses of AWS.
They’d simplify dualstack configuration.
They’d think, and build, IPv6-first.
The IPv6 standard itself is older than AWS, so it’s not as if they haven’t had time to do these things. But there is very little evidence that they are working to prioritise IPv6. (Here at SiteHost, we’ve supported IPv6 as a standard feature since 2013.)
Instead of doing the heavy lifting, AWS have put a little-looking price tag on a crucial bit of kit. Headline prices won’t change, but Amazon’s bottom line will grow. Smart move - for them.
Back to those big questions
We started out with some big questions on our mind. Let’s finish with them, too.
Does AWS offer value for money? It definitely can. But today there’s ever less justification for AWS to be the default choice. The difficulties of controlling cost are a main reason businesses like Sparks Interactive leave AWS. New IPv4 charges will probably boil a few more frogs. (There's a lot more to cover here, which is why we asked NotebookLM to make quick work of the long Cloud Exit story in October 2024).
As technology improves, are more gains going to AWS customers or shareholders? The shift from IPv4 to IPv6 is different to other forms of tech evolution like Moore’s Law. But we still see AWS wringing more money out of the old rather than enthusiastically embracing the new. It’s a shareholders-first mentality.
Meanwhile customer-first thinking looks like our Dedicated Server benchmarks over time. The CPU performance that we offer has increased by 100x since 2007, while the price has barely budged. Storage costs are down 95%, and drives are almost incomparably quicker than they were.
It would be difficult to seriously argue that AWS today offers 100 times as much value to customers as it did 15 years ago. Instead, while bare metal performance has been accelerating, AWS has offered its shareholders double-digit growth and billions of dollars of revenue and profit.
What does today’s behaviour tell us about what AWS might be like in the future? If IPv4 addresses are ripe for new charges, who can tell where you’ll feel the next little bite? AWS benefits from complex billing - charges so granular that it’s hard to see what, exactly, is pushing the bottom line further each month. You’re the camel, and the IPv4 charge is just another straw that Amazon has found for your back.
This matters because we’re looking for a turning point
For the first time in its history, AWS is dealing with a concerted flow of companies leaving the cloud, cheered on by investors. In a lot of cases there are solid business reasons for swapping cloud services for dedicated hardware, which is getting better at ever-faster rates.
That gives AWS two options:
Compete harder. Innovate (by making it easier to adopt IPv6, for example), contain costs, and give more businesses more reasons to jump on board.
Charge harder. Accept that AWS isn’t going to be the default option for CIOs much longer, and instead work the wallets of current customers.
If AWS were genuinely encouraging IPv6 adoption, that would be competing harder. If they are adding fees that businesses can’t avoid, that’s charging harder.
As we’ve seen, the new IPv4 fees look much more like a "charging harder" kind of a thing.
This news just might be a signal that AWS no longer sees itself as an inevitable winner. Perhaps even the world’s biggest cloud provider recognises that Dedicated Hardware is an attractive option for anyone not already locked into AWS.