2022-01-22 Chapter 7 - Elastic Block Storage (EBS) and Elastic File System (EFS)

service-ebs-001; Elastic Block Storage (EBS) are {{c1::storage volumes}} that you can attach to your {{c1::EC2 instances}}. You can use it the same way that you use any {{c1::system disk}} e.g. create a file system, run an OS or database.

service-ebs-002; EBS is automatically {{c1::replicated}} within {{c1::a single AZ}} to protect against hardware failures.

service-ebs-003; You can dynamically change EBS {{c1::capacity}} and {{c1::volume type}} with no downtime or performance impact.

service-ebs-004; {{c1::Different types}} of EBS volumes are available.

service-ebs-005; General purpose SSD (gb2 / gp3) are types of EBS volume. These are useful for {{c1::boot devices}} and {{c1::general applications}}. They support up to {{c1::16,000}} IOPS per volume and 99.9% durability.

service-ebs-006; Provisioned IOPS (io1/io2) are types of EBS volume. These are useful for {{c1::latency sensitive use cases}} and {{c1::large (OLTP) databases}}. They support up to {{c1::64,000}} IOPS per volume.

service-ebs-007; Another type of EBS volume is throughput optimized HDD (st1). This is a low-cost HDD volume i.e. magnetic disk. Useful for {{c1::big data, ETL, data warehouse, log processing}} i.e. {{c1::throughput-optimised}} workloads. This cannot be a {{c1::boot volume}}.

service-ebs-008; Another type of EBS volume is cold HDD (sc1). This is the {{c1::lowest cost}} option. It's good choice for data requiring fewer scans per day e.g. a file server. This cannot be a {{c1::boot volume}}.

service-ebs-009; IOPS measures {{c1::the number of read and write operations per second}}. This is an important metric for {{c1::transactional}} workloads. It relates to the ability to action reads and writes very quickly.

service-ebs-010; Throughput measures {{c1::the number of bits read or written per second}}. This is an important metric for large datasets, large I/O sizes or complex queries i.e. large dataset processing.

service-ebs-011; EBS volumes are {{c1::virtual hard disks}}. You need a minimum of {{c1::one}} EBS volume per EC2 instance. This is called the {{c1::root device}} volume and is where the {{c1::operating system}} is installed.

service-ebs-012; EBS Snapshots are {{c1::point-in-time copies}} of volumes. Snapshots exist on {{c1::S3}}. They are {{c1::incremental}} i.e. only the delta since the last snapshot is saved. This implies that the first snapshot {{c1::takes longer to create}}.

service-ebs-013; For a consistent EBS snapshot, first {{c1::stop the instance}} then take the snapshot.

service-ebs-014; If the EBS volume is {{c1::encrypted}} then the snapshot is automatically {{c1::encrypted}}.

service-ebs-015; To share EBS snapshots between AWS accounts or regions, you must first {{c1::copy the snapshot to the target region}}.

service-ebs-016; EBS volumes are always in the same {{c1::AZ}} as the EC2 instance.

service-ebs-017; You can resize EBS volumes or change volume types {{c1::on the fly i.e. without stopping the instance}}.

service-ebs-018; You can encrypt EBS volumes using either {{c1::KMS}} or a {{c1::customer-managed key}}.

service-ebs-019; When EBS volumes are encrypted, all {{c1::data at rest}} is encrypted, as is {{c1::data in flight between the EC2 instance and the volume}}. In addition, {{c1::snapshots taken from the volume}} are encrypted and {{c1::volumes created from those snapshots}} are encrypted.

service-ebs-020; To encrypt an unencrypted root device volume, first create a {{c1::snapshot}}, then create an {{c1::encrypted copy of the snapshot}}. Then, create an {{c1::Amazon Machine Image (AMI)}} from the encrypted copy and use that {{c1::AMI}} to launch a new instance.

service-ebs-021; EC2 hibernation persists {{c1::an instance's RAM contents to EBS}}. This allows much faster {{c1::booting}} as it's not necessary to {{c1::reload the operating system}}.

service-ebs-022; EC2 hibernation is available on {{c1::C, M and R}} instance types running {{c1::Windows, Amazon Linux or Ubuntu}}, where the RAM is no more than {{c1::150GB}}.

service-ebs-023; EC2 instances can't be hibernated for longer than {{c1::60 days}}.

service-ebs-024; EC2 instance hibernation is available for both {{c1::on-demand}} and {{c1::reserved}} instances.

service-ebs-025; Elastic File System (EFS) is managed {{c1::network file system (NFS)}} that can be mounted on many EC2 instances. It works with EC2 instances in multiple {{c1::AZs}}. It's highly available and scalable but expensive.

service-ebs-026; EFS supports the {{c1::NFSv4}} protocol.

service-ebs-027; With EFS, you only pay for {{c1::the storage that you use}}.

service-ebs-028; EFS can scale to {{c1::petabytes}} and can support {{c1::thousands}} of concurrent NFS connections.

service-ebs-029; Data in EFS is stored across multiple {{c1::AZs within a region}} and the service promises {{c1::read-after-write consistency}}.

service-ebs-030; Amazon FSx for Windows is built on {{c1::Windows Server}} and provides a {{c1::fully-managed native Microsoft Windows file system}} to support moving Windows apps requiring file storage (SMB) to AWS.

service-ebs-031; FSx for Lustre supports {{c1::very high performance}} use cases. It can store data directly on {{c1::S3}}.

service-ebs-032; Use EFS when you need {{c1::distributed, resilient storage for Linux instances and apps}}. Use FSx for Windows when you need the same for {{c1::native Windows apps e.g. SharePoint, SQL Server, IIS}}. Use FSx for Lustre for {{c1::high-performance computing (HPC) Linux use cases like AI and machine learning}}.

service-ebs-033; {{c1::Amazon Machine Images (AMIs)}} provide the information required to launch an EC2 instance (region, OS, architecture, launch permissions and root device volume). They are region-specific.

service-ebs-034; AMIs are backed either by EBS or Instance Store. EBS implies an {{c1::EBS snapshot}}, whereas Instance Store uses templates stored in {{c1::S3}}.

service-ebs-035; Instance Store volumes are {{c1::ephemeral}} storage. They cannot be {{c1::stopped}} and if the underlying host fails then the data is {{c1::gone}}. By contrast, EBS volumes can be {{c1::stopped without data loss}}.

service-ebs-036; It's possible to {{c1::reboot}} EBS and instance store volumes without data loss.

service-ebs-037; By default, root volumes are {{c1::deleted}} when EC2 instances are terminated. However, with EBS you can optionally {{c1::tell AWS to keep the root device volume}}.

service-ebs-038; AWS Backup is a way of consolidating {{c1::backups across multiple AWS services (EC2, EBS, EFS, Storage Gateway, etc)}}.

service-ebs-039; You can use AWS Backup it in conjunction with {{c1::AWS Organisations}} to backup multiple {{c1::AWS accounts}} in a centralised manner.

service-ebs-040; AWS Backup offers central management and automation including {{c1::lifecycle}}, {{c1::compliance}}, enforced {{c1::encryption}} & {{c1::auditing}}.