Timedora

2 Amazon EBS Block Storage

Learn how Amazon EBS provides persistent block storage for EC2, how to attach and prepare volumes, how to match volume types to workloads, and how to plan snapshot-based recovery.

Persistent block storage for EC2

provides persistent, block-level storage for EC2 instances. A block device presents data as addressable blocks, so the operating system can partition it, format it with a file system, and mount it like a disk. EBS is commonly used for operating-system disks and application data that changes frequently.

An persists independently of an instance's running life, subject to its delete-on-termination setting. This makes EBS useful for boot storage as well as persistent application and database files, including transaction logs.

Attaching and preparing volumes

An is created in a particular and can attach only to an EC2 instance in that same zone. An instance can have multiple volumes attached, subject to the attachment limits of its instance type.

After attaching a volume, prepare it in the operating system. Typically, identify the device, create a file system if needed, and mount it. Take care not to format a volume that already contains data.

Most volumes are attached to one instance at a time. is available for supported and volumes and compatible instances, allowing a volume to attach to multiple instances. It does not coordinate concurrent writes, so use a cluster-aware file system or an application designed for shared block storage where appropriate.

Before detaching a data volume, unmount it to reduce the risk of data loss. A detached volume can attach to another instance in the same Availability Zone. To use its data in another zone, create a snapshot and create a volume from that snapshot in the destination zone.

Matching volume types to workloads

Choose a volume type according to the workload's access pattern and performance needs. measures input/output operations per second, while measures the volume of data transferred per second. Small random reads and writes often depend on and latency; large sequential transfers are often limited by . Actual performance is constrained by both the volume and the EC2 instance's EBS limits.

SSD volume types

  • General Purpose SSD: Has a baseline of 3,000 IOPS\text{3,000 IOPS} and 125 MiB/s\text{125 MiB/s}; and can be provisioned higher. It is a common starting point for general-purpose storage, including boot and data volumes, development and test, interactive applications, and many databases.

  • General Purpose SSD: Performance scales with volume size and can burst. It is used for existing general-purpose workloads; consider when selecting or migrating volumes.

  • and Provisioned SSD: Provide provisioned for workloads requiring sustained, intensive I/O. They suit I/O-intensive databases and other latency-sensitive transactional workloads. Block Express supports particularly high performance on compatible instances.

HDD volume types

  • Optimized HDD: Designed for large, sequential I/O and -oriented workloads, such as log processing, data warehouses, and big-data workloads. It is not suitable as a boot volume.

  • Cold HDD: A lower-cost choice for infrequently accessed, -oriented data when storage cost is a priority. It is not suitable as a boot volume.

These profiles are broad guidance, not guarantees of application performance. Volume size, provisioned settings, I/O size and pattern, workload demand, and instance bandwidth all matter. For example, large sequential reads suit better than small random database writes, while a demanding database may benefit from . Check current limits for the selected volume and instance type.

Snapshots and recovery

An is a point-in-time backup of a volume. The first snapshot is full; later snapshots of that volume are incremental and store blocks changed since the previous snapshot. Snapshots are stored and managed by EBS rather than accessed as ordinary objects through an S3 bucket. A snapshot can be used to create a new volume, including in another Availability Zone, and can provide a basis for backup, recovery, or repeatable volume creation.

Snapshot creation is asynchronous, and the volume can remain in use while the snapshot is being created. A snapshot captures data written to the volume at the time requested, not data still held in application or operating-system caches. For an application-consistent backup, coordinate or pause writes, or use appropriate application and backup procedures.

EBS does not automatically back up volumes. Configure a regular snapshot schedule or a backup policy that meets recovery requirements. Snapshots can be used to restore a volume, create a copy in another Availability Zone, or establish a consistent starting point for new volumes.