LinkedIn

Cloud  /  AWS

AWS Amazon Web Services 61 guides · updated 2026

Hands-on guides to compute, storage, databases, networking, and serverless on the world's most widely adopted cloud platform.

Amazon EBS: Block Storage for EC2 With Tuneable Performance and Snapshot Backup

When an EC2 instance needs storage that behaves like a hard drive — a place to put the operating system, run a database, or write files that survive a reboot — it needs Amazon Elastic Block Store. EBS presents a raw block device to the instance’s operating system. The OS formats it, mounts it, and uses it exactly like a locally attached disk, but the hardware is managed by AWS in a data center you never touch.

That physical separation from the instance is important. An EBS volume persists when you stop or restart an EC2 instance. You can detach a volume from one instance and attach it to another. You can take a point-in-time snapshot and restore from it days later. None of that would be possible if the storage were truly inside the server.

How EBS Attaches to EC2

EBS volumes live in a single Availability Zone. An EC2 instance can only attach volumes that are in the same AZ. The connection runs over the same high-speed internal network that connects EC2 to AWS infrastructure, but from the operating system’s perspective it looks like a local SCSI or NVMe device.

EBS Attachment Model
====================


Availability Zone: us-east-1a
┌──────────────────────────────────────────────────────────┐
│                                                          │
│  EC2 Instance (i-0abc1234)                               │
│  ├── /dev/xvda → Root EBS volume (gp3, 30 GB)           │
│  └── /dev/xvdf → Data EBS volume (io2, 500 GB)          │
│           │                                              │
│      EBS Volume                                          │
│   (replicated within AZ across hardware)                 │
│                                                          │
└──────────────────────────────────────────────────────────┘


Constraints:
- Volume and instance must share the same AZ
- Standard volumes attach to one instance at a time
- Volume persists after instance stop; detaches on termination
  (if configured to not delete on termination)

Volume Types

AWS organises EBS into four families. Each is optimised for a different performance characteristic.

General Purpose SSD — gp3

gp3 is the current default and the right starting point for most workloads. Every gp3 volume provides 3,000 IOPS and 125 MB/s throughput at no extra charge, regardless of size. You can provision additional IOPS independently up to 16,000 and additional throughput up to 1,000 MB/s — without resizing the volume itself. This decoupling of performance from capacity is the key improvement over the older gp2 type, where IOPS grew linearly with size at 3 IOPS per GB.

Provisioned IOPS SSD — io2 and io2 Block Express

io2 volumes deliver deterministic performance. The storage layer is built for IOPS consistency, not just peak numbers. io2 supports up to 64,000 IOPS per volume. io2 Block Express pushes that ceiling to 256,000 IOPS with throughput up to 4,000 MB/s. These volumes cost more per GB but make latency spikes structurally unlikely — the right choice when database SLA requirements leave no room for I/O variability.

Throughput Optimised HDD — st1

st1 is an HDD volume designed for sequential reads and writes rather than random I/O. It delivers up to 500 MB/s throughput at a significantly lower cost per GB than SSD options. Cannot be used as a boot volume.

Cold HDD — sc1

sc1 is the least expensive EBS volume type. Designed for data that sits idle most of the time but still needs block storage. Maximum throughput is 250 MB/s. Use it when cost per GB matters more than access latency.

EBS Volume Type Comparison
===========================


Type       | Max IOPS   | Max Throughput | Use Case
-----------|------------|----------------|---------------------------
gp3        | 16,000     | 1,000 MB/s     | General purpose, databases
gp2        | 16,000     | 250 MB/s       | Legacy (prefer gp3)
io2        | 64,000     | 1,000 MB/s     | High-transaction databases
io2 BE     | 256,000    | 4,000 MB/s     | Largest enterprise databases
st1        | 500        | 500 MB/s       | Log processing, ETL, analytics
sc1        | 250        | 250 MB/s       | Cold data, archival workloads

IOPS vs Throughput

These two performance dimensions get confused frequently. IOPS counts how many discrete read or write operations the volume handles per second, regardless of operation size. Throughput measures bytes transferred per second. A relational database doing thousands of small row lookups needs high IOPS. A data warehouse reading a 500 GB file sequentially needs high throughput. The two requirements are independent, and gp3 lets you tune each one separately.

Snapshots

An EBS snapshot is a point-in-time backup stored in S3 (AWS manages this S3 bucket; it does not appear in your account’s S3 console). The first snapshot copies every block. Subsequent snapshots are incremental — only blocks that changed since the previous snapshot are copied.

Snapshot Incremental Behaviour
================================


Day 1: Full snapshot → copies all 500 GB
Day 2: Changed 10 GB → snapshot copies only 10 GB
Day 3: Changed 5 GB  → snapshot copies only 5 GB


Restore: any snapshot rebuilds a full, usable volume
Region copy: copy a snapshot to another region for disaster recovery
Cross-AZ migration: snapshot → new volume in different AZ

Snapshots enable several operational patterns: scheduled backups via AWS Backup or Data Lifecycle Manager, creating pre-configured AMIs that include a data volume, migrating volumes between Availability Zones, and spinning up a test copy of a production database without affecting live data.

Encryption

Enable encryption at volume creation and every byte — at rest and in transit between the EC2 instance and the EBS service — is encrypted. AWS uses KMS to manage the data key. You can use the default AWS-managed key or bring your own customer-managed KMS key if you need to control rotation and access policy separately.

Encryption propagates automatically: snapshots of encrypted volumes are encrypted, and volumes created from encrypted snapshots are encrypted. At the account level, you can set a default that encrypts all new EBS volumes automatically, eliminating the risk of an unencrypted volume being created by oversight.

Multi-Attach

io2 volumes support attaching to up to 16 EC2 instances simultaneously, all within the same Availability Zone. The application layer is responsible for coordinating concurrent writes — EBS does not provide distributed locking. This is used with cluster-aware file systems like GFS2 or custom applications that explicitly manage concurrent block-level access.

Real-World Scenario: PostgreSQL Database Server

A SaaS company runs a PostgreSQL 16 database on a single EC2 instance. The workload handles 6,000 transactions per second with an average I/O size of 8 KB.

Storage Layout
==============


Root volume:
  Type: gp3
  Size: 30 GB
  Purpose: OS, PostgreSQL binaries, config files


Data volume:
  Type: gp3
  Size: 1 TB
  Provisioned IOPS: 8,000
  Purpose: PostgreSQL data directory (pg_data)


WAL volume:
  Type: gp3
  Size: 100 GB
  Provisioned IOPS: 3,000 (default)
  Purpose: Write-Ahead Log (sequential writes only)


Snapshot schedule (via AWS Data Lifecycle Manager):
  Frequency: every 12 hours
  Retention: 7 days
  Cross-region copy: us-west-2 (disaster recovery)

When the engineering team needs to test a risky schema migration, they restore the latest snapshot to a new volume, attach it to a test instance, and experiment. Production is never touched, and the test environment reflects real data.

Key Points Worth Knowing