Storage
Intermediate 12 min read Storage

Block Storage Volumes

Virtual hard drives for VMs

Block storage (EBS, managed disks, Persistent Disk) is a virtual hard drive attached to a VM over the network. It offers raw devices, snapshots, IOPS tiers and the durability semantics a filesystem expects.

EBSblock storagevolumemanaged disksnapshotIOPSPersistent Disk
Prerequisites: Virtual Machines and Instances
Before we start

What you will learn

  • Explain how a block volume maps to physical storage
  • Choose volume types and IOPS for workloads
  • Snapshot and resize volumes safely
In 60 seconds

A block volume is a raw device that mounts like /dev/sda1: the OS formats it with a filesystem. Network-attached, it survives instance termination, snapshots capture point-in-time state, and IOPS/size can grow live.

Introduction

What is this?

AWS EBS types: gp3 (general), io2 (provisioned IOPS), st1 (throughput), sc1 (cold); snapshots are incremental. Azure managed disks: Standard HDD/SSD, Premium SSD, Ultra Disk (extreme IOPS), snapshots and image capture. GCP Persistent Disk (pd-standard, pd-balanced, pd-ssd) with snapshots and regional PDs. Volumes attach to one VM at a time (multi-attach options limited); detach/attach is instant; size and IOPS expand online (increasingly).

Motivation

Why do you need it?

  • VM-local disks are ephemeral (instance store); volumes persist through stop/start.
  • Snapshots give cheap, reliable backups and cloning for fleets.
  • Throughput/IOPS tiers let you pay for exactly the performance you need.
  • Detach/attach enables failover (recover volumes to a healthy instance).
Think about it

Mental model

Imagine

External hard drives with a super-fast network cable

Think of

Block storage volumes

Each drive has capacity and speed ratings (IOPS), can be unplugged from one computer and plugged into another, and can be snapshot-photographed to preserve its exact contents for restoration.

Mechanics

How it works

  • The provider returns a device (e.g. /dev/sda1) over the hypervisor's storage network.
  • You format a filesystem (ext4/xfs) and mount it; the drive appears as a normal disk.
  • IOPS scale with volume size and type (gp3 baseline 3000 IOPS) or are provisioned (io2).
  • Snapshots capture incremental changes; restore by creating a new volume from the snapshot.
  • Resize: extend the volume in the API, then grow the filesystem on the OS.

Volume lifecycle.

Create volume
Attach to VM
Format + mount
Snapshot
Resize/move
Hands-on

Examples

Provision and mount a volume

Provision and mount a volume
# AWS
aws ec2 create-volume --availability-zone us-east-1a --size 100 \
  --volume-type gp3 --iops 9000
# show device, then on the VM:
sudo mkfs -t xfs /dev/sda1 && sudo mkdir /data && sudo mount /dev/sda1 /data
# Azure: managed disk then attach
az disk create -n data-disk -g app-rg --size 128 --sku Premium_LRS
az vm disk attach -g app-rg --vm-name web-01 --disk data-disk

Create the volume in the same zone as the VM, attach a device, then let the OS mount it.

Real world

In production

  • A database stores data files on a provisioned-IOPS (io2/Ultra) volume sized to its workload.
  • ELK cluster nodes use freshly sized pd-ssd per node with snapshots before upgrades.
  • A build farm snapshots a clean compile volume to clone quickly onto new spot nodes.
Guidelines

Best practices

  • Snapshot before any risky in-place operation (resize, filesystem change).
  • Choose IOPS from actual workload metrics, not the top SKU.
  • Keep volumes in the same zone as the instance; cross-zone attach fails.
  • Enable deletion protection where losing the disk is worse than losing the VM.
Watch out

Common mistakes

  • Using instance-store 'ephemeral' disks for data you can't lose.
  • Skipping filesystem grow after API resize → space not actually expanded.
  • Over-provisioning IOPS that the application never drives.
  • Terminating the VM with DeleteOnTermination=true on a database volume.
Root cause analysis

Common issues

Error
Size grew in console but df unchanged
Root cause

Filesystem not grown after volume resize

Fix

Run resize2fs (ext4) or xfs_growfs to extend the filesystem to the new size.

Error
Volume can't attach to another VM
Root cause

Zone mismatch or still attached

Fix

Verify the volume is in the same AZ/zone and detached from the prior instance.

When things break

Debugging tips

  • Volume io slow: check the type's baseline IOPS and burst throttle graph.
  • After resize, run 'lsblk' and 'resize2fs/xfs_growfs' to confirm the grow took.
  • Snapshot missing/old: verify snapshot completion and lifecycle rules.
  • Attach conflicts: a volume can be attached to one instance; Detach before moving.
Interviews

Interview checkpoint

Practice

Hands-on lab

Create, Attach, Snapshot and Resize a Block Volume
30 min · intermediate
In progress
Objectives
  • Provision a volume and attach it to a VM
  • Write data, snapshot, and restore it
  • Resize the volume and grow the filesystem

Create, Attach, Snapshot and Resize a Block Volume

30 min · intermediate

0/4 steps
0%
sandbox · Linux sandbox
$
Try these commands
Test yourself

Quick quiz

0/1
1

A snapshot of a volume is a point-in-time copy you can restore by creating a new volume.

Go deeper

Official documentation

AWS — Amazon EBS
docs
Azure — Managed disks
docs
GCP — Persistent Disk
docs