How to Fix AWS EC2 Instance Stuck in Stopping State Step-by-Step

If your EC2 instance has been sitting in the "stopping" state for more than 10-15 minutes, force stop it: in the console, select the instance, choose Instance state → Force stop instance → Stop, or from the AWS CLI run aws ec2 stop-instances --instance-ids i-xxxxxxxx --force. AWS's own troubleshooting guide says this is almost always a problem with the underlying host computer, not something you broke — and here's the part that catches people off guard: you are not being billed extra for the time it sits stuck. Amazon EC2 only charges for instance usage while an instance is in the running state, so a "stopping" instance from an hour ago and a "stopped" instance from a week ago cost exactly the same — nothing, other than the storage on its attached volumes.

Jake called me on a Tuesday afternoon sounding like he'd already had a bad day before this one started. He runs a small phone repair shop, and last year he moved his repair-ticket database onto a $10-a-month EC2 instance because his old desktop kept overheating in the back room. He'd gone to stop the instance overnight — a habit he picked up after someone told him it saves money — and it had been sitting in "stopping" for forty minutes. His first thought wasn't about the instance. It was "am I getting billed for this while it just sits there doing nothing?"

That question turns out to be the most common one people ask when this happens, and the answer is reassuring: no, you are not. Amazon EC2 does not charge for instance usage or data transfer while an instance is not in the running state — that covers "stopping," "stopped," "shutting-down," all of it. What you keep paying for is the storage attached to it: the EBS root volume and any data volumes stay billed at their normal per-GB rate the whole time, running or not, because they still exist and still hold your data. So Jake's stuck instance wasn't burning extra money. It was just refusing to finish a job it had already started, which is its own kind of annoying when you're trying to close up shop and go home.

Why EC2 instances actually get stuck in "stopping"

When you tell an EBS-backed instance to stop — from the console, the CLI, or the API — AWS doesn't just yank the power. By default it attempts a graceful operating system shutdown first: it sends the shutdown signal to your OS, waits for it to flush file system caches and metadata to disk, close open files, and finish whatever cleanup scripts you've configured. Only once that finishes, or times out, does the instance actually move to "stopped." That in-between window is where "stopping" sits, and for the overwhelming majority of stops it lasts a few minutes at most.

AWS's own troubleshooting documentation for this exact problem gives a short, blunt list of the scenarios where an EBS-backed instance appears "stuck" in stopping:

• There's an issue with the underlying hardware that hosts the instance, or the instance failed a system status check.
• The instance is running out-of-memory (OOM) and can't process the shutdown request cleanly.
• You're trying to hibernate the instance rather than perform a plain stop, and hibernation is taking longer than a normal stop would.

Notice what's missing from that list: nothing about your instance type, your region, or "user error." Most of the time this isn't something you did wrong. It's the physical machine underneath your virtual one having a bad day, or your own operating system being too busy (or too broken) to answer the phone when AWS calls to say "please shut down now."

What "stopping" actually looks like step by step

Ethan, who's been helping Jake with this stuff since the shop first got a business internet line, put it to him this way: "Think of it like asking someone to leave a party politely instead of pulling the fire alarm. You knock, you wait for them to grab their coat, say goodbye to a few people, maybe use the bathroom on the way out. Most people are out the door in five minutes. Sometimes someone's stuck in a conversation they can't escape, and you're standing at the door wondering if you need to go in and physically walk them out."

That "walking them out" step is the force stop, and we'll get to exactly how and when to use it. But first, since AWS documentation itself says the normal shutdown attempt can take a few minutes, it's worth being precise about what counts as normal versus what counts as stuck, because jumping to a force stop too early costs you nothing catastrophic — but it does mean skipping a step that could have avoided a forced, unclean stop altogether.

Are you being charged while it's stuck? (The part everyone panics about)

This deserves its own section because it's the question that makes people panic-click things they shouldn't. To repeat it plainly, straight from AWS's own guidance: there is no cost for instance usage while an instance is in the stopping state, or any other state except running. You're only billed for compute time when the instance is actually running.

What does keep costing money the entire time — stopping, stopped, doesn't matter — is:

