Public IP vs. Elastic IP: Mastering Cloud Connectivity & Persistence

The Transient vs. The Immutable

In the physical world, your home address rarely changes. If you move, you get a new one, but while you are there, it is fixed. In the cloud (Amazon Web Services, Google Cloud, Azure), this assumption is turned on its head. By default, resources are ephemeral — they are born, they do work, and they die. Their identities are just as fleeting.

When you launch a virtual server (like an Amazon EC2 instance), the provider gives you an IP so you can talk to it. But which kind did you get? Is it a Standard Public IP that will vanish the moment you stop the server for maintenance? Or is it an Elastic IP that remains tethered to your account forever? Choosing the wrong one is a classic "Day 1" mistake that can lead to broken DNS records, failing API calls, and frustrated users. In this guide, we will peel back the layers of cloud networking to help you build stable, persistent infrastructure.

The Analogy: Hotel Room vs. Owned Apartment

To understand these two, forget about bits and bytes and think about housing.

The Public IP (The Hotel): You check into a hotel and they give you Room 302. While you are there, anyone can find you at 'Hotel Room 302'. But the moment you check out and go home, Room 302 is given to someone else. If you come back next week, you'll probably get Room 415. Your 'identity' was temporary and tied only to your active stay.
The Elastic IP (The Apartment): You sign a 12-month lease on Apartment 4B. Whether you are currently in the room, sleeping, or away on vacation for a month, that apartment remains 'yours'. You can even move your furniture (your server data) to a larger apartment next door and keep the same 'Apartment 4B' address.

What is a Standard Public IP?

A standard public IP is part of a massive pool of addresses owned by your cloud provider. When you launch a new instance and check the box that says "Enable Public IP," the cloud console grabs the next available number from that generic bucket and hands it to you.

The Lifecycle Problem

The most critical thing to understand about a Public IP is when it is released. In AWS, a public IP is dissociated and returned to the pool if:

The instance is Stopped (not just rebooted).
The instance is Terminated (deleted).
You manually dissociate the IP from the network interface.

If you have an A-Record in your DNS pointing www.yourbrand.com to 54.21.12.9 (a public IP), and your server undergoes a scheduled maintenance 'Stop/Start', your server will come back with a new IP like 34.212.11.4. Your website will be down for everyone until you manually update your DNS and wait for propagation. This is a nightmare for production systems.

What is an Elastic IP (EIP)?

An Elastic IP is a static, IPv4 address designed for dynamic cloud computing. Unlike a standard IP, an EIP is allocated to your account, not just a specific running instance. Once you 'allocate' an EIP, it is yours until you explicitly 'release' it back to the provider.

Total Control and Re-Mapping

The 'Elastic' part of the name comes from its ability to move. Imagine your primary web server crashes. You can quickly launch a backup server from a snapshot and re-map your Elastic IP to the new server in seconds. To the outside world, nothing has changed; the IP address remains identical, so no DNS updates are required.

The 'Anti-Squatting' Cost

Cloud providers want addresses to be used actively because IPv4 addresses are a scarce global resource. To prevent users from 'hoarding' thousands of IPs they aren't using, AWS (and others) have a unique pricing model:

Active EIP: Usually free (or very cheap) as long as it is attached to a running instance.
Idle EIP: You are charged a small hourly fee (e.g., $0.005 per hour) if you have an allocated EIP that is not attached to a running instance.

Always release your Elastic IPs when you are done with a project, or you will see a surprise charge on your monthly bill.

Comparative Breakdown Table

Feature	Standard Public IP	Elastic IP (EIP)
Permanence	Lost on instance 'Stop/Terminate'	Persistent until manually released
Re-mapping	Cannot be moved to another server	Easily moved between servers in seconds
Best Use Case	Testing, small dev environments	Production apps, APIs, Mail servers
Cost	Always free while active	Free while active; Small fee when idle
DNS Impact	Requires frequent DNS A-Record updates	Zero DNS updates required during migration
Assignment	Automatic by provider on boot	Manual allocation by the user

Elastic IPs, ENIs, and how AWS binds addresses

In AWS, a public IPv4 auto-assigned to an instance attaches to an ENI (Elastic Network Interface). Stopping and starting a classic scenario can reassign that auto-public address back to the pool. An Elastic IP is a static reservation you associate to an ENI; the control plane updates Internet ingress/egress so DNS A-records remain stable.

Architecturally, production systems often place an Application Load Balancer or Network Load Balancer in front of instances so application nodes stay in private subnets without 1:1 public NAT. EIPs then attach to ingress tiers or NAT gateways—not every workload VM. DNS TTL still matters: long TTLs amplify outage duration when you must repoint manually.

Advanced Considerations for Engineers

