Why Your EC2 Instance Gets a New Public IP After a Restart

Stop and start an EC2 instance and you'll likely come back to a different public IP address than the one you left with. Here's what's actually happening under the hood, why a simple reboot behaves differently, and what it means for anything that depends on that address staying put.

Starting Back Up

I had an EC2 instance sitting in a stopped state from earlier work, and it was time to bring it back online. The straightforward way to do this is through the AWS Console: find the instance, select it, and choose Start. Within a few seconds it begins moving through its lifecycle states — starting, then running, then a brief initializing period while the underlying host gets the instance ready to actually respond to traffic.

There's also a CLI path for this if you'd rather not click through the console every time — the ec2 start-instance command does the same job, and it needs the instance ID to know what to start. I'm not going to dig into the CLI mechanics here since that's really its own topic (autocompleting instance IDs so you're not copy-pasting long strings is a nice quality-of-life addition once you're working from the terminal regularly). For this walkthrough, the console is enough to see what I actually want to show you.

One thing worth flagging before you even hit Start: you need the instance ID regardless of which method you use. If you've got multiple instances running, especially ones with similar names or default naming, it's easy to start the wrong one. Get in the habit of double-checking the ID against the instance you actually intend to bring up, particularly if you're managing more than a handful of them.

The IP That Wasn't There Anymore

Once the instance finished initializing, I went to check on it the way I usually do — grab the public IP from the console and confirm it's reachable. Except the IP address showing up now wasn't the one I'd used before stopping the instance. The old address was simply gone, reassigned to who-knows-what elsewhere in AWS's pool, and a new one had taken its place. I connected to the new address and it worked exactly as expected, so functionally nothing was broken. But it was a very concrete, real-time demonstration that the address itself is not a fixed property of the instance.

If you haven't run into this before, it's a little disorienting the first time. You bookmark an IP, or you've got it saved in a config file, or a teammate has it in a Slack message, and then it just stops being valid. Nothing about the instance itself changed — same OS, same disk, same configuration — but the address you use to reach it did.

This is the kind of thing that's easy to miss if you only ever start an instance once and never stop it again. It tends to surface later, usually at an inconvenient moment, when someone stops an instance to save on costs overnight and then can't figure out the next morning why their bookmarked SSH connection or API endpoint suddenly refuses to connect.

Reboot vs. Stop/Start: Two Different Animals

The behavior comes down to a distinction that isn't always obvious from the console UI: a reboot and a stop/start are not the same operation, even though they can feel similar from the outside. Rebooting an instance is closer to restarting an operating system — the underlying host stays the same, and from what I've seen, the public IP address is preserved across that reboot. Stopping and then starting an instance is a different story: the instance is released from its underlying host, and when it starts again, it can end up on different physical hardware entirely, with a freshly assigned public IP. Terminating an instance and launching a new one behaves the same way — a new IP, no continuity with whatever the old instance had.

I'd treat the reboot-preserves-IP, stop/start-reassigns-IP split as the general rule of thumb rather than something to build critical infrastructure on without double-checking against AWS's current documentation — cloud provider behaviors do shift, and it's the kind of detail worth confirming for your specific instance configuration before you rely on it in production. But as a working mental model for day-to-day use, it's held up: reboot for a quick restart where you want everything, including the address, to stay put; stop/start when you actually want to release the instance and don't mind (or specifically want) a clean slate.

It's worth sitting with why AWS defaults to this behavior at all rather than treating it as an annoyance. Public IPv4 addresses are a finite, shared resource across the entire platform. Permanently tying one to every stopped instance — even instances sitting idle for months — doesn't scale well across millions of accounts. The dynamic default lets AWS pool and reallocate addresses efficiently, and it nudges you toward an explicit choice if you genuinely need a fixed address, rather than assuming every instance needs one by default.

Why This Actually Matters

The obvious question once you know an IP can change out from under you is: what depends on it staying the same? For a lot of casual or dev use, the answer is nothing — you look up the current IP each time you connect and move on. But the moment you have anything referencing that address indirectly, the dynamic behavior stops being a curiosity and starts being a maintenance problem.

DNS records are the most common case. If you've pointed an A record at an instance's public IP so a domain resolves to it, a stop/start cycle will silently break that mapping until you update the record. Scripts and automation are another — anything that has the IP hardcoded, whether it's a deployment script, a monitoring check, or a config file pushed out to other servers, will start failing (or worse, silently pointing at the wrong destination if that IP gets reassigned to someone else's instance) the next time the address changes.

There's also the coordination cost across a team. If one person stops an instance to save on costs and it comes back with a new address, everyone downstream — teammates, CI pipelines, third-party integrations expecting a webhook callback at that IP — needs to know. That's a lot of moving parts to keep synchronized manually every time someone needs to restart a box, and it's exactly the kind of thing that's easy to forget until something breaks in production.

The Fix: Elastic IPs

AWS's answer to this is the Elastic IP — a static, persistent public IP address that you allocate to your account and then associate with an instance. Once it's attached, that address stays with the instance through stop/start cycles instead of getting reassigned. It's the tool that exists specifically to solve the problem I just watched happen in real time: you allocate the address once, associate it, and from then on, restarting the instance doesn't touch your DNS records, scripts, or anyone's saved connection details.

It's not something to reach for automatically on every instance, though. Elastic IPs are free while they're actively attached to a running instance, but AWS charges for ones that are allocated and sitting idle (or attached to a stopped instance) — a small cost, but a real one if you spin up and forget about them. The tradeoff is straightforward: dynamic IPs are the right default for disposable or short-lived instances where you don't care what address you land on, and Elastic IPs make sense the moment you have something durable depending on that address staying fixed — a production server, a DNS record, an integration another system relies on.

Conclusion

If you manage instances that anything else depends on — a DNS record, a script, a teammate's bookmarked connection — it's worth checking now whether any of them are quietly relying on a public IP that could change the next time you stop and start. If so, allocating and associating an Elastic IP for that instance is a small step that removes the problem entirely.