Which of the EBS volume types can be used as boot volumes when you create EC2 instances?

Question

Accepted Answer

Booting an operating system requires fast random I/O — reading small, scattered blocks of data quickly during the kernel and service startup process. SSD-based volumes excel at this because they are optimized for IOPS (Input/Output Operations Per Second). HDD-based volumes (st1 and sc1) are designed for sequential, throughput-heavy workloads and perform poorly on the random small-block reads that OS booting requires. AWS therefore restricts boot volumes to SSD types only. gp2 (General Purpose SSD v2) — Supported. Was the previous default boot volume type. Being replaced by gp3. gp3 (General Purpose SSD v3) — Supported and RECOMMENDED. Current default boot volume type. 20% cheaper than gp2 with better baseline performance. io1 (Provisioned IOPS SSD v1) — Supported. Used for boot volumes when consistent, high IOPS is required for the OS disk (rare, but supported for demanding applications). io2 (Provisioned IOPS SSD v2) — Supported. Most durable SSD option, used in mission-critical environments needing high IOPS on the OS volume. st1 (Throughput Optimized HDD) — NOT supported as a boot volume. Designed for large sequential reads (Hadoop, log processing). Cannot boot from st1. sc1 (Cold HDD) — NOT supported as a boot volume. Designed for infrequently accessed cold storage. Absolutely not suitable for OS boot operations. Instance Store — Not an EBS volume, but technically can be used as a boot volume on specific instance types. Data is lost on stop/terminate. gp3 — Use for most workloads: web servers, app servers, general-purpose instances, development environments. Best cost-performance ratio. io1/io2 — Use when the OS disk itself requires very high IOPS — for example, databases that do intensive random reads/writes on the OS partition, or systems with demanding startup sequences. gp2 — Avoid for new instances. AWS recommends migrating existing gp2 boot volumes to gp3 for cost savings. General rule — 99% of EC2 instances should use gp3 as the boot volume type. # Launch EC2 instance with gp3 boot volume (recommended)
aws ec2 run-instances \
  --image-id ami-0abcdef1234567890 \
  --instance-type t3.medium \
  --block-device-mappings '[{
    "DeviceName": "/dev/xvda",
    "Ebs": {
      "VolumeType": "gp3",
      "VolumeSize": 30,
      "Iops": 3000,
      "Throughput": 125,
      "DeleteOnTermination": true,
      "Encrypted": true
    }
  }]'

# Launch with io2 boot volume for high-IOPS requirement
aws ec2 run-instances \
  --image-id ami-0abcdef1234567890 \
  --instance-type r6i.xlarge \
  --block-device-mappings '[{
    "DeviceName": "/dev/xvda",
    "Ebs": {
      "VolumeType": "io2",
      "VolumeSize": 100,
      "Iops": 10000,
      "DeleteOnTermination": false,
      "Encrypted": true
    }
  }]'

# Attempting to use st1 as boot volume will result in:
# An error occurred (InvalidParameterCombination):
# The volume type 'st1' is not supported for boot volumes.

Which of the EBS volume types can be used as boot volumes when you create EC2 instances?

Only SSD-backed EBS volume types — gp2, gp3, io1, and io2 — can be used as boot (root) volumes for EC2 instances. The HDD-backed volume types (st1 and sc1) cannot be used as boot volumes because their performance characteristics are not suitable for OS boot operations.

Which of the EBS volume types can be used as boot volumes when you create EC2 instances?

Only SSD-backed EBS volume types — gp2, gp3, io1, and io2 — can be used as boot (root) volumes for EC2 instances. The HDD-backed volume types (st1 and sc1) cannot be used as boot volumes because their performance characteristics are not suitable for OS boot operations.

Scenario Questions

Follow-up Questions