Update: February 1, 2024 – AWS now charges for public IPv4 addresses provided by AWS. This blog post has more details on this topic.

Today AWS announced new charges for AWS-provided public IPv4 addresses beginning February 1, 2024. In this blog post, we introduce two new features launching today to help you track and monitor your idle and in-use public IPv4 addresses, estimate future costs, and identify opportunities for optimization. To help you better understand how these changes will affect your AWS bill, starting today you will see new usage types in the AWS Cost and Usage Report (CUR) that provide detailed information on your public IPv4 addresses. We are also launching Public IP Insights, a new and free feature of Amazon VPC IP Address Management (IPAM) that simplifies monitoring, analysis, and auditing of public IPv4 addresses. Finally, we share common best practices for using public IPv4 addresses and identifying optimization opportunities.

Let’s start with a quick review of the four types of AWS public IPv4 addresses, and how they each factor into the announced charges:

Types of AWS public IPv4 addresses

AWS tracks four types of public IPv4 addresses: Amazon EC2 public IPv4 addresses, Amazon-owned Elastic IP addresses, service managed public IPv4 addresses, and Bring Your Own IPs (BYOIP). The new charges apply to all public IPv4 address types—except BYOIP.

1. Amazon Elastic Compute Cloud (EC2) public IPv4 addresses
When you launch AWS resources in a default Amazon Virtual Private Cloud (VPC), or in subnets that have the auto-assign public IP address setting enabled, they automatically receive public IPv4 addresses from the Amazon pool. Automatically assigned public IPv4 addresses are not associated with your AWS account. Therefore, when an EC2 public IPv4 address is disassociated from your instance, it’s released back into the Amazon address pool and cannot be reused. An EC2 public IPv4 address is automatically released from an instance when it is stopped, hibernated, or terminated, and a new one is assigned if you restart the instance. Details can be found in the EC2 public IPv4 documentation. Charges will apply for all EC2 public IPv4 addresses associated with resources in your VPCs, starting February 1, 2024.

2. Elastic IP addresses
An Elastic IP address is a public IPv4 address you can allocate to your AWS account, as opposed to a specific resource. Using an Elastic IP address instead of an EC2 public IPv4 address allows you to manage how it is associated with resources in your VPC. You can disassociate and reassociate an Elastic IP address without releasing it back to the Amazon pool. Today, there is no charge for the first Elastic IP (EIP) address you associate with a running instance, but you are charged for each additional EIP, and for idle EIPs assigned to your account. Starting February 1, 2024, the new charges will apply to all Elastic IP addresses in your AWS account.

3. Service managed public IPv4 addresses
AWS managed services that are deployed in your account, such as internet-facing Elastic Load Balancers, NAT gateways, or AWS Global Accelerators, make use of public IPv4 addresses from the Amazon-owned pool. When you deploy managed services in subnets with the auto-assign public IP option enabled, they automatically receive public IPv4 addresses. You can find a list of AWS services that use public addresses in our documentation. Starting February 1, 2024, charges will apply for all service managed public IPv4 addresses, and on resources launched in your Amazon VPCs, on AWS Global Accelerator, and on AWS Site-to-Site VPN tunnel endpoints.

4. BYOIP addresses
There is no charge for using your own IPv4 addresses. You can bring part or all of your publicly routable IPv4 address range from your on-premises network to your AWS account. You can configure one or more BYOIP address pools, either directly in EC2 or using Amazon VPC IPAM. When using BYOIP, you continue to own the address range, and control its advertisement status on the internet. Public IPv4 addresses from BYOIP pools are free as Elastic IP addresses and assigned to AWS services such as EC2 instances or NAT gateways. Also, you can use BYOIP addresses for AWS Global Accelerator, incurring no charges.

Note: From this point on we refer to EC2 Public IPv4 addresses, in-use Elastic IPv4 addresses, and service managed public IPv4 addresses as in-use public IPv4 addresses. We refer to idle Elastic IP addresses as idle public IPv4 addresses.

Estimating public IPv4 address charges

Starting today, and by default, your Cost and Usage Report (CUR) includes comprehensive usage data related to both in-use and idle public IPv4 addresses. When you set up CUR, you have the option of selecting Include Resource IDs to add more detailed resource level analysis. We show this in the following screenshot (figure 1):

Figure 1: AWS Cost and Usage Report showing where to select Resource IDs

In the updated CUR you will see two new usage types for public IPv4 addresses:

• PublicIPv4:IdleAddress: shows usage across all public IPv4 addresses that are idle in your AWS account
• PublicIPv4:InUseAddress: shows usage across all public IPv4 addresses that are in-use by your AWS resources. These include EC2 public IPv4 addresses, Elastic IP addresses, and service managed public IPv4 addresses. It does not include BYOIPs, as there is no charge for using BYOIP addresses.

