Yeah, that's annoying. You click stop, wait an hour, and the instance just sits there spinning in 'stopping'. Let's cut to the chase — the fix is usually a force-stop, but the real work is figuring out why it hung so it doesn't come back.
The Immediate Fix: Force-Stop
When an instance is stuck in 'stopping', the AWS control plane is waiting for the guest OS to finish shutting down. If the OS never responds, you're stuck. Force-stop tells AWS to just kill the underlying hypervisor process. No graceful shutdown, no waiting.
You can do this from the console: EC2 → Instances → select the stuck instance → Instance state → Stop (not 'Stop', but the dropdown might say 'Stop' — actually it's 'Stop' then there's a checkbox). Wait — in the console, when you click 'Stop', you get a dialog with a checkbox: 'I'm aware that stopping this instance will not preserve data on instance store volumes'. That's not what you want. To force-stop, you need the CLI or API.
Use the AWS CLI:
aws ec2 stop-instances --instance-ids i-1234567890abcdef0 --force
The --force flag is the magic. It bypasses the guest OS shutdown and directly tells the hypervisor to halt. For EBS-backed instances, the instance state will change to 'stopping' briefly, then 'stopped'. You might lose data in instance store volumes (if any), but you don't have those on most modern instance types anyway.
If the CLI isn't your thing, you can also use the AWS Console — but you have to use the new EC2 console, and it's hidden. Go to the instance, right-click → Instance state → Stop. There's a checkbox that says 'Force stop' — but only if you're in the new console. Actually, I've seen it vary. The CLI is deterministic. Use the CLI.
Why Did It Hang? The Root Cause
Now that it's stopped, let's talk about why it wouldn't stop on its own. More often than not, it's one of these:
- A hung systemd shutdown unit — a service that doesn't respond to SIGTERM, or a mount that won't unmount. The OS waits forever.
- A kernel panic during shutdown — rare, but possible, especially on custom kernels.
- A stuck NFS or network mount — if the instance has a mount pointing to an unreachable NFS server, shutdown hangs trying to unmount it.
- Hypervisor-level issue — AWS side glitch. This happens, though less often.
What's actually happening here is that AWS sends an ACPI shutdown signal to the instance. The OS processes it and starts the shutdown sequence. If any step in that sequence blocks, the OS never tells AWS 'I'm done'. AWS waits — and waits — because it doesn't want to risk data corruption by killing the VM mid-shutdown. But after a few hours, you've already waited too long. Force-stop is the only move.
The reason force-stop works is that it skips the guest OS entirely. The hypervisor (Nitro or Xen, depending on your instance type) directly stops vCPUs and detaches the EBS volumes. It's like pulling the plug on a desktop that won't shut down — not graceful, but it ends the loop.
Less Common Variations
Stuck in 'Stopping' But Never Reaches 'Stopped' After Force-Stop
If you force-stop and it still stays in 'stopping', that's a sign of a deeper AWS-side problem. Check the EC2 service health dashboard. Occasionally, a regional issue can cause state updates to lag. Give it 20 minutes. If it's still stuck, open a support ticket with the instance ID and the time you initiated the stop.
Instance Stuck in 'Stopping' After a Scheduled Maintenance
AWS scheduled events sometimes trigger a stop/start. If the instance hung during that, you might see a status check failure. Same fix — force-stop, then start again.
Windows Instances
Windows EC2 instances get stuck in 'stopping' for a different reason: Windows Update running at shutdown. Or a pending reboot that never completes. Force-stop works, but be ready for a dirty shutdown — you'll want to check the system event log after you start it back up.
Quick note: If you have a Windows instance with an encrypted EBS volume and you force-stop, you might need to re-enter the encryption key on the next start. Not always, but it's happened to me.
Prevention: Stop Chasing the Problem
The real fix is to make sure this doesn't happen again. Here's what gets you there:
- Use CloudWatch alarms on 'StatusCheckFailed_System' — this catches hypervisor-level issues early.
- Set a shutdown timeout in the OS. For systemd, edit
/etc/systemd/system.confand setDefaultTimeoutStopSec=30s. That way, even if a service hangs, the OS kills it after 30 seconds instead of waiting forever. - If you use NFS mounts, add
_netdevto the fstab entry. This tells the OS to wait for the network before trying to mount, and also helps unmount during shutdown. - Test your shutdown process — stop and start your instances on a schedule (like during low-traffic windows) so you know they can actually stop. It's like testing your smoke alarms.
Also, if you're using Auto Scaling groups, set a custom termination policy that includes a shorter shutdown timeout. But that's a different rabbit hole.
After You Restart
Once you force-stop and then start the instance, check /var/log/cloud-init-output.log (Linux) or C:\ProgramData\Amazon\EC2-Windows\Logs\EC2ConfigLog.txt (Windows) for shutdown errors. Look for anything hanging — a stuck service, an unmount failure. That log tells you exactly what was blocking the graceful stop.
One more thing — don't get in the habit of force-stopping every time. Use it as a last resort. Force-stopping on a regular basis can cause filesystem corruption, especially on instances with high write activity. But when you're already hours in with a stuck instance, it's the only sane move.