Stopping and Restarting an EC2 Instance: What Actually Happens to Your Public IP

Stop an EC2 instance and a few things happen that aren't obvious the first time you see them: your browser might still show the old page, the console takes its time updating, and the public IP you had before is gone for good. Here's what I found working through it from the command line.

First, Confirm the Instance Is Actually Running

Before I touch anything, I like to go back to the AWS console and make sure the instance I set up is still there and still running. It sounds like a trivial step, but it's saved me more than once — instances can get stopped by a billing alarm, a scheduled action, or just because I forgot I'd shut it down in a previous session. When I open the EC2 dashboard, the default instance list filter often hides stopped or terminated instances, so if you don't see what you're looking for, check that the status filter is set to show all instance states, not just "running."

Once I confirm the instance shows a running state in the console, I go back to the browser tab where I'd loaded the instance's web page in an earlier session and reload it. Seeing that familiar "Hello from EC2" response come back is a nice sanity check — it tells me the instance is up, the security group rules are still allowing traffic, and the web server process on the box is actually answering requests, not just that the instance status says "running." That distinction between instance state and application state matters more than it seems like it should, and it's going to come back around later in this walkthrough in a more confusing way.

Peeking Under the Hood with describe-instances

With the instance confirmed healthy, I switch over to the terminal, where the AWS CLI is already configured from earlier setup. The first command I run is a simple one: aws ec2 describe-instances. It doesn't take any arguments in its most basic form, and it returns everything the API knows about every instance in your account and region — which turns out to be a lot.

The output is a single, deeply nested JSON document. Instance ID, instance type, launch time, VPC and subnet IDs, security groups, tags, block device mappings, network interface details — it's all in there, and scrolling through it for the first time is a little overwhelming. I didn't try to absorb all of it in one sitting; the plan is to come back to specific fields as they become relevant later, using them as a reference rather than trying to memorize the whole schema up front. If the output is more than you want to page through in your terminal, Ctrl-C will get you out of it without doing any harm — you're just reading data, not changing anything.

What this command is really useful for in the moment is finding the instance ID, which I'm going to need for the next step. I copied mine out of the JSON output rather than retyping it, which is generally the safer move — instance IDs are long enough that a typo is easy to make and can send a command at the wrong resource.

Stopping the Instance from the Command Line

With the instance ID in hand, stopping the instance is a single command: aws ec2 stop-instances --instance-ids followed by the ID. Run it, and the CLI comes back almost immediately with a small JSON response showing the state transition — from running to stopping. That response is just an acknowledgment, though; it doesn't mean the instance is fully stopped yet.

Switching back to the console, I watched the status column update in something closer to real time. There's a genuine lag between issuing the stop command and the instance actually finishing its shutdown — it sits in "stopping" for a bit before settling into "stopped." That delay is expected. EC2 instances go through an orderly shutdown process rather than being yanked offline instantly, and the console reflects the true state as it happens rather than the moment you issued the command.

The other thing I noticed once the instance fully stopped: the public IP address field in the console goes blank. That's not a display glitch — it's a preview of the bigger point this whole exercise is building toward. For now, the instance has no public IP at all while it's in the stopped state, because AWS releases that address back into its pool the moment the instance stops.

Don't Trust Your Browser Cache

Here's the part that actually caught me off guard a little, even knowing intellectually that the server was down. I flipped back to the browser tab that still had the "Hello from EC2" page open from earlier and, without thinking too hard about it, it still looked fine. Nothing had visibly changed. For a second that's genuinely confusing if you don't know what's going on — the instance is stopped, the public IP has vanished from the console, and yet the page in front of you looks completely alive.

That's the browser cache doing what it's designed to do. It had already rendered that page once during this session and had no reason to go back out to the network unless I forced it to. The moment I actually triggered a real reload — not just glancing at an already-loaded tab, but forcing the browser to re-request the page — the illusion broke immediately. The page hung in a loading state and never resolved, because there was nothing on the other end to answer the request anymore; the server, and the IP address it had been reachable at, were both gone.

It's a small moment, but it's a useful one to internalize early if you're new to working with cloud infrastructure. The state you see in a browser tab is not a live readout of server state — it's a snapshot from whenever the page last actually loaded. If you're ever debugging "why does this still look like it's working" during infrastructure changes, a hard reload (or a private/incognito window, which won't have any cached history to fall back on) is one of the first things worth trying before you assume something is wrong with your setup.

Restarting Gets You a Different Public IP — Plan Accordingly

This is really the payoff of the whole exercise. When you restart a stopped EC2 instance — whether you do it from the console with the Start button or from the CLI — AWS assigns it a new public IPv4 address by default. It's overwhelmingly likely to be different from the one you had before, not a refresh of the same address. That's just how EC2's default networking behaves: standard public IPs are ephemeral and tied to the instance's running lifecycle, not permanently reserved for you, so every stop/start cycle effectively puts you back in line for a new one. If a stable, unchanging address matters for what you're building — because you've pointed a DNS record at it, or a client application has it hardcoded — this is exactly the situation an Elastic IP is meant to solve, since it stays associated with your account until you explicitly release it, independent of whether the instance is running.

It's worth flagging that the exact odds of getting a different address aren't something I'd treat as a hard guarantee — I wouldn't take a specific probability as a documented AWS fact, just a practical rule of thumb. But operationally, the takeaway is the same either way: never build something that assumes a standard EC2 public IP will survive a stop/start cycle, because in practice it usually won't.

One more thing worth keeping in mind if you're following along and spinning up your own instance to test this: a running EC2 instance accrues charges the whole time it's up, regardless of whether you're actively using it. It's easy to leave a test instance running in the background and forget about it. If you're just experimenting with stop-instances and describe-instances the way I was here, get in the habit of stopping — or terminating, if you're done with it entirely — any instance you're not actively using.

Conclusion

None of this is complicated once you've seen it happen once, but it's the kind of behavior that's much easier to internalize by watching the state changes yourself than by reading about them. If you've got an instance sitting around, try the sequence firsthand: describe it, stop it, watch the public IP disappear from the console, and then start it back up and compare the new address to the old one. Seeing that IP actually change is a lot more convincing than being told it will.