Elastic Block Store

Elastic Block Store (EBS) is a storage service that creates and manages volumes based on four underlying storage types. Volumes are persistent, can be attached and removed from EC2 instances, and are replicated within a single AZ.

Volume Types

• Mechanical scl and stl; Solid State gp2 and iol
• scl: Lowest cost, infrequent access, can’t be boot volume
• stl: Low cost, throughput intensive, can’t be a boot volume
• gp2: Default, balance of IOPS/MiBis – burst pool IOPS per GB
• iol: Highest performance, can adjust size and IOPS separately

To protect against AZ failure, EBS snapshots (to S3) can be used. Data is replicated across AZs in the region and (optionally) internationally.

 

Legacy non-EBS-optimized instances used a shared networking path for data and storage communications.

EBS-optimized mode, which was historically optional and is now the default, adds optimizations and dedicated communication paths for storage and traditional data networking. This allows consistent utilization of both — and is one required feature to support higher performance storage.

 

Key Features

• Maximum volume size of 16 TiB Volumes can only be mounted to one instance at a time
• Multiple volumes can be mounted to a single instance
• Raw, unformatted block storage

– A file system must be created

– RAID is supported if the OS supports it

• Created in an Availability Zone and must be used with instances in that zone

– Automatically replicated in that zone

– Protects against hardware failure, not high availability

 

Persistence

• Attached volumes are independent of the instance

– Terminating the instance will not terminate the volume

• Root volumes, by default, terminate with the instance

– This behavior is changed by setting DeleteOnTermination attribute to false

 

Snapshots

• Images or backups of EBS volumes
• Stored in an Amazon-managed S3 bucket (charged based on volume’s total size)
• Exact copy of the original volume, Encryption included
• Incremental in nature, but full volume can be restored from any snapshot

 

EBS snapshots are a point-in-time backup of an EBS volume stored in 53. The initial snapshot is a full copy of the volume. Future snapshots only store the data changed since the last snapshot.

Snapshots can be used to create new volumes and are a great way to move or copy instances between AZs. When creating a snapshot of the root/boot volume of an instance or busy volume, it’s recommended the instance is powered off, or disks are “flushed.”

Snapshots can be copied between regions, shared, and automated using Data Lifecycle Manager (DLM).

 

Performance

EBS uses IOPS (input/output operations per second) as a performance measure, measured in KiB (kibibytes = 1024 bytes).

Burst Buckets:  Allows an EBS volume to “burst” above the baseline performance Volumes earn credits Credits are then spent whenever the volume needs more performance There is a maximum number of credits

• Not available for Provisioned IOPS SSD (I01)

• Reported as a BurstBalance metric in CloudWatch

 

SSD

Consistent performance with sequential and random operations

Good for frequent read/writes using small I/O sizes (10PS) IOPS measured with 256 KiB I/O size (chunks of data)

• One 1024 KiB operation = 4 IOPS

• Four 64 KiB sequential operations = 1 IOPS

• Four 64 KiB random operations = 4 IOPS

 

General Purpose SSD Volumes ( gp2 )

• Volume size: 1 GiB to 16 TiB
• Baseline performance: 100 to 10,000 IOPS
• 3 IOPS per GiB of volume size
• Minimum of 100 IOPS (below 33.3 GiB volume size)
• Maximum throughput = 160 MiB/s
• Burst Bucket

• 5.4 million credits to start (max 3,000 IOPS for 30 minutes)

• Credits earned at 3 IOPS per GiB of volume size

• Maximum credits = 5.4 million

• Volumes greater than 1,000 GiB never deplete (baseline = burst max)

 

Provisioned IOPS SSD volumes ( iol )

• Volume size: 4 GiB to 16 TiB
• Baseline performance: 100 to 64,000 IOPS
• User/provisioner chooses a consistent IOPS rate
• AWS SLA = 99.9 of the time within 10% of provisioned IOPS
• Maximum ratio is 50:1
• A 640 GiB volume size or greater can use maximum IOPS
• AWS recommends a ratio larger than 2:1 with provisioned IOPS volumes
• If 4,000 IOPS are needed, volume size should be less than 2,000 GiB
• Maximum throughput = 500 MiB/s

 

 

HDD

Optimal performance with large and sequential operations
Good for large streaming workloads (throughput) IOPS measured with 1024 KiB I/O size (chunks of data)

• One 1024 KiB operation = 1 IOPS

• Eight 128 KiB sequential operations = 1 IOPS

• Eight 128 KiB random operations = 8 IOPS

 

Throughput Optimized HDD volumes ( stl )

• Not supported as a boot device
• Ideal for frequently accessed and throughput intensive workloads Volume size: 500 GiB to 16 TiB
• Maximum throughput = 500 MiB/s
• Burst bucket: Credits gained at 40 MiB/s per TiB; Credit capacity = 1 TiB; Maximum burst = 500 MiB/s (volume sizes 2 TiB and larger)

Cold HDD volumes ( scl )

• Not supported as a boot device Ideal for infrequently accessed data and lowest storage cost
• Volume size: 500 GiB to 16 TiB
• Maximum throughput = 250 MiB/s Burst bucket
• Credits gained at 12 MiB/s per TiB
• Credit capacity = 1 TiB • Maximum burst = 250 MiB/s (volume sizes 2 TiB and larger)

Magnetic volumes

• Somewhat deprecated (Previous Generation volume)
• Low-cost storage for small volume sizes
• Volume Size: 1 GiB to 1 TiB
• Burst capability to hundreds of IOPS

 

Join multiple gp2, lot st1, or sc1 volumes together in a RAID 0 configuration (stripe set) to use the available bandwidth, improving throughput.

 

Cloudwatch Metrics

• Five-minute period data available at no charge
• Provisioned IOPS SSD send one-minute period data automatically
• Included metrics measure disk management

• VolumeReadBytes, VolumeWriteBytes

• VolumeReadOps, VolumeWriteOps

• VolumeTotalReadTime, VolumeTotalWriteTime

• VolumeIdleTime

• VolumeQueueLength

• Provisioned IOPS SSD (i01) volumes only:

• VolumeThroughputPercentage

• VolumeConsumedReadWri teOps

• General Purpose SSD (gp2), Throughput Optimized HDD (st1), and Cold HDD (sc1) volumes only:

• BurstBalance

 

EBS Status Checks

• Tests run every five minutes
• Returns: OK, warning, impaired, insufficient-data
• User can change the result of the impaired response

 

Resizing or changing root volumes

Modify the size, IOPS, or type of an EBS volume
The Manual Method:

1. Modify the EBS volume
2. Extend the partition to fill available space
3. Expand the filesystem in the resized partition

For Nitro-based instances (e.g. t3.micro):

For T2 instances:

 

The “Automated” Method:

• We can replace the launch configuration of an Auto Scaling group.
• In a true n-tier application that is decoupled, we should then be able to terminate instances one by one to recreate them using the new configuration.

 

Ensuring data durability upon EC2 instance termination

• By default, instance store and EBS root volumes are not backed up
• Will not persist upon termination
• Cannot stop instance store volumes, so termination is the only option
• This is why EBS volumes are recommended
• How do we save the data on a root volume?

– Uncheck “Delete on Termination” in the console: Also a CLI parameter with run-instances

– Create a snapshot before deletion

– We can create a separate volume and attach to the instance:  Attached volumes persist when the instance is terminated