Right, let’s talk about pulling the plug. You’ve got an EC2 instance humming along, and you need to shut it down. You’ve got two big red buttons: Stop and Terminate. One is a cryogenic freeze, the other is a thermonuclear option. Pressing the wrong one is the cloud equivalent of accidentally deleting your entire thesis the night before it’s due. We’re not going to let that happen.

The core distinction is brutally simple: Stop preserves the hard drive (the EBS volumes). Terminate destroys it by default. Everything else—the CPU, the memory, the network card—is ephemeral and gets reclaimed by AWS in both cases. The root volume is the soul of your instance; everything else is just the temporary, disposable body.

What Actually Happens When You Stop an Instance

When you issue a stop command, it’s not a hard power-off. The OS on the instance gets a polite ACPI signal to shut down gracefully. This gives it time to flush caches, close files, and say its goodbyes. Once it’s fully shut down, AWS hypervisor detaches the EBS volumes and places the instance into a stopped state.

Here’s the magic: those detached volumes just sit there, accruing a tiny storage charge, waiting for you to call upon them again. When you Start the instance, AWS finds those volumes, re-attaches them to new hardware (which is why you get a new public IP and potentially a new underlying physical host), and boots it up. Your data, your installed packages, your bizarre configuration files—all of it is right where you left it.

Use the AWS CLI to stop an instance. It’s idempotent, so running it twice won’t hurt anything.

aws ec2 stop-instances --instance-ids i-1234567890abcdef0

The Permanent Farewell of Termination

Terminate is the point of no return. The process begins the same way: a graceful OS shutdown. But once the instance is shut down, the hypervisor doesn’t just detach the EBS volumes; it deletes them. Well, it deletes any volume where the DeleteOnTermination attribute is set to true (which, and this is crucial, is the default for the root volume created from the AMI at launch time).

The instance itself briefly enters the shutting-down state and then moves to terminated. It stays visible in your console for an hour (so you can mourn your loss) before it vanishes forever. All that remains is a ghost in the form of a CloudTrail log entry, proving it once existed.

To terminate an instance, you run:

aws ec2 terminate-instances --instance-ids i-1234567890abcdef0

The “DeleteOnTermination” Landmine

This is the single biggest “oh crap” moment for newcomers. You meticulously added a 500 GB data volume, filled it with important stuff, and then terminated the instance. Poof. The data volume is gone too. Why? Because when you attach a volume at launch, its DeleteOnTermination attribute defaults to false. But the root volume? That defaults to true.

The best practice is to never rely on the default. Always explicitly set these attributes at launch. The AWS CLI makes this clear, if a bit verbose. Here, we launch an instance where the root volume will be deleted on termination (bad idea for a long-lived instance) but the additional data volume (/dev/sdf) will be preserved.

aws ec2 run-instances \
    --image-id ami-0c02fb55956c7d316 \
    --instance-type t3.micro \
    --block-device-mappings "[{\"DeviceName\":\"/dev/xvda\",\"Ebs\":{\"DeleteOnTermination\":true}},{\"DeviceName\":\"/dev/sdf\",\"Ebs\":{\"DeleteOnTermination\":false}}]"

If you have a running instance and you’re suddenly struck with the fear of God about this setting, you can check it. Describe the instance and look for the BlockDeviceMappings.

aws ec2 describe-instances --instance-ids i-1234567890abcdef0 --query "Reservations[].Instances[].BlockDeviceMappings"

When to Stop, When to Terminate

  • Stop when you’re done for the day but need to pick up tomorrow. Think development environments, nightly batch processing servers, or any stateful system you need to pause. You’re saving money on compute costs but paying a pittance for storage.
  • Terminate when you’re truly done. This is for auto-scaling, temporary processing nodes, or any instance you consider cattle, not pets. If you designed your system correctly (data on external, persisted storage, configuration in user data scripts), termination should be a non-event. The ability to destroy and recreate instances on a whim is the superpower of the cloud.

One final, critical edge case: you cannot stop an instance that has an Amazon EBS volume encrypted with a custom KMS key from another account. The hypervisor needs permission to that key to re-attach the volume on start. If it can’t access the key, it can’t start the instance. It’s a classic “break-glass” scenario—make sure you have a plan for this if you’re using cross-account KMS keys.

So choose your button wisely. Stop is “see you later.” Terminate is “goodbye.” Unless you messed up the DeleteOnTermination flag, in which case it’s “I will never financially recover from this.”