04 / 09

What is the significance of the root volume in an EC2 instance?

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.

EBS-Backed Root Volume (Most Common)
  1. 1

    The OS is stored on a network-attached EBS volume

  2. 2

    Instance can be stopped and restarted — data persists on the EBS volume

  3. 3

    By default, the root EBS volume is deleted when the instance is terminated (DeleteOnTermination = true)

  4. 4

    You can change DeleteOnTermination to false to keep the volume after termination

  5. 5

    Supports snapshots for backup and AMI creation

  6. 6

    Can be encrypted using AWS KMS

  7. 7

    Supports volume type changes (gp2, gp3, io1, io2) for performance tuning

  8. 8

    Boot time is typically faster and more reliable than instance store

Instance Store-Backed Root Volume (Ephemeral)
  1. 1

    The OS is stored on physically attached NVMe/SSD storage on the host server

  2. 2

    Extremely high I/O performance — no network latency

  3. 3

    Data is permanently LOST when the instance is stopped, terminated, or the host fails

  4. 4

    Cannot be stopped — only rebooted or terminated

  5. 5

    Not suitable for production data storage without external replication

  6. 6

    Best for temporary scratch space, caches, or buffer data

Root Volume Best Practices
  1. 1

    Always use gp3 (General Purpose SSD v3) for root volumes — it is cheaper and faster than gp2

  2. 2

    Enable encryption on root volumes for security compliance (HIPAA, PCI-DSS)

  3. 3

    Set DeleteOnTermination to false for critical instances to prevent accidental data loss

  4. 4

    Take regular EBS snapshots of root volumes for backup and disaster recovery

  5. 5

    Size the root volume appropriately — avoid running out of OS disk space in production

  6. 6

    Separate application data and logs onto a dedicated EBS volume, not the root volume

Modify Root Volume DeleteOnTermination Setting
Difficulty: 5/10
Topics: root volume lifecycle, EBS vs instance store, snapshot & backup

Scenario Questions

0-2 years experience
  1. 1

    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?

  2. 2

    How would you increase the size of a running instance's root volume without losing the data on it?

  3. 3

    What would you expect to happen if you attempted to delete the root EBS volume while the instance is still running?

2-5 years experience
  1. 1

    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.

  2. 2

    When deciding between an instance‑store root volume and an EBS‑backed root volume for a web server, what trade‑offs do you consider?

  3. 3

    Explain why you might want to encrypt the root volume and what impact that has on instance launch time and backup.

5-8 years experience
  1. 1

    Design a strategy for handling root‑volume snapshots across a fleet of auto‑scaling instances to ensure quick recovery while keeping storage costs low.

  2. 2

    Your team is adopting immutable infrastructure. How would you leverage the characteristics of the root volume to support that pattern at scale?

  3. 3

    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?

8+ years experience
  1. 1

    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?

  2. 2

    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.

Follow-up Questions

  • How do you ensure a consistent snapshot of the root volume?
  • What changes if the root volume is an instance store instead of EBS?
  • Can you walk me through the steps to encrypt an existing root volume?