Skip to content

AWS Updated 2026-07-04

Elastic IPs on AWS: when you actually need one, the limits, and the idle charges

When an Elastic IP is the right tool on EC2, when DNS or an NLB does the job better, the five-per-Region quota, and how the public IPv4 charge changed the cost math.

You need an Elastic IP when something outside your control is pinned to a literal IPv4 address: a partner’s firewall allowlist, a mail server’s reverse DNS, a legacy client that cannot follow DNS changes, or a self-managed NAT instance. For almost everything else — web apps, APIs, anything behind a load balancer — DNS pointing at a load balancer is the better answer, and the EIP is just a cost and a quota slot. Since AWS began charging for every public IPv4 address, the old habit of “grab an EIP just in case” has a monthly price tag whether the address is attached or not.

What you are deciding

An Elastic IP (EIP) is a static public IPv4 address you allocate to your account in one Region and associate with an instance or network interface. Its one superpower: it survives instance stop/start and can be remapped to a replacement instance in seconds, so the world keeps reaching the same address while the machine behind it changes. Compare that to the default auto-assigned public IP, which is released every time the instance stops.

The real decision is: does anything depend on the address itself, or only on reaching the service?

  • Address itself matters → EIP territory: IP allowlists at customers or partners, SMTP servers needing stable rDNS (AWS will set reverse DNS on an EIP on request), SFTP endpoints baked into someone’s scripts, licensing tied to an IP, a NAT instance.
  • Only reachability matters → use DNS. Point a record at an ALB or NLB and let AWS manage the addresses. If clients need static IPs and you need load balancing, an NLB gives you one static IP per AZ — and you can attach your own EIPs to it, a pattern covered in static IPs with a Network Load Balancer.

Two constraints shape the decision. Quota: the default is five EIPs per Region per account. It is raiseable through Service Quotas, but the low default is deliberate — IPv4 is scarce, and architectures that need dozens of EIPs usually needed a load balancer instead. Cost: since February 2024, AWS charges hourly for every public IPv4 address — attached, idle, EIP or auto-assigned. The old rule (“attached EIPs are free, idle ones cost”) is gone; now every public IPv4 is a small metered line item, and an idle EIP is pure waste. Model your address count in the AWS pricing calculator if you hold more than a handful.

What to check first

  • How many EIPs does the account hold, and how many are associated? Unassociated ones are paying rent for nothing.
  • What actually references each EIP? DNS records, partner allowlists, rDNS entries. An EIP nothing references is releasable.
  • Are any instances relying on auto-assigned public IPs for something stable? That address disappears on stop — a latent incident.
  • Is an EIP standing in for a missing load balancer? One instance, one EIP, production traffic: that is a single point of failure with a static address.
  • Could the endpoint be IPv6 or private? Dual-stack or an internal-only design removes the IPv4 charge entirely.

How to verify

Inventory all EIPs and whether they are attached:

aws ec2 describe-addresses \
  --query 'Addresses[].[PublicIp,AllocationId,AssociationId,InstanceId,NetworkInterfaceId]' \
  --output table

Rows with an empty AssociationId are idle — billed, unused. Check your current quota and usage:

aws service-quotas get-service-quota \
  --service-code ec2 --quota-code L-0263D0A3

In the console: EC2 > Network & Security > Elastic IPs lists every address with its association state; Billing and Cost Management > Bills shows the public IPv4 charges under the VPC section (they bill through Amazon VPC, not EC2 — a regular source of “what is this line item” questions). Cost Explorer filtered to usage type containing PublicIPv4 shows the trend.

The approach

  1. Write down the dependency for every EIP you keep. “Partner X allowlists this IP, ticket #123.” An EIP with no written dependency is a release candidate.

  2. Release idle EIPs after confirming nothing references them (check DNS zones and partner docs first — reclaiming a released address later is not guaranteed):

    aws ec2 release-address --allocation-id eipalloc-0123456789abcdef0

  3. Move web-facing workloads behind a load balancer with DNS, then release the instance EIPs. The ALB’s addresses change; your CNAME does not care.

  4. Where partners demand static IPs at scale, use an NLB with EIPs attached — you get static addresses plus health-checked failover instead of one pinned box.

  5. For outbound-only static IP requirements (a partner allowlists your egress), a NAT gateway’s EIP covers the whole subnet — one address for the fleet instead of one per instance.

  6. Request a quota raise only with the dependency list in hand. If the list is short, you did not need the raise; if it is long, revisit the architecture before filing.

When this is the wrong move

Do not build new dependencies on IPv4 addresses if you can avoid it — every allowlist entry you hand a partner is future migration friction. Do not use an EIP as a high-availability strategy by planning to re-associate it manually during incidents; that is a human-speed failover for a machine-speed problem, and a load balancer or DNS failover does it better. And inside a VPC, never use an EIP for instance-to-instance traffic: private IPs are free, faster, and traffic hairpinning out through a public address costs data transfer for nothing.

Common mistakes

  • Relying on an auto-assigned public IP and discovering after a stop/start that the address changed and the DNS record, firewall rule, or webhook registration broke.
  • Holding “spare” EIPs since 2021 — they now bill hourly, and the reason anyone kept them (scarcity on reallocation) rarely justifies the standing cost.
  • Forgetting EIPs are Regional. You cannot move one to another Region; a Region migration means new addresses and a partner-notification exercise.
  • Attaching an EIP to fix “my IP changes” on a dev box that only ever needed a DNS record or Session Manager access.

Keeping it under control

  • A monthly scripted check for unassociated EIPs, wired to a ticket rather than a silent report.
  • Tag every EIP with owner and dependency so the release decision never requires archaeology.
  • Watch the public IPv4 usage types in Cost Explorer — the charge scales with address count and catches sprawl early.
  • Prefer dual-stack (IPv6) endpoints for new services where clients support it; IPv6 addresses carry no hourly charge.
  • Route new “we need your IP” partner requests toward NAT gateway or NLB addresses, not per-instance EIPs.

The pattern to internalize: EIPs are for commitments to the outside world, not for convenience inside it — keep few, document each, and let DNS and load balancers do the rest. If nobody on your team truly owns the AWS environment end to end, that is the root of most of these problems — Stack Harbor runs AWS accounts daily under AWS Operations, and you can book an AWS review.