Last week, AWS announced a new tool to report your use of IPv4 public addresses, across your AWS account. That’s the good news.
There is bad news too, of a sort: AWS are going to bill for IPv4 address uses. Not yet, and in fact not until February 2024, but it’s coming.
I’m going to run through some common scenarios and explain what those extra costs could look like.
If you want to move straight into the cost analysis, feel free to jump to that section.
Context
There are two IP address families on the Internet: version 4, and version 6 (the other versions were basically experiments).
IPv4 is what made the internet what it is today. IPv4 addresses look like 233.252.0.42, and we’ve run out. Seriously,
there aren’t enough to meet demand. Back when the internet was used to connect military servers in one country, the US,
a 32-bit range felt like plenty. There are still addresses left, including over one million at AFRINIC (covering Africa),
but for the rest of the world there is a waiting list for new IP address assignments.
The answer, at least in theory, is IPv6. Back in the late 20th century, internet engineers saw the problem coming and
designed a new packet format for the internet that supports a lot more IP addresses (roughly 340 undecillion more).
IPv6 addresses look like 2001:db8:43e2:ad7:345b::239d - leaving all that room meant switching to 128 bit addresses.
Some of AWS already supports IPv6, including the basics: EC2 compute, S3 storage, network load balancing. You can run internal workloads without using any public IPv4 addresses at all - and there are firms who already do. AWS have a table detailing which other services have IPv6 support; most still don’t. Even key services like IAM and STS are IPv4 only, right now.
Switching is hard, though, and the day when your very last customer is ready for IPv6 will still be a long way off. Until then, we’re stuck with scarcity, and with workarounds for that scarcity such as network address translation (NAT). What AWS recently announced is an incentive to use those workarounds even more sparingly.
Cost analysis
The first part is easy. Public IPv4 addresses cost you $0.005 per hour, anywhere in the world. That charge comes in from the 1st of February 2024.
Now, $0.84 per week doesn’t seem like a lot. Honestly, a lot of firms won’t need to worry about this. AWS are making this change to encourage good practice at IPv4 address management - or, really, to impose a cost on mismanagement.
VPC with NAT gateways and one load balancer
Let’s say you have an Amazon VPC across three availability zones, and you have a NAT Gateway in each zone for resilience. The price goes from $0.045 to $0.05 per hour, per gateway. That’s $25.20 per week for all three, up from $22.68. Over a year, you pay an extra $131.50 in fees.
Add in a load balancer, and you’re paying twice as much: $262.98. However, it’s not quite that simple. For a high traffic website, the load balancing costs more because behind the scenes, AWS runs extra compute and assigns more IP addresses. Scaled out, that could actually be 24 public IPv4 addresses. With the NAT Gateways and application load balancers together, the extra cost could be as high as $1183.41.
You’re unlikely to pay that much - you might have a peak load that runs at full ALB scale-out, but it’s really uncommon to have that kind of load pattern all year round. However, a busy site could see an extra $500 on the cloud costs next year just from the VPC and the load balancing.
Kubernetes with pods in a public subnet
Usually, you don’t give public IPv4 addresses to Kubernetes Pods. However, sometimes people need to for their workload, using a custom network plugin. AWS elastic networking allows you to assign additional IP addresses to an EC2 instance, and Kubernetes lets you map that to a particular Pod.
(One motivation for this might be cost saving if your workload handles a lot of inbound traffic, such as web crawler).
If you’re doing this, each elastic IP address that you’re using is already costing you $0.005 per hour, and after the change it will still cost you $0.005 per hour. It’s easy maths: you pay an extra $0.00 per year because this price isn’t going to change, no matter how many Pods you’re using.
Fargate with tasks in a public subnet
A simpler alternative to Kubernetes is to use Fargate, with ECS managing container tasks. You can run tasks in a public subnet; usually it’s better not to, but the option is there.
These IP addresses are dynamic: if you launch a new task, it gets a new IP address from AWS’ pool of them. So long as that’s not a problem, every task you launch into a public subnet can have a public IPv4 address, and right now that costs you nothing extra. That changes in February next year. Let’s say you are running with horizontal autoscaling, averaging 75 tasks in the working week and 2 tasks the rest of the time.
Let’s say you’re paying $295 per week right now, and all those tasks have a public IPv4 address. After the change, you’re paying around $50 more a week (I calculated it as $2525.44 extra per year). That ≅17% increase on your cloud bill would stand out.
Global accelerator
AWS Global Accelerator lets you cut the latency that end users experience by placing endpoints at edge locations. As a managed service, Global Accelerator is able to make use of a bunch of tricks to get a good outcome. There’s even an IPv6 version.
Pricing for this service is global - as you might expect - with an extra component depending on how AWS routes the traffic to your application. That extra component doesn’t change costs at all as a result of these IPv4 price changes.
Each global accelerator uses exactly two public IPv4 addresses, so over a year you’ll pay an extra $87.66 - a sum that won’t break the bank.
One thing to note, though. You can have a global accelerator as IPv4-only, or dual stack (IPv4 and IPv6). So, even if you’ve converted the whole application to IPv6, you’re still paying a fee for the IPv4 addresses as part of that service. Just something to bear in mind.
RDS cluster with public access
First up, a note. The database technologies that you can run inside RDS are well-tested and are run as a managed service. Even so, these aren’t designed to be open to the world. If you do have a database cluster in AWS, with a public IP address, then you should make sure that the both the service and its clients are using TLS properly. If you’ve got any option to limit access using security group rules, do that as well.
Anyway, if this is you, you will pay more per instance. A typical multi-AZ cluster has two database instances, so that’s $0.01 per hour ($0.005 × 2). You’ll pay an extra $16.80 a week or $63.66 per year.
Lambda
When you set up a Lambda to run inside a VPC, it uses a special kind of network interface called a Hyperplane ENI. These network interfaces always use private networking. You’d need a NAT gateway or a similar mechanism to reach the public internet (your code might not need to).
Because the Lambda function doesn’t have a public IPv4 address, the extra cost would be $0.00 in all cases.
Options
The extra cost is small in most cases, and fixed: you’re not paying more as you scale out. In those cases, it’s not really broken and I really wouldn’t fix it.
Most customers using AWS will see a small increase on their cloud bill. These price increases are rare but, to be fair to AWS, this one looks justified. IPv4 addresses are scarce, and nobody is making an more of them.
For the Fargate scenario I mentioned, you will pay more after the pricing change and that cost does depend on your scale. You have options here:
- You may be able run fewer, larger tasks.
- If (and only if) the IPv4 networking is used just for outbound connections, then you can switch to private IPv4 for the tasks. Private networking means you also need NAT gateways. This option would require the fewest changes to application code; if you don’t already operate a NAT gateway, watch out for those costs (at least $438.30 per gateway annually). That’s still likely to be saving, but it depends on the volume of traffic. If the tasks are fetching a lot of data, making this change could even cost you considerably more.
- Potentially, you can use IPv6. You can usually do that even when you’re serving to clients that can only talk IPv4; that works because an application load balancer is able to use both address families. You can assign a public IPv6 address to a task even if it only has a private IPv4 address (you may need to run an egress-only internet gateway for security filtering, and pay a cost for those). Make sure that your application software is ready for this change.
If your SaaS architecture uses public IPv4 addresses per instance, per shard, or per tenant, watch out for this change next year, and make sure you’ve considered what design changes you might need in response.
Running a SaaS platform can be complex and costly. If you’d like some additional guidance managing the cost of running your workload so you’re confident you’re making good decisions, The Scale Factory offer a focused AWS health check.
You’ll receive a free report with a risk profile and specific technical recommendations. Book yours now.
This blog is written exclusively by The Scale Factory team. We do not accept external contributions.
