Think about your home address. You get mail there, friends know where to find you, your pizza delivery always arrives at the right door. Now imagine your address changed every time you left the house and came back. The mail carrier would have no idea where to deliver. FedEx would give up. Your friends would stop visiting.
That's exactly the problem a static IP solves. It gives your server a permanent, unchanging address on the internet, so clients, records, and other services always know exactly where to find it.
Every production system you've ever used. Google, Netflix, your company's API, sits behind a static IP. Without one, DNS records would break every time the server rebooted, SSL certificates wouldn't match, and firewall rules would become useless overnight.
An IP address is just a number that identifies a device on a network. Like a phone number, but for computers.
A static IP is an IP address that's been permanently assigned to a device. It doesn't change when the device restarts, disconnects, or moves between networks.
| Property | Static IP | Dynamic IP |
|---|---|---|
| Changes? | Never (until you explicitly release it) | Every lease renewal or reboot |
| Assigned by | Manual configuration or cloud provider | DHCP server automatically |
| Cost | Usually costs money | Free (included with most services) |
| Use case | Servers, APIs, databases | Laptops, phones, IoT devices |
Here's the thing people miss: a static IP isn't a different kind of IP address. It's the same IPv4 or IPv6 address as any other. The only difference is the assignment policy, it's been reserved for you and won't be given to anyone else.
In cloud providers like AWS, you request an Elastic IP (their name for a static IP). Google Cloud calls them "static external IP addresses." Azure calls them "static public IPs." Different names, same concept, a reserved address that sticks.
Watch what happens when a server with a dynamic IP reboots, and why that's a disaster for production systems.
Use a static IP when:
Don't use a static IP when:
The real-world pattern: In production, you almost never point DNS directly at a single static IP anymore. You point DNS at a load balancer, and the load balancer has the static IP. The actual servers behind it can have dynamic IPs, they come and go as the auto-scaler does its thing. The static IP lives on the load balancer, not the individual servers.
AWS figured this out early. Their Elastic Load Balancers have static IPs (or stable DNS names) while the EC2 instances behind them use dynamic IPs. Netflix routes billions of requests through this pattern daily.
A static IP in the cloud is not a line item on a form. It is a real reservation against a real pool of routable IPv4 addresses that AWS, Google, and Azure lease from the regional internet registries. Since February 2024, AWS charges 0.005 dollars per hour for every public IPv4 address in your account whether it is attached to an instance or sitting idle. A single forgotten Elastic IP is 3.60 dollars per month of pure waste, and the internet is littered with old accounts bleeding hundreds per month on EIPs nobody remembers allocating.
Stripe learned this the expensive way during a 2023 cost audit. They found dozens of Elastic IPs left behind by decommissioned webhook gateways, each one still billing, each one still occupying an address in the regional pool. The fix was a Cost Explorer alert on unattached EIPs plus a weekly reaper script. The lesson is universal: static IPs are a scarce billable resource, not a free convenience.
The allocation flow itself is three API calls. You call AllocateAddress to pull one address from the regional pool into your account. You call AssociateAddress to bind it to an Elastic Network Interface on a specific EC2 instance. And you write an A record in Route 53 pointing at the EIP with a short , usually 60 seconds, so that if you ever need to swap instances the resolver cache turns over fast. The EIP is the stable identity. The instance behind it is disposable.
Watch an Elastic IP get allocated out of the regional pool, pinned to an EC2 instance through its network interface, and finally exposed to the world via a Route 53 A record.
The whole point of a static IP is that clients never see it change. But the workload behind that IP does fail, and when it does you need a way to move the address to a healthy instance without customers noticing. Elastic IP reassociation is the fastest recovery pattern AWS offers. It takes 1 to 3 seconds to repoint the IP at a new instance because it happens inside the AWS edge network, not through propagation.
Compare that to a pure DNS failover. Route 53 health checks plus DNS record updates propagate through resolver caches across the public internet. Even with a 60 second , tail latency for full global propagation runs 3 to 5 minutes because stub resolvers, corporate recursive resolvers, and home routers all hold their own caches. EIP reassignment skips all of that. The address does not move, the routing does.
The pattern is a health monitor, often a small Lambda triggered by CloudWatch alarms, that watches the primary instance. Three consecutive failed health checks trip the alarm. The Lambda calls AssociateAddress with the standby instance ID. AWS updates its edge routing tables and the very next connection attempt from the client lands on the standby. Total downtime is roughly 30 to 40 seconds, dominated by health check detection not by address propagation.
Watch a client resolve the hostname once, hit the primary, suffer a health failure, and transparently get served by the standby after the EIP is reassociated, all without a second DNS query.
2 questions - Score 80% to pass
A junior developer asks why their staging server becomes unreachable after every reboot. What's the most likely cause?
In a modern cloud production setup, where does the static IP typically live?
The default EIP quota is 5 per region. That sounds like plenty until you are mid-incident trying to spin up a replacement and AWS rejects the allocation because you already hit the cap. Raise the quota proactively to at least 20 through Service Quotas. It is free and it removes one surprise from your 3 AM runbook.
Always pin at the Elastic IP with a short TTL, not at the instance hostname. Google Public DNS and Cloudflare 1.1.1.1 aggressively cache long TTLs across hundreds of millions of clients. A 3600 second TTL means a DNS change takes an hour to propagate globally during an incident. A 60 second TTL lets you swap upstream servers in under two minutes.
Never rely on the auto-assigned public IPv4 of an EC2 instance for anything that matters. That address is released on every stop and start, so your monitoring playbook that hardcodes an IP will break the next time someone reboots the box. Production uses EIPs. Development can get away with auto-assigned.
The most common mistake is running an EIP directly on a single EC2 instance in production. That works for a demo but it means your recovery story is a single point of failure. The grown-up pattern is an Application Load Balancer that fronts an auto scaling group, where the ALB itself has stable endpoints and the instances behind it rotate freely.
Tune your health check to the failure modes you actually care about. A 10 second interval with a threshold of 3 gives you 30 second detection, which is usually the right balance. Going to 5 seconds catches failures faster but generates false positives on brief network hiccups. Going to 30 seconds is too slow for anything customer-facing.
Pair EIP reassociation with connection draining on the primary. If the instance is unhealthy but still reachable, cleanly close existing connections before the swap so in-flight requests finish instead of getting a TCP reset. On AWS, ALB target groups do this automatically with the deregistration delay setting.
This pattern does not work across regions. An Elastic IP is pinned to a single region. Cross-region failover requires either Global Accelerator, which gives you a pair of anycasted static IPs that route to the nearest healthy region, or DNS failover through Route 53, which is slower but more flexible. For multi-region active-active, Cloudflare and Fastly also offer anycasted static IP services that are operationally simpler than running your own Global Accelerator setup.
The trap is assuming EIP reassociation protects against an AZ outage. It does, as long as your standby is in a different AZ. But if your health monitor is also in the dead AZ, nothing triggers the failover. Run the health monitor in a third AZ or in a different region to avoid a dependency cycle that silently defeats your own failover.