beginnerintermediateadvanced

AWS · EC2 Storage and Lifecycle

EC2 Storage and Lifecycle

What actually persists through a stop, and why a fix should become a new AMI rather than a hand edit

Snapshots are incrementalonly changed blocks copy after the first
Instance store is host-localgone on stop, terminate, or hardware failure
A fix is a new AMI versionnever an SSH session on a running instance
Cattle, not petsreplace freely — drift cannot accumulate on something disposable

1.EBS volume types and snapshots

EBS is network-attached block storage that persists independently of the instance it's attached to. A snapshot is an incremental, point-in-time backup stored in S3 — the first snapshot copies everything, later ones copy only the blocks that changed.

Key features

gp3: general purpose SSD, the default choice for most workloads
io2: provisioned IOPS SSD, for latency-sensitive, high-IOPS workloads (databases)
st1/sc1: throughput-optimized/cold HDD, for large, sequential, infrequent-access workloads
A snapshot is incremental — only changed blocks are copied after the first one
Encryption is enabled by default in most accounts for new volumes and snapshots

EBS volume types and what they fit

EBS volume types and what they fit
Type	Best for
gp3 (SSD)	General purpose — the default starting choice
io2 (SSD)	High-IOPS, low-latency — databases, latency-critical workloads
st1 (HDD)	Large, sequential throughput — big data, log processing
sc1 (HDD)	Infrequent access, lowest cost per GB

Snapshots are incremental — only the delta is copied

First snapshot

No prior snapshot to build on
Copies all 100GB of used blocks
The expensive one

Second snapshot, next day

Only 2GB actually changed
Copies just that 2GB delta
References the first for the rest

Command

bash

aws ec2 create-snapshot --volume-id vol-0abc123 --description "pre-migration backup"

A snapshot is incremental — only changed blocks are copied after the first — and gp3 is the sensible default; reach for io2 only once a workload has measured, sustained IOPS/latency needs gp3 cannot meet.

2.Instance store vs EBS

Instance store is physically attached to the specific host an instance runs on — extremely fast, but its data is gone the moment the instance stops or the underlying host changes. EBS is network-attached and survives a stop, a reboot, and even reattachment to a different instance.

Key features

Instance store: physically attached, ephemeral, data lost on stop/terminate/hardware failure
EBS: network-attached, persists independently, can be detached and reattached elsewhere
Instance store is typically faster (no network hop) but never durable on its own
Not every instance type offers instance store — it depends on the specific type
Instance store data does NOT survive a stop, even though the instance itself might restart

What survives what

Instance store

Survives: reboot
Lost on: stop, terminate, host failure
Best for: caches, scratch space, replicated data

EBS

Survives: stop, reboot
Lost on: terminate (unless retained), explicit deletion
Best for: anything that must persist

Command

text

Instance store: instance-attached, ephemeral  → survives reboot, NOT stop/terminate
EBS:            network-attached, persistent  → survives stop, terminate (unless configured to delete)

Instance store is fast but tied to the specific host — gone on stop, terminate, or hardware failure. EBS is network-attached and persists through a stop — use instance store only for data that can be safely lost or rebuilt.

3.AMIs, image pipelines, and immutable infrastructure

Instead of configuring a running instance by hand and hoping to remember how, an image pipeline builds a fresh AMI from a defined recipe every time — so replacing an instance means launching a new one from that AMI, not patching the old one in place.

Key features

An AMI is a point-in-time, reusable template — OS, packages, and configuration baked in
An image pipeline (e.g. EC2 Image Builder) automates building, testing, and publishing new AMIs
Immutable infrastructure: instances are never patched in place — a new AMI produces new instances
A snapshot underlies an AMI's root volume — the AMI is a pointer to that snapshot plus metadata
Rolling out a change means a new AMI version, then replacing instances, not SSH-ing in to edit them

Command

text

Recipe (Image Builder pipeline) → new AMI, versioned → Auto Scaling launches instances from it

Immutable infrastructure means a fix becomes a new AMI version, not an SSH session on a running instance — every instance launched afterward is identical because they all trace back to the same recorded artifact.

4.Why hand-tuned servers cause configuration drift

Configuration drift is when running instances gradually diverge from what their launch template or AMI describes — each manual fix, each skipped update, each one-off tweak makes the fleet less uniform, until no two instances are quite the same anymore.

Key features

Drift: the gap between what infrastructure code/AMI describes and what is actually running
Every manual SSH fix that is not also captured in the AMI or launch config is a source of drift
Replacement (terminate + relaunch from the current AMI) resets an instance to a known-good state
Drift is invisible until something depends on the assumption of uniformity and breaks
A pet (hand-tuned, irreplaceable) vs cattle (uniform, freely replaceable) is the common shorthand for this distinction

Pets vs cattle

Pets (hand-tuned)

Feared to replace
Manual fixes accumulate, uncaptured
Drift builds silently over time

Cattle (uniform)

Replaced freely, on a schedule
Every fix lives in the AMI/launch config
Nothing survives a replacement, so drift cannot accumulate

Command

text

Pets: hand-tuned, feared to replace, drift accumulates
Cattle: uniform, replaced freely, drift cannot accumulate because nothing survives a replacement

Configuration drift accumulates one uncaptured manual fix at a time — treating instances as freely replaceable "cattle" (not irreplaceable "pets") is what prevents drift from ever building up in the first place.

Spotted a mistake on this page? Tell us.

Read Sheet