• EBS volume storage. Your root volume and any attached data volumes are still allocated storage and billed by the GB, whether the instance is running or not.
• Elastic IP addresses not attached to a running instance may incur their own small hourly charge, separate from the instance itself — check that separately if you're watching every dollar.
• Any other resources you're running alongside it — a load balancer, an RDS database, a NAT gateway — keep billing exactly as they would if the instance were happily running.

For Jake, that meant the actual dollar cost of his instance being stuck overnight was zero beyond what he was already paying for the 30 GB volume attached to it. The real cost was his own time, and the risk that whatever was mid-write on that disk when it froze might not land cleanly. That second part is worth taking seriously even though the first part isn't.

Step one: confirm what state it's actually in

Before you do anything drastic, refresh and confirm you're actually looking at "stopping" and not "shutting-down" (which is what a terminate shows while it's in progress — a very different, much more permanent action) or "stopped" that just hasn't refreshed in your browser tab yet. In the console, click the refresh icon on the Instances page rather than trusting a page you opened twenty minutes ago.

If you'd rather not trust the UI, the CLI gives you the ground truth. This is also the command AWS's own re:Post knowledge center leads with when walking through this exact issue, because the JSON response tells you not just the state but why:

aws ec2 describe-instances --instance-ids i-0123ab456c789d01e --output json

Look at the State.Name field and the StateTransitionReason field in the response. If StateTransitionReason mentions anything about a status check, or "Server.InsufficientInstanceCapacity," or a scheduled retirement, that's your clue — it's telling you this is a host-level issue, not something to chase inside your own operating system.

A five-minute-old "stopping" is not a support ticket. AWS's documentation and its own support engineers repeatedly point to the same window: if the instance hasn't stopped within about 10 minutes, it's reasonable to treat it as stuck and act. Under that, you're watching a normal shutdown happen slower than usual — annoying, but not broken.

Fix 1: Wait it out (cheapest, and often correct)

The least dramatic fix is also the right one for the first several minutes: don't touch anything. A default stop tries a full graceful OS shutdown, and depending on how many services your instance is running, how much data is in memory waiting to be flushed, and whether any shutdown scripts are configured, that can legitimately take a few minutes longer than you'd expect. There's no cost penalty for waiting, since (as covered above) you're not billed for instance usage while it's not running.

Ethan's rule of thumb with Jake: "If it's been less than ten minutes, go get a coffee. If you come back and it's still stopping, now we talk." That lines up with what AWS's own documentation implies through its escalation timing — force stop first, and if it hasn't resolved after 10 minutes, that's the point to post on re:Post or open a support case, not before.

Fix 2: Force stop from the console

Force stop is the option AWS points to directly in its own StopInstances API documentation whenever an instance appears stuck: "you can use the StopInstances operation together with the Force parameter to force stop your instance." In the console, that button only exists while your instance is showing "stopping" — it's greyed out or missing entirely in other states, so if you don't see it, refresh first and confirm the instance is actually in that state.

1. Open the Amazon EC2 console and go to Instances.
2. Select the checkbox next to the stuck instance.
3. Click Instance state in the top action bar.
4. Choose Force stop instance.
5. Confirm by choosing Stop in the dialog that appears.

What actually happens underneath that button click is not instant, and this is worth knowing before you panic a second time: a force stop still attempts the graceful shutdown first, flushing file system caches and metadata where it can. Only if that graceful attempt fails to complete within its timeout window does the instance shut down forcibly, skipping the flush. So "force stop" doesn't mean "instant stop" — it means "stop, and if the OS won't cooperate within a reasonable window, stop anyway without asking permission." Give it a few minutes to work through that sequence before assuming it also failed.

Fix 3: Force stop from the AWS CLI

