AWS Instance Storage Deep Dive: EBS vs SSD Technical Differences and Best Practices for EC2 Configuration


1 views

When configuring EC2 instances, the storage options present a common point of confusion. The "Instance Storage (GB)" dropdown presents two choices: "EBS only" and "SSD". This appears contradictory because:

  • EBS (Elastic Block Store) is AWS's persistent block storage service
  • SSD refers to physical solid-state drives used for ephemeral instance storage

The key distinction lies in persistence characteristics:

// Example showing storage attachment in AWS CLI
aws ec2 run-instances \
    --image-id ami-0abcdef1234567890 \
    --instance-type t3.large \
    --block-device-mappings \
        "DeviceName=/dev/sda1,Ebs={VolumeSize=100,VolumeType=gp3}" \
        "DeviceName=/dev/sdb,VirtualName=ephemeral0"

Instance store volumes are physically attached to the host computer:

  • Higher performance (lower latency, higher IOPS)
  • Data persists only during instance lifetime
  • Ideal for temporary storage, cache, or buffers

Common use cases include:

# Redis configuration using instance store
dir /mnt/redis-data
appendonly yes
appendfsync everysec

EBS provides persistent storage with several volume types:

Type Description Use Case
gp3 General Purpose SSD Default for most workloads
io2 High Performance SSD Latency-sensitive apps
st1 Throughput Optimized HDD Big data, data warehouses

Consider these patterns when choosing storage:

// Terraform example combining both storage types
resource "aws_instance" "web" {
  ami           = "ami-0c55b159cbfafe1f0"
  instance_type = "m5d.large"
  
  ebs_block_device {
    device_name = "/dev/sda1"
    volume_type = "gp3"
    volume_size = 100
  }

  ephemeral_block_device {
    device_name  = "/dev/sdb"
    virtual_name = "ephemeral0"
  }
}

For database workloads, a common optimization is:

  1. EBS gp3 for persistent data
  2. Instance store for temporary tables/indices

The additional storage selection in Step 4 refers to EBS volume types:

  • SSD-backed: gp2/gp3 (general purpose) or io1/io2 (provisioned IOPS)
  • Magnetic: st1 (throughput optimized) or sc1 (cold HDD)

This selection doesn't conflict with the instance storage choice - it specifies parameters for attached EBS volumes.

Sample fio test comparing storage types:

[global]
ioengine=libaio
direct=1
runtime=60

[ebs-test]
filename=/dev/nvme1n1
rw=randread
iodepth=32
numjobs=4

[instance-store-test]
filename=/dev/nvme2n1
rw=randwrite
iodepth=16
numjobs=2

Typical results show instance store providing 2-3x higher IOPS for random workloads.


When configuring EC2 instances, the storage options fundamentally differ in architecture:

// Architecture comparison pseudocode
if (storageType == "Instance Store SSD") {
    // Physically attached to host server
    // Ephemeral storage (data lost on instance termination)
    performance = "Very High IOPS";
    useCase = "Temporary cache, scratch disks";
} else if (storageType == "EBS") {
    // Network-attached persistent storage
    // Survives instance termination
    performance = "Configurable (gp2/gp3/io1/io2)";
    useCase = "Databases, persistent data";
}

The dropdown in Instance Storage (GB) refers specifically to ephemeral SSD volumes physically attached to the host server. This contrasts with EBS volumes which are network-attached. Example scenarios:

# High-performance computing instance with NVMe SSD
aws ec2 run-instances \
    --instance-type i3en.2xlarge \
    --block-device-mappings "DeviceName=/dev/sdb,VirtualName=ephemeral0" \
    --count 1

Key characteristics of instance store SSDs:

  • Lower latency (microsecond response times)
  • Higher throughput (up to 16 GB/s for NVMe)
  • No additional cost (capacity included in instance price)

This refers to EBS volume types, completely separate from the instance store selection:

Type Performance Use Case
gp3 (SSD) Baseline 3000 IOPS, 125MB/s General purpose workloads
io2 (SSD) Up to 256,000 IOPS Mission-critical databases
st1 (HDD) 500MB/s throughput Big data analytics

For optimal performance with instance store volumes:

#!/bin/bash
# RAID 0 configuration for instance store volumes
mdadm --create /dev/md0 --level=0 --raid-devices=2 /dev/nvme1n1 /dev/nvme2n1
mkfs.xfs /dev/md0
mount /dev/md0 /mnt/scratch

When combining EBS and instance store:

// CloudFormation snippet showing both storage types
Resources:
  MyInstance:
    Type: AWS::EC2::Instance
    Properties:
      InstanceType: r5d.2xlarge
      BlockDeviceMappings:
        - DeviceName: /dev/sda1
          Ebs:
            VolumeType: gp3
            VolumeSize: 100
        - DeviceName: /dev/sdb
          VirtualName: ephemeral0

Sample fio test results (4k random reads):

  • Instance Store (NVMe): 250,000 IOPS @ 0.3ms latency
  • EBS io2 Block Express: 256,000 IOPS @ 1.2ms latency
  • EBS gp3: 16,000 IOPS @ 2.4ms latency

Remember that instance store requires data lifecycle management:

# Automate backup to S3 before instance termination
aws s3 cp /mnt/scratch/important-data s3://my-backup-bucket/ \
    --recursive \
    --region us-west-2