Elastic Block Storage (EBS)

Basic Facts

• EBS is the hard disk that is attached to an EC2 instance.
• EBS is a distributed system.
• The AMI is a snapshot of an EBS volume. The AMI will be converted to a volume again before attachment.
• EBS data is persistent. It survives machine restarts and can be attached and detached from an EC2 instance.
• Not to be confused with Instance Store (ephemeral storage) – More on that below.
• EBS volume is always in the same AZ as the EC2 instance it is connected to.
• You can attach as many EBS volumes to an EC2 instance as you like. Think of these as additional HDDs.
• Cost drivers are per GB per month.

Design Questions

Think about how much storage is needed on the EC2 instance and if it needs to be persistent. Use Elastic Volumes with lower storage / IOPS, to begin with. This can grow over time and change on the fly. The file system on the OS may need to be modified to take advantage of the new volume size.

Match your EC2 instance type to the EBS type. Ensure the hardware is complimentary. Burst needs must also be taken into consideration here.

The application will dictate the EBS type required. Is the application in question throughput intensive, IO intensive, or neither?

More cost-efficient methods may be to store large data sets on S3 and access them remotely.

Delete old volumes. Take a Snapshop before deleting.

Think of using EBS optimized where necessary/possible.

Ensure Cloudwatch is configured for monitoring.

Think of using AB testing to check the right EBS type for the workload.

Set DeleteOnTermination where it makes sense to avoid costs. USE WITH CARE!

Redundancy Design

Volumes are replicated transparently by design. No need for RAID or any other redundancy strategy. Currently, 99,999% service availability is guaranteed. Durability is 0,1 – 0,2% annual failure rate (AFR).

EBS is redundant within one AZ. The SAN/disk/volume technology is managed by AWS.

EBS is AZ-specific. We can move it to another AZ or region via snapshot.

EBS Types

Media	Type	Use Case	Application	Notes
SSD	GP2	General-purpose	General-purpose use cases. Good for boot volumes.	Latency insensitive. 1GiB to 16TiB capacity. IOPS scales with capacity.
SSD	GP3			4 times faster than GP2.
SSD	IO1	IO optimized.	Business Applications. Production databases	Provisioned IOPS. 4GiB – 16TiB capacity.
SSD	IO2
HDD	ST1	Throughput optimized.	Big data applications. Log processing. Streaming applications. Data warehouse. Media transcoding.	500GiB to 16TiB. Not designed for boot volumes.
HDD	SC1	Infrequent access.	Data and Analytics. Kafka, Splunk, etc. File sharing (CIFS, NFS, etc)	500GiB to 16TiB. Not designed for boot volumes.

EBS volume size and type can be changed on the fly.

Use iostat (Linux command) to verify current use.

IOPS vs Throughput

IOPS is for quick transactions. Refers to the number of reads/writes per second. Think quick transactions.

Throughput is the number of bits read or written per second. Think bid data and large data sets.

Snapshots

Snapshots are a point-in-time copy of the EBS volume. They are incremental.

Ensure to tag Snapshots for easier housekeeping.

Snapshots are stored on S3. They must be accessed through the EBS API and cannot be accessed directly by users. They are stored as AMIs and can be used to launch instances.

Servers should be shut down before snapshot to ensure no data is lost.

Snapshots can be shared across accounts.

Snapshots can be automated with Lifecycle Manager. Volume level or instance level (all volumes).

Fast Snapshot Restore – 6 x faster restore of volumes.

Encryption

Encryption is optional – must be activated. Uses AES256 encryption. Amazon KMS. Uses Customer Master Keys (CMKs).

Encryption can be enforced for an account in a region (account level regional setting). IAM policies can prevent unencrypted volumes from being launched.

Encryption applies to:

• Data at rest inside the volume
• Data in flight between volume and instance
• Snapshots created from the volume
• Volumes created from the snapshots

Use the KMS console to create a master key.

Encryption does not have an impact on performance.

Nitro cards handle encryption offload.

Instance Store Volumes

Ephemeral storage. Data is lost after EC2 is shut down.

These are SSDs physically attached to the host running the EC2 instance via a fast NVMe (nonvolatile memory express) interface.

Cost is included in the instance itself.

Good for usecases where data is loaded from an external source for processing or if the instance is part of an autoscaling group.

Useful Links

https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/AmazonEBS.html