Visual overview
EBS volumes attach as block devices; snapshots provide point-in-time protection.
Technical reference
EBS is AZ-scoped network block storage with an independent resource lifecycle.
A volume is created in an AZ and normally attaches to compatible instances in that AZ.
Volume and EC2 instance limits both influence end-to-end storage performance.
Volume delete-on-termination behavior can be configured separately from instance stop/termination.
Point-in-time block-storage protection used to create new volumes for recovery or migration.
A durable block device for EC2
Amazon Elastic Block Store (Amazon EBS) provides block-level storage volumes that can be attached to Amazon EC2 instances. The operating system sees an attached volume as a block device that can be partitioned and formatted with a file system. This makes EBS suitable for boot volumes, databases and applications that expect conventional disk semantics rather than an object-storage API.
EBS volumes persist independently from an EC2 instance's running state and can remain after an instance is stopped. Whether a particular volume is deleted when an instance is terminated depends on its delete-on-termination configuration. This persistence is a fundamental difference from EC2 instance-store volumes, whose data is tied to the lifetime of the underlying instance host.
Availability Zones and attachment behavior
When you create an EBS volume, you select an Availability Zone. A standard attachment therefore couples the volume to EC2 compute in that same AZ. Multiple EBS volumes can be attached to one compatible instance, and a volume can be detached and attached to another compatible instance in the same AZ. Some supported volume and instance combinations provide Multi-Attach, but it is a specialized capability and does not turn ordinary EBS into a general shared file service.
This AZ boundary matters in recovery design. If compute must move to another Availability Zone, an architect cannot simply attach the same zonal volume across the boundary. Instead, snapshots or application-level replication can create the data needed in another AZ. Availability architecture must therefore consider the data layer as well as the replaceability of EC2 instances.
Snapshots, encryption and changing volumes
EBS snapshots are point-in-time backups of EBS volumes and persist independently of the source volume. Snapshot data is replicated across the Availability Zones in its Region, and a snapshot can be used to create new EBS volumes. Snapshots also support copy workflows across Regions and accounts according to AWS permissions and encryption requirements, making them a key building block for backup and migration patterns.
EBS supports encryption for volumes and snapshots. AWS also provides Elastic Volumes capabilities that can modify characteristics such as volume type, size or performance for supported volumes without the old pattern of always rebuilding storage from scratch. Operationally, the important habit is to monitor the workload and treat capacity, IOPS and throughput as separate dimensions rather than equating a larger volume with better performance in every case.
Key takeaways
- 01
EBS provides persistent block-level storage for EC2 workloads that expect disk semantics.
- 02
EBS volumes are Availability-Zone resources and normally attach to EC2 instances in that same AZ.
- 03
EBS snapshots are independent point-in-time backups and can create new volumes for recovery or migration.
- 04
EBS volume type, capacity, IOPS and throughput should be matched to the workload rather than treated as one sizing dimension.
Official AWS sources
Use these primary AWS resources for the source material behind this article and for deeper reference.