Elastic IPs
Elastic IPs provide a stable, portable public identity for your cloud resources — enabling high availability, seamless failover, and production-grade networking in WiLine Edge Cloud (WEC).
What is an Elastic IP?
An Elastic IP (EIP) is a static, public IPv4 address that is allocated to your account and remains yours until you explicitly choose to release it.
To understand why this matters, consider how standard public IP addresses behave in most cloud environments. When you launch a virtual machine instance, it typically receives a public IP address automatically. However, that address is ephemeral—it is borrowed from a shared pool and tied directly to the lifecycle of that specific instance.
This creates a fundamental problem: if you stop the instance, restart it, or if it fails and is replaced, you receive a completely different public IP address.
An Elastic IP solves this by decoupling the address from the resource. The IP belongs to your account, not to any particular instance. This means:
- The address does not change over time
- It can be reassigned instantly from one resource to another
- It provides a consistent external endpoint for your services
A Concrete Analogy
Imagine you operate a business. A standard public IP is like renting a P.O. box at the post office where the box number changes every time you renew your lease. Your customers, suppliers, and partners constantly need to update their records just to reach you.
An Elastic IP is like owning the deed to a specific street address. You own it. It is recorded in your name. If you tear down the building and construct a new one, the address—123 Main Street—remains unchanged. Anyone trying to reach you simply goes to 123 Main Street, regardless of what structure currently occupies that land.
In cloud computing terms, this means you can destroy a failing virtual machine, launch a brand new one, and attach the exact same Elastic IP to it. To the outside world, nothing has changed—your service simply continues operating at the same address.
Why Elastic IPs Matter
Core capabilities
Deeper Explanation of Each Capability
Stable Public Endpoint: Consider a web application that serves customers globally. If your IP address changes, those customers may experience downtime while DNS records propagate—a process that can take anywhere from minutes to 48 hours depending on configuration. With an Elastic IP, your DNS A record points to a fixed address that never changes, eliminating this entire class of failure.
Instant Failover: Traditional disaster recovery often requires updating DNS records and waiting for propagation. With an Elastic IP, failover becomes a programmatic operation. You detect a failure, call the API to reassign the Elastic IP to a standby instance, and traffic begins flowing to the new resource within seconds—not hours.
Flexible Infrastructure: Many enterprise environments rely on IP-based security controls. Firewall rules, VPN configurations, and third-party service integrations (payment gateways, SaaS platforms) often require allowlisting specific IP addresses. Without Elastic IPs, every infrastructure change would require coordinating with multiple external teams to update these allowlists—a process fraught with delays and human error.
Production Reliability: For systems that serve critical business functions, the ability to maintain a consistent network identity is not optional—it is essential. Elastic IPs provide the foundation for building resilient, production-worthy cloud architectures.
How Elastic IPs Work
The fundamental mechanism behind Elastic IPs is the separation of address ownership from resource lifecycle.
Instead of an IP address being generated and destroyed along with a compute instance, Elastic IPs follow a four-stage lifecycle:
- Allocation: You request an Elastic IP from the regional pool. The address becomes associated with your account. You own it.
- Association: You attach the Elastic IP to a specific resource, such as a virtual machine instance. Traffic to that IP is routed to the associated resource.
- Reassignment: If needed, you detach the Elastic IP from one resource and attach it to another. This operation typically completes in seconds.
- Release: When you no longer need the address, you explicitly release it back to the regional pool.
Important Technical Nuance
When you associate an Elastic IP with an instance, the instance's original public IP address (if it had one) is released back to the pool. The instance now uses the Elastic IP as its sole public-facing address. The private IP address of the instance remains unchanged—only the public-facing mapping is modified.
When to Use Elastic IPs
Elastic IPs are the correct architectural choice when your workload exhibits one or more of the following requirements:
- Hosting public APIs or web services where clients connect directly to an IP address or where DNS changes would cause unacceptable downtime
- Configuring IP-based allowlists for firewalls, database access controls, or third-party SaaS integrations that require fixed source IPs
- Running VPN endpoints or secure tunnels that depend on stable endpoint addresses for tunnel establishment
- Implementing active-passive failover strategies where traffic must be rapidly redirected to standby infrastructure
- Maintaining consistent DNS mappings for legacy systems or applications that do not handle DNS changes gracefully
Real-World Example: API Gateway
Imagine you operate an API gateway that processes payments for an e-commerce platform. The payment processor requires you to register your outbound IP address for security allowlisting. Without an Elastic IP, every infrastructure change would require a support ticket with the payment processor, a manual review process, and potentially hours or days of downtime while the change is approved.
With an Elastic IP, you register the address once. It remains valid indefinitely. You can upgrade servers, replace failed hardware, or migrate between availability zones—the payment processor never knows anything changed.
When NOT to Use Elastic IPs
Elastic IPs are powerful tools, but they are not universally appropriate. Understanding when to avoid them demonstrates mature architectural thinking.
Avoid Elastic IPs when:
- You can rely on DNS-based routing: Modern architectures often use load balancers with DNS names. Clients connect to
api.example.comrather than an IP address. As long as the DNS record points to the correct load balancer, the underlying IP addresses can change freely. - You use cloud load balancers as your entry point: Load balancers themselves provide stable endpoints (typically through DNS names). Placing Elastic IPs behind or in front of load balancers often creates unnecessary complexity.
- The service does not require a fixed public endpoint: Internal services, batch processing jobs, or ephemeral development environments rarely benefit from static IP addresses.
- You are designing for horizontal scalability: Elastic IPs are a one-to-one mapping. They do not scale horizontally. If you need to distribute traffic across dozens or hundreds of instances, a load balancer with a DNS name is the correct solution.
Cost and Conservation Considerations
IPv4 addresses are a finite, globally scarce resource. Cloud providers typically charge a small hourly fee for Elastic IPs that are allocated but not associated with a running resource. This pricing model encourages efficient use:
- Associated with a running instance: No additional charge (beyond standard data transfer)
- Allocated but unattached: Small hourly charge applies
- Released: No charge
This structure incentivizes releasing unused addresses rather than hoarding them.
Key Characteristics Summary
| Characteristic | Description |
|---|---|
| Static | The address does not change unless you explicitly release it |
| Portable | Can be reassigned across different resources within the same region |
| Public | Routable on the public internet; accessible from anywhere |
| Account-bound | Persists independently of any specific instance or service |
| Region-scoped | Tied to a specific cloud region; cannot be moved between regions |
Best Practices
Adhering to established best practices ensures you derive maximum value from Elastic IPs while avoiding common pitfalls.
Use Only When Stability Is Required
The default should be to rely on DNS and load balancers. Reserve Elastic IPs for workloads that demonstrably require static addressing.
Release Unused Addresses Promptly
Monitor your allocated Elastic IPs. If an address sits unattached for an extended period, release it. You can always allocate a new one later if needed. This avoids unnecessary charges and conserves IPv4 space.
Combine with Firewall Rules and VPC Isolation
A static public IP address is an attack surface. Always protect instances behind Elastic IPs with appropriate security groups, network ACLs, and—where possible—placement within private subnets with controlled egress.
Prefer DNS and Load Balancing for Scalable Architectures
For horizontally scaled applications serving significant traffic, place a load balancer in front of your instances and point DNS at the load balancer. This pattern provides both stability (the load balancer endpoint) and scalability (many backend instances).
Document Your IP Allocations
Maintain a record of which Elastic IPs are assigned to which services and why. This prevents accidental releases and helps during security audits or incident response.
Summary
An Elastic IP is a static, public IPv4 address that belongs to your account rather than to any specific cloud resource. It enables stable external connectivity, rapid failover, and flexible infrastructure management by decoupling your public network identity from the lifecycle of individual instances.
Use Elastic IPs when your workload requires a fixed public address for allowlisting, API stability, or fast disaster recovery. Avoid them when DNS-based routing or load balancers can meet your requirements. Release unused addresses to minimize costs and practice good IPv4 stewardship.
References
This documentation synthesizes information from authoritative industry sources and widely accepted cloud networking principles.
Primary Source:
- Amazon Web Services. "Elastic IP addresses." AWS EC2 User Guide. https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/elastic-ip-addresses-eip.html
Secondary and Educational Sources:
- GeeksforGeeks. "What is AWS Elastic IP Address?" DevOps Tutorials. https://www.geeksforgeeks.org/devops/aws-elastic-ip-addresses/
- How-To Geek. "What Are AWS Elastic IPs, and What Do They Do?" Cloud & Internet. https://www.howtogeek.com/devops/what-are-aws-elastic-ips-and-what-do-they-do/
Industry Context:
- The concepts described here reflect standard practices across major cloud providers, including AWS, Google Cloud (external static IP addresses), and Microsoft Azure (static public IP addresses). While terminology varies, the underlying principles of static, portable public addressing are universal in cloud computing.
Next Step
Ready to work with Elastic IPs in practice?
Allocating and Managing Elastic IPs in WEC — A step-by-step guide to creating, associating, and managing Elastic IPs through the WiLine Edge Cloud interface and API.