You can use the new CUR information to update your automation around billing data, and to simplify public IPv4 tracking and cost calculation. These new usage types are added today to help you estimate public IPv4 related charges, and are not billed until February 1, 2024. The following image (figure 2) shows an example of how these usage types appear in a CUR.

Figure 2: AWS Cost and Usage Report showing the new PublicIPv4:IdleAddress and PublicIPv4:InUseAddress usage types (Click to open larger image in a new tab)

Calculating costs by UsageType

You can aggregate PublicIPv4:IdleAddress to estimate idle IPv4 address usage, and PublicIPv4:InUseAddress to estimate in-use IPv4 address usage. Using the data shown in figure 2, for the sample one-hour period between 2023-07-28 01:00 to 2023-07-28 02:00, we can calculate:

• Total idle public IPv4 address usage: 2 IPs x 1 hour
• Total in-use public IPv4 address usage: 7 IPs x 1 hour

Starting February 1, 2024, using these nine public IPv4 addresses will cost $0.045 for the one-hour interval. This breaks down as:

• An existing cost for the total idle public IPv4 address usage: 2 IPs x 1 hour x $0.005/IP/hour = $0.010
• A new cost for the total in-use public IPv4 address usage: 7 IPs x 1 hour x $0.005/IP/hour = $0.035

Calculating costs by Operation

If you want a more granular analysis, you can use the information in the lineItem/Operation column to identify public IPv4 usage based on IP type:

• AllocateAddressVPC: tracks Elastic IP addresses that are idle in your AWS account.
• AssociateAddressVPC: tracks Elastic IP addresses that are in-use and associated with your AWS resources.
• RunInstances: tracks all EC2 public IPv4 addresses associated with your AWS resources in VPCs.
• DescribeNetworkInterfaces: tracks service managed public IPv4 addresses in VPCs.
• CreateVpnConnection: tracks public IPv4 addresses associated with AWS Site-to-Site VPN connections
• CreateAccelerator: tracks public IPv4 addresses associated with AWS Global Accelerator accelerators

Let’s break down the same one-hour sample period between 2023-07-28 01:00 to 2023-07-28 02:00 that we used in the prior example. We calculate the following usage for each IP type using Operation data:

• Total idle Elastic IP address usage: 2 IPs x 1 hour
• Total in-use Elastic IP address usage: 2 IPs x 1 hour
• Total in-use EC2 public IPv4 address usage: 3 IPs x 1 hour
• Total in-use service managed public IPv4 address usage: 2 IPs x 1 hour

Starting February 1, 2024, using these nine public IPv4 addresses will cost $0.045 for the one-hour interval. This breaks down as:

• An existing cost for the total idle Elastic IP address usage: 2 IPs x 1 hour x $0.005/IP/hour = $0.010
• A new cost for the total in-use Elastic IPv4 address usage: 2 IPs x 1 hour x $0.005/IP/hour = $0.010
• A new cost for the total in-use EC2 public IPv4 address usage: 3 IPs x 1 hour x $0.005/IP/hour = $0.015
• A new cost for the total in-use service managed public IPv4 address usage: 2 IPs x 1 hour x $0.005/IP/hour = $0.010

Which totals to $0.045 for the nine public IPv4 addresses during the one-hour time interval.

Next, let’s review how you can use the new Amazon VPC IPAM Public IP Insights to monitor and manage public IPv4 usage on AWS.

Monitoring public IPv4 usage with Amazon VPC IPAM Public IP Insights

You need to create an Amazon VPC IPAM to use Public IP Insights. You are not charged for using Amazon VPC IPAM when you are only using Public IP Insights as a part of VPC IPAM Free Tier.

Public IP Insights is a new free feature of Amazon VPC IPAM that helps you monitor, analyze and audit public IPv4 address usage across your AWS accounts in an AWS Organization, and across AWS Regions. Public IP Insights helps you discover:

• What resources and services are using public IPv4 addresses: It shows public IPv4 addresses across IP types, including Amazon-owned Elastic IPs, service managed IPs, EC2 public IPs, and Bring Your Own IP (BYOIP) addresses. The following screenshot (figure 3) shows the Public IP Insights dashboard, highlighting the total number of public IPv4 addresses, together with a breakdown by type and association status.

Figure 3: Public IP insights dashboard within the Amazon VPC IP Address Manager (IPAM) console

• Why are public IP addresses used on specific resources: It shows security groups associated with network interfaces to help you identify internet access policies (for example, a web server listening on TCP port 80, or a bastion host with TCP port 22 opened) that rely on public IPv4 connectivity. This allows you to evaluate whether or not you can adopt more efficient alternatives. For example, the following screenshot (figure 4) shows TCP port 22 opened for remote SSH access from the internet. Depending on your use case, this may not be necessary.

