You may have already received a email like the one above or seen the news already. But effective from February 1, 2024, AWS will charge $0.005 per hour for each dedicated public IPv4 address. In the words AWS Chief Evangelist Jeff Barr “This change reflects our own costs and is also intended to encourage you to be a bit more frugal with your use of public IPv4 addresses and to think about accelerating your adoption of IPv6 as a modernization and conservation measure." Charges will apply to all AWS services across all regions, regardless of if the address is attached to a service or not. Some of these services include:
- EC2
- Relational Database Service (RDS) database instances
- Elastic Kubernetes Service (EKS) nodes
- ECS Fargate tasks configured with public IPs
- Global Accelerator IPs
- Site-to-site VPN IPs
- RDS
- Managed NAT Gateways
Owned IPs in AWS BYOIP feature are not impacted by this change. Along with AWS free tier for EC2 which will include 750 hours (1 IP address) of public IPv4 address usage per month for the first 12 months, starting from the same date the charges do.
The cost changes may appear inconsequential at first glance however it means a significant base price increase for many of these services. For example, more than 50% for public Elastic Load Balancer configurations. Managed NAT Gateways as another example will see a increase of ~10%. Which should also serve as a reminder that intentionally configuring public IPv4 on EC2 instances and Fargate tasks just to avoid Managed NAT Gateway is in fact cheaper up until approximately ten public IPv4 addresses per availability zone.
How to check if you will be affected?
Usage
Alongside the blog post AWS also announced a new feature of Amazon VPC IP Address Manager called Public IP Insights (no charge). This feature will make it easier to monitor and audit your usage of public IPv4 addresses with multiple filtering options.
Billing
There’s a couple different ways to get insights on billing as usage is already be accounted for but listed as $0 until February 2024.
- Billing Dashboard > Bills - usage can be found as PublicIPv4:InUseAddress under the Virtual Private Cloud section
- View your usage usage (hours) in the billing dashboard.
- Cost Explorer - filter to include PublicIPv4:InUseAddress. This is nice because Cost Explorer shows usage per day/hour and it’s easy to group e.g. by member account.
- Select “PublicIPv4:InUseAddress (Hrs)” for the “Usage types filter
What should you do to identify and reduce usage
Identify
A free tool you can use to help identify your usage of IPv4 is Overmind’s Explore feature. After configuring a read-only managed AWS source * local-sources coming soon, you are able to explore all the resources in that account and their relationships. If you have multiple accounts then simply add multiple sources and you can view resources across all of them in one place.
As we are specifically interested in IPv4 usage we can start by running a LIST all query for type EC2-Address.
From here we can double click the items and expand the link depth to find related items easily. For example any related subnets, VPC’s and NAT gateways along with any meta data including tags.
For things like NAT gateways it may not be immediately obvious how they are related to IPv4 addresses if you were to just look in the AWS console. Using Overmind makes it easier to understand these relationships and help you to make decisions on the engineering effort that may be required to reduce your usage of IPv4.
Reducing Usage
With IPv6 addresses being free of charge then it might be time to start thinking about how to adopt them. You can go down one of two paths:
- Dual-stack - configuring IPv4 and IPv6 addresses on all systems.
- IPv6-only internally - IPv4 connectivity when facing the general public. Examples include in the edge, or CDNs taking care of serving IPv4 clients.
In terms of popularity, in recent times it’s become more well known that running and maintaining dual-stack can be overly complex. Therefore, consensus has shifted to migrating to IPv6-only deployments, eliminating the added complexity, cost, and security risks associated with running two network protocols.
IPv6 Support
Before you go changing all your systems to IPv6 only it is worth reading up on the current state of support. DuckBillGroup has compiled an excellent list highlighting IPv6 gaps across AWS's service offerings.
With over 90% of all service API endpoints not supporting IPv6 the reality means for some applications it would be impossible to run IPv6-only. When configuring core services like API Gateway, Lambda, ECS or App Runner into IPv6-only subnets you’ll son run it error messages like the one below.
An issue that can not even be remediated by running dual-stack. When configured to use dual-stack, you’ll find most of these services will ignore the subnet has IPv6 configured subnet and instead connect to IPv4 only. Even using the AWS recommended way of Systems Manager to configure and manage instances will not work.
Overmind supports showing you the risks when changing or updating the config of a EC2 address, NAT Gateway or changing to support IPv6. It does this by parsing the output of your Terraform Plan and combining that with your current application config to generate a blast radius. From this it then generates a human-readable set of risks about your change that can be viewed in the app or commented back as part of your CI /CD run. From this you are then able to make any further changes or continue with your apply.
In this example, Overmind detected that attempts were made to change the config to support IPv6 however there were some high and medium risk considerations. For examples although a DNS record had been changed to support IPv6, other parts of the infrastructure including the ECS service and ELB may not be fully support.
There’s not one single solution which means changing all systems to IPv6 in its current state is not possible meaning you should expect at least some costs when these changes go live on February 1st 2024. The impact of these change will depend heavily on the type of user. For businesses operating at scale, this IPv4 charge is another drop in the ocean and one that a team would find difficult to prioritise giving other potential cost savings elsewhere. On the the other hand for many smaller businesses, startups and individual users, this charge can quite easily amount to anything as much as a quarter of their monthly bills. These customers would definitely want to try figure out what their usage looks like and start adopting IPv6 before the cost is introduced early next year.
