Storage Architecture

What cloud block storage actually costs

Block storage pricing is where cloud bills quietly go wrong. The headline figure is usually a per-gigabyte rate, but the number that determines your invoice is what sits around it: provisioned IOPS billed separately from capacity, throughput tiers you have to buy in blocks, snapshot storage charged at a different rate, and egress every time data leaves. Two providers quoting the same per-GB figure can differ by a multiple once those are added.

MarQi Cloud prices block storage on capacity, and we do not charge egress fees — moving your data out, between zones, or back to your own hardware costs nothing. Included IOPS are not metered separately, and snapshots and backups come with every plan rather than appearing as a line item later. Current figures are on our pricing page.

Cloud block storage pricing

Block storage is USD 0.13 per GB per month, SSD-backed and billed on allocated capacity. There is no provisioned-IOPS tier to buy on top, snapshot storage is not charged at a premium rate, copies between zones are not billed as transfer, and there are no egress fees. Compute is priced separately at USD 2 per vCPU and USD 2 per GB of RAM per month, so a storage-heavy workload does not drag a compute bill behind it.

These are arithmetic on the published per-GB rate and cover capacity only. Because IOPS, snapshots and egress are not separate lines, the figure above is the figure on the invoice — which is the part that usually differs from a public cloud quote. Full plan detail is on the pricing page.

Cloud SAN versus public cloud block storage

A traditional SAN gives you predictable latency and dedicated spindles, but you buy the array up front and you own the refresh cycle. Public cloud block storage gives you elasticity, but performance is a purchased tier and cost scales with every gigabyte you keep. Our storage sits between the two: a dedicated Ceph/PetaSAN cluster per zone, sized and operated by us, billed like cloud capacity rather than like a capital purchase.

That matters most for workloads with steady, high-IOPS demand — transactional databases, virtualisation estates, analytics working sets — where the public cloud model charges an elasticity premium you are not actually using.

How the cluster is built

Every zone runs its own storage cluster rather than sharing one across regions, so reads and writes stay local to the compute consuming them. Each volume is replicated three times across separate nodes. A failed disk is a background repair; a failed host is a re-replication event, not an outage. Because the cluster scales horizontally, adding capacity means adding nodes rather than migrating to a bigger array.

Replication protects against hardware failure. It does not protect against a dropped table or a bad migration — for that you need a point you can return to, which is what snapshots and backups provide. The two are complementary, and we include both.

Block, file, and object on one platform

Teams routinely end up with block storage from one provider, an object store from another, and a file share on a box nobody wants to touch. Consolidating them removes an entire category of integration work and makes capacity planning a single conversation. Ceph underpins all three access patterns, which is why we build on it.

Performance you can verify

IOPS and throughput figures are only meaningful against a stated block size, queue depth and read/write mix — a number quoted without them is marketing. We will benchmark against your actual workload profile before you commit, on the same compute platform and network fabric you would run on in production.

Where storage fits

Volumes attach to instances in your private VPC over the fabric described under network fabric, reachable through WireGuard and private networking. If part of your estate stays on your own arrays, both can serve one environment under our hybrid cloud model, or you can rack your own gear alongside ours via colocation. Zone locations are listed under our zones.

Sizing a storage tier, or comparing a quote against your current SAN? Talk to an engineer — we will do the arithmetic with you.

NVMe cloud storage: two transports, one cluster

NVMe cloud storage is not a single product — it is a transport decision made per volume on the same back end. MarQi Cloud presents block storage over both NVMe over Fabrics (NVMe/TCP) and iSCSI.

Cloud SAN storage and triple replication

Every block write is committed to three separate OSDs on three separate nodes before it is acknowledged. Losing a node loses no data, and the volume stays online while the cluster rebuilds. That is what makes it a cloud SAN rather than a disk attached to a hypervisor.

Object storage on the same Ceph foundation

Alongside block storage, MarQi Cloud provides Ceph-based object storage for backups, media and dataset archives — on the same cluster, with the same no-egress-fee billing when you read the data back out.