Figure 4: EC2 public IPv4 address associated with an instance configured with a security group for remote SSH access

Best practices for Public IPv4 usage optimization

The following common best practices can help you optimize public IPv4 usage:

• Consider disabling the auto-assignment of public IPv4 addresses on default subnets, as shown in the screenshot that follows (figure 5). For example, subnets that host your Amazon ECS deployments, or RDS databases, may not need public IPv4 addresses.

Figure 5: Where to turn off auto-assignment of public IPv4 addresses

• If disabling auto-assignment of public IPv4 addresses at the subnet level is not an option, consider changing the auto-assignment of public IP addresses during instance launch. Overriding the subnet’s public IP addressing attribute allows you to control the level of granularity when resources receive public IPv4 addresses, as shown in the following screenshot (figure 6):

Figure 6: The Amazon VPC console showing where to disable auto-assignment of public IPv4 address at instance launch

• Assess which resources must be deployed in public subnets and require individual public IPv4 addresses. Resources like databases or container services can be deployed in private subnets, without being exposed directly to the internet. This will help you optimize the number of public IPv4 addresses associated with your resources.
• For remote access to resources within your VPCs, consider using Amazon EC2 Instance Connect (EIC) Endpoints instead of assigning public IPv4 addresses to each resource. This will help you optimize the number of public IPv4 addresses associated with your resources and improve your security posture.
• For inbound internet traffic, consider using Elastic Load Balancers or AWS Global Accelerator. These services help you increase the availability and performance of your workloads while optimizing public IPv4 utilization. When assessing the use of Elastic Load Balancers or AWS Global Accelerator, consider your architecture and traffic profiles.
• For outbound internet traffic, NAT gateways can help you optimize public IPv4 address utilization. NAT gateway offers you the capability to perform source address translation at scale, in each Availability Zone. When assessing the use of NAT gateway, consider your architecture and traffic profiles.

Let’s review examples of associated solutions and reference architectures:

Using EC2 Instance Connect Endpoints

EC2 Instance Connect Endpoint (EIC Endpoint) is a new feature that allows you to connect securely to your EC2 instances and other VPC resources from the internet. With EIC Endpoints, you no longer need public IPv4 addresses on your resources, an internet gateway in your VPC, or any agent to manage your environment. More details on using EIC Endpoint are covered in the Secure Connectivity from Public to Private: Introducing EC2 Instance Connect Endpoint blog post. Once you’re using an EIC endpoint to connect privately to your VPC resources, security group information available in Public IP Insights can help identify which resources no longer need public IPv4 addresses.

Integrating NAT gateways and Elastic Load Balancers for internet traffic

Outbound internet traffic

For outbound internet traffic, you can use AWS NAT gateway, a highly available and horizontally scalable Network Address Translation (NAT) service from AWS. AWS NAT gateway allows resources in private subnets to connect to internet endpoints using the NAT gateway’s IP address(es). Additionally, NAT gateways automatically scale to 100 Gbps and 10 million packets per second in an Availability Zone, supporting up to eight associated Elastic IP addresses. When assessing the use of NAT gateway, traffic patterns may determine whether it’s possible to integrate it in your architecture, and if the effort will lead to overall cost optimization.

For example, let’s consider a workload deployed in a default VPC in us-east-1, that uses on average 100 Amazon EC2 instances during a month and has an aggregated Data Transfer Out to the internet of 100 GB. The following architecture diagram (figure 7) shows an example of this deployment, where all EC2 instances receive EC2 Public IPv4 addresses automatically.

Figure 7: Amazon EC2 instances in public subnets when the auto-assign public IP setting is enabled and automatically receive Public IPv4 addresses

To assess the cost of using EC2 Public IPv4 addresses, we can apply the same calculations as in our previous examples:

• EC2 public IPv4 charges: 100 EC2 Public IPs x $0.005/IP/hour x 730 hours/month = $365/month

For the same workload, when using AWS NAT gateway we can optimize the use of public IPv4 addresses, as shown in the architecture that follows (figure 8):

Figure 8: NAT gateway architecture example for the same setup

Assuming we have the sample workload deployed across two AZs in us-east-1, the cost of integrating the AWS NAT gateway totals $77.50/month:

• NAT gateway hourly charges: $0.045/hour/NAT gateway x 730 hours x 2 NAT gateways = $65.70/month
• NAT gateway Data Processing charges: $0.045/GB x 100 GB = $4.50/month
• In-use Public IPv4 address charges: $0.005 /IP/ hour x 730 hours x 2 Elastic IPs = $7.30/month

