Stopping Charges for Elastic IPs: When to Disassociate and Release

If you stopped your EC2 instance and are still seeing Elastic IP charges, understanding the AWS public IPv4 billing model introduced in February 2024 is essential to stop the hourly fee.

TL;DR: Elastic IP Charges After Stopping an EC2 Instance

EIP State Billed? Action Required
Associated with a running instance Yes — ~$0.005/hr per public IPv4 None (expected cost)
Associated with a stopped instance Yes — ~$0.005/hr per public IPv4 Disassociate + Release if not needed
Allocated but unassociated Yes — ~$0.005/hr per public IPv4 Release immediately if not needed
Released (returned to AWS pool) No Done — no further charges

Rates shown are approximate. Always verify current pricing on the EC2 On-Demand Pricing page for your region, as rates and exceptions may vary.

Why Elastic IP Charges Persist After Stopping an Instance

Stopping an EC2 instance does not release its associated Elastic IP. The EIP allocation remains in your account, and as of February 1, 2024, AWS charges for all allocated public IPv4 addresses — regardless of whether the associated instance is running, stopped, or whether the address is unassociated. This is a fundamental shift from the previous model, where only unassociated EIPs incurred a fee.

The practical implication: stopping an instance no longer eliminates the IPv4 address cost. You must explicitly release the EIP to stop charges.

Analogy: An Elastic IP is like a reserved parking spot with a monthly fee. Parking your car elsewhere (stopping the instance) doesn't cancel the reservation fee — you must formally give up the spot (release the EIP) to stop paying.

Understanding the February 2024 Public IPv4 Pricing Change

Before February 1, 2024, AWS only charged for Elastic IPs that were allocated but not associated with a running resource. After that date, AWS extended the public IPv4 charge to cover all in-use public IPv4 addresses in EC2, including those associated with running instances. The charge applies to Elastic IP addresses allocated to your account. For the precise scope of which resource types and contexts are covered — including any regional exceptions — consult the official EC2 pricing page and the AWS announcement blog post.

Pricing and billing scope can change. Any concrete rate cited in this post should be treated as a reference point, not a guarantee — always confirm with current AWS documentation before making cost decisions.

EIP Lifecycle and Billing State Diagram

stateDiagram-v2 [*] --> Allocated_Associated_Running : allocate-address + associate-address Allocated_Associated_Running --> Allocated_Associated_Stopped : Stop EC2 instance Allocated_Associated_Stopped --> Allocated_Associated_Running : Start EC2 instance Allocated_Associated_Running --> Allocated_Unassociated : disassociate-address Allocated_Associated_Stopped --> Allocated_Unassociated : disassociate-address Allocated_Unassociated --> Allocated_Associated_Running : associate-address Allocated_Unassociated --> Released : release-address Allocated_Associated_Running --> Released : release-address Released --> [*] Allocated_Associated_Running : Allocated + Associated (Instance Running) 💲 Billed Allocated_Associated_Stopped : Allocated + Associated (Instance Stopped) 💲 Billed Allocated_Unassociated : Allocated + Unassociated 💲 Billed Released : Released ✅ No Charge
  1. Allocated & Associated (Running): The EIP is attached to a running instance. Public IPv4 charges apply.
  2. Allocated & Associated (Stopped): The instance is stopped but the EIP remains attached. Public IPv4 charges continue — this is the state most engineers overlook.
  3. Allocated & Unassociated: The EIP has been disassociated but not released. Charges continue.
  4. Released: The EIP is returned to the AWS pool. Charges stop. The IP address is no longer yours.

How to Stop Elastic IP Charges: Disassociate and Release

To eliminate the public IPv4 charge, you must release the EIP. Disassociation alone is not sufficient — a disassociated but still-allocated EIP continues to accrue charges. The recommended workflow is to disassociate first (for clarity and to avoid disrupting any running resource), then release.

Note: The release-address API can be called on an associated EIP directly in some cases, but disassociating first is the safer, more explicit operational practice and avoids ambiguity about which resource loses connectivity.

Step 1: Identify Your Elastic IP Allocations

— Why this step: you need both the AllocationId (eipalloc-*) and the AssociationId (eipassoc-*) — they are different identifiers serving different API calls, and confusing them is the most common CLI error in this workflow.

aws ec2 describe-addresses \
  --query 'Addresses[*].{AllocationId:AllocationId,AssociationId:AssociationId,PublicIp:PublicIp,InstanceId:InstanceId}' \
  --output table

