Volume types

Objective

Read this page before choosing a volume size or building anything latency-sensitive on this platform. It says what the disk underneath a volume actually is.

the only source of truth for the offer; this page restates it and nothing else.

The type

Field	Value
Our name	`hdd`
EC2 name (`VolumeType` on the wire)	`standard`
Minimum size	1 GiB
Maximum size	1000 GiB
IOPS	48
Throughput	11 MB/s
Default	Yes — the only type

There is one type because the box has one kind of disk: 7200 rpm SATA. No SSD, no NVMe.

standard is Amazon’s own name for magnetic storage, so the alias is honest. There is deliberately no gp3 or io2 alias: those names promise SSD latency this hardware cannot deliver, and a customer whose module says type = "gp3" should get an error, not a slow disk that looks like a fast one.

Where 48 IOPS comes from

It is measured, then divided.

Step	Value
Measured with `fio` on 2026-08-23, whole pool	580 random-read IOPS, 664 random-write IOPS, 132 MB/s sequential
Most instances the box can hold	24 vCPU ÷ 2 vCPU per instance = 12
Per-volume figure published	580 ÷ 12 = 48 IOPS, 132 ÷ 12 = 11 MB/s

The division is the point. A figure quoted to one customer is a figure every customer can have at once. The alternative — publishing the whole-pool number and hoping only one customer is busy — is how a shared HDD box becomes an outage.

What that means in practice

48 IOPS is a spinning disk’s share, and it is small. Concretely:

A database on a volume will be slow, and the slowness will be seek time, not bandwidth. Postgres, MySQL and anything else doing small random writes are the worst fit for this storage.
Sequential work is fine. Backups, logs, media, build artefacts, object data, anything that streams — 11 MB/s sustained per volume, more in bursts while the pool is quiet.
Put the working set in RAM. The memory shapes (cd-memory-*) exist because on this hardware buying RAM is cheaper than buying IOPS.

If your workload needs SSD latency, this is the wrong platform today, and we would rather say so on this page than discover it together on your first production incident.

[!warning]

The IOPS figure is not enforced yet. The platform’s first rule is that every capability figure is enforced, not advertised — if the catalog says 48 IOPS, the hypervisor limits the disk to 48 IOPS. For volumes that limit does not exist today: bootstrap/roles/openstack/tasks/resources.yml creates the compute service flavors from the catalog and nothing else, so there is no the block-storage service QoS specification associated with the hdd type.

Until that task exists, one busy volume can take the whole pool’s throughput and every other volume on the box slows down. This is a known defect. It is tracked as our internal readiness list gap 5 and as open decision 2 on the Volume actions page.

Capacity, and what shares the pool

Every volume, and every instance root disk, is carved from one LVM volume group on one machine.

Figure	Value	Source
Pool name	`default`
Sellable capacity	1400 GiB
Physical	1.7 TB, ZFS
Reserved for instance root disks	1200 GiB, thin LV `nova-instances`
Volume GiB already sold	Tracked internally — free space plus this must still cover the catalog

Root volumes are thin-provisioned. The sum of what has been sold is capped, so the pool cannot fill silently behind customers who are each within their own quota. A create that would take the pool past the cap is refused.

Root disk against attached volume

They are not the same thing and they are not priced the same way.

	Root disk	Attached volume
Where it comes from	The instance type’s `root_gib` (see Instance types)	`CreateVolume`
Size	Fixed by the shape, 20–160 GiB	1–1000 GiB, growable
Survives termination	No — `deleteOnTermination` is `true`	Yes
Cost	Included in the instance price	Not billed today — see below
Backend	the compute service’s thin LV `nova-instances`	the block-storage service, same pool

Durability, honestly

One box. One pool. The pool is not mirrored across disks today (our internal readiness list gap 1: one HDD holds the OS and the only pool; the second disk is not yet attached as a mirror).
There is no cross-host replication and no cross-region copy.
Snapshots are stored in the same pool as the volumes they protect. A snapshot protects you against rm -rf, not against the disk.
Backups with a tested restore are our internal readiness list gap 2 and do not exist.

Treat a volume as durable against a process crash or a guest mistake, not against a hardware failure. Take snapshots, and copy anything you cannot lose off the platform.

Pricing

Attached storage is not rated today. The catalog’s pricing rule prices the AWS-equivalent instance type and nothing else, which is why the storage-dense shape cd-storage-4-16-1000 was removed from the catalog rather than sold at a compute price.

The practical consequence: a volume you create is free, and will not stay free. See How prices are set.

Go further

Volume actions — the EC2 API for volumes
Storage developer guide — the block-storage service directly
Snapshot actions
Instance types