EBS

Introduction

• Elastic Block Store (EBS) is a block based storage per a AZ, works like a hard drive for EC2.

• EBS Options:

  • General Purpose SSD (GP2)

    • 3 IOPS per GB, min: 100 IOPS, burst to 3,000 IOPS. max 16,000 IOPS

    • Volume size: 1GB ~ 16TB. (More size, more speed. +1TB = +3,000 IOPS. So around 5.x TB, the limited IOPS is reached.)

  • Provisioned IOPS SSD (IO1)

    • Min: 100 IOPS, max: 64,000 (SR-IOV for Nitro compatible EC2 instances), 32,000 (others).

    • Volume size: 4GB ~ 16TB. (Size and IOPS are independent).

    • Good for: Large RDB, NoSQL DB

  • Throughput Optimized HDD (ST1)

    • For data being read/written sequentially, like:

      • Throughput: 500 MB/s

      • Volume size: 500 GB ~ 16 TB

      • Good for: Big Data, Data warehousing, Log processing

      • HDD is not a bootable volume

  • Cold HDD (SC1)

    • Throughput: 250 MB/s

    • Volume size: 250GB ~ 16TB

    • Good for: infrequent accessing data. Ex.file Server

    • HDD is not a bootable volume

  • Magentic HDD (standard)

    • Lowest cost of bootable EBS volume types

Feature

• EBS can be mounted to EC2 instance only in the same AZ.

• One EBS can only be mounted to one instance at a time, instead use EFS.

• On an EBS-backed instance, the root EBS volume would be deleted with EC2 termination by default.

• Encyption

  • Non-root volume encryption

    • Create a snapshot of the EBS volume

    • Copy the snapshot and encrypt the new one

    • Then create a volume from the snapshot

    • Detach the original volume and attach the new encrypted EBS to the same device name of the instance

  • Root volume encryption

    • Stop the instances and create AMIs

    • Copy the AMIs to the same region and select the "Encrypt target EBS snapshots".

    • Redeploy the instances using the AMI copies you made

  • Additional volumes can be encrypted

  • Once encryption enabled, below are also encrypted:

    • Data at rest inside the volume

    • All data moving between the volume and the instance

    • All snapshots created from the volume

    • All volumes created from those snapshots

• Volume change

  • Volume can only be scaled up

  • Once change is made, another change would be after 6 hours.

  • Can be changed on the fly (except for Magnetic standard)

Volumes vs Snapshots

• Volumes (hard drive like C Disk in Windows) exist on EBS.

• Snapshots exist on S3.

• Can take a snapshot of a volume, recommend to detach it then do it. (Can still do it when it's attached.)

• EBS backups need IO, so don't do it when system is busy.

• Snapshots are incremental, only changed parts are moved to S3.

• Snapshots can do copy to a different AZ or region (for DR)

• Volumes restored from snapshot need to be pre-warmed (using fio or dd command to read the entire volume)

• Can share snapshots only when they are not encrypted

• Can create AMI from Snapshot

• Snapshots can be automated with Amazon Data Lifecycle Manager.

  • Snapshots themselves still have costs.

  • Snapshots can only be created every 2, 3, 4, 6, 8, 12, 24 hours.

  • The automation can be cross region.

RAID

• RAID (Redundant Array of Independent Disks)

  • RAID 0 - striped (make multi-disks as one), no redundancy, good performance

  • RAID 1 - mirrored, redundancy

  • RAID 5 - good for reads, bad for writes (AWS doesn't recommend ever putting RAID 5's on EBS)

  • RAID 10 - mirror then stripe, good redendancy and performance

  • RAID 01 - stripe then mirror, good redendancy and performance

  • RAID on EBS is generally not needed, and AWS do not recommend RAID configurations other than RAID0 & RAID1.
• Ways to flush the application cache for taking a snapshot:

  • Freeze the application

  • Unmount the RAID

  • Shutdown EC2 instance

Instance Store vs EBS

• Instances by default don't come with EBS volumes, it's attached intentionally.

• Pros:

  • Better IO performance

  • Good for buffer / cache for temporary data

  • Data can survive after reboots

• Cons:

  • Can't create snapshot. (Only EBS volumes can.)

  • Can't resize.

  • Instance Store is ephemeral.

    • On stop or termination, the instance store is lost.

    • Data needs to be backup by yourself.

      • The AMI CLI tools can be used to create a bundle and upload it to S3.

      • Then register the AMI to the file in the S3 bucket.

Local EC2 Instance Store

• Physical disk attached to the physical servcer where your EC2 is. Very high IOPS (can be 1.4M IOPS).

• Disks up to 7.5 TB, stripeped to reach 30 TB. (can change over time)

• Risk of data loss if hardware fails.

Amazon machine Image (AMI) root device types (EBS vs Instance Store)

• Instance store can't be stopped. If the host fails, the data is lost.

• EBS can be stopped. If the host stops, the data will remain.

• Both can be rebooted, and data will remain.

• By default, both root volumes will be deleted with EC2 termination. However EBS can be kept with option.

Scenario and practice

• If need an EBS to be mounted to an EC2 intance in a different AZ / Region:

  • Create a snapshot of the EBS

  • Create a volume from the snapshot and select the AZ of the EC2 instance

  • Mount that new volume to EC2 instance

• If need to copy an EC2 instance to a different AZ / Region:

  • Create an AMI from a snapshot or an EBS volume

  • Launch EC2 instance from AMI