Wait! IP4 has a cost?

Caveat: I started this post in April because lots of people were shocked at the cost appearing on their bill. I got half way and though it wasn't worth publishing as the chatter would die down. However 4 months later I am still  seeing people ask what can they do about IPv4 costs so thought I'd finish it off.

So you will know, or should know, that the 1st February 2024 saw AWS introduce charges for all public IPv4 addresses in use within an AWS account.

If your were not aware, and seems many weren’t, take a look at the announcement from last July. https://aws.amazon.com/blogs/aws/new-aws-public-ipv4-address-charge-public-ip-insights/

So what does this mean and why are people still making such a fuss?

Well the bottom line is if you are using a public, AWS Provided, IPv4 addresses you are charged just under $4 a month, which ends up being $45 a year, for each IP address that you use, and that could rack up!

But that's not much!

So let’s address the first view that this is not a lot. If you are running reasonable size instances, let's say 4vCPU, then these average about these average around $150 a month so you are going to have to pay about 2.5% more. While more, it’s not a particularly huge cost, especially considering AWS have not implemented price rises and if you continue to move workloads to new instances you can make savings to out weight these costs. For example convert your instance to graviton and gain savings of around 25% (if your workload can support it).

But what if across your AWS estate you have a reasonable amount of workloads and a thousand public IPv4 addresses? That "not so small" increase is now $4k a month or $45k a year. Money that could be used for something else.

So what is the real cost?

Well it might be higher than you think.

While we will look at items within a VPC that you've deployed, if you are using any service that you've enabled "public access" it probably will be have been allocated an "Service-managed IPv4 addresses". This includes, but not limited to RDS (Databases), EKS (Kubernetes), or MSK (Kafka).

So for VPCs the answer might be just don't put your EC2 in a public subnet. Something I looked at in my previous post "You put what in a public subnet". This might reduce your public IP cost because those instances are not needed or not using a public IP anymore.

However, what if you moved those instances behind a load balancer. What if you've implemented a three tier landscape and private subnets go via a NAT Gateway?

Cost Implication on VPC Components

NAT Gateway

So you put in a NAT gateway to add security and reduce exposure of your instances. This is great but it does allocate public IPs to use for the NAT IP. Looking at the cost of this it seems a big increase from the 4.5c an hour to be 5c an hour. But remember, if you're in 3 AZs it will be 3 times this so an increase from 13.5c to 15c. This is then only about a 10% increase. However, NAT gateways you will know that this is not what makes up the big portion of costs. Data processing is where it makes the money and this will not change. So in reality you will probably see only a small increase for your gateways. And this is instead of lots of instances having public IPs. However, if you have thousands of accounts and VPCs this might become a significant amount.

Load Balancer

Well what about a load balancer? We know one way to remove IPs is to shift to LB and have multiple EC2 behind. So let’s look at the IP4 impact on ELB costs. Depending on region and type this is about 2.5c an hour so about $18 a month. This would, in theory, increase to be 3c an hour or about $22 a month. Again a lot of charges for ELBs is the data processing and that would not change. However, there is a catch. ELB are just that, elastic. They are not a single instance/IP like EC2 or NAT Gateways, and dependent on your configuration will span AZs and can scale to more than a single IP per AZ. So with best practice of multi-AZ the charges could increase from $18 to about $29 which is a significant amount, and under heavy workloads this could be higher.

So how do i reduce the cost?

NAT Gateway

First: Do you actually need a NAT Gateway?
This sounds drastic but if your services make no outbound calls and just reply via a load balancer in the public subnet you might not need a NAT Gateway. Maybe you do have traffic to AWS services and these could be moved to a VPC endpoint.
Note: VPC endpoints do cost so analyze traffic before doing a move, but there are increased security options with a VPC endpoint.

Second: Do you need a NAT Gateway in every AZ?
For non-production VPC's I'd suggest asking if you really need a gateway in every public subnet/AZ? Could you move to a single AZ and eliminate cost. This would not only save the IPv4 charge, but also the NAT Gateway hourly charges .

Third: Could you centralize egress?
If you have a large estate with many NAT Gateways you might want to look at a central egress for internet traffic. Does every VPC really need a NAT Gateway? Forgetting the IP charge, NAT Gateways are expensive and if it’s just for system updates or external API calls does every VPC really need one or could you centralize. This is especially cost effective in non-production environments where there might not be as much traffic, and possible increased latency is not an issue. This needs analysis because depending on your networking you could end up just moving costs from NAT Gateway to something like Transit Gateway and your overall costs wouldn't decrease. But if you do move to one of the various Central Egress solution and add a firewall for enhanced security there could be extra benefits that balance the cost.

Load Balancer

So what can you do here as I told you to put everything behind a Load Balancer right!

First: Could you reduce the number of Load Balancers?
One option is to reduce the number of public load balancers. I have seen many people put a Network Load Balancer in the public subnet and it purely routes to an Application Load Balancer. NLBs can have fixed public IPs and due to what they do tend not to need to scale as much as an ALB. While the ALB might scale a lot more it would not have any impact on IP usage.
If you NLB is only access by your application then this is a great option as you could also just allocate different ports on the NLB to direct to different ALBs in the back end.

Second: Could you centralize ingress?
Have you looked at central ingress as well as egress? Again, it does not fit every use case but could be a way or reducing costs for not only IPs but other services. Similar to outbound NAT Gateways, inbound inspection in every VPC can quickly become costly and administration heavy. Putting all ingress in a central VPC which inspects and then routes could be an option, again, especially for non-production systems.

AWS Service

So what about all those services that just allocate an IP address for you.

First: Are you accessing it over the network.
For some services they might have a network interface to be able to do direct service call. For example writing to RDS using a SQL client in your application.
However, if you are only accessing via an AWS SDK/API then the service itself does not need to be accessible at all on the network.
So the first thing is to look at your service usage and see if it needs to be accessible on the network.

Second: Do they really need to be public?
So you've confirmed there are direct service/applicaiton calls and the solution needs to be on a network. While it might have been easy to just select public access and not worry about networking should your database really be open on the internet to everyone? While there are cost associated with hosting your application in a VPC it does have a big impact on the security and control of your services. Review if its time to move to a VPC for your solution. Again, this is a cost and benefit analysis, and you might decide that its easier, cheaper, or "better" for you not to use a VPC. And that might be the right answer for you or your application.

Why are we in this mess?

For me while looking at a lot of the complaints or "queries" around IPv4 I keep ending up with the question:

Why do you have so much using public IPs?

The obvious answer is "because I have a lot of public services" and while, especially if instances, moving them behind a gateway or load balancer might be the answer it highlights a few issues that would be resolved if you looked at something like the Well-Architected Framework.

Part of the AWS Well-Architected Review process focuses on the fact you should review designs frequently. If you had been doing this you would have realized at some point those 3 public instances in an autoscaling group was now 100 instances. The question would have already been asked why is it not behind an ELB. This should have been highlighted from a security and scalability perspective as doing this is a benefit to both. It reduces exposure of the machines and allows routing to multiple instances to be resilient to failure of a single instance.

In many cases it is because the solution has grown and they have not thought about the design. They had an EC2 that ran everything, then they made lots of EC2 that might have done everything or split roles for different parts of the solution. So often that POC becomes production and the analysis never happens. Maybe now is the time to do that?

Doing reviews would have also asked how are you keeping up to date on changes to AWS services. This would have meant you had address the announcement long before the 1st February implementation

Hopefully this gives you some ideas on how to build your solution to reduce IPv4 costs, but also how to overall build better designs. As always I appreciate any feedback you might have on the topics discussed.