How to Stop Your EC2 Server From Changing Its IP Address

If you've ever restarted an EC2 instance and found your web server unreachable at the address you'd been using, you've run into the default public IP problem. Here's how I fixed it with an Elastic IP, and what actually happens when you stop and restart the instance afterward.

The problem with default public IPs

When you spin up an EC2 instance, AWS hands it a public IP address automatically, and that's usually fine while the instance just sits there running. The catch shows up the moment you stop it and start it again, or the moment something unexpected forces a restart: that default IP can change out from under you. If you've pointed a domain at it, bookmarked it, or shared it with anyone, it's now wrong.

That's the exact problem I ran into with a web server I'd set up on EC2. I didn't want to have to go re-check and re-share a new address every time I stopped the instance for maintenance or it happened to restart on its own. The fix AWS offers is an Elastic IP: a static, account-owned address you allocate once and then attach to whichever instance you want. Think of it less like a phone number tied to a specific device and more like a domain name you own and can point wherever you like.

Allocating an Elastic IP

The whole process starts in the EC2 console under Network & Security, where there's an Elastic IPs section. I went with the console for this rather than the CLI or infrastructure-as-code, mostly because it's the fastest way to see the mechanics the first time through — you can always script it later once you know what's actually happening.

The one detail that matters here is region. Elastic IPs are region-scoped, so whatever region your EC2 instance lives in, that's the region you need to be in when you allocate the address. My instance was in us-east-1, so I made sure the console was set to that region before hitting allocate. Get this wrong and you'll allocate a perfectly good IP address that simply can't attach to your instance.

Allocating is a single click beyond that. AWS assigns you a new address, and it now belongs to your account — sitting unattached until you decide what to do with it.

Associating the IP with your instance

An allocated Elastic IP isn't doing anything by itself; it needs to be associated with a running instance. From the Elastic IPs list, selecting the new address and choosing Actions > Associate Elastic IP Address brings up a list of running instances to pick from, pulled automatically from the account.

I'll admit I picked mine off the list by its name — "web server" — rather than by instance ID, because I hadn't bothered to memorize the ID. That worked fine for me with a single instance in play, but it's worth flagging: if you're running multiple instances with similar or generic names, matching by name alone is an easy place to grab the wrong one. Double-checking the instance ID before confirming the association is a cheap habit to build now, especially once you're managing more than a handful of servers.

Once you confirm the association, AWS immediately reassigns the instance's public IP to the new Elastic IP. The old default address is released back into AWS's pool, and your instance answers at the new one from that point forward.

Verifying the web server actually responds

Association happening in the console is one thing; confirming it actually works is another, so I pasted the new IP straight into a browser tab. A couple of small practical notes here. First, the new address ended in a different set of digits than the instance's original default public IP, which is exactly what you'd expect — it's a new, separate address now. Second, browsers don't always guess the protocol correctly from a bare IP, so I had to add the https:// prefix manually to get the page to load rather than just error out.

With that done, the page came up and rendered the running web server, which confirmed the Elastic IP was correctly routed to the instance. That's really the whole verification step: allocate, associate, load it in a browser, done. It's satisfying in its simplicity, but the more interesting question — and the actual point of using an Elastic IP in the first place — is what happens to that address when the instance stops.

Stopping and restarting: does the IP actually stick?

This is the part that matters, so I tested it directly rather than taking it on faith. I stopped the instance — not terminated it, which is an important distinction, since terminating would tear the instance down entirely and mean rebuilding it from scratch, reinstalling the web server software, and rerunning any startup scripts. Stopping just pauses it; the instance and its configuration stay intact, ready to boot back up.

With the instance stopped, I went back to the browser to confirm the server was actually unreachable, and hit a small snag: the page still appeared to load at first, which had me second-guessing whether the stop had actually taken effect. That turned out to be the browser serving a cached copy of the page rather than actually reaching the server. A hard refresh cleared it up and showed the real state — unreachable, as expected. If you're testing this yourself, keep that caching wrinkle in mind; it's an easy thing to misread as the Elastic IP not working when it's really just your browser being helpful in the wrong moment.

Then I restarted the instance and loaded the same address again. It came right back up, serving the same web server, at the exact same Elastic IP it had before the stop. That's the entire value proposition in one test: a default public IP would very plausibly have changed here, but the Elastic IP didn't move. Once it's associated with an instance, it stays put across stop/start cycles — which is the whole reason to bother with this over just letting AWS assign whatever it wants.

What this actually costs, and why it's worth it

The reason Elastic IPs exist as a distinct feature comes down to that persistence guarantee. A default public IP is fine as long as nothing interrupts your instance, but any unplanned restart — a host-level failure on AWS's side, a maintenance event, anything outside your control — can hand you back a different address with zero warning. If you're running anything people actually connect to by IP or domain, that's a real problem. An Elastic IP removes that risk: it's yours until you release it, regardless of what happens to the instance underneath.

On cost, I'll pass along the numbers I've seen, with the same caveat I'd give anyone: AWS pricing shifts, and you should check the current pricing page rather than trust a number from a video or article. As I understand it, an Elastic IP costs a small fraction of a cent per hour, and I've seen that ballpark come out to something like three or four dollars a month if left running continuously — I want to stress that's a rough figure, not a quote, and it's exactly the kind of detail that's worth confirming directly against AWS's current documentation before you budget around it. There's also nuance around exactly when charges apply — historically, AWS billed differently depending on whether the address was actively associated with a running instance versus sitting idle, and that policy is another thing worth checking fresh rather than assuming.

The practical habit that matters more than memorizing a rate: don't let Elastic IPs sit around unused. If you allocate one for testing and then tear down the instance, release the IP too. Idle static addresses are the kind of thing that quietly accumulates on a bill without anyone doing anything wrong — you just forgot to clean up. I made a point of stopping and eventually deleting the test instance I used for this walkthrough for exactly that reason.

Conclusion

If your EC2 setup involves anything you connect to by address rather than through a load balancer or DNS record that's already handling this for you, allocating an Elastic IP is a ten-minute task that removes a real source of downtime risk. Try it on a test instance first: allocate one, associate it, then stop and restart the instance to watch the address hold steady yourself — and while you're in the pricing console confirming the association worked, take a minute to check the current Elastic IP rates so you're budgeting off real numbers rather than an estimate.