← Back to Services

EBS

Priority Tier 2 Domain 1: Design Secure Architectures Domain 2: Design Resilient Architectures Domain 3: Design High-Performing Architectures Domain 4: Design Cost-Optimized Architectures

Amazon Elastic Block Store (EBS) provides persistent, block-level storage volumes for EC2 instances, functioning like virtual hard drives connected over the network. Root volumes for EC2 instances are typically EBS volumes. Data stored on EBS volumes is persistent and survives EC2 instance stops or terminations.

Learning Objectives

Introduction to Amazon EBS

Amazon Elastic Block Store (EBS) offers persistent, block-level storage for EC2 instances, acting as virtual hard drives attached over the network.

Amazon Elastic Block Store (EBS) provides persistent, block-level storage volumes for EC2 instances, functioning like virtual hard drives connected over the network.
Data stored on EBS volumes is persistent and survives EC2 instance stops or terminations, unless the “delete on termination” setting is configured to remove them.
EBS volumes are provisioned within a specific Availability Zone and can only be attached to EC2 instances residing in that same AZ.
By default, a single EBS volume can be attached to only one EC2 instance at a time. However, the multi-attach feature is available for specific high-performance volume types.
Users provision volumes based on desired size and performance metrics (IOPS, throughput). Billing is calculated based on this provisioned capacity, regardless of actual usage.
For the first 12 months, the AWS Free Tier includes 30 GB of EBS storage, 2 million IOPS, and 1 GB of snapshot storage per month.
Technical Specs: 30 GB of EBS storage, 2 million IOPS, 1 GB of snapshot storage per month (first 12 months)

EBS Volume Types

EBS volumes are categorized into SSD-based and HDD-based types, each optimized for different workloads and cost profiles.

EBS volumes offer a range of performance and cost options, broadly divided into Solid State Drives (SSD) for transactional workloads and Hard Disk Drives (HDD) for throughput-intensive or infrequently accessed data.

General Purpose SSD (GP2)

A cost-effective SSD-backed volume suitable for a broad range of transactional workloads.
Technology: SSDs
Use Cases: General workloads, dev/test, interactive applications, boot volumes
Baseline Performance: 3 IOPS per GB
Minimum IOPS: 100 IOPS
Maximum IOPS: 16,000 IOPS per volume
Burst IOPS: Up to 3,000 IOPS (for volumes under 1 TB)
Maximum Throughput: 250 MB/s per volume
Latency: Single-digit millisecond latency
IOPS Dependency: Scales directly with volume size
Use Cases:
  • General workloads
  • dev/test
  • interactive applications
  • boot volumes

General Purpose SSD (GP3)

A versatile and cost-optimized SSD volume that allows for independent provisioning of IOPS and throughput, offering better price-performance than GP2.
Technology: SSDs
Key Feature: Independently provisions IOPS and throughput from storage capacity
Use Cases: Most workloads, virtual desktops, medium-sized databases, Hadoop clusters, low-latency interactive apps
Baseline Performance: 3,000 IOPS
Baseline Throughput: 125 MB/s
Minimum IOPS: 3,000 IOPS
Maximum IOPS: 16,000 IOPS per volume
Maximum Throughput: 1,000 MB/s per volume
Latency: Single-digit millisecond latency, high reliability
Cost: Cost-optimized compared to GP2, better price-performance
Use Cases:
  • Most workloads
  • virtual desktops
  • medium-sized databases
  • Hadoop clusters
  • low-latency interactive apps

Provisioned IOPS SSD (IO1)

Designed for IOPS-intensive and throughput-intensive workloads that require consistent low latency and high durability.
Technology: SSDs
Use Cases: IOPS-intensive NoSQL and relational databases (e.g., MongoDB, Oracle, SQL Server), transactional workloads, high throughput log processing
IOPS per GB: Up to 50 IOPS per GB
Minimum IOPS: 100 IOPS
Maximum IOPS: 64,000 IOPS per volume
Maximum Throughput: 1,000 MB/s
Durability: 99.99%
Use Cases:
  • IOPS-intensive NoSQL/relational databases
  • transactional workloads
  • high throughput log processing

Provisioned IOPS SSD (IO2 Block Express)

