# 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](https://docs.aws.amazon.com/AWSEC2/latest/WindowsGuide/nvme-ebs-volumes.html) 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](https://aws.amazon.com/about-aws/whats-new/2020/01/aws-backup-supports-cross-region-backup/).

**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](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/raid-config.html#ebs-snapshots-raid-array), 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