EC2 Boot from EBS Explained: Architecture, Trade-offs, and an AWS CLI Workflow

Booting EC2 instances from Amazon EBS changed how teams manage compute lifecycle, persistence, and maintenance. If you run cloud infrastructure, this guide will help you understand the model, compare it with older instance-store roots, and apply it through a practical AWS CLI workflow.

Originally published on 2010-03-19; fully revised and updated.

This revision is based on the original DevOpsSchool post: Powerful New Amazon EC2 Boot Features – Introduction.

What booting from EBS introduced

The original article announced a new EC2 capability: using an EBS volume as the root device at launch time (created from an EBS snapshot), instead of relying on a local instance-store root disk. That change made EC2 instances easier to stop and restart while preserving the root filesystem.

• Root disk could be created from an EBS snapshot at boot.
• Additional EBS volumes could be attached as part of launch configuration.
• Instances could be stopped and later started with root volume state preserved.
• Compute and storage lifecycle became more decoupled for maintenance operations.

The original post also embedded a secondary historical image from All Things Distributed: serverfolders-small.jpg.

Instance-store root vs EBS-backed root

Boot and restart workflow with EBS-backed instances

The high-level lifecycle below captures the model introduced in the original announcement and still useful for operational design.

flowchart TD
    A[Choose EBS backed AMI] --> B[Create root EBS volume from snapshot]
    B --> C[Attach optional data EBS volumes]
    C --> D[Boot instance]
    D --> E[Run workload]
    E --> F[Stop instance]
    F --> G[EBS volumes persist]
    G --> H[Start instance possibly with new instance type]
    H --> D

AWS CLI example workflow

Use the following as a practical template. Replace IDs and names with values from your own account and region.

1) Discover EBS-backed AMIs

aws ec2 describe-images \
  --owners amazon self \
  --filters Name=root-device-type,Values=ebs Name=state,Values=available \
  --query 'Images[].{ImageId:ImageId,Name:Name,CreationDate:CreationDate}' \
  --output tableCode language: PHP (php)

2) Launch an instance with an additional EBS data volume

aws ec2 run-instances \
  --image-id ami-0abc1234example \
  --instance-type t3.micro \
  --key-name my-key \
  --subnet-id subnet-0123456789abcdef0 \
  --security-group-ids sg-0123456789abcdef0 \
  --block-device-mappings 'DeviceName=/dev/xvdb,Ebs={VolumeSize=50,VolumeType=gp3,DeleteOnTermination=false}' \
  --tag-specifications 'ResourceType=instance,Tags=[{Key=Name,Value=ebs-boot-demo}]'Code language: JavaScript (javascript)

3) Verify root device type

aws ec2 describe-instances \
  --instance-ids i-0123456789abcdef0 \
  --query 'Reservations[].Instances[].{RootDeviceType:RootDeviceType,RootDeviceName:RootDeviceName,State:State.Name}' \
  --output tableCode language: JavaScript (javascript)

4) Stop, change instance type, and start again

aws ec2 stop-instances --instance-ids i-0123456789abcdef0
aws ec2 wait instance-stopped --instance-ids i-0123456789abcdef0
aws ec2 modify-instance-attribute \
  --instance-id i-0123456789abcdef0 \
  --instance-type Value=t3.small
aws ec2 start-instances --instance-ids i-0123456789abcdef0

Important: changing instance type is a normal stop/start operation. Changing operating system typically requires launching from a different AMI or replacing the root volume strategy, not just a simple restart.

Operational impact for DevOps teams

• Maintenance flexibility: stop instances for planned changes and resume with persistent root state.
• Cost behavior: compute charges pause while stopped, but EBS storage charges continue.
• Safer change windows: snapshot-based backup workflows are easier to integrate.
• Clearer separation of concerns: compute scaling and disk persistence can be managed independently.

Best practices and common pitfalls

• Set DeleteOnTermination intentionally for every attached volume.
• Take snapshots before high-risk changes or major patch cycles.
• Do not assume a stopped instance keeps the same public IP unless you use an Elastic IP.
• Use encryption and IAM controls for EBS volumes and snapshots.
• Treat historical size and performance claims as time-bound; verify current AWS limits and behavior in official docs.

Rajesh Kumar

I’m Rajesh Kumar, a DevOps, SRE, DevSecOps, Cloud, and Platform Engineering expert passionate about sharing practical knowledge, real-world experiences, and industry best practices. I have worked at Cotocus and regularly write about technology, travel, investing, health, product reviews, and digital marketing through my various platforms.

I publish technical articles at DevOps School, travel stories at Holiday Landmark, stock market insights at Stocks Mantra, health and fitness guidance at My Medic Plus, product reviews at TrueReviewNow, and SEO and digital marketing strategies at Wizbrand.