In this case, using the EC2 public IP setup costs $365/month while the NAT gateway approach costs $77.50/month.

Conversely, if we consider a workload with four EC2 instances, deployed across the two AZs in the same setup, with the same total data processing requirements of 100 GB in a month, the public IPv4 charges become:

• EC2 public IPv4 charges: 4 EC2 Public IPs x $0.005/IP/hour x 730 hours = $14.60/month

In this case, using the EC2 public IP setup costs $14.60/month while the NAT gateway approach costs $77.50/month, as calculated in the previous example.

In conclusion, it may be that some of your workloads can benefit from the public IPv4 optimization the NAT gateway provides, while others can continue using public IPv4 addresses, depending on their internet communication needs.

Inbound internet traffic

For inbound internet traffic, Application or Network Load Balancers automatically distribute application traffic across multiple targets or virtual appliances in one or more AZ. This alleviates the need to manage individual EC2 instances and the public DNS records associated with each, and can help you optimize your public IPv4 usage. You can find the full set of features and capabilities in the Elastic Load Balancing documentation.

For example, let’s consider an internet facing web application, deployed in a default VPC, that uses 100 Amazon EC2 instances in a month. This web application processes 10 GB per hour of client traffic a month (requests and responses), and generates 1 GB of egress data originating in the VPC and going to the internet. The architecture diagram that follows (figure 9) details the sample setup. All EC2 instances are configured with Elastic IPv4 addresses, and DNS for the web application endpoint is managed in Amazon Route 53.

Figure 9: Amazon EC2 instances in public subnets with Elastic IPv4 addresses for a web application

To assess the cost of using Elastic IP addresses associated with the web application instances, we can apply the same calculations as above:

• EC2 public IPv4 charges: 100 EC2 Public IPs x $0.005/public IP/month x 730 hours = $365.00/month

For this workload, we can assess the integration of both an Application Load Balancer for client traffic, and NAT gateway for egress traffic originating in the VPC. The following diagram (figure 10) shows an architecture example of this web application using an internet-facing Application Load Balancer and a NAT gateway in each AZ:

Figure 10: Using NAT gateway and Application Load Balancer for internet traffic

The cost of integrating the AWS NAT gateway totals $73.045/month:

• NAT gateway hourly charges: $0.045/hour/NAT gateway x 730 hours x 2 NAT gateways = $65.70/month
• NAT gateway Data Processing charges: $0.045 / GB x 1 GB = $0.045/month
• In-use Public IPv4 address charges: $0.005 / IP / hour x 730 hours x 2 Elastic IPs = $7.30/month

For the Application Load Balancer, assuming the amount of traffic processed determines the number of Load Balancer Capacity Units (LCUs), the cost totals to $82.125/month:

• ALB hourly charges: $0.0225 / ALB / hour x 1 ALB x 730 hours = $16.425/month
• ALB per LCU hourly charges: $0.008 /LCU-hour x 10 LCUs x 730 hours = $58.40/month
• In-use Public IPv4 address charges: $0.005 / IP / hour x 730 hours x 2 ALB Elastic IPs = $7.30/month

This yields a total cost of integrating AWS NAT gateway and Application Load Balancer of $155.17/month, while the Elastic IP approach totals $365.00/month. In this example, without taking into account the additional benefits provided by Elastic Load Balancers, we can optimize public IPv4 address usage and cost by adopting NAT gateway and Application Load Balancer.

Using AWS Global Accelerator with private resources in your VPCs

AWS Global Accelerator is a networking service that helps you improve the availability, performance, and security of your public applications. Global Accelerator provides two global static public IPs that act as a fixed entry point to your application endpoints, such as Application Load Balancers, Network Load Balancers, and EC2 instances.

When you configure internal endpoints in AWS Global Accelerator (for example, EC2 instances in private subnets, or internal Application Load Balancers), you enable internet traffic to flow directly to the endpoints in your VPCs, without requiring public IP addresses. Response traffic also flows through Global Accelerator. The following diagram (figure 10) shows Global Accelerator with private EC2 instances as endpoints. Note that the EC2 instances will continue to use the NAT gateway for outbound internet traffic that starts in the VPC.

Figure 11: AWS Global Accelerator with private EC2 endpoints for inbound internet traffic

Note: The right optimization option for you depends on your workloads and application types, and their traffic profiles.

Conclusion

In this blog post we covered how you can use new data in the AWS Cost and Usage Reports to estimate your public IPv4 address charges, and reviewed Public IP Insights, a new and free feature of Amazon VPC IPAM that helps you monitor public IPv4 address usage. We also covered common best practices and architectures that allow you to optimize public IPv4 usage. If you have questions about this post, start a new thread on AWS re:Post, or contact AWS Support.

About the authors