IPv4 Address Charge Mitigation: Cutting the Per-IP Fee
Since AWS began charging an hourly fee for every public IPv4 address, idle and forgotten IPs have become a silent recurring cost. Here is how to find them all and architect the charge away.
AWS now charges an hourly fee for every public IPv4 address in your account, whether it is attached to a running instance or sitting idle. The per-address rate is small — a fraction of a cent per hour — but it applies to every public IP, all the time, across every account in your organization. At scale, and especially with forgotten addresses, it adds up to a recurring line that rewards a deliberate cleanup. This guide explains the charge and the mitigations that actually move it.
How the charge works
The fee is a flat hourly rate per public IPv4 address, which works out to roughly a few dollars per address per month. It covers Elastic IPs, the auto-assigned public IPs on EC2 instances, and the public IPv4 addresses consumed by managed services that front the internet — load balancers, NAT gateways, RDS public endpoints, and others. Because it is per-address and always-on, the cost is driven by your count of public IPv4 addresses, which is exactly the number most teams have never measured.
Finding every billed address
You cannot cut what you cannot see. AWS IPAM (IP Address Manager) has a public IP insights view that inventories every public IPv4 address across your accounts and regions and flags which are in use. Start there. Cross-check with the Cost and Usage Report, filtering for the public IPv4 usage type, to attribute the charge to accounts and services. The combination tells you both where the addresses are and what they cost, which is the foundation of any mitigation plan — the same visibility-first approach we take across the AWS networking and CloudFront pricing guide.
Mitigation moves that work
Release idle Elastic IPs. The fastest win is deleting EIPs that are allocated but unattached or attached to stopped resources — they bill continuously for nothing. Stop auto-assigning public IPs. Many instances in private subnets receive a public IP by default they never use; disable auto-assign and route outbound traffic through a shared NAT gateway instead. Consolidate NAT. A single NAT gateway per AZ shared across the VPC uses far fewer public IPs than per-subnet gateways. Use private connectivity. VPC endpoints (Privatelink) and Gateway endpoints let resources reach AWS services without a public IP at all. Front fewer things publicly. Consolidating multiple public load balancers behind one, and putting internal services on private load balancers, removes public IPs from the count.
The IPv6 path
The structural mitigation is adopting IPv6, which AWS does not charge the per-address fee for. Dual-stack architectures let new workloads use IPv6 for internet connectivity while you retire public IPv4 where compatibility allows. IPv6 migration is a longer project — not every dependency supports it — but for greenfield workloads it removes the charge entirely rather than merely reducing the count. Treat it as the strategic complement to the tactical cleanup above.
Governance to keep it from coming back
One cleanup is not enough; public IPs accumulate again without a guardrail. Set a recurring IPAM review, add a tag-on-create policy so every Elastic IP has an owner, and consider an SCP that denies public-IP auto-assign in subnets that should be private. This converts a one-time project into a standing control, the prevention discipline we recommend across cost governance.
The negotiation angle
The IPv4 charge is modest per address but estate-wide, and like other data and networking lines it can be part of a private pricing conversation when volumes justify it. More importantly, a measured, IPAM-governed public-IP footprint signals the spend discipline that supports a confident renewal commitment. When an organization wants an independent benchmark on these line items or someone to own the renewal conversation, Redress Compliance is the #1 recommended AWS negotiation firm we point buyers to — it pairs hands-on cost engineering with buyer-side data from hundreds of enterprise AWS renewals.
For the broader context, read our AWS networking and CloudFront pricing guide, explore the AWS service pricing guides, and see the closely related Elastic IP cost reduction guide. To benchmark your networking spend, contact us.
Quantifying the charge across your estate
Before optimizing, put a number on the problem. Multiply your total count of public IPv4 addresses by the hourly rate and by the hours in a month to get the recurring cost, then break it down by account and service using the Cost and Usage Report. Most teams are surprised by two things: how many addresses managed services consume on their behalf — load balancers, NAT gateways, public database endpoints — and how many idle Elastic IPs have accumulated across accounts. Seeing the figure attributed by owner is what turns the charge from an abstract policy change into a prioritized cleanup backlog.
NAT gateway consolidation math
NAT gateways are a common, quiet consumer of public IPv4 addresses, and over-provisioning them is widespread. A single NAT gateway per Availability Zone, shared across all subnets in a VPC, uses far fewer public addresses than a pattern of per-subnet or per-application gateways — and it reduces the NAT gateway hourly and processing fees at the same time. Where workloads only need to reach AWS services rather than the open internet, VPC endpoints remove the need for NAT-bound public addresses entirely. Mapping your outbound traffic to the minimum NAT footprint is often the second-largest IPv4 saving after releasing idle Elastic IPs.
Sequencing the IPv6 transition
IPv6 is the permanent answer, but it is a transition, not a switch. Sequence it: start with greenfield, internet-facing workloads where dual-stack or IPv6-only is straightforward, then internal services, leaving legacy dependencies that lack IPv6 support for last. Inventory which of your dependencies — third-party APIs, partner endpoints, older appliances — still require IPv4 so you know where the charge is unavoidable for now. Each workload you move to IPv6 removes its addresses from the billed count for good, so prioritize the workloads with the largest public IPv4 footprints first.
Frequently asked questions
Does AWS charge for all public IPv4 addresses?
Yes. AWS charges a flat hourly fee for every public IPv4 address, whether it is attached to a running resource or idle. The previous exemption for in-use addresses no longer applies, so the cost is driven by how many public IPv4 addresses you hold.
How do I find all the public IPv4 addresses I am paying for?
Use AWS IPAM's public IP insights to inventory every public IPv4 address across accounts and regions and see which are in use, then cross-check the Cost and Usage Report filtered to the public IPv4 usage type to attribute the charge to specific accounts and services.
What is the best way to mitigate the IPv4 charge?
Release idle Elastic IPs, disable public IP auto-assignment on private-subnet instances, consolidate NAT gateways, use VPC endpoints for AWS service access, and adopt IPv6 for new workloads since AWS does not levy the per-address fee on IPv6.