AWS Elastic IP Pricing: The Small IPv4 Charge That Multiplies

AWS charges for public IPv4 addresses, including Elastic IPs whether attached or idle, so the cost is small per hour but meaningful across accounts and environments.

The official rate is the source of truth and can vary by service or program. The practical FinOps task is inventorying every address, multiplying by hours, and deciding which workloads truly need stable public IPv4.

Table of contents

• How the charge works
• Calculate the real monthly total
• Find and remove idle allocation
• Reduce public IPv4 dependence
• Build a monthly IPv4 review
• How this fits the rest of the stack
• FAQ

How the charge works

AWS documentation states that public IPv4 addresses are billed hourly, with the widely published baseline of 0.005 USD per address-hour introduced in 2024. At roughly 730 hours in a month, one address is about 3.65 USD before taxes or regional differences. Ten addresses are 36.50 USD; one hundred are 365 USD. Verify the current VPC pricing page before approving a budget because cloud prices and free-tier allowances can change.

An Elastic IP is a stable public address you allocate to an account and associate with supported resources. The charge applies while it is allocated, not only when traffic passes through it. Releasing an unused address stops future address-hour charges but also gives up that address.

Calculate the real monthly total

Count Elastic IPs, auto-assigned public IPv4 addresses, load balancer addresses, NAT gateway addresses, and other billed public IPv4 usage. Do not look at the Elastic IP console alone and assume it represents the estate. Use billing reports and Public IP Insights to reconcile inventory with charges.

monthly estimate = address count × hourly rate × hours
20 addresses × $0.005 × 730 = $73.00 per month

The IPv4 line may be smaller than NAT processing or data transfer, but it is predictable waste when addresses are idle. Tagging account, environment, service owner, and expiry date makes that waste actionable.

Find and remove idle allocation

List allocations in every region and account, then classify attached, unattached, reserved for recovery, or unknown. Confirm with the service owner before release; DNS, partner allowlists, firewall rules, and certificates may depend on a stable address even when no instance is currently attached.

Automate alerts for unattached addresses and temporary environments past their expiry date. A delete button is not a governance strategy. The durable control is a request path that records why a stable address exists and who owns the dependency.

Reduce public IPv4 dependence

Place private workloads on private addresses, expose shared entry points instead of every instance, and adopt IPv6 where clients and dependencies support it. A load balancer can consolidate ingress, but it has its own fixed and usage costs. NAT gateways allow private outbound access yet can cost far more than the address itself. Compare the complete architecture rather than optimizing one line in isolation.

A stable public address is justified for protocols or partner rules that require it. The goal is not zero IPv4 at any cost; it is deliberate IPv4 with known owners and no forgotten allocations.

Build a monthly IPv4 review

1. Export address inventory across accounts and regions
2. Reconcile it to billing usage
3. Flag unattached and untagged allocations
4. Validate external dependencies with owners
5. Release confirmed waste
6. Model load balancer, NAT, proxy, and IPv6 alternatives
7. Track address count and cost as a trend

Review the official rate alongside the report. This article uses current public documentation as of July 2026, but a cost control must retrieve live pricing rather than preserve one number forever.

Include address cost in architectural reviews and internal showback, not merely in a quarterly cleanup. A per-team dashboard turns anonymous IPv4 usage into an owned decision. Budget alerts should watch both dollars and address count because a falling rate or credit can temporarily hide growing dependence that returns later.

How this fits the rest of the stack

Public IPv4 is one line in a larger deployment bill. The RunxBuild hosting calculator lets you model compute, database, storage, and bandwidth together, while the RunxBuild dashboard keeps the deployed service visible.

Useful related references:

• GCP vs AWS: Pricing, Network, and When to Pick Each
• AWS vs GCP: Pricing, Network, and When to Pick Each
• Google Cloud vs AWS: Pricing, Networking, and When to Pick Each
• Services on RunxBuild

FAQ

Are attached Elastic IP addresses charged?

Yes. AWS charges for public IPv4 addresses whether the Elastic IP is attached or idle, subject to current pricing and allowances.

What does one address cost per month?

At 0.005 USD per hour and 730 hours, the estimate is 3.65 USD. Verify the live AWS pricing page.

Does releasing an Elastic IP stop charges?

It stops future allocation charges, but you lose the address and must first remove DNS, allowlist, and service dependencies.

Are NAT gateways a cheaper alternative?

Not automatically. NAT gateways add hourly and data-processing costs. Compare the complete architecture.

How do I find all public IPv4 usage?

Use Public IP Insights, regional inventory APIs, and billing reports across every account, not only the Elastic IP console.