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.

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

PreviousDynamoDBNextEFS

Last updated

Was this helpful?