The root volume is the primary storage volume that contains the operating system of an EC2 instance. It determines boot behavior, persistence of the OS across stop/start cycles, performance characteristics, and whether data survives instance termination.
Every EC2 instance has a root volume that holds the operating system, boot loader, and base configuration derived from the Amazon Machine Image (AMI). The type of root volume — either EBS (Elastic Block Store) or Instance Store — has major implications for data persistence, instance behavior during stop/terminate operations, and overall reliability.
The OS is stored on a network-attached EBS volume
Instance can be stopped and restarted — data persists on the EBS volume
By default, the root EBS volume is deleted when the instance is terminated (DeleteOnTermination = true)
You can change DeleteOnTermination to false to keep the volume after termination
Supports snapshots for backup and AMI creation
Can be encrypted using AWS KMS
Supports volume type changes (gp2, gp3, io1, io2) for performance tuning
Boot time is typically faster and more reliable than instance store
The OS is stored on physically attached NVMe/SSD storage on the host server
Extremely high I/O performance — no network latency
Data is permanently LOST when the instance is stopped, terminated, or the host fails
Cannot be stopped — only rebooted or terminated
Not suitable for production data storage without external replication
Best for temporary scratch space, caches, or buffer data
Always use gp3 (General Purpose SSD v3) for root volumes — it is cheaper and faster than gp2
Enable encryption on root volumes for security compliance (HIPAA, PCI-DSS)
Set DeleteOnTermination to false for critical instances to prevent accidental data loss
Take regular EBS snapshots of root volumes for backup and disaster recovery
Size the root volume appropriately — avoid running out of OS disk space in production
Separate application data and logs onto a dedicated EBS volume, not the root volume
If you launch an EC2 instance with the default settings, where does the operating system live and what happens to it when you terminate the instance?
How would you increase the size of a running instance's root volume without losing the data on it?
What would you expect to happen if you attempted to delete the root EBS volume while the instance is still running?
You notice that after a recent deployment the instance fails to boot and logs point to a corrupted root volume. Walk me through how you would diagnose and recover the instance.
When deciding between an instance‑store root volume and an EBS‑backed root volume for a web server, what trade‑offs do you consider?
Explain why you might want to encrypt the root volume and what impact that has on instance launch time and backup.
Design a strategy for handling root‑volume snapshots across a fleet of auto‑scaling instances to ensure quick recovery while keeping storage costs low.
Your team is adopting immutable infrastructure. How would you leverage the characteristics of the root volume to support that pattern at scale?
If you need to migrate thousands of instances to a new AMI but must preserve data on the existing root volumes, what steps and automation would you put in place?
At a multi‑team organization, you must standardize root‑volume size, encryption, and IOPS across all environments while still allowing teams to use custom AMIs. How would you architect governance and tooling to enforce this without slowing deployments?
Discuss the long‑term cost and performance implications of using large provisioned‑IOPS root volumes for a globally distributed service, and how you would decide when to switch to a different storage approach.