The highest performance block storage option, offering enhanced durability and sub-millisecond latency for business-critical applications.
Technology: SSDs
Key Feature: Highest performance block storage, enhanced durability, lower latency
Use Cases: Business-critical, latency-sensitive applications (SAP HANA, Oracle E-Business Suite), large relational databases, mission-critical transactional workloads
IOPS per GB: 1,000 IOPS per GB
Minimum IOPS: 100 IOPS
Maximum IOPS: 256,000 IOPS per volume
Maximum Throughput: 4,000 MB/s per volume
Latency: Sub-millisecond latency
Durability: 99.999% (5 nines)
Use Cases:
  • Business-critical, latency-sensitive applications (SAP HANA, Oracle E-Business Suite)
  • large relational databases
  • mission-critical transactional workloads

Throughput Optimized HDD (ST1)

HDD-backed volume for frequently accessed, throughput-intensive workloads that are not boot volumes or databases.
Technology: Hard Disk Drives (HDDs)
Use Cases: Frequently accessed, throughput-intensive workloads (big data analytics - HDFS, EMR), data warehouse ETL, log processing
Baseline Throughput: 40 MB/s per TB
Burstable Throughput: Up to 250 MB/s per TB
Maximum Throughput: 500 MB/s per volume
Use Cases:
  • Big data analytics (HDFS, EMR)
  • data warehouse ETL
  • log processing

Cold HDD (SC1)

The lowest cost HDD option for infrequently accessed data or large cold datasets.
Technology: HDDs
Use Cases: Infrequently accessed data, large cold datasets, archive logs, backup repositories, disaster recovery storage
Baseline Throughput: 12 MB/s per TB
Burstable Throughput: Up to 80 MB/s per TB
Maximum Throughput: 250 MB/s per volume
Primary Metric: IOPS are not a primary metric
Use Cases:
  • Archive logs
  • backup repositories
  • disaster recovery storage

EBS Volume Type Comparison

comparison-table

A side-by-side comparison of EBS volume types to aid in selection for specific workloads.

EBS volumes vary in technology, performance, and cost, offering specialized options for different application requirements.

Option Technology Primary Use Case IOPS Range Throughput Range (MB/s) Latency Durability Cost Notes Boot Volume Support
GP2 SSD General purpose, boot volumes, dev/test 100 - 16,000 (3 IOPS/GB, burst to 3,000 for <1TB) Up to 250 Single-digit ms 99.999% Scales with size Yes
GP3 SSD Most workloads, cost-optimized for performance 3,000 (baseline) - 16,000 (independently provisioned) 125 (baseline) - 1,000 (independently provisioned) Single-digit ms 99.999% Better price-performance than GP2 Yes
IO1 SSD IOPS-intensive relational/NoSQL DBs, transactional workloads 100 - 64,000 (up to 50 IOPS/GB) Up to 1,000 Single-digit ms 99.99% Higher than GP types Yes
IO2 Block Express SSD Business-critical, latency-sensitive applications (SAP HANA, large DBs) 100 - 256,000 (1,000 IOPS/GB) Up to 4,000 Sub-millisecond 99.999% Highest cost for highest performance Yes
ST1 HDD Frequently accessed, throughput-intensive workloads (big data, ETL) N/A (throughput-optimized) 40-250 per TB (max 500 per volume) N/A (HDD) 99.8% - 99.9% Lower cost/GB than SSDs No
SC1 HDD Infrequently accessed data, large cold datasets, archive logs N/A (throughput-optimized) 12-80 per TB (max 250 per volume) N/A (HDD) 99.8% - 99.9% Lowest cost/GB No

Key EBS Features and Concepts

EBS offers several features to enhance data management, security, and availability for EC2 instances.

This feature allows a single EBS volume to be attached to multiple EC2 instances simultaneously. It requires application-level coordination to ensure data integrity, as multiple instances can write to the same volume.
Technical Specs: Supported Volumes: IO1 and IO2 Block Express only; Instance Limit: Up to 16 Nitro-based EC2 instances; AZ Requirement: All attached instances must reside in the same AZ; Configuration: Must be enabled at creation; Restrictions: Cannot be boot volumes, Windows instances only support multi-attach for IO2 Block Express
This setting controls whether an EBS volume is automatically deleted when its associated EC2 instance is terminated. Root EBS volumes are deleted by default upon instance termination, while non-root volumes are preserved by default.
Technical Specs: Default: Root volumes deleted, non-root volumes preserved; Configurable via DeleteOnTermination flag during launch or later.
EBS offers built-in encryption for data at rest and in transit between EC2 instances and EBS volumes, using AWS Key Management Service (KMS) with AES-256 encryption. There is no additional cost or performance impact.
Technical Specs: Scope: Data on volume, in transit, and in snapshots; Encryption: AES-256 via KMS; Cost/Performance: No additional cost or performance impact; Immutability: Cannot enable on existing unencrypted volumes (requires snapshot, restore to new encrypted volume).
Snapshots are point-in-time backups of EBS volumes. They are incremental, meaning only the blocks that have changed since the last snapshot are stored. Snapshots are stored redundantly in Amazon S3.
Technical Specs: Incremental backups; Stored in Amazon S3
Multiple EBS volumes can be restored from a single snapshot, and restoration can occur in any Availability Zone. Volumes restored from snapshots are 'lazy loaded,' incurring latency on initial block access. Fast Snapshot Restore (FSR) preloads all blocks for a snapshot, delivering full performance immediately.
Technical Specs: Lazy loading by default post-restore; Fast Snapshot Restore (FSR) for immediate full performance
Snapshots can be copied to other AWS regions for disaster recovery or migration purposes. They can also be shared with other AWS accounts.
Technical Specs: Cross-region copying for DR/migration; Shareable with other AWS accounts
AWS Data Lifecycle Manager (DLM) can be used to automate snapshot creation and retention policies.
Technical Specs: AWS Data Lifecycle Manager (DLM) for automation
EBS volumes can be resized on the fly and their types can be changed.
Technical Specs: Can be resized on the fly; Volume types can be changed

