Compare stopping, hibernating and terminating an EC2 instance: what happens to the instance's RAM contents, its EBS root volume, and any instance-store data in each case?
answer
- one of the three keeps memory
- memory has to land somewhere durable
- instance store belongs to the host
- enabled at launch or not at all
- a flag per volume decides deletion
basics
~20 sStopping discards RAM and instance-store data and keeps the EBS root volume. Hibernating first writes RAM to the encrypted root volume and restores it on start. Terminating is permanent and deletes volumes whose DeleteOnTermination flag is true.
solid answer
~50 sA stop shuts the guest down and releases the instance from its host: RAM and every running process are gone, instance-store data is gone with the host, and the EBS root volume plus any other EBS volumes persist untouched. Hibernation is a stop that first signals the guest to write the contents of memory into a file on the encrypted EBS root volume; on the next start that memory image is read back and processes resume where they left off. Hibernation has to be enabled at launch, needs an encrypted root volume large enough to hold RAM, and is only supported on certain instance families and AMIs. Termination is the destructive one: the instance goes to `shutting-down` then `terminated`, the instance ID is never usable again, and each attached volume is deleted or kept according to its `DeleteOnTermination` flag — which defaults to true for the root volume.
go deeper
Know the three verbs and their headline effect: stop keeps the disk but loses memory, hibernate saves memory to disk, terminate deletes the instance. Say clearly that terminate is not reversible.
Explain the mechanics: where the hibernation image is written, why the root volume must be encrypted and sized for RAM, and that DeleteOnTermination decides per volume what a termination destroys.
Demonstrate judgment about when warm memory is worth the constraints hibernation imposes, and show that you design so termination is cheap — state off the instance, rebuildable images, no surprises on instance store.
Frame the choice as a fleet policy rather than a per-instance one: which workloads may hold local state at all, what the organisation's default lifecycle is, and how you keep an expensive-to-warm workload from becoming a pet nobody dares replace.
## The state machine An EC2 instance moves through a small, fixed set of states: `pending` while it is being placed and booted, `running` once it is live, `stopping` → `stopped` when you stop it, `shutting-down` → `terminated` when you terminate it. You are billed instance-hours only in `running` (and briefly during the transitions in and out of it). `stopped` and `terminated` are both non-billing for compute, but they are wildly different in what they preserve. ## Stop `StopInstances` sends the guest an ACPI shutdown, waits for it, and then releases the virtual machine from its physical host. - **RAM**: discarded. Every process is dead; nothing resumes. - **EBS volumes**: untouched. The root volume and any data volumes stay attached and keep their contents. - **Instance store**: discarded. Those are physical disks on the host you just left. - **Billing**: instance-hours stop; EBS storage and any Elastic IP keep billing. - **Restart**: the instance is scheduled onto a different host, so the auto-assigned public IPv4 address is replaced. A stop is also the gate for attribute changes that require different hardware — the instance type, for instance, can only be modified while the instance is stopped. ## Hibernate Hibernation is a stop with a memory dump in front of it. AWS signals the guest to hibernate; the operating system writes the contents of RAM into a file on the root volume and then powers off. The instance reports as `stopped`. On the next `StartInstances`, the instance is placed on a fresh host, the memory image is read back off the root volume, and the previously running processes continue — long-running in-memory caches, JIT-warmed runtimes and loaded models come back without a cold start. The constraints are the part interviewers actually probe, because hibernation is a launch-time decision: - it must be **enabled at launch** (`HibernationOptions.Configured=true`); you cannot turn it on for an existing instance - the **root volume must be EBS and encrypted**, and large enough to hold the whole RAM image on top of the filesystem - only certain instance families, sizes and AMIs support it - instance-store data is still lost, and the public IPv4 address still changes — hibernation preserves memory, not host-lent resources - you still pay for the (now larger) EBS storage while hibernated, and nothing for instance-hours ```bash # hibernation is a launch-time property aws ec2 run-instances --image-id ami-0123456789abcdef0 \ --instance-type m5.large \ --hibernation-options Configured=true \ --block-device-mappings '[{"DeviceName":"/dev/xvda","Ebs":{"VolumeSize":60,"Encrypted":true}}]' # then, later aws ec2 stop-instances --instance-ids i-0123456789abcdef0 --hibernate ``` ## Terminate `TerminateInstances` deletes the instance. It passes through `shutting-down` to `terminated`, remains visible in the console for a short while, and then disappears. The instance ID is retired permanently. What happens to storage is decided per volume by the `DeleteOnTermination` flag in the instance's block device mappings: it defaults to true for the root volume created at launch, so by default terminating an instance destroys its root disk. Volumes you attached separately with `AttachVolume` default to false and survive as unattached volumes. Instance-store data is gone, as always. Termination is what an Auto Scaling group does on scale-in and what a Spot interruption ends with, which is why "my data was on the instance" is a losing architecture on AWS. ## Choosing between them - **Stop** when the instance is idle and you want to stop paying for compute but keep the machine — dev boxes overnight, a machine awaiting a resize. - **Hibernate** when the *warm state in memory* is the expensive part and rebuilding it takes minutes — a large in-memory cache, a licence-checked application with a slow boot. - **Terminate** when the instance is disposable, which in a well-designed system is nearly always. If the instance is rebuildable from an image plus configuration, termination is not a loss. ## Traps Candidates commonly claim hibernation "keeps the instance running cheaply" — it does not; it is a stop, and nothing executes. Others assume hibernation can be enabled after launch, or that it preserves the public IP because the memory came back. And plenty forget that a stop already loses instance-store data, which is the single most expensive surprise on storage-optimized instance families.
- Why does hibernation require the root volume to be encrypted?Because the hibernation file written to that volume is a verbatim image of RAM — it contains whatever secrets, keys and customer data the running processes held. AWS requires the root volume to be an encrypted EBS volume so that memory contents are never persisted in the clear, and requires it to be sized for the RAM image plus the filesystem.
- Can you enable hibernation on an instance that is already running?No. `HibernationOptions.Configured` is set at launch and cannot be changed afterwards, so an existing instance can never be hibernated. The practical path is to create an AMI from the instance and launch a replacement with hibernation configured, an encrypted root volume and a supported instance type.
- An Auto Scaling group scales in and removes an instance. Which of these three operations does it perform?It terminates the instance — scale-in is destructive, not a stop. Anything on instance store is gone, and any volume whose `DeleteOnTermination` flag is true goes with it. That is why state on a scaled instance must live somewhere else, and why lifecycle hooks exist to drain work before the terminate proceeds.
saying these in an interview costs you the question
- Believes a hibernated instance keeps running at a lower rate
- Thinks hibernation can be switched on after launch
- Says stopping preserves instance-store data
- Assumes terminating always keeps attached EBS volumes
- Confuses stopped billing with terminated billing