The CLI version does the same thing as the console button, with one important advantage: it works in more situations. AWS's own documentation is specific about this — force stop is only available in the console while the instance shows "stopping." If it's sitting in some other state (except "shutting-down" or "terminated," where it's too late to stop it anyway), the console button won't be there, but the CLI's --force flag will still work.

aws ec2 stop-instances \
  --instance-ids i-0123ab456c789d01e \
  --force

Swap in your own instance ID (it always starts with i-, followed by a string of letters and numbers — you'll find it on the Instances page, or in the JSON from the describe-instances command above). If you're running an older version of the CLI and the flag is rejected, update it first; the AWS CLI's own release notes and support docs flag outdated CLI versions as a common source of confusing errors on commands that otherwise look correct.

After running it, poll the state instead of guessing:

aws ec2 describe-instances \
  --instance-ids i-0123ab456c789d01e \
  --query "Reservations[0].Instances[0].State.Name" \
  --output text

Fix 4: Skip the OS shutdown entirely

This is the newest and most aggressive tool in the box. AWS added a skip-os-shutdown parameter to both StopInstances and TerminateInstances that lets you bypass the graceful OS shutdown attempt entirely — instead of asking your operating system nicely and waiting, it's the equivalent of pulling the power cable straight out of the wall. AWS's own documentation is direct about the tradeoff: "bypassing the graceful OS shutdown might result in data loss or corruption — for example, memory contents not flushed to disk or loss of in-flight I/Os — or skipped shutdown scripts."

aws ec2 stop-instances \
  --instance-ids i-0123ab456c789d01e \
  --force \
  --skip-os-shutdown

Skip the OS shutdown flag was added in mid-2025 and requires a recent AWS CLI version (2.15 or later) if you're running it from the CLI; console support and SDK support followed shortly after. If your CLI predates that, upgrade before you try it — you'll get a straightforward "unrecognized argument" error rather than anything useful.

All four stop methods, side by side

AWS documents these as the four distinct ways to perform a user-initiated stop. Here's how they stack up against each other, from gentlest to most drastic:

After a forced stop: the step almost everyone skips

Here's the part of AWS's own troubleshooting guide that people scroll straight past because they're relieved the instance finally stopped: "perform file system check and repair procedures," and the note underneath it is not decorative — "performing these procedures is crucial because a forced stop prevents flushing of file system caches and metadata." A force stop that had to shut down forcibly (as opposed to sneaking in under the graceful-shutdown timeout) may have left your file system in an inconsistent state, the same way pulling a USB drive out mid-copy can leave files half-written.

Practically, that means once your instance starts back up:

1. On Linux, run a file system check on the root volume (fsck, using the correct variant for your file system — ext4, xfs, and so on) before assuming everything's fine. Many distributions run this automatically on the next unclean boot; check your boot log to confirm it happened rather than trusting it silently.
2. On Windows, let CHKDSK run if Windows prompts for it after an unclean shutdown, and don't cancel it out of impatience — it's checking exactly the kind of metadata inconsistency a skipped shutdown can leave behind.
3. Check application-level state too, not just the file system — a database that was mid-transaction when the power effectively got cut needs its own consistency check (most modern databases handle this via write-ahead logs on their next startup, but it's worth watching the startup logs rather than assuming silence means success).

Jake asked the obvious follow-up here: "Do I have to do this every single time I stop the instance normally?" No — this only matters after a forced stop that had to fall back to the unclean path, or any stop where you used --skip-os-shutdown on purpose. A default stop that completed normally already flushed everything cleanly; there's nothing to check.

When it's a system status check failure, not a stuck stop

This is where a lot of people get stuck twice in a row without realizing it's a different problem than they think. If your instance failed a system status check before you tried to stop it, force-stopping it only gets you back to "stopped." That's job half-done. System status check failures point to a problem with the underlying host, and getting off that host requires actually starting the instance again afterward — AWS's documentation is explicit that a stop-and-start (not a reboot) migrates an EBS-backed instance to new, healthy hardware. A reboot alone keeps you on the exact same physical host, which does nothing if that host is the problem.

• System status check failed — issue with AWS's underlying hardware or infrastructure. Fix: stop, then start (not reboot) to migrate to a different host.
• Instance status check failed — usually a problem inside your own operating system (kernel panic, misconfigured network settings, full disk). Force-stopping and restarting won't fix the underlying cause, only get it running again long enough for you to investigate from inside, via SSH, RDP, or the EC2 Serial Console.

You can see which check actually failed on the Status and alarms tab of the instance detail page in the console, or via describe-instance-status from the CLI. Don't skip this step — treating an instance status check failure (something inside your OS) with the fix for a system status check failure (a host problem) means you'll get it running again and watch it fail the exact same way ten minutes later.

One important side effect Ethan flagged for Jake before he tried this: when you stop and start an EBS-backed instance, its public IP address changes, unless you've attached an Elastic IP address instead of relying on the automatically-assigned one. If Jake's repair-ticket app has a hardcoded IP address anywhere — a firewall rule, a bookmark, a DNS record he set manually — a stop/start will quietly break it. This is exactly the kind of thing that turns "I fixed the stuck instance" into "why can't I reach my app anymore" twenty minutes later.

Windows EC2 instances: what's different

Everything above applies to Windows instances the same way it applies to Linux, with one specific caveat straight from AWS's own CLI reference for the --force flag: "this option is not recommended for Windows instances." The underlying reason isn't spelled out in detail in that documentation, but the practical implication is clear enough — Windows's own file system and registry handle an unclean shutdown less gracefully than most Linux file systems do, so treat force stop on a Windows instance as a genuine last resort, not a first move, and be extra diligent about running CHKDSK afterward rather than assuming it's fine because the instance came back up and looked normal.

If your Windows instance is unresponsive over RDP specifically (rather than just stuck in "stopping"), AWS documents a separate troubleshooting path for Windows RDP issues and Windows instance start issues that's worth checking in parallel — sometimes what looks like a stuck stop is actually a Windows instance that was already unhealthy before you tried to stop it, and the stop request is just the first thing that surfaced the underlying problem.

When force stop also fails

Sometimes none of it works, and that's frustrating in a way that's specific to cloud infrastructure — there's no physical machine to walk over to and unplug. AWS's own documentation is honest about this scenario rather than pretending it can't happen: if, after about 10 minutes, a force stop still hasn't resolved the state, the recommended next steps are to post a request for help on AWS re:Post (including the instance ID and exactly which steps you've already tried, since that speeds up any response), or — if you have a paid support plan — open a technical support case in the Support Center, which gets you direct engineering attention rather than community volunteers.

While you're waiting on either of those, AWS's own documentation for this exact scenario suggests a practical workaround if the instance is business-critical and you can't afford to wait: create a replacement instance. Take an AMI (Amazon Machine Image — think of it as a complete, bootable snapshot of everything on the instance, not just the data but the operating system and installed software too) of the stuck instance if you can still reach it, then launch a fresh instance from that image. One important caveat AWS flags here: if the original problem was a system status check failure specifically, creating an AMI from the stuck instance and launching a copy will just copy over an exact replica of whatever's broken on the underlying disk. Confirm which status check actually failed before you go this route, or you may just be relocating the same problem to a new instance ID.

Instance store volumes: the case with no safety net

Everything above assumes an EBS-backed instance, because that's what "stopping" even means — instance store-backed instances can't be stopped at all. AWS's documentation is direct about it: you can only terminate instance store-backed instances, not stop and restart them, because there's nowhere for the instance store data to persist to while the instance is off. If you check your instance's root device type and it comes back as instance-store rather than ebs, "stuck in stopping" as a phrase doesn't apply to you at all — you'd be looking at a stuck termination instead, which has its own separate troubleshooting path and its own force-terminate option.

Check which type you're dealing with before you spend time on any of the above:

aws ec2 describe-instances \
  --instance-ids i-0123ab456c789d01e \
  --query "Reservations[0].Instances[0].RootDeviceType" \
  --output text

Even on an EBS-backed instance, don't forget that any separate instance store volumes attached alongside the EBS root volume lose their data the moment the instance stops — running or ephemeral cache data living there is gone, by design, whether the stop finishes cleanly or gets forced. That's worth knowing before you force-stop something in a hurry and only remember afterward that the temp directory your application was writing to lived on instance store, not EBS.

Auto Scaling groups, hibernation, and other edge cases

Instances inside an Auto Scaling group

If the stuck instance is part of an Auto Scaling group, stopping it manually can trigger the group's own health-check logic to decide the instance is unhealthy and replace it — which might solve your immediate problem by launching a fresh instance, but can also fight against whatever you're trying to do if you actually wanted to keep that specific instance. Check your group's health check settings and scale-in protection before forcing anything, or you may end up debugging a second, self-inflicted problem on top of the first.

You were trying to hibernate, not just stop

Hibernation is different from a plain stop — instead of discarding what's in RAM, AWS saves the contents of memory to the EBS root volume so the instance can resume exactly where it left off, rather than doing a fresh boot. AWS's own documentation notes hibernation as one of the specific scenarios that can leave an instance appearing stuck in "stopping," because saving potentially many gigabytes of RAM contents to disk simply takes longer than a normal shutdown does, especially on instances with a lot of memory. If you enabled hibernation and it's taking a while, that's more likely to be "still working" than "actually stuck" — give it noticeably longer than a plain stop before reaching for force stop, since AWS documentation also notes that if hibernation itself fails, it automatically falls back to a normal shutdown rather than getting permanently wedged.

Managing the instance remotely, with no console access to spare

If you manage this instance entirely over SSH or RDP through a bastion host, and that instance is the one that's stuck, you're in an awkward spot: the thing you'd normally use to investigate is the thing that's frozen. This is exactly the situation the console and CLI methods above are built for — you don't need shell access to the instance itself to force-stop it, since the request goes to AWS's control plane, not through the operating system. If you also use AWS Systems Manager Session Manager for access instead of a bastion, don't be surprised if a Session Manager connection to a stuck instance simply hangs too; that's consistent with the instance being unresponsive at the OS level, not a separate problem to chase down.

A scheduled AWS-initiated stop, not one you triggered

Not every stop starts with you clicking a button. AWS occasionally schedules a stop event for an instance it's decided needs to move off degraded hardware, and you'll get an email notice ahead of time with a scheduled window. Check your instance's scheduled events (visible on the instance detail page, under a notice banner, or via describe-instance-status) before assuming a mysterious stopping instance is something you need to fight — sometimes it's AWS doing exactly the maintenance you'd otherwise have to do manually.

Preventing this the next time you stop an instance

You can't fully prevent underlying host issues — that part is genuinely outside your control, the same way you can't prevent a rental car from having a mechanical fault before you picked it up. But a few habits reduce how often you'll hit this and how bad it is when you do:

1. Set up automatic recovery. A CloudWatch alarm watching the StatusCheckFailed_System metric, wired to EC2's automated recovery action, can stop-and-start the instance for you the moment a system status check fails, rather than you finding out when your application goes down and someone calls you.
2. Use an Elastic IP for anything with hardcoded connection details. This sidesteps the "why did my app stop responding after I fixed the stuck instance" surprise entirely, since an Elastic IP stays attached across a stop and start.
3. Keep shutdown scripts short and defensive. A shutdown hook that waits on a slow network call, an unreachable NFS mount, or a database connection that never times out is one of the most common self-inflicted causes of a slow OS shutdown. Add explicit timeouts to anything your shutdown scripts wait on.
4. Snapshot before anything drastic. If you're about to force-stop or skip-OS-shutdown a production instance holding data you can't lose, taking an EBS snapshot first (even a quick manual one from the console) costs a couple of minutes and gives you a rollback point if the forced stop leaves the file system in worse shape than expected.
5. Know your support plan before you need it. Confirm now, not during an outage, whether your account has a paid support plan that lets you open a technical case — that's not something you want to be discovering for the first time while an instance has been stuck for two hours.
6. Tag your instances with an owner and a purpose. It sounds unrelated to a stuck stop until the moment you're three instances deep into a re:Post thread and realize you're not entirely sure which one runs what. A clear Name tag and an owner tag save real time during any incident, this one included.

A word on data before you force anything

Jake's actual worry, once he understood he wasn't being double-billed, was simpler and more human: was the repair-ticket database on that instance going to be intact when it finally came back? That's a fair thing to ask before you force-stop anything holding data you care about, and it deserves a straight answer rather than reassurance.

A default stop, even one that ends up needing a force stop because the OS was slow to respond, still attempts the graceful shutdown first — and AWS's documentation confirms the root volume and any data volumes persist through a stop regardless (they're only deleted automatically on termination, and only if their DeleteOnTermination setting says so). What you should genuinely worry about is the combination of "in-flight writes at the exact moment of an unclean shutdown" plus "no recent backup." Neither force stop nor skip-OS-shutdown deletes your data outright; they risk leaving whatever was mid-write in an inconsistent state, which is a very different and much more recoverable problem than data loss, provided you run the file system check afterward instead of skipping it.

Console vs. CLI: which one should you actually use?

For a one-off stuck instance, the console is perfectly fine — there's no meaningful speed or reliability advantage to the CLI for a single instance you can see in front of you. The CLI earns its keep in two specific situations: when the instance isn't in the "stopping" state the console requires for that button to appear, and when you're dealing with more than one stuck instance at once and don't want to click through the console for each one individually.

You can pass multiple instance IDs to the CLI force-stop command in one go, which matters more than it sounds like if you're ever dealing with a fleet-wide issue rather than a single unlucky instance:

aws ec2 stop-instances \
  --instance-ids i-0123ab456c789d01e i-0456cd789e012f34a \
  --force

For the power user: scripting this with Systems Manager Automation

If you're managing a fleet rather than one instance, AWS Systems Manager ships pre-built Automation runbooks that do this kind of thing for you on a schedule, or on demand, without you hand-typing CLI commands every time. AWS-RestartEC2Instance is Amazon's own maintained runbook for restarting one or more instances, and it takes just an InstanceId parameter (a list, so it accepts several at once) plus an optional AutomationAssumeRole if you want it to run under a dedicated IAM role rather than your own permissions:

aws ssm start-automation-execution \
  --document-name "AWS-RestartEC2Instance" \
  --parameters "InstanceId=i-0123ab456c789d01e"

That particular runbook reboots rather than stops-and-starts, so it won't move you off degraded hardware — but it's the same idea AWS uses for its own maintained automations, and it's the pattern to copy if you want to build a custom runbook that stops, waits, and starts a batch of instances on a trigger, rather than wiring the CloudWatch alarm mentioned earlier to just one instance at a time.

Popular advice that's wrong (or half-right)

A few pieces of advice circulate around this problem that deserve a correction:

"Just reboot it instead." A reboot doesn't help here at all, and if the root cause is a system status check failure, it's actively useless — a reboot keeps the instance on the exact same physical host, so if that host is the problem, you're rebooting straight back into the same failure. Only a stop followed by a start actually moves you to different hardware.

"Terminate it and relaunch from your last AMI, it's faster." Sometimes true, but it's a bigger hammer than most stuck-stopping situations need, and it's irreversible — any data on the instance's volumes that isn't captured in that AMI or a snapshot is gone the moment termination completes (assuming DeleteOnTermination is set, which it is by default for the root volume). Try force stop first; it's reversible right up until the moment you actually choose to terminate something.

"Force stop always causes data loss, so avoid it." This overstates the risk in the common case. A force stop still attempts the graceful shutdown first — it only skips the flush if the OS genuinely fails to respond within the timeout. The version that reliably risks data loss is specifically --skip-os-shutdown, not force stop on its own.

Frequently asked questions

How long is normal before an instance actually stops?

A few minutes is typical for a default stop. AWS's own guidance treats about 10 minutes as the point where it's reasonable to call it stuck and force-stop it rather than keep waiting.

Am I being charged while my instance is stuck in "stopping"?

No. EC2 doesn't charge for instance usage or data transfer while an instance is in any state other than running. You still pay for the storage on its attached EBS volumes, exactly as you would if it were stopped normally.

Will force stopping delete my data?

No, not by itself. Your root volume and any data volumes persist through a stop, forced or not. What a forced stop risks is leaving the file system in an inconsistent state if the graceful shutdown had to be interrupted, which is why a file system check afterward matters — but it's not the same as losing the data outright.

What's the difference between force stop and skip OS shutdown?

Force stop still attempts a graceful OS shutdown first and only falls back to a hard stop if that attempt times out. Skip OS shutdown bypasses the graceful attempt entirely and shuts the instance down immediately, which carries a higher risk of unflushed data and skipped shutdown scripts.

Why doesn't the Force stop button appear in my console?

It's only available in the console while the instance is showing the "stopping" state. If your instance is in another state (other than shutting-down or terminated, which can't be stopped at all), use the AWS CLI's --force flag instead, which works regardless of the current state.

My instance failed a system status check. Does force stop fix that?

Force stop only gets you to "stopped." Fixing a system status check failure requires starting the instance again afterward, since a stop-then-start migrates it to a different, healthy physical host. A reboot alone won't do this, since it keeps the instance on the same host.

Can I stop an instance store-backed instance?

No. Instance store-backed instances can only be terminated, not stopped, because there's no persistent storage for their data to live on while powered off. If your root device type is instance-store, this whole "stuck in stopping" scenario doesn't apply to you.

Will my public IP address change after I force stop and restart?

Yes, if you're relying on the automatically-assigned public IP address rather than an Elastic IP. A stop and start (not a plain reboot) assigns a new public IP by default. Attach an Elastic IP if anything depends on a fixed address.

Is force stop safe on a Windows instance?

AWS's own documentation specifically notes that force stop is not recommended for Windows instances. Use it as a genuine last resort on Windows, and run CHKDSK afterward rather than assuming the instance is fine just because it booted successfully.

What if force stop also doesn't work after 10 minutes?

Post a request for help on AWS re:Post, including your instance ID and the steps you've already tried, or open a technical support case in the Support Center if you have a paid support plan. If you need the workload running immediately, consider creating an AMI of the instance (if reachable) and launching a replacement.

I have the free Basic support plan. Can I get AWS to help directly?

Not through a technical support case — that requires a paid support plan. On the Basic plan, your options are the public AWS re:Post forum or upgrading your support plan if the situation is urgent enough to justify it.

Does force-stopping trigger any Auto Scaling group behavior I should worry about?

Potentially, yes. If the instance is part of an Auto Scaling group, manually stopping it can trigger the group's health check to consider it unhealthy and launch a replacement. Check your scale-in protection and health check settings before force-stopping an instance you specifically want to keep.

I was trying to hibernate, not just stop — is that why it's slow?

Possibly. AWS documents hibernation as one specific scenario that can leave an instance appearing stuck in "stopping," since saving RAM contents to the EBS root volume takes longer than a normal shutdown, especially on instances with a lot of memory. Give it more time than you would a plain stop before force-stopping.

Can I prevent this from happening again?

You can't prevent underlying host issues, but you can reduce how often you're surprised by one: set up CloudWatch-based automatic recovery for system status check failures, keep shutdown scripts short with explicit timeouts, and use an Elastic IP for anything with hardcoded connection details so a stop/start doesn't quietly break your app.

Should I take a snapshot before force-stopping a production instance?

Yes, if the instance holds data you can't afford to lose and you have a few spare minutes. A manual EBS snapshot before you force-stop or skip the OS shutdown gives you a clean rollback point in case the file system needs more than a quick check-and-repair afterward.

Why did my instance's state transition reason mention "InsufficientInstanceCapacity" or a scheduled event?

That's telling you this is a host- or capacity-level issue on AWS's side rather than something in your operating system. Check the instance's scheduled events in the console or via describe-instance-status — AWS sometimes schedules a stop on its own initiative to move an instance off degraded hardware, and will email you ahead of the scheduled window when it does.

Jake's instance, in the end, needed exactly one force stop and about four minutes of waiting. He checked the status tab out of curiosity afterward and saw it had been a system status check failure — a host problem, nothing he'd done. He started it back up, watched the public IP change, updated the one firewall rule that had it hardcoded, and went back to fixing phones. "That's it?" he asked. Ethan just shrugged: "That's usually it. The scary part was never the fix. It was not knowing whether you were allowed to touch it."

Revision note. Written September 2026. AWS periodically updates its console layout and default status-check thresholds, so if a button described here has moved, the underlying force-stop and status-check logic is very unlikely to have changed alongside it. If you've been staring at a frozen "stopping" instance for the last hour, take a breath — you're not being charged for the wait, and the fix really is this short.