EC2 Stop vs. Terminate: What Actually Happens to Your EBS Data

You stopped your EC2 instance to cut costs over the weekend — but now you're second-guessing yourself: did you just risk losing everything on that volume? Understanding the precise difference between Stop and Terminate is one of the most operationally critical distinctions in AWS, and getting it wrong can mean permanent, unrecoverable data loss.

TL;DR

Dimension Stop Terminate
Instance State Stopped (restartable) Terminated (permanent)
EC2 Billing No instance-hour charges while stopped No instance-hour charges after termination
Root EBS Volume Persists, remains attached Deleted by default (configurable)
Additional EBS Volumes Persist, remain attached Persist by default (configurable)
Instance Store (ephemeral) Data is lost on stop Data is lost on termination
Elastic IP Retained (but billed if unassociated) Disassociated from instance
Private IP Retained Released
Public IP (non-EIP) Released on stop, new one on start Released
RAM Contents Lost (unless Hibernate is enabled) Lost
Reversible? Yes — Start the instance No — Permanent action

The Instance Lifecycle: A State Machine View

An EC2 instance is a state machine. Stop and Terminate are two distinct state transitions with very different downstream effects on attached resources. The diagram below maps the full lifecycle.

stateDiagram-v2 [*] --> pending : "Launch Instance" pending --> running : "Boot Complete" running --> stopping : "Stop Action" stopping --> stopped : "OS Shutdown Complete" stopped --> running : "Start Action" running --> hibernating : "Hibernate Action" hibernating --> stopped : "RAM saved to EBS" running --> shutting_down : "Terminate Action" stopped --> shutting_down : "Terminate Action" shutting_down --> terminated : "Cleanup Complete" terminated --> [*]
  1. pending → running: Instance boots; EBS root volume is attached and in-use.
  2. running → stopping → stopped: OS is shut down gracefully. The instance is frozen but all EBS volumes remain attached. No compute charges accrue.
  3. stopped → running: Instance restarts, potentially on different underlying hardware. EBS data is fully intact.
  4. running → shutting-down → terminated: A one-way door. By default, the root EBS volume is deleted. The instance record eventually disappears from the console.
  5. Any state → terminated: Force-termination is possible from most states.

Architecture: What Happens to Your Storage

The most consequential difference is storage behavior. The diagram below shows the fate of each storage type under both actions.

