Right, let’s talk about what your EC2 instance is actually doing when you’re not looking. It’s not just sitting there; it’s got a whole internal life, a state of being. Knowing these states is the difference between confidently running infrastructure and frantically refreshing the AWS console at 2 AM wondering where all your money went.

Think of these states as the instance’s mood. It can be fired up and ready for action (running), taking a well-deserved nap (stopped), or… well, dead (terminated). You need to know these moods because they directly impact two things: your bill and your data.

The Big Five (Well, Four and a Ghost)

An instance cycles through a few key states, and I’ll walk you through each one.

Pending: The Anxious Prelude

This is the “hold music” state. You’ve clicked “Launch,” and AWS is now frantically behind the scenes preparing your slice of a physical server. It’s allocating the hardware, staging the AMI onto a host, and getting the network plumbing sorted. You can’t do anything with it yet. The console says pending and the Instance State column taunts you with a little spinning icon.

How long does it take? Usually less than a minute. If it’s stuck pending for ages, you’ve likely hit a capacity issue in that specific Availability Zone. AWS doesn’t have infinite capacity everywhere, all the time. The fix? Your best friend here is the InstanceLaunchError event in the Instance Status tab. It’ll tell you straight up if it’s a capacity problem. The solution is almost always to just retry in a different AZ.

# While it's pending, describe its status to see the gory details
aws ec2 describe-instance-status --instance-id i-1234567890abcdef0

Running: Showtime

This is the state you pay for by the second. The virtual machine is fully booted, its network interfaces are live, and it’s ready for your commands. Well, almost. running just means the hypervisor thinks it’s running. The OS inside could be a smoldering crater. Always check the system status checks post-boot; a running instance with failed status checks is like a car that’s on but has a check engine light—it might move, but you shouldn’t trust it.

This is also where the meter is running. Remember: running == you are being billed.

Stopping: The Graceful Shutdown

You’ve issued the stop command. AWS now sends an ACPI shutdown signal to the instance’s OS—it’s the equivalent of clicking “Shut Down” in the start menu. This gives the OS a chance to flush caches, cleanly unmount filesystems, and generally not corrupt itself. This state is usually very brief (a minute or so).

Crucial Pitfall Alert: This is not a reboot. When you stop an instance, a few important things happen:

  1. You lose all ephemeral (“instance store”) data on the root volume. Poof. Gone.
  2. The public and private IP addresses are released back into the pool… unless you’ve assigned an Elastic IP (which you should for any persistent workload, come on).
  3. The instance moves to…

Stopped: The Coma

The machine is powered down. You are not billed for compute usage in this state. Let me say that again: Stopped instances do not cost money for the instance itself. This is your “pause” button. It’s fantastic for dev environments you only use during the day or for keeping a known-good configuration around without paying for it 24/7.

But—and there’s always a but—you are still billed for any attached EBS volumes. That root disk and any additional drives are still allocated to you, sitting on a shelf in an AWS data center, so you pay for the GB-month of storage.

Why would you use this? It’s perfect for cost-saving on non-production instances. Stop it Friday evening, start it Monday morning. You just saved ~66% on your compute bill for that box.

# Stop your instance to save money (but not storage costs)
aws ec2 stop-instances --instance-ids i-1234567890abcdef0

# Start it back up when you need it again. It'll get new IPs unless using EIPs.
aws ec2 start-instances --instance-ids i-1234567890abcdef0

Terminated: The Great Beyond

This is the point of no return. The instance is being dismantled. The virtual hardware is de-provisioned, and—this is the most important part—the root EBS volume is typically deleted by default. Any additional EBS volumes set to “delete on termination” will also be vaporized. The metadata of the instance hangs around in the console for a short while, greyed out, like a digital ghost, before it disappears forever.

There is no coming back from this. The only way to “recover” a terminated instance is if you’ve taken an AMI of it beforehand. Otherwise, it’s gone. This is why you should never, ever make Terminate the default action in the console protections. Always set it to Stop.

The shutdown-hibernate behavior is different. It tries to save the contents of your instance’s RAM to the root EBS volume, so a subsequent start should bring it back to its exact pre-hibernation state. It’s neat, but the stars have to align for it to work (supported instance types, enough EBS bandwidth, etc.). I treat it as an experimental feature for most use cases.