EC2 Instance Store vs. EBS

comparison-table

Choosing between EC2 Instance Store and EBS is critical as they offer distinct characteristics regarding persistence, performance, and cost.

EC2 instances can utilize either ephemeral EC2 Instance Store or persistent Amazon EBS volumes, each suited for different data storage needs.

Option Definition Performance Data Persistence Attachment Cost Availability
EC2 Instance Store Temporary block storage physically attached to the host computer running the EC2 instance. Extremely high IOPS (potentially millions), ultra-low latency. Ephemeral; lost if instance is stopped, hibernated, terminated, or type is changed (persists through reboots). Automatically provisioned and attached at launch; cannot be detached or attached later; tied to instance’s lifecycle. Included in EC2 instance price; no additional charge. Not available on all EC2 instance types.
Amazon EBS Network-attached persistent block storage. Wide range (SSD/HDD) with varying IOPS/throughput; generally lower than instance store but highly configurable. Persistent; survives instance stops and terminations (unless 'delete on termination' is enabled). Can be detached from one EC2 instance and attached to another within the same Availability Zone. Billed based on provisioned storage capacity and performance. Available for all EC2 instances; scoped to a specific Availability Zone.

EBS and EC2 Integration

EBS plays a critical role in various EC2 configurations and services, providing foundational storage capabilities.

Amazon EC2 offers several storage solutions, with EBS being a primary choice for persistent block storage. Root volumes for EC2 instances are typically EBS volumes. When launching an EC2 instance, users configure the root volume and any additional EBS volumes, including the 'delete on termination' option.
Technical Specs: Root volumes are typically EBS; 8 GB of gp2 storage often used for root volume (demo example)
EC2 Hibernation, which preserves the in-memory RAM state of an instance, requires the root EBS volume to be encrypted. The RAM state is written to a file on this encrypted root EBS volume.
Technical Specs: Root EBS volume must be encrypted for EC2 Hibernation
In the Performance Efficiency pillar of the AWS Well-Architected Framework, selecting the right AWS services based on use cases is key. EBS is specifically noted as a storage solution.
AWS Compute Optimizer provides recommendations for optimal compute and EBS resources. It helps analyze and optimize costs by suggesting scaling up or down of these resources.

Exam Tips

Glossary

Amazon Elastic Block Store (EBS)
Provides persistent, block-level storage volumes for EC2 instances, functioning like virtual hard drives connected over the network.
IOPS
Input/Output Operations Per Second, a performance metric for storage.
Throughput
The rate at which data can be transferred, typically measured in MB/s.
Snapshot
A point-in-time backup of an EBS volume, stored incrementally in Amazon S3.
Fast Snapshot Restore (FSR)
A feature that preloads all blocks for a snapshot into EBS storage, allowing volumes created from it to deliver full performance immediately.
AWS Key Management Service (KMS)
A managed service for creating and controlling encryption keys, used by EBS for encryption.
AWS Data Lifecycle Manager (DLM)
A service that automates snapshot creation and retention policies for EBS volumes.
EC2 Instance Store
Temporary block storage physically attached to the host computer running the EC2 instance, offering high performance but ephemeral data persistence.

Key Takeaways

Content Sources

Elastic Beanstalk Amazon EC2 07_AWS_Solutions_Architect_Associate_... OpsWorks AWS Well-Architected Framework: Pilla... Extracted: 2026-01-26 09:52:15.942925 Model: gemini-2.5-flash