Review your Public IPv4 address usage on AWS before February 1, 2024

Starting February 1, 2024, AWS will charge their customers for the use of Public IPv4 addresses. It was expected, as Google Cloud and Microsoft Azure already charge for this type of usage.

In this post, I will explain the new charges and the resources that will be affected by this pricing change. I will also guide you on how to analyze the potential cost of this change and suggest ways to minimize its impact. This could also be an excellent opportunity for you to review your current deployments that are publicly exposed.

Using Public IPv4 addresses by AWS resources and Managed Services will (mostly) not be free anymore

Previously, it was free to use Public IPv4 addresses to expose AWS resources on the Internet, except for cases where an Elastic IP was not associated with an active resource or used as a secondary IP address in an EC2 instance, which always had a cost. However, this policy has now changed.

You can access four types of Public IPv4 addresses in AWS:

1. Amazon EC2 Public IPv4 addresses
2. Amazon-owned Elastic IP addresses
3. Public IPv4 addresses used by AWS Managed Services
4. Bring Your Own IPs (BYOIP)

Starting February 1, 2024, using certain types of IP addresses will cost $0.005 per IP per hour, which comes out to around $3.65 per IP per month if we consider an average month to have 730 hours. However, if you bring your own IP addresses that belong to you (not to AWS), and attach them to certain AWS services, you won't be charged. This remains the same as before. Also, beginning February 1, 2024, the AWS Free Tier for EC2 will include up to 750 hours of Public IPv4 address usage per month for the first 12 months. Please note that AWS Data Transfer charges for outgoing network traffic will remain unchanged.

Assigning public IPs to EC2 instances (the first of the four types of Public IPv4 addresses mentioned) is very common. Less obviously, multiple AWS Managed Services consume public IPv4 addresses by definition (e.g., AWS Site-to-Site VPN) or by connecting them to subnets that self-assign public IPs (e.g., Amazon RDS, Relational Database Services). You can find a non-comprehensive list of the most common AWS services that can use public IPv4 addresses in the AWS documentation.

Therefore, the cost change will affect many AWS users, and controlling those addresses is critical. The good news is that:

1. You can analyze the economic impact of changes before they occur.
2. It's also an opportunity to optimize your AWS architectures and improve their security.

Analyzing the impact of this price change

If you're aware of the number of hours your resources are connected to the internet, then calculating the extra cost resulting from this change is straightforward. You simply need to multiply the price of using a Public IPv4 address per hour by that number. However, not all customers have complete control over the number of Public IPv4s they use, as cost was not a concern until now. Furthermore, it can be challenging to identify the Public IPv4 addresses consumed by AWS Managed Services that are directly exposed to the internet.

To help customers identify the number and type of exposed public IPv4 addresses, AWS provides two tools that we can immediately use.

• Public IP Insights

Amazon has introduced a new feature in its VPC IP Address Manager (IPAM) that is available for free. This feature enables users to monitor, analyze and audit public IPv4 address usage in their AWS account by Region. However, it is important to note that using the rest of the VPC IPAM service incurs a cost.

The feature will list all Public IPv4 addresses across the four types: Amazon EC2 Public IPv4 addresses, Amazon-owned Elastic IP addresses, Public IPv4 addresses used by AWS Managed Services, and Bring Your Own IPs (BYOIP).

Furthermore, this feature can be used to analyze the security groups that are associated with the network interfaces used by exposed resources. This information can help users to make better decisions regarding how these resources are exposed on the Internet, and even detect insecure configurations that they were unaware of.

• Two new “Usage Types” for Public IPv4 addresses in the CUR (Cost and Usage Report) files

The AWS Cost and Usage Reports (CUR) are CSV files that store a detailed set of cost and usage data, which are saved in an Amazon Simple Storage Service (Amazon S3) bucket of your choice. Enabling this feature is free, and you are only charged for the Amazon S3 usage.

In the updated CUR files, you will notice two new "Usage Type" values: "PublicIPv4:IdleAddress" and "PublicIPv4:InUseAddress". These values will help you identify idle and in-use public IPv4 addresses. The new usage types are already available and will allow you to estimate the public IPv4-related charges before they become effective on February 1, 2024.

To analyze the reports, you have various options such as using spreadsheet software, accessing them from an application using the Amazon S3 API to process the data, using Cost Explorer, or even QuickSight.

