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:
- EBS gp3 for persistent data
- 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