Key fields to note from the output:

  • AllocationId (eipalloc-*): identifies the EIP allocation in your account. Used with release-address.
  • AssociationId (eipassoc-*): identifies the association between the EIP and a specific network interface or instance. Used with disassociate-address.
  • InstanceId: if populated, the EIP is currently associated with that instance.

Step 2: Disassociate the Elastic IP

— Why this step: disassociation removes the EIP from the instance or network interface, making the subsequent release unambiguous and preventing accidental connectivity loss on a running resource.

aws ec2 disassociate-address \
  --association-id eipassoc-0123456789abcdef0

Replace eipassoc-0123456789abcdef0 with the AssociationId from Step 1. If the EIP is already unassociated (no AssociationId in the output), skip this step and proceed directly to release.

Step 3: Release the Elastic IP

— Why this step: release is the only action that stops billing — disassociation alone leaves the allocation active in your account and charges continue.

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

Replace eipalloc-0123456789abcdef0 with the AllocationId from Step 1. After a successful release, the public IP address is returned to the AWS pool and is no longer associated with your account. Charges stop from that point forward.

In general, allocated public IPv4 addresses are billed per hour from the moment of allocation until release; check the EC2 pricing page for current regional rates and any exceptions.

Step 4: Verify No Remaining Allocations

— Why this step: accounts accumulate forgotten EIP allocations over time — especially in multi-region environments — and a single describe call confirms your billing exposure is eliminated.

aws ec2 describe-addresses \
  --query 'Addresses[*].{AllocationId:AllocationId,PublicIp:PublicIp,InstanceId:InstanceId}' \
  --output table

An empty result set confirms no EIPs remain allocated in the current region. Repeat this check in every region where you operate — EIP allocations are regional resources.

Diagnosing Unexpected Elastic IP Charges: A Decision Flow

flowchart TD A["Start: Unexpected EC2 charges"] --> B["Run describe-addresses in all regions"] B --> C{"Any EIPs allocated?"} C -- No --> D["Check other EC2 cost drivers"] C -- Yes --> E{"EIP associated with instance?"} E -- No --> F["Unassociated EIP 💲 Billed — release immediately"] E -- Yes --> G{"Instance state?"} G -- Running --> H["Expected charge under Feb 2024 pricing"] G -- Stopped --> I["EIP on stopped instance 💲 Still billed"] I --> J{"EIP needed for future restart?"} J -- No --> K["Disassociate then Release"] J -- Yes --> L["Retain EIP and accept cost, or plan IPv6 migration"] F --> K K --> M["Verify with describe-addresses — empty = no charges"]
  1. Start by running describe-addresses to enumerate all allocations.
  2. If allocations exist, check whether each is associated with a running or stopped instance.
  3. If the instance is stopped and the EIP is no longer needed, proceed to disassociate and release.
  4. If the EIP is needed for a future restart, consider whether the cost of retaining it is justified versus re-allocating when needed.

The most expensive mistake is assuming that stopping an instance stops all associated resource charges.

IAM Permissions Required

To perform disassociation and release operations, the executing IAM principal needs the following minimum permissions. Note that ec2:DescribeAddresses does not support resource-level restrictions and requires "Resource": "*".

🔽 Click to expand — Minimum IAM policy for EIP management 
{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Sid": "DescribeEIPs",
      "Effect": "Allow",
      "Action": "ec2:DescribeAddresses",
      "Resource": "*"
    },
    {
      "Sid": "DisassociateAndReleaseEIPs",
      "Effect": "Allow",
      "Action": [
        "ec2:DisassociateAddress",
        "ec2:ReleaseAddress"
      ],
      "Resource": "*"
    }
  ]
}

Scope these permissions to specific teams or automation roles responsible for lifecycle management. Avoid granting ec2:ReleaseAddress broadly — an accidental release of an in-use EIP causes immediate connectivity loss for any resource depending on that IP.

Production Gotcha: The Stopped-Instance Billing Blind Spot

Symptom: EC2 costs drop after stopping instances, but the bill still shows unexpected EC2 charges. Misdiagnosis: Engineers check running instance hours and Reserved Instance coverage, assuming the charge is a compute cost. Actual cause: Elastic IPs associated with stopped instances now accrue public IPv4 charges under the February 2024 pricing model — a line item that appears under EC2 but is not a compute charge. Check Cost Explorer filtered by usage type containing ElasticIP or PublicIPv4 to isolate these charges.

The billing line item changed — the instance state did not.

Automating EIP Cleanup to Prevent Recurring Charges

