Skip to content

AWS Updated 2026-09-28

EC2 stop vs terminate vs hibernate: what you lose with each

Stop an EC2 instance when you want it back unchanged, hibernate it when you also need what is in memory, and terminate it only when you can rebuild it. Each action discards something different, so knowing what survives keeps you from losing data or paying for forgotten disks.

If you are pausing a dev server overnight or retiring an old instance, choosing between EC2 stop, hibernate and terminate comes down to what you need to keep. Stop it if you want the same machine back later with its disks intact. Hibernate it if you also want its memory back, which only works if hibernation was turned on at launch. Terminate it only when you can rebuild it, because there is no undo.

Each action throws away something different. Stopping keeps your EBS volumes (the network disks attached to the instance), the instance ID and the private IP. It loses RAM, anything on instance store (temporary disks on the physical host) and the auto-assigned public IP. Terminating deletes the instance and, by default, its root disk. Hibernating saves RAM to the encrypted root volume so the machine resumes where it left off. The costly mistakes here come from not checking where your data lives before you click.

What you are deciding

The real decision is what you need to survive the pause, and what you are willing to keep paying for while paused.

Stop ends compute billing but keeps every EBS volume billing at normal storage rates. What survives: all EBS volumes and their data, the instance ID, the private IP, Elastic IPs, network interfaces, and the instance configuration. What you lose: everything in RAM, everything on instance store (ephemeral) volumes — permanently, see why instance store data vanishes — the auto-assigned public IPv4, and your capacity slot on the host. That last one matters: a stopped instance is not guaranteed to start again immediately if its type is scarce in the AZ.

Terminate ends all billing for the instance and, by default, deletes the root EBS volume with it — DeleteOnTermination defaults to true on root volumes and false on additionally attached data volumes. So a terminated instance typically takes its operating system disk to the grave but leaves data volumes orphaned (and still billing) in EC2 > Volumes. Elastic IPs are released from the instance but stay allocated to your account, where they continue to bill while unattached. There is no undo. Termination protection (DisableApiTermination) exists precisely because of that.

Hibernate is a stop that first writes RAM contents to the root EBS volume, so a start restores running processes, caches, and open connections’ local state instead of cold-booting. The prerequisites are strict: hibernation must be enabled at launch (not retrofittable), the root volume must be encrypted and large enough to hold RAM, RAM must be within the supported limit (up to 150 GiB depending on type and OS), and the instance type and OS must support it. An instance cannot stay hibernated for more than 60 days. While hibernated you pay for EBS storage — including the space holding the RAM image — but no compute.

What to check first

  • Where is the data? EBS survives stop; instance store does not survive stop or terminate. RootDeviceType and the block device mapping tell you what you have.
  • What is DeleteOnTermination set to on each volume? This flag, not your intention, decides what terminate destroys.
  • Is anything pointing at the public IP? Without an Elastic IP, stop/start hands you a new address.
  • Was hibernation enabled at launch? If not, hibernate is simply not on the menu for this instance.
  • Is the type scarce? Stopping a GPU or newest-generation instance risks a capacity fight when you start it again.

How to verify

Check what a terminate would actually delete, and whether hibernation is available:

# DeleteOnTermination per attached volume, plus hibernation flag
aws ec2 describe-instances --instance-ids i-0123456789abcdef0 \
  --query 'Reservations[].Instances[].[HibernationOptions.Configured,BlockDeviceMappings[].[DeviceName,Ebs.VolumeId,Ebs.DeleteOnTermination]]'

# Any instance store volumes on this type?
aws ec2 describe-instance-types --instance-types m5d.xlarge \
  --query 'InstanceTypes[].InstanceStorageInfo'

In the console, the same facts live under EC2 > Instances > Storage tab. Termination protection is under Actions > Instance settings > Change termination protection. The full state-change reference is at https://docs.aws.amazon.com/ec2/, and if you are weighing pause-versus-keep-running economics, https://calculator.aws/ prices the EBS-only cost of a stopped fleet honestly.

The approach

  1. Stop for pauses measured in hours to weeks. Dev boxes overnight, staging between releases, anything you will want back as-is. Accept the changed public IP or attach an Elastic IP first. Copy anything on instance store to EBS or S3 before stopping.
  2. Hibernate for expensive warm-up state. If the instance takes twenty minutes to rebuild caches, load models into memory, or re-establish long computations, hibernation buys that time back at the cost of EBS space for the RAM image. Decide at launch time — it cannot be added later — and remember the 60-day ceiling.
  3. Terminate for anything you can rebuild. If the instance came from an AMI, a launch template, or infrastructure-as-code, termination is the clean end state: no idle EBS billing, no zombie inventory. Snapshot first if there is any doubt about what lives on the volumes.
  4. Before terminating a pet, walk the volume list. Set DeleteOnTermination deliberately, snapshot the root volume, and check for orphaned Elastic IPs afterward — unattached ones bill until released.
  5. Protect what must never die. Termination protection on stateful singletons, stop protection on instances whose capacity slot you cannot afford to lose, and scheduled backups on everything whose disks matter.

When this is the wrong move

Stopping instances is the wrong cost lever for production fleets — that is what Auto Scaling, right-sizing, and commitment discounts are for; a stopped production node is just unavailability you scheduled yourself. Hibernation is the wrong tool for long-term archival of a machine state (60-day limit, and an AMI is cleaner anyway). And terminate-then-rebuild is the wrong reflex on an instance nobody has an AMI or recipe for — archaeology on a live disk beats archaeology on a snapshot of a disk you already destroyed.

Common mistakes

  • Assuming stop preserves everything — RAM and instance store are gone, and on *d instance types (m5d, c6gd, i4i) that instance store may hold the database you cared about.
  • Terminating with a data volume attached and DeleteOnTermination accidentally set to true on it — the flag wins, not your assumption.
  • Leaving stopped instances around for months as “backups” while EBS bills accumulate — an AMI plus termination is cheaper and cleaner.
  • Counting on hibernate for an instance where it was never enabled at launch, and discovering that during the maintenance window.

Keeping it under control

  • Tag instances with an owner and a lifecycle policy (stop-nightly, never-stop, disposable) so state changes are decisions, not accidents.
  • Enable termination protection by default on stateful singletons; leave it off for ASG-managed cattle.
  • Audit DeleteOnTermination on data volumes as part of provisioning, not during the incident.
  • Sweep the account monthly for stopped instances, unattached volumes, and idle Elastic IPs — the quiet line items of an unowned account.
  • Prefer AMIs and launch templates over long-stopped instances as the way you keep “a copy of the server.”

The three verbs are simple; the losses are not symmetrical. Know what each one discards before you need the answer under pressure. If nobody on your team truly owns the AWS environment end to end, that is the root of most of these problems — Stack Harbor runs AWS accounts daily under AWS Operations, and you can book an AWS review.