Snapshot actions

A snapshot is a point-in-time copy of a volume. On a platform with no provider backups, snapshots are the only recovery mechanism you have, so it is worth knowing exactly what they do and do not protect against.

Permissions

Action	Resource scope
`ec2:CreateSnapshot`	Both `volume/<id>` and `snapshot/*`
`ec2:DescribeSnapshots`	Requires `"Resource": "*"`
`ec2:DeleteSnapshot`	`snapshot/<id>`

Every action accepts DryRun.

CreateSnapshot

Parameter	Type	Required	Notes
`VolumeId`	string	Yes	Attached or detached, either works
`Description`	string	No	Up to 255 characters
`TagSpecification.N`	list	No	`ResourceType` must be `snapshot`
`DryRun`	boolean	No

Response: snapshotId, volumeId, status (pending), startTime, progress, volumeSize, description, tagSet, ownerId, encrypted (false).

The call returns as soon as the snapshot is registered. Copying continues afterwards and status moves pending → completed. A snapshot cannot create a volume until it is completed.

snap = ec2.create_snapshot(VolumeId=vol, Description="before upgrade")
ec2.get_waiter("snapshot_completed").wait(SnapshotIds=[snap["SnapshotId"]])

Not idempotent, and there is no ClientToken for it. A retry after a lost response creates a second snapshot occupying the same space again. Tag at creation and reconcile by tag.

What a snapshot captures

Whatever was on the disk at the instant it was taken — including a filesystem part-way through a write.

Workload	Do this first
A database	Stop it, or use its own dump or hot-backup mechanism
A filesystem that can freeze	`fsfreeze -f /data`, snapshot, `fsfreeze -u /data`
Anything else	Unmount, or accept crash consistency

Crash-consistent means the snapshot is exactly what the disk would look like after a power cut. Most filesystems recover from that; most databases do not guarantee it.

sudo fsfreeze -f /data
sc ec2 create-snapshot --volume-id vol-… --description "nightly"
sudo fsfreeze -u /data

Keep the frozen window short — writes block for its duration.

[!warning]

A snapshot is stored on the same hardware as the volume. It protects you from your own mistakes — a bad deploy, a wrong rm, a migration you want to undo — not from the failure of the machine holding both.

It is not a backup, we do not describe it as one, and anything you cannot lose must be copied off this platform.

Restoring

Restore by creating a new volume from the snapshot, then attaching it:

sc ec2 create-volume \
  --availability-zone hel1-a \
  --snapshot-id snap-… \
  --volume-type standard

sc ec2 attach-volume --volume-id vol-NEW --instance-id i-… --device /dev/sdg

Size may be omitted to take the snapshot’s size, or given to create a larger volume. It may never be smaller.
The restored volume is a new volume with a new id. Nothing is restored in place, and the original volume is untouched.
If you grew the volume during restore, grow the filesystem inside the guest afterwards — see Volume actions.

Restoring beside the original rather than over it is the safer habit: mount the restored volume somewhere else, check it, then swap.

DescribeSnapshots

Parameter	Type	Notes
`SnapshotId.N`	list
`Filter.N`	list	`status`, `volume-id`, `volume-size`, `start-time`, `progress`, `description`, `tag:<key>`, `tag-key`
`OwnerId.N`	list	Only your own account resolves
`MaxResults`	integer	5–1000
`NextToken`	string

Paginated. Returns only snapshots your account owns — there are no public or shared snapshots, and none from other accounts.

Filters naming things this platform never reports — encryption, storage tier, restore state — return InvalidParameterValue rather than matching nothing.

DeleteSnapshot

Parameter	Type	Required
`SnapshotId`	string	Yes
`DryRun`	boolean	No

Permanent, with no recycle bin.

A volume already created from the snapshot is unaffected — it is a volume in its own right from the moment it is created, not a reference to the snapshot.

They consume the pool, and nothing expires them

[!warning]

Snapshots occupy the same storage pool as every volume and every instance root disk. The pool is finite and shared.

Nothing expires a snapshot. There is no lifecycle policy, no retention rule and no scheduling. A nightly snapshot taken by a cron job you forgot about accumulates until something fails to create.

When the pool is full, CreateVolume returns InsufficientVolumeCapacity — and that failure lands on whoever asks next, not necessarily on the account whose snapshots filled it.

Practical rule: if you take snapshots on a schedule, delete them on a schedule too. Nothing else will.

# snapshots older than 30 days, oldest first
sc ec2 describe-snapshots --owner-ids self \
  --query 'sort_by(Snapshots,&StartTime)[?StartTime<`2026-08-05`].[SnapshotId,StartTime,VolumeSize]' \
  --output table

Billing

Snapshots are not rated today. Nothing charges for the storage they occupy.

That is a gap in the rating configuration, not a discount — see How prices are set. It will change, and when it does, forgotten snapshots become an invoice line. The capacity they consume is real now regardless of what they cost.

Errors

Code	Status	Cause
`InvalidSnapshot.NotFound`	400	No such snapshot, or another account’s
`InvalidSnapshot.InUse`	400	A volume is still being created from it
`InvalidVolume.NotFound`	400	No such volume to snapshot
`IncorrectState`	400	The volume is not in a state that can be snapshotted
`InsufficientVolumeCapacity`	500	The pool cannot hold it
`InvalidParameterCombination`	400	Restore size smaller than the snapshot

Not implemented

CopySnapshot, ModifySnapshotAttribute, ResetSnapshotAttribute, CreateSnapshots (multi-volume), snapshot sharing, fast snapshot restore, archive tiers, and the EBS direct APIs return InvalidAction.

There is no cross-region or off-platform copy. Getting data out is your job, through the filesystem.