Instance Lifecycle: Stop, Start, Hibernate, Terminate

Every EC2 (Elastic Compute Cloud, Amazon’s virtual server service) instance moves through a small set of states during its life, and each action you take — stop, start, reboot, hibernate, terminate — changes what happens to your compute, your memory, your disks, and your network address. Getting these confused is one of the most expensive and painful mistakes a new cloud engineer can make: a single terminate can delete your data forever, and an accidental stop can lose the public IP address your DNS points at. This page explains exactly what each state and action does so you never have to guess.

The instance states

An EC2 instance is always in exactly one state. AWS reports it as the instance-state and you see it in the console and CLI.

State	What it means	Are you billed for compute?
pending	The instance is booting up (after launch or start).	No (transient)
running	The instance is on and usable.	Yes
stopping	The instance is shutting down toward stopped.	No
stopped	The instance is off. EBS disks are kept.	No (you still pay for storage)
shutting-down	The instance is being terminated.	No (transient)
terminated	The instance is gone permanently.	No

Key idea: you pay for compute only while an instance is running. But you keep paying for EBS storage (the virtual hard disks) the whole time an instance is merely stopped. Stopping saves money on compute; it does not make storage free.

Stop and start

Stop powers the instance off cleanly, like shutting down a laptop. Start boots it back up. This is the everyday way to “pause” a server you do not need overnight.

What survives a stop/start cycle:

• EBS volumes (Elastic Block Store, your persistent network-attached disks): preserved. Your operating system, files, and installed software are all still there.
• RAM (memory): wiped. Anything in memory is lost; the OS boots fresh.
• Instance store (local “ephemeral” disks physically attached to the host): lost forever. Never put data you care about here.
• Public IPv4 address: released and changes on the next start (unless you attached an Elastic IP — a permanent public IP address you reserve in your account).
• Private IP and Elastic IP: preserved.

When to use stop/start: dev and test boxes that only run during work hours, or to change an attribute that requires the instance to be off (like the instance type). When NOT to: for a quick OS-level fix where you only need a clean boot — use reboot instead, which keeps the same host, the same public IP, and the same instance store.

Console steps to stop:

1. Open the EC2 console and go to Instances.
2. Select your instance (for example i-0a1b2c3d4e5f).
3. Choose Instance state then Stop instance.
4. Confirm. The state moves running then stopping then stopped.

CLI equivalent:

aws ec2 stop-instances --instance-ids i-0a1b2c3d4e5f

Output:

{
    "StoppingInstances": [
        {
            "InstanceId": "i-0a1b2c3d4e5f",
            "CurrentState": { "Code": 64, "Name": "stopping" },
            "PreviousState": { "Code": 16, "Name": "running" }
        }
    ]
}

Start it again with:

aws ec2 start-instances --instance-ids i-0a1b2c3d4e5f

Reboot

Reboot is just an OS restart. The instance stays on the same physical host, so the public IPv4 address does not change, instance-store data is kept, and the instance never leaves the running state for long. Use reboot when you need to apply a kernel update or clear a hung process — never a stop/start unless you specifically need a different host or a config change.

aws ec2 reboot-instances --instance-ids i-0a1b2c3d4e5f

In the console: Instance state then Reboot instance.

Hibernate

Hibernate is a special kind of stop. Instead of throwing your RAM away, EC2 writes the entire contents of memory to the root EBS volume before powering off, then restores it on the next start. The OS, your running applications, and in-memory caches all come back exactly as they were — no cold boot.

When to use hibernate: long-running services with slow warm-up (large in-memory caches, JVM applications, ML model servers) where a fresh boot is costly. When NOT to: tiny stateless boxes where a normal stop/start is simpler and cheaper.

Hibernate has requirements you must meet at launch time — you cannot turn it on later:

• The root volume must be encrypted EBS, and large enough to hold all of RAM plus the OS.
• Hibernation must be enabled when you launch the instance.
• Only specific instance families and AMIs (Amazon Machine Images, the OS templates) support it.

Launch a hibernation-capable instance via CLI:

aws ec2 run-instances \
  --image-id ami-0abcdef1234567890 \
  --instance-type m6i.large \
  --key-name my-key \
  --security-group-ids sg-0a1b2c3d \
  --subnet-id subnet-0a1b2c3d \
  --hibernation-options Configured=true \
  --block-device-mappings '[{"DeviceName":"/dev/xvda","Ebs":{"VolumeSize":30,"Encrypted":true}}]'

Then hibernate it like a stop, with one extra flag:

aws ec2 stop-instances --instance-ids i-0a1b2c3d4e5f --hibernate

Cost note: while hibernated you stop paying for compute, but the saved RAM lives on your EBS volume — so a 32 GiB instance needs roughly 32 GiB of extra EBS, billed at the usual gp3 rate (about $0.08 per GiB-month in us-east-1). Big-memory hibernation is not free.

Terminate

Terminate permanently deletes the instance. This is irreversible — there is no undo, no “trash”, no recovery. By default, terminating an instance also deletes the root EBS volume, taking your operating system and any data on it with it.

Two settings protect you, and you should know both before you ever click terminate:

• Termination protection (disableApiTermination): blocks accidental termination via the API or console until you explicitly turn it off.
• DeleteOnTermination: a per-volume flag. If true (the default for the root volume), that EBS volume is deleted when the instance terminates. Extra data volumes usually default to false, but always verify.

Check what will be deleted before you terminate:

aws ec2 describe-instances --instance-ids i-0a1b2c3d4e5f \
  --query "Reservations[].Instances[].BlockDeviceMappings[].{Device:DeviceName,Volume:Ebs.VolumeId,DeleteOnTerm:Ebs.DeleteOnTermination}"

Output:

[
    {
        "Device": "/dev/xvda",
        "Volume": "vol-0a1b2c3d4e5f",
        "DeleteOnTerm": true
    }
]

That true means the root disk dies with the instance. To keep a volume, flip the flag while the instance is running:

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

Enable termination protection:

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

In the console: Actions then Instance settings then Change termination protection.

Stop vs hibernate vs reboot vs terminate

Action	RAM	Instance store	EBS volumes	Public IPv4	Reversible?
Reboot	Kept	Kept	Kept	Same	Yes
Stop	Lost	Lost	Kept	Changes	Yes (start)
Hibernate	Saved to EBS	Lost	Kept	Changes	Yes (start)
Terminate	Lost	Lost	Root deleted by default	Released	No

Best practices

• Turn on termination protection for any production instance you cannot afford to lose.
• Always run describe-instances and check DeleteOnTermination before terminating anything with data on it.
• Attach an Elastic IP if you stop/start instances but need a stable public address — otherwise the IP changes every start.
• Treat instance-store disks as scratch space only; persist anything that matters to EBS and take regular EBS snapshots.
• Use stop (not terminate) to pause dev boxes overnight and cut compute cost while keeping your setup.
• Reach for hibernate only when warm-up time genuinely hurts, and remember it consumes EBS equal to your RAM.
• Prefer reboot over stop/start when you just need a clean restart on the same host and IP.

Related Topics

• What is EC2?
• EBS volumes
• Instance store
• Elastic IP addresses
• EBS snapshots