An AWS Elastic IP may look like a regular public IP address, but it works differently and can play an important role in how you manage EC2 infrastructure. In this blog we will help you understand how Elastic IPs work, what happens to them during the EC2 instance lifecycle, and when a static IP is useful compared with options such as DNS, load balancers, or private networking.
1. What Is an AWS Elastic IP, and Why Does It Exist?
An Elastic IP (EIP) is a static public IPv4 address that you allocate to your AWS account. You can associate it with an EC2 instance, network interface, or another supported AWS resource when needed.
The main reason to use an Elastic IP is to keep the same public IPv4 address even when the resource behind it changes.
The problem with a changing public IP
When you launch an EC2 instance with a public IPv4 address, AWS can automatically assign one to the instance. That address is not permanent. If you stop the instance and start it again, AWS can assign a different public IPv4 address.
This can cause problems when another system depends on the original address. For example, a customer's firewall may allow traffic from a specific IP, or a partner system may connect directly to your application using that address. When the address changes, those connections may stop working.
An Elastic IP solves this problem by giving you a public IPv4 address that remains allocated to your AWS account. You can keep the same address and associate it with the resource you need.
What does static addressing mean?
A regular EC2 public IPv4 address can change during the instance lifecycle. An Elastic IP is different because you allocate it to your account and keep it until you release it.
You can also disassociate an Elastic IP from one resource and associate it with another when needed.
In simple terms, a regular public IP is assigned to your instance for its current lifecycle. An Elastic IP gives you a fixed public address that you can manage separately from the instance itself.
2. Public IPv4 vs Elastic IP: What's the Difference?
A public IPv4 address and an Elastic IP may look identical in the AWS console because both are shown as IPv4 addresses. The difference is how they are managed and how long they remain available.
| Attribute | Public IPv4 | Elastic IP |
| Persistence | Can change after stop and start | Remains allocated until released |
| Ownership | Automatically assigned by AWS | Allocated to your AWS account |
| Cost | Public IPv4 charges may apply | Public IPv4 charges may apply |
| Control | Managed automatically | You control allocation and association |
| Reuse | Not designed to be moved between instances | Can be disassociated and associated with another resource |
| DNS | Can change when the public IP changes | Remains tied to the same Elastic IP address |
Related concepts to keep in mind
Private IPv4: Used for communication inside your VPC. It is not directly reachable from the internet and normally remains associated with the instance while the instance exists.
Public DNS hostname: AWS can provide a public DNS hostname for an EC2 instance. When the public IPv4 address changes, the hostname can also change.
Stop and start behavior: A regular public IPv4 address can change when an instance is stopped and started again. The private IPv4 address remains, while an Elastic IP remains associated with the resource as long as you keep that association.
3. How an Elastic IP Works With an EC2 Instance
An Elastic IP is not part of the operating system or the EC2 instance itself. It is associated with the instance's Elastic Network Interface (ENI) and provides a public address that maps to a private IPv4 address on that network interface.
This separation is important because the Elastic IP can be managed independently of the instance.
Why the ENI relationship matters
Because the Elastic IP is associated with a network interface, you can move the address between supported resources when required.
For example, you can:
- Associate an Elastic IP with an EC2 instance through its network interface.
- Use a network interface with another EC2 instance and keep the associated Elastic IP.
- Disassociate an Elastic IP from one resource and associate it with another.
This makes Elastic IPs useful when you need to move traffic to another instance without changing the public address used by clients.
4. What Happens When You Stop, Start, Reboot, or Terminate an EC2 Instance?
Understanding the EC2 lifecycle is one of the most important parts of using an Elastic IP.
| Instance action | Without an Elastic IP | With an Elastic IP |
| Stop and start | A new public IPv4 address can be assigned | The Elastic IP remains associated |
| Reboot | The public IPv4 address remains unchanged | The Elastic IP remains associated |
| Terminate | The public IPv4 address is released | The Elastic IP is disassociated but not automatically released |
What happens when the instance is terminated?
Terminating an EC2 instance removes the association between the instance and the Elastic IP. The Elastic IP itself remains allocated to your AWS account.
You can then associate that Elastic IP with another resource or release it when you no longer need it.
The important distinction is that disassociation and release are two different actions. Terminating an instance does not automatically release the Elastic IP.
5. How to Allocate, Associate, Disassociate, and Release an Elastic IP
Elastic IPs have a simple lifecycle with four main actions.
| Action | What it does |
| Allocate | Reserves an Elastic IP for your AWS account |
| Associate | Connects the Elastic IP to a supported resource |
| Disassociate | Removes the Elastic IP from the current resource without releasing it |
| Release | Returns the Elastic IP to AWS and removes it from your account |
The distinction most people get wrong
Disassociating an Elastic IP does not release it.
After you disassociate an Elastic IP, it remains allocated to your AWS account. You can associate it with another resource later. To stop using the address completely, you must release it.
Once an Elastic IP is released, you should not assume that you can get the same address back.
6. Using Elastic IP for High Availability and Failover
An Elastic IP can also be used as part of a simple failover design.
For example, one EC2 instance can normally serve traffic using an Elastic IP. If that instance fails, automation can detect the failure and associate the same Elastic IP with a standby instance.
The basic flow is:
- The primary instance handles traffic using the Elastic IP.
- A health check or monitoring system detects a failure.
- Automation moves the Elastic IP to the standby instance.
- New connections can continue using the same public IP address.
This approach can be useful for older applications or integrations that require a fixed IP address.
However, an Elastic IP by itself does not provide high availability. It does not perform health checks, distribute traffic, or automatically recover a failed application. Modern systems often use load balancers and other AWS services for these responsibilities.
7. When Should You Use an Elastic IP?
An Elastic IP makes sense when the public IPv4 address itself needs to remain stable.
Common use cases include:
- IP allowlisting when a customer, partner, or firewall requires a specific public IP.
- Legacy applications that cannot easily be changed to use a DNS name.
- Administrative or bastion hosts that need a predictable public address.
- Simple failover designs where the same IP must move between resources.
- Integrations that depend on a fixed source or destination IP.
The important question is not whether you can use an Elastic IP. It is whether your system actually needs a fixed public IPv4 address.
8. When Should You Not Use an Elastic IP?
An Elastic IP is not always the best choice for a production architecture.
If clients connect directly to a single EC2 instance through a static IP, that instance can become a single point of failure. It also creates a strong dependency on one specific resource.
For many applications, it is better to expose a DNS name or a load balancer instead.
| Alternative | When it is a better fit |
| Application Load Balancer | HTTP and HTTPS applications running across multiple instances |
| Network Load Balancer | TCP and UDP workloads that need high performance and static IP addresses |
| Route 53 | Applications where clients should connect through a DNS name |
| CloudFront | Applications that benefit from edge delivery and origin protection |
| Private networking | Resources that do not need to be directly reachable from the internet |
An Elastic IP can be a simple solution for a small or specialized workload, but simplicity does not always mean better resilience.
9. Elastic IP Costs, Limits, and Important AWS Considerations
AWS charges for public IPv4 addresses, including Elastic IP addresses. Charges can apply to both addresses that are in use and addresses that remain unused in your account. An Elastic IP is also a regional resource, so it must be used within the AWS Region where it was allocated. AWS also applies a default quota to the number of Elastic IP addresses that can be allocated in a Region, and that quota can be increased when required.
To avoid unnecessary costs and resource management issues, release Elastic IP addresses that are no longer needed. Keeping unused addresses provides little value and can make it harder to track your resources. Since AWS pricing and quotas can change over time, always check the latest AWS documentation before making cost or infrastructure decisions.
10. NAT Gateway and Remote Access Use Cases
Two of the most common practical uses for an Elastic IP go beyond simple instance facing traffic: enabling outbound internet access for private resources, and giving administrators a dependable way to reach instances directly.
NAT Gateway integration
A NAT Gateway lets resources in a private subnet, such as database servers or backend application instances, initiate outbound connections to the internet for tasks like software updates or API calls, without being directly reachable from the internet themselves. A NAT Gateway requires a static public IP address to operate, and this is where an Elastic IP comes in. You allocate an EIP and assign it to the NAT Gateway when you create it.
Because the EIP doesn't change, any external service that logs or filters traffic based on the NAT Gateway's outbound IP, for example a third party API that allowlists your requests, continues to work reliably, even if the private resources behind the NAT Gateway are scaled, replaced, or redeployed.
Remote administration
Administrators often need a consistent way to reach instances directly for tasks like SSH on Linux or RDP on Windows, especially for bastion hosts or jump servers that sit at the edge of a VPC. Without an Elastic IP, the public address of an administrative instance could change after a stop and start, breaking saved SSH configs, bookmarked RDP connections, or any automation scripts that reference the address directly.
Attaching an Elastic IP to a bastion or administrative instance keeps that entry point stable, so operators can rely on the same address across restarts, and any firewall rules or VPN configurations that reference it don't need to be updated.