In practice, teams operating at scale benefit from a scheduled audit of unassociated or stopped-instance-associated EIPs. A simple approach is a CloudWatch Events (EventBridge) scheduled rule triggering a Lambda function that calls describe-addresses and alerts — or automatically releases — EIPs meeting defined criteria.

Before automating releases, ensure your workflow accounts for EIPs intentionally retained for future use (e.g., whitelisted in partner firewalls). Automated release of a whitelisted IP requires re-coordination with external parties and cannot be undone — the released IP returns to the AWS pool and may be reassigned to another customer.

Stopping Elastic IP Charges: Summary and Next Steps

Releasing an Elastic IP is the only action that stops public IPv4 billing. Stopping an EC2 instance, disassociating an EIP, or both — without releasing — leaves the allocation active and billable. The February 2024 AWS pricing change made this more consequential because the charge now applies even when the EIP is associated with a running instance, not just idle allocations.

Recommended next steps:

  • Run aws ec2 describe-addresses across all active regions to audit current allocations.
  • Review EC2 On-Demand Pricing for current public IPv4 rates and regional exceptions.
  • Read the AWS announcement: New – AWS Public IPv4 Address Charge for the full scope of the billing change.
  • Consider IPv6 adoption for new workloads where external connectivity requirements permit — IPv6 addresses do not incur the public IPv4 charge.

Glossary

Term Definition
Elastic IP (EIP) A static public IPv4 address allocated to your AWS account, designed for dynamic cloud computing. Persists independently of instance lifecycle.
AllocationId The identifier (eipalloc-*) representing an EIP allocation in your account. Used with release-address.
AssociationId The identifier (eipassoc-*) representing the binding between an EIP and a specific network interface or instance. Used with disassociate-address.
Disassociate The act of detaching an EIP from a network interface or instance. The EIP remains allocated (and billable) until released.
Release The act of returning an EIP to the AWS public IP pool. This is the only operation that stops public IPv4 billing for that address.

Related Posts

Comments

Post a Comment

Popular posts from this blog

EC2 No Internet Access in Custom VPC: Fix Internet Gateway and Route Table

EC2 no internet access in a custom VPC is one of the most common launch-day failures — the instance is running, but outbound connectivity is completely silent. TL;DR: EC2 No Internet Access — Fix Checklist Step What to Do Why It Matters Complexity 1 Create and attach an Internet Gateway to the VPC Without an IGW, the VPC has no path to the public internet Low 2 Add a default route (0.0.0.0/0) pointing to the IGW in the subnet's route table The IGW exists but traffic has no route to reach it Low 3 Assign a public IP or Elastic IP to the instance Private IPs are not routable on the public internet Low 4 Verify Security Group allows outbound traffic A restrictive outbound rule silently drops all egress Low 5 Verify Network ...
Read more

EC2 SSH Connection Timeout: Which Security Group Rules to Check

An EC2 SSH connection timeout is one of the most common blockers when launching a new instance — the fix is almost always a missing or misconfigured inbound rule in your Security Group. TL;DR — Diagnostic Steps at a Glance Step What to Check Common Fix 1 Security Group inbound rules Add SSH (TCP 22) from your IP 2 Subnet route table Ensure 0.0.0.0/0 routes to an Internet Gateway 3 Network ACL rules Allow inbound TCP 22 and ephemeral return ports 4 Instance public IP / Elastic IP Confirm a public IP is assigned 5 Key pair and SSH username Use correct private key and AMI-specific username Why SSH Times Out Instead of Refusing A connection refused error means the TCP handshake reached the host but nothing is listening. A connection timed out error means packets never arrived — or replies never returned. On EC2, that silence is almost always a network-layer block, not an OS-level problem. The Se...
Read more

Difference Between IAM User and IAM Role: Which One Should Your EC2 Use?

Understanding the difference between IAM User and IAM Role is critical — choosing wrong means either hardcoded credentials in your app or a silent security exposure you won't catch until an audit. TL;DR: IAM User vs IAM Role at a Glance Dimension IAM User IAM Role Identity type Permanent, named human or service identity Assumable identity with temporary credentials Credential type Long-lived access keys or password Short-lived STS tokens (auto-rotated) Attached to EC2? No native attachment — keys must be embedded Yes — via Instance Profile, injected automatically Rotation required? Manual — your responsibility Automatic — AWS STS handles it Recommended for EC2 → S3? No Yes — always Cross-account access Requires separate user per account Native — assume role across accounts Audit trail Tied to user identity Tied to role + session name in CloudTrail What IAM User and IAM Role Actual...
Read more