graph TD Instance["EC2 Instance"] --> RootEBS["Root EBS Volume
/dev/xvda"] Instance --> ExtraEBS["Additional EBS Volume
/dev/xvdb"] Instance --> InstStore["Instance Store
ephemeral0"] RootEBS --> StopRoot["STOP:
State: in-use
Data: Intact
Billed: Yes"] RootEBS --> TermRoot{"TERMINATE:
DeleteOnTermination?"} TermRoot -->|"true (default)"| TermRootDel["Volume DELETED
Data: Gone"] TermRoot -->|"false (configured)"| TermRootKeep["Volume survives
State: available"] ExtraEBS --> StopExtra["STOP:
State: in-use
Data: Intact
Billed: Yes"] ExtraEBS --> TermExtra{"TERMINATE:
DeleteOnTermination?"} TermExtra -->|"false (default)"| TermExtraKeep["Volume survives
State: available"] TermExtra -->|"true (configured)"| TermExtraDel["Volume DELETED
Data: Gone"] InstStore --> StopInst["STOP:
Data: PERMANENTLY LOST"] InstStore --> TermInst["TERMINATE:
Data: PERMANENTLY LOST"] style TermRootDel fill:#ff4d4d,color:#fff style TermExtraDel fill:#ff4d4d,color:#fff style StopInst fill:#ff4d4d,color:#fff style TermInst fill:#ff4d4d,color:#fff style TermRootKeep fill:#2ecc71,color:#fff style TermExtraKeep fill:#2ecc71,color:#fff style StopRoot fill:#3498db,color:#fff style StopExtra fill:#3498db,color:#fff
  1. On Stop: The EBS root volume and any additional EBS volumes remain attached to the (stopped) instance. Their state is in-use. You continue to pay EBS storage costs.
  2. On Stop (Instance Store): All data on instance store (ephemeral) volumes is immediately and permanently erased. This is a hardware-level wipe — there is no recovery path.
  3. On Terminate (Root EBS): The DeleteOnTermination flag governs this. It defaults to true for root volumes — meaning the volume is deleted when the instance terminates.
  4. On Terminate (Additional EBS): The DeleteOnTermination flag defaults to false for non-root EBS volumes — they persist as available, unattached volumes after termination.
Analogy: Think of Stop like putting your laptop into sleep mode and locking it in a drawer. The hard drive is untouched; you just aren't paying for electricity. Terminate is like sending the laptop to a shredder — the hard drive (root volume) is destroyed by default, unless you specifically told the shredder to eject it first (DeleteOnTermination=false).

Deep Dive: EBS Volume Behavior

The DeleteOnTermination Flag

This attribute is set per-volume at instance launch and controls whether an EBS volume is deleted when its attached instance is terminated. It can be modified while the instance is running or stopped.

Check the current flag value via AWS CLI:

aws ec2 describe-instances \
  --instance-ids i-0abcdef1234567890 \
  --query "Reservations[].Instances[].BlockDeviceMappings[].{Device:DeviceName,DeleteOnTermination:Ebs.DeleteOnTermination}" \
  --output table

Modify the flag on a running or stopped instance (protect your root volume):

aws ec2 modify-instance-attribute \
  --instance-id i-0abcdef1234567890 \
  --block-device-mappings '[{"DeviceName":"/dev/xvda","Ebs":{"DeleteOnTermination":false}}]'

Setting DeleteOnTermination=false on the root volume is a critical safety net for production instances. If the instance is accidentally terminated, the root volume survives as an unattached EBS volume that you can re-attach or snapshot.

EBS Costs While Stopped

Stopping an instance eliminates EC2 compute charges, but EBS volumes continue to accrue storage costs regardless of instance state. If cost elimination is the goal, you must snapshot the volume, delete it, and restore from the snapshot when needed. Pricing and limits vary — always check the official AWS documentation.

Hibernate: The Third Option

Standard Stop discards RAM contents. Hibernate is a special stop mode that saves the in-memory state (RAM) to the root EBS volume before shutting down, allowing the instance to resume exactly where it left off — open connections, running processes, and all.

Behavior Stop Hibernate
RAM contents saved No Yes (written to root EBS)
Boot time on resume Full OS boot Near-instant resume
Root EBS requirement Standard Must be encrypted; must have enough free space for RAM dump
Instance type support All EBS-backed Specific instance families only

Hibernate must be enabled at launch time — it cannot be enabled on an already-running instance.

Termination Protection: Your Last Line of Defense

AWS provides a Termination Protection flag that prevents accidental termination via the console, CLI, or API. It does not protect against termination triggered by Auto Scaling or Spot interruptions.

Enable termination protection:

aws ec2 modify-instance-attribute \
  --instance-id i-0abcdef1234567890 \
  --disable-api-termination

Verify the setting:

aws ec2 describe-instance-attribute \
  --instance-id i-0abcdef1234567890 \
  --attribute disableApiTermination

Decision Framework: Which Action Should You Take?

graph TD Start(["I want to pause my EC2 instance"]) --> Q1{"Do you need the instance
again in the future?"} Q1 -->|"No"| Q2{"Do you need to preserve
any EBS volumes?"} Q1 -->|"Yes"| Q3{"Do you need RAM state
preserved on resume?"} Q2 -->|"No"| Terminate["TERMINATE
Default flags apply"] Q2 -->|"Yes"| SetFlag["Set DeleteOnTermination=false
on volumes, then TERMINATE"] Q3 -->|"No"| Stop["STOP
Safe — EBS data intact"] Q3 -->|"Yes"| HibCheck{"Was Hibernate enabled
at launch?"} HibCheck -->|"Yes"| Hibernate["HIBERNATE
RAM saved to EBS"] HibCheck -->|"No"| Stop2["STOP (only option)
RAM contents will be lost"] style Terminate fill:#e74c3c,color:#fff style SetFlag fill:#e67e22,color:#fff style Stop fill:#2ecc71,color:#fff style Stop2 fill:#2ecc71,color:#fff style Hibernate fill:#3498db,color:#fff

Operational Checklist Before Terminating

🔽 [Click to expand] Pre-Termination Safety Checklist
  1. ✅ Snapshot all EBS volumes you want to preserve:
    aws ec2 create-snapshot --volume-id vol-0abcdef1234567890 --description "Pre-termination backup"
  2. ✅ Verify DeleteOnTermination flags for all attached volumes using describe-instances.
  3. ✅ Note your Elastic IP associations — EIPs are disassociated on termination but not released (you'll be billed for unassociated EIPs).
  4. ✅ Export any data from instance store volumes — this data is gone the moment the instance stops or terminates.
  5. ✅ Check for dependent resources — Load balancer target groups, Auto Scaling groups, or Route 53 health checks pointing to this instance.
  6. ✅ Deregister from load balancers if applicable to avoid 502/503 errors during the transition.
  7. ✅ Review IAM instance profile — document the role ARN (e.g., arn:aws:iam::123456789012:role/MyInstanceRole) for re-attachment to a replacement instance.

Glossary

Term Definition
EBS (Elastic Block Store) Network-attached, persistent block storage for EC2. Data survives instance stop and (by configuration) termination.
Instance Store Physically attached ephemeral storage on the host machine. Data is lost on stop, hibernate, or termination — no exceptions.
DeleteOnTermination A per-volume EBS attribute that controls whether the volume is automatically deleted when its attached instance is terminated.
Termination Protection An instance-level flag (DisableApiTermination) that blocks termination via the API, CLI, or console.
Hibernate A stop mode that persists RAM contents to the encrypted root EBS volume, enabling fast resume without a full OS boot.

Next Steps

Related Posts

Comments

Post a Comment

Popular posts from this blog

EC2 No Internet Access in Custom VPC: Attaching an Internet Gateway and Fixing Route Tables

Launching an EC2 instance in a custom VPC only to find it cannot reach the internet is one of the most common networking pitfalls in AWS — and it almost always comes down to two missing pieces: an Internet Gateway (IGW) and a correctly configured Route Table. This post walks you through the exact architecture, the root cause, and the precise steps to fix it. TL;DR Step Action Why It Matters 1 Create and attach an Internet Gateway to your VPC Without an IGW, there is no path between your VPC and the public internet 2 Add a 0.0.0.0/0 route pointing to the IGW in your subnet's Route Table The route table is the traffic director — without this entry, outbound packets have nowhere to go 3 Assign a Public IP or Elastic IP to the EC2 instance The IGW performs NAT only for instances with a public IP address 4 Verify Security Group allows outbound traffic Security Groups are stateful firewalls; outbound rules...
Read more

EC2 SSH Connection Timeout: The Exact Security Group Rules You Need to Fix It

You've launched a fresh EC2 instance, fired up your terminal, and run ssh ec2-user@<your-ip> — only to watch the cursor hang until Connection timed out kills your hope. This is one of the most common EC2 onboarding blockers, and it almost always traces back to a misconfigured Security Group inbound rule. TL;DR Check What to Verify Correct Value Protocol Security Group inbound rule protocol TCP Port Destination port in the inbound rule 22 Source Allowed source CIDR or IP Your public IP (e.g., 203.0.113.10/32 ) or 0.0.0.0/0 for testing Instance State EC2 instance status checks 2/2 checks passed Subnet Route Table Route to Internet Gateway (public subnet) 0.0.0.0/0 → igw-xxxxxxxx Public IP / EIP Instance has a reachable public address Public IPv4 or Elastic IP assigned Why "Connection Timed Out" Specifically? A timeout (as opposed to Connection refused ) means your TC...
Read more

IAM User vs. IAM Role: Why Your EC2 Instance Should Never Use a User

Choosing between an IAM User and an IAM Role is one of the most consequential security decisions in AWS — get it wrong and you either expose long-lived credentials or block your application entirely. This post cuts through the confusion and gives you a definitive answer for the EC2-to-S3 access pattern. TL;DR — Quick Comparison Dimension IAM User IAM Role Identity type A person or a static service account An assumable identity for AWS services, users, or external principals Credential type Long-lived Access Key ID + Secret Access Key Short-lived, auto-rotating STS tokens (max 12 h by default) Credential rotation Manual — you must rotate keys yourself Automatic — AWS rotates them transparently Stored on EC2? Yes — in ~/.aws/credentials or env vars (risky) No — delivered via the In...
Read more