Continuing Amazon’s storage services overviews, it is time to take a closer look at Elastic Block Store (EBS). It is one of the options for EC2 instances for storage. As the name suggests, it provides block level storage volume and it is visible in OS as a raw, unformatted disk. EBS volumes are created in single AZ and automatically replicated within it. They are best for the primary storage for file systems, databases, or for any applications that require fine granular updates and access to block storage. You can attach EBS volume to only one instance, which is located in the same AZ. Volume doesn’t have to be always bound to an instance and they can be detached.

Be aware of default lifecycle behavior:

• EBS volumes that are attached to a running instance automatically detach from the instance when that instance is terminated.
• EBS volumes that are created and attached to an instance at launch are deleted when that instance is terminated.

Volume types

During creation of EBS you can choose from various volume types which are intended for different use cases:

• General Purpose SSD (gp2) – suitable for most types of workloads. Baseline performance scales linearly at 3 IOPS per GB of volume size, between a minimum of 100 IOPS (at 33.33 GB and below) and a maximum of 10,000 IOPS (at 3,334 GB and above). Throughput for a gp2 volume can be calculated using the following formula, up to the throughput limit of 160 MB/s:
  volume_size_GB × IOPS_per_GB × I/O_size_KB = Throughput in MB/s
  Example for 200 GB disk: 200 GB x 3 (IOPS) x 256 KB= 153 MB/sBursting
  One caveat related to gp2 performance (also for st1 and sc1) is that it can get burst beyond its baseline performance depend on available credit. Each volume receives an initial I/O credit balance of 5.4 million I/O credits, which is enough to sustain the maximum burst performance of 3,000 IOPS for 30 minutes. This initial credit balance is designed to provide a fast initial boot. Volume can accumulate I/O credits based on volume size, bigger volume accumulates credits faster. When your volume requires more than the baseline performance I/O level, it draws on I/O credits in the credit balance to burst to the required performance level. Detailed math how credits are calculated can be found in AWS documentation.
• Provisioned IOPS SSD (io1) – volume not dependent on size when aiming for IOPS performance, good for databases or any workloads that require sustained IOPS performance. You can choose desirable IOPS with the maximum ratio of provisioned IOPS to requested volume size (in GB) 50:1. For example for 200 GB disk max IOPS would be 10 000. An io1 volume can range in size from 4 GB to 16 TB and you can provision from 100 up to 32,000 IOPS per volume.
• Throughput Optimized HDD (st1) – volume provides low-cost magnetic storage that defines performance in terms of throughput rather than IOPS. It is designed to support frequently accessed data.
• Cold HDD (sc1) – with a lower throughput limit than st1, sc1 is a good fit for large, sequential cold-data workloads. If you require infrequent access to your data and are looking to save costs, sc1 provides inexpensive block storage. Bootable sc1 and st1 volumes are not supported.
• Magnetic – Previous generation of HDD volumes.

Snapshots

Really useful EBS feature are snapshots. EBS snapshot is a point-in-time copy of EBS volume, which is lazily copied to S3 (not yours, you don’t have access to it via S3). Each snapshot is an incremental copy of data on your EBS volume, so your are billed only for changed blocks. Deleting a snapshot removes only data not needed by any other snapshot. That means when you delete one snapshot in a chain you can still revert your volume to any other snapshot, without any data loss.

Snapshot use cases:

• Backup enabler – you can use snapshot as a tool for your backup strategy. EBS snapshot does not perform flushing or locking operations by itself, so you need to do it yourself before taking snapshot. It can be achieved by just shutting down workload or, if you require consistent backups from running workloads, by scripting quiescing or using some 3^rd party tools.
• Increasing EBS volume size – during snapshoting you can change size of the volume.
• Sharing to others, like customers or community.
• Copying volumes across regions.

Encryption

You can create encrypted or unencrypted EBS volumes. When you create an encrypted volume and attach it to a supported instance type, the following types of data are encrypted:

• Data at rest inside the volume.
• All data moving between the volume and the EC2 instance.
• All snapshots created from the volume.
• All volumes created from those snapshots.

IOPS performance on encrypted volumes is similar as on unencrypted volumes, with a minimal effect on latency. Encryption and decryption are handled transparently using AWS Key Management Service (AWS KMS) customer master keys (CMKs). Basic behavior when working with encrypted volumes:

• While copying an unencrypted snapshot of an unencrypted volume, you can encrypt the copy.
• Volumes restored from this encrypted copy are also encrypted.
• You cannot remove encryption from an encrypted snapshot.

Reference Materials

EBS snapshots
Amazon EBS documentation