One of the advantages of using the CUR for this analysis is that you can view the usage data generated in all (or selected) regions and in one of multiple AWS Accounts, and even filter it by other attributes. In contrast, Public IP Insights only displays regional data in the current account.

Optimizing costs and security

The strategies to minimize the impact of these new costs are not new and can be summarized in two mutually compatible categories.

• Exposing the minimum number of instances that use public IPv4 addresses

Elastic Load Balancers, AWS Global Accelerator, NAT Gateways/Instances and VPC Endpoints remove the need to enable public routing to EC2 instances. API Gateway and AppSync are also options if you are exposing an API.

For outbound internet traffic, AWS NAT Gateway allows resources in private subnets to connect to internet endpoints using the NAT gateway’s IP addresses. The cost of using NAT Gateway can be lower than a pure EC2 public IP setup, depending on the workload and data transfer volume. A more traditional approach involves using an EC2 instance as an unmanaged NAT server or a combination of both managed and unmanaged NAT, using AlterNAT.

To avoid the NAT Gateway charges, you can leverage one or more VPC Endpoints. If you want to access S3 from private instances, you could set up a Gateway Type VPC Endpoint and route the traffic to/from S3 through the VPC endpoint instead of going through the NAT Gateway. There are no data processing or hourly charges for using Gateway Type VPC Endpoints. However, Gateway Type VPC Endpoints can only access DynamoDB and S3. For other supported AWS services, you can use Interface Type VPC Endpoints. Most of them have a cost.

For inbound internet traffic, Application or Network Load Balancers can distribute application traffic across multiple targets or virtual appliances in one or more Availability Zones. If you need to load balance HTTP(S) requests, you can use the Application Load Balancer (ALB). You can deploy a Network Load Balancer for network/transport protocols (layer 4 - TCP, UDP) load balancing and extreme performance/low latency applications. Pricing is different for each type of load balancer.

As an alternative to Load Balancers, AWS Global Accelerator is another service that can improve public applications' availability, performance, and security. It provides two global static public IPs that act as fixed entry points to application endpoints. These IP addresses are anycast from AWS edge locations, so they’re announced from multiple AWS edge locations at the same time. This enables traffic to ingress onto the AWS global network as close to your users as possible. When configured with internal endpoints, it enables internet traffic to flow directly to the endpoints in your VPCs without requiring public IPv4 addresses in the backend. The cost depends on the source and destination of the traffic.

Finally, this approach (minimizing public IPv4 exposure) allows us not only to contain costs but also to implement the security recommendation of reducing the attack surface.

Moreover, administrative access to private EC2 instances can still be achieved using a Virtual Private Network (VPN) or Direct Connect connection, Session Manager or EC2 Instance Connect. A blog post on this topic will follow soon.

The AWS blog post, Identify and Optimize Public IPv4 Address Usage on AWS, expands on these (and additional) best practices.

• Adopting IPv6

IPv6 offers several advantages over IPv4, such as an increased number of addresses (340 trillion trillion trillion IP addresses versus 4.29 billion IP addresses available in IPv4, roughly 7.91*10²⁸ more addresses!) and simplified routing. However, transitioning to IPv6 can be as challenging as managing IPv4, and, in general, most organizations haven't prioritized IPv6 adoption. Despite this, AWS has been steadily working on enabling IPv6 on their services, but not all of them support IPv6 fully. If you're interested in getting started with IPv6 on AWS, the following links can be helpful:

Introducing IPv6-only subnets and EC2 instances

Dual-stack IPv6 architectures for AWS and hybrid networks

Architect dual stack Amazon VPC with multiple IPv6 CIDR blocks — Part 1

Architect dual stack Amazon VPC with multiple IPv6 CIDR blocks — Part 2

AWS services that support IPv6

Conclusion

Starting from February 1, 2024, AWS will charge for the use of every public IPv4 address that you use in their services, whether assigned directly or indirectly through an AWS Managed Service. This aligns AWS with its competitors, Google Cloud and Microsoft Azure, which are already charging for this usage. The cost will depend on how your resources are exposed on the Internet.

To help you prepare for this change, AWS provides data in the Cost and Usage Report (CUR) files and the free Public IP Insights feature of VPC IPAM.

To address your IP addresses fleet, there are two complementary strategies that you can follow: 1) Expose the minimum number of instances that use public IPv4 addresses, and 2) adopt IPv6.

You still have time to analyze and optimize how you use public IPv4 addresses before the new charges go into effect.