> For the complete documentation index, see [llms.txt](https://ysfang82.gitbook.io/development-notes/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://ysfang82.gitbook.io/development-notes/aws-notes/service/storage/ebs.md). # 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 --- # Agent Instructions This documentation is published with GitBook. GitBook is the documentation platform designed so that both humans and AI agents can read, navigate, and reason over technical content effectively. Learn more at gitbook.com. ## Querying This Documentation If you need additional information that is not directly available in this page, you can query the documentation dynamically by asking a question. Perform an HTTP GET request on the current page URL with the `ask` query parameter, and the optional `goal` query parameter: ``` GET https://ysfang82.gitbook.io/development-notes/aws-notes/service/storage/ebs.md?ask=&goal= ``` `ask` is the immediate question: it should be specific, self-contained, and written in natural language. `goal` is optional and describes the broader end goal you are ultimately trying to accomplish on behalf of the user. GitBook uses it to tailor the answer towards what is most useful for that goal. The response will contain a direct answer to the question and relevant excerpts and sources from the documentation. Use this mechanism when the answer is not explicitly present in the current page, you need clarification or additional context, or you want to retrieve related documentation sections.