SSD vs EBS: Understanding Root Device Storage in AWS EC2 Instance Types


2 views

Many AWS users face this fundamental question: When launching an instance with SSD instance storage (like m3.medium), does the system automatically utilize this high-performance storage for the root device? The answer is no - and here's why that matters.

Instance store (ephemeral storage) and EBS volumes serve different purposes:

  • Instance Store: Physically attached to host machine, ultra-low latency, but ephemeral (data lost on stop/terminate)
  • EBS: Network-attached persistent storage survives instance termination

Your current setup has these characteristics:

Original AMI:
- Root Device Type: EBS (8GB)
- Instance Type: t1.micro

Target Configuration:
- Instance Type: m3.medium
- Instance Storage: 4GB SSD (unused by default)

The SSD storage remains completely unused unless you specifically mount and utilize it. Your application continues running on the EBS-backed root volume.

To leverage the instance store SSD, you have two approaches:

Option 1: Secondary Mount

Keep EBS root but mount SSD for specific workloads:

# After launching instance
sudo mkfs.ext4 /dev/xvdb  # Format the SSD
sudo mkdir /mnt/ssd
sudo mount /dev/xvdb /mnt/ssd

Option 2: Instance-store AMI

Create a new AMI with instance-store as root:

# Conversion process
aws ec2 create-image --instance-id i-1234567890abcdef0 --name "MyInstanceStoreAMI"
# Note: Must be done from running instance with instance store volumes

The launch wizard enforces EBS root because:

  • 99% of workloads need persistence
  • Instance-store AMIs can't be stopped/started (only terminated)
  • EBS enables snapshots and easy migration

Here's how to test your storage performance:

# EBS volume test
dd if=/dev/zero of=/tmp/ebstest bs=1M count=1024 conv=fdatasync

# SSD instance store test
dd if=/dev/zero of=/mnt/ssd/ssdtest bs=1M count=1024 conv=fdatasync

For most web applications:

  • Stick with EBS root for persistence
  • Use instance store SSD for temporary files/cache
  • Consider EBS-optimized instances if you need both persistence and performance

When working with AWS EC2 instance types that offer instance storage (like m3.medium's 4GB SSD), many developers assume this storage automatically becomes available for their root volume. However, this isn't how AWS architecture works.

Your AMI's root device type determines the storage behavior:


# Check root device type via AWS CLI
aws ec2 describe-images --image-id ami-1234567890abcdef0 \
    --query "Images[0].RootDeviceType"

Key observations from your scenario:

  • EBS-backed AMIs always use EBS volumes for root
  • Instance store-backed AMIs use ephemeral storage
  • The m3.medium's SSD is additional storage, not replacement

Option 1: Mount the instance store as secondary storage:


# After launching instance
sudo mkfs -t ext4 /dev/xvdb
sudo mkdir /mnt/ssd
sudo mount /dev/xvdb /mnt/ssd

Option 2: Create an instance-store backed AMI if you truly need SSD root:


# Convert EBS-backed instance to instance-store AMI
aws ec2 create-image --instance-id i-1234567890abcdef0 \
    --name "MyInstanceStoreAMI" \
    --no-reboot \
    --block-device-mappings "[{\"DeviceName\": \"/dev/sda1\",\"VirtualName\": \"ephemeral0\"}]"

EBS offers persistence and flexibility that instance stores don't provide:

  • Survives instance termination
  • Supports snapshots and AMI creation
  • Can be detached/reattached
  • Resizable without downtime

For database workloads where you need SSD performance:


# MySQL configuration using instance store
[mysqld]
datadir = /mnt/ssd/mysql
tmpdir = /mnt/ssd/tmp

Remember that instance storage is ephemeral - implement proper backup strategies if using it for critical data.