Whitelisting and Security

If your cloud server needs to connect to a corporate database or a third-party API that uses an IP whitelist, you must use an Elastic IP. If your server reboots and gets a new Public IP, the third-party API will reject your connection because your 'new' identity isn't on their list of approved addresses.

Email Deliverability (rDNS)

If you are running a mail server (SMTP), you need a Reverse DNS (PTR) record. Standard Public IPs generally don't allow you to customize rDNS. Elastic IPs allow you (through a support request or console setting) to map your IP back to your domain name, which is essential for passing spam filters.

Zero Downtime Deployment

With Elastic IPs, you can perform Blue/Green deployments. You keep the 'Blue' server running with your live IP. You build the 'Green' server and test it. When ready, you simply 'flip' the EIP to the Green server. If there's a bug, you flip it back. The user never notices a change in IP.

Common Misconceptions

Myth 1: "Public IPs are more private because they change"

While rotation provides a tiny bit of 'obscurity', it is not a security feature. Both IP types leave the same footprints in logs. If you need privacy, use a VPN or a proxy; don't rely on IP rotation.

Myth 2: "Elastic IPs increase my connection speed"

No. Both IPs use the same underlying network fabric provided by the cloud edge. An EIP is a management and routing feature, not a performance upgrade.

Myth 3: "I should put an EIP on every instance"

This is a waste of money and resources. In a properly designed architecture, you only put an EIP on your Load Balancer or NAT Gateway. Your individual app servers should live in a private subnet with no public IP at all, protected from the open web.

Pro Tips for Power Users

Automate with Terraform/Bicep: Never manually allocate EIPs in the console for anything important. Define them in your 'Infrastructure as Code' so that when you destroy and rebuild your stack, your IP persistent settings are preserved.
Tag Your IPs: A common cause of wasted spend is 'Ghost IPs' left over from deleted projects. Always tag your Elastic IPs with the project name so you know what can be safely deleted.
Monitor Association: Set up a CloudWatch alert to notify you if an EIP becomes 'Unassociated'. This usually means a server has crashed and you are now being charged for an idle IP.
Consider BYOIP: If your company already owns a large block of IPv4 addresses, AWS allows you to 'Bring Your Own IP' (BYOIP). You can use your own reputable IPs inside their cloud, which is great for maintaining your existing reputation with email providers.

Mastering the difference between public and elastic identities is the difference between a 'homework project' and a professional, resilient cloud deployment. Check the status of your current IP here.

Usually, it is free if it is attached to a running instance. However, cloud providers charge a small hourly fee if the IP is unattached (idle). This prevents users from hoarding limited IPv4 addresses they aren't actually using.

A 'Reboot' usually keeps the IP. However, a 'Stop' followed by a 'Start' will almost always results in a new public IP. If you need persistence through a stop/start cycle, you must use an Elastic IP.

Most providers like AWS start with a soft limit of 5 Elastic IPs per region per account. You can request a limit increase if your architecture genuinely requires more.

Not directly through the console. You usually have to release it from one and hope to catch it in the other, which is risky. Some providers offer 'IP Transfer' features for business accounts.

No. If your development server stops, your DNS will break. Always point your A-Record to an Elastic IP or, better yet, a Load Balancer's DNS name (CNAME).

They are conceptually the same (a permanent address). 'Elastic IP' is simply the specific brand name used by cloud providers to describe a static IP that can be programmatically re-mapped to different servers.

An Elastic IP is specifically for making a server reachable from the public internet. If your server is intended to be internal-only, you should use a Private IP and a NAT Gateway.

Changing an instance type usually requires stopping the server. If you are using a standard Public IP, it will be lost. An Elastic IP will remain assigned to your account and can be re-attached to the new instance type.

Go to the 'Elastic IPs' section of your cloud console, select the IP, and choose 'Release'. Note: You must dissociate it from an instance before you can release it.

IPv6 addresses are so abundant that the concept of 'Elastic' is slightly different. Most cloud providers give you a permanent IPv6 block for your VPC, so you don't 'reserve' them in the same way you do for rare IPv4s.

This is the command that tells AWS to take an Elastic IP from your account and 'plug it in' to a specific virtual server. This can be done while the server is running.

Yes. Because the IP address never changes, you never have to tell the internet's DNS servers that your server moved. The connection remains stable regardless of server reboots.

No. An IP can only be associated with one network interface at a time. To spread traffic across multiple servers, you need a Load Balancer.

Not inherently. However, it allows for more stable firewall rules (Security Groups) and whitelisting, which leads to better overall security management.

As of early 2024, AWS began charging a small hourly fee for all public IPv4 addresses (including standard ones) to encourage the transition to IPv6. Check your billing console for the specific breakdown.