Introduction

As you might already know, the new charge for public IPv4 addresses has finally taken effect on February 1, 2024. All public IPv4 addresses, both idle and in use, now incurs a charge of US$0.005 per hour or US$3.65 per month. Many AWS users have previously enjoyed free public IPv4 addresses with running resources and thus paid less attention on the usage. However, the new cost could accumulate significantly if not monitored closely.

With this blog post, I hope to raise awareness of the impact from the new charge and reiterate some strategies that will help you review and reduce public IPv4 address usages. Let's first start by reviewing your environment with a convenient tool.

Review your public IPv4 address usage with public IP insights

As recommended in the AWS blog post New – AWS Public IPv4 Address Charge + Public IP Insights, the Amazon VPC IP Address Manager (IPAM) provides a feature that helps you analyze your public IPv4 address usage. The public IP insights feature helps you visualize your usage by address type and by service for your AWS account (or your organization if configured).

Create a new IPAM

Getting started in the AWS Management Console is easy. You first need to open Amazon VPC IP Address Manager and create an IPAM for the first time. The following settings are recommended if you plan to use only the public IP insights feature for a consolidated view:

• IPAM tier: Free Tier

• Operating regions: Add all regions

After the IPAM is created, you can click Public IP insights from the left menu where you will be asked to wait for IPAM to populate your data. In my case, it took about 10 to 15 minutes for the data to show up for my single-account environment.

Review the public IP types and EIP usage charts

The Public IP insights page provides two donut charts to help you quickly identify how public IPv4 addresses are used in your environment. For example, here is a screenshot for my environment:

On the left, there is a donut chart that shows public IPv4 address allocation by type. The most relevant types are:

• Service managed IPs - Public IPv4 addresses provisioned and managed by an AWS service.

• Amazon-owned EIPs - Elastic IP (EIP) addresses that you have provisioned or assigned to resources in your AWS account.

• EC2 public IPs - Public IPv4 addresses assigned to EC2 instances when the instances were launched into a default subnet or into a subnet that’s been configured to automatically assign a public IPv4 address.

For my environment, I have one Amazon-owned EIP for a NAT gateway and two service managed IPs for an Application Load Balancer (ALB) that spans two AZs. As another example, I could also have an EC2 public IP which is associated with a bastion host deployed in the public subnet that is configured to automatically assign public IPv4 addresses.

Whereas the donut chart on the right indicates EIP usage by association status. Of particular interest are unassociated Amazon-owned EIPs which would incur a charge. These would be obvious candidates to delete, unless you have a reason to preserve the static IP address. I don't have any unassociated EIPs in my environment, thus the KPI shows 0 in the "donut hole".

Review the public IP address details

For more details pertaining to each assigned public IPv4 address, the Public IP addresses table at the bottom of the page comes in handy. As an example, here is a screenshot for my environment:

The table shows plenty of details that could help me identify how IPv4 addresses are allocated, so that I have a rough idea on where I stand.

Common IPv4 address usage optimization strategies

Once you know your public IPv4 address usage, you can do a bit of analysis and devise a mitigation plan to optimize cost. Below are some common scenarios and mitigation strategies that are worth reiterating.

Remove unassociated EIPs

Courtesy of Captain Obvious, if the EIP usage chart shows a non-zero number, you should review the unassociated EIPs and remove them if they are not needed. Even though you'd still have been charged before the new charge took effect, as a cost optimization best practice these EIPs should be unregistered unless you have legitimate reasons to retain them.

Use SSM Sessions Manager to connect to EC2 instances

AWS Systems Manager (SSM) Sessions Manager provides a secure and auditable means to connect to your EC2 instances via SSH or RDP within the AWS Management Console. Once an EC2 instance is configured with the proper outbound security group rules and IAM instance provide to allow SSM access, Sessions Manager can be used for shell access without a public IP address. This results in better security since your EC2 instance can reside in a private subnet, and it saves you from either assigning a public IP address to the instance or needing a bastion host (or jump box) which itself requires a public IP address.

Centralize inbound and outbound endpoint services

Depending on your architecture, you may be able to consolidate inbound endpoint services for your workloads. Both ALB and NLB supports multiple listeners and rules, while Amazon CloudFront can route to private ALBs and EC2 instances via AWS Global Accelerator.

Meanwhile, outbound internet access should be enabled using NAT gateways as per AWS best practices, instead of deploying all resources in public subnets and assigning public IP addresses.

It is important to note that these endpoint services consume IP addresses themselves on a per-AZ basis, so it is imperative that you deploy them optimally based on the actual high availability needs (for example, a 2-AZ setup may be sufficient to meet your SLA).

Disable public IPv4 address auto-assignment in your public subnets

In the past, public IPv4 addresses that are automatically assigned by public subnets are free, so many users may have enabled this feature out of convenience. Now that there is an associated cost, it is better to disable this option and assign EIPs on a case-by-case basis instead. You can check and disable the option in the (public) subnet settings as per the screenshot below:

As part of this, you may also identify EC2 instances that actually do not need to be in a public subnet, in which case you can consider moving them to a private subject (expect some work for this effort).

Consider using IPv6 instead (with caveats)

The main motivation behind the new IPv4 address usage fees is to discourage users from using the increasing-scarce IPv4 addresses, and instead start using IPv6 addresses. While this is a logical step forward, however not all AWS services can work exclusively with IPv6 addresses, nor are all end-users and applications ready for it. For example, Elastic Load Balancing still requires a dual-stack setup if IPv6 is required, and RDS requires IPv4 to operate. That being said, it is never too early to look into leveraging IPv6 as it will be an inevitable move as the world continues to be digitalized and exhausts the IPv4 address pool. For more details, refer to the AWS whitepaper IPv6 on AWS.

Summary

In this blog post, we outlined a general process to review your IPv4 address usages and different optimization methods so that you don't get charged unnecessarily. Many AWS users may still be unaware of this pricing change (I know some of my customers are), so I would appreciate if you can spread the word and send them a link to this blog post. With any luck, you can earn some brownie points or a beer for a fellow AWS user by saving them a few bucks :)

If you like this article, please check out my other blog posts for more helpful and intriguing content on AWS and DevOps. Thank you for reading and have a great one!