The meter on your disk, and the array without one
Cloud block storage bills capacity, operations, and throughput on separate meters. On an array you own, there is nothing to provision and nothing to negotiate.
In this article 4 sections
- A rented block volume feeds several meters at once: capacity per gigabyte-month, provisioned IOPS, a throughput tier, snapshots on their own line, and egress when the data moves out.
- Owned flash has no allocation to size.
- Our side of the argument fits in one line: it's your array; there's no per-IOP meter and no egress toll on your own data.
- On owned all-flash, a spike lands on hardware you already paid for. A decade of election nights on our hardware says the busiest night costs the same as the slowest one.
Rent a block volume from a public cloud and the invoice splits your disk into five separate meters, every one of them real, published, and running. Here is how they work, and what the same disk looks like when the array underneath it is yours.
One rented volume feeds five separate meters
The word on the invoice is storage, singular. The billing underneath it is plural. Here is the anatomy, meter by meter, as cloud providers publish it.
- CAPACITY
- Billed per gigabyte-month. The one meter everyone expects to find, and usually the smallest of the family.
- OPERATIONS
- A modest baseline comes included. Past it, you provision IOPS as an allocation and pay for the allocation whether you use it or leave it idle.
- THROUGHPUT
- Megabytes per second on the same disk sit on their own tier, billed separately from the operations.
- SNAPSHOTS
- Backups of the volume land on a separate storage line that grows month over month.
- THE EXIT
- Moving your data anywhere else is metered per gigabyte. The exit tax has its own post.
None of this is hidden. Every meter sits on the provider's published price sheet, itemized per region, which is the honest part. The meters multiply: one database draws on several of them at once, and the one that matters most for a busy workload is the provisioned operations.
Provisioned IOPS are billed by allocation
A disk you own performs at whatever the hardware can do. A provisioned volume performs at its allocation.
Most production workloads carry a wide gap between the steady state and the peak. On a provisioned volume, sizing that gap is a decision you revisit as your traffic changes.
Teams on provisioned volumes usually manage this by watching the graphs, forecasting the peak, and re-provisioning the allocation on a schedule. On owned flash, that job does not exist.
Owned flash has no meter to negotiate with
Our position is short. It's your array; there's no per-IOP meter and no egress toll on your own data. Customer data here lives on dedicated all-flash arrays reached over Fibre Channel, with service times of single-digit milliseconds or better. We standardized on HPE 3PAR all-flash and learned it cold; the details are on our storage page.
When your traffic spikes, the operations land on flash you already own. There is no allocation to raise first and no overage line to explain afterward. We have watched that play out over ten years of election nights on our hardware with a national news publisher.
| RENTED BLOCK VOLUME | OWNED ALL-FLASH ARRAY | |
|---|---|---|
| Capacity | Per gigabyte-month, forever | Sized once, in the build |
| Operations per second | Provisioned and billed, used or idle | Whatever the array serves; no allocation to buy |
| Throughput | A separate paid tier | No separate line |
| Peak traffic | Billed by allocation | Lands on headroom already in the box |
| Your data, leaving | Egress per gigabyte | No egress toll on your own data |
The absence of the meter is easy to underrate. Storage is the layer where load is hardest to predict hour to hour, and it is exactly the layer the meters instrument most finely. Take the meters off and a whole class of work above them stops existing: the forecasting and the scheduled re-provisioning.
A metered volume is the right call for small, idle data
If your footprint is a few gigabytes with light traffic, the meters round to pocket change and we would tell you to stay put. The meters start to matter when there is a steady base and a real peak underneath a business: a production database, a busy application, a system people wait on. That is the workload that gains the most from owning the flash underneath it. If you want to know whether yours crosses that line, bring the traffic graph and ask an engineer.
The disk meter is one of a family. The bill for leaving has another, and the full set of questions worth putting to any host about where your data actually lives is in the storage post that started this series.
Straight answers
Which meters am I actually paying on a cloud block volume?+
Capacity per gigabyte-month, provisioned IOPS above an included baseline, a throughput tier on the same volume, snapshot storage on its own line, and egress per gigabyte whenever the data moves out. Every one of them is public, priced per region on the provider's own pages. Read yours next to your last invoice and count how many lines one disk generates.
How do you price storage without a meter?+
The array is part of the build. We size it with you up front, from what your workload actually does, and it lands on the same fixed line as the rest of the machine. No per-IOP allocation, no throughput tier, and moving your data out is not a billable event.
What performance do I get if there is no provisioned number?+
Whatever the array serves. Your data lives on a dedicated all-flash array over Fibre Channel, with service times of single-digit milliseconds or better, and there is no allocation to enforce, so nothing throttles you at your peak.
What happens when my traffic spikes past what we sized?+
The spike lands on headroom already in the build, so nothing needs raising first and nothing shows up as an overage line afterward. If the workload genuinely outgrows the array, resizing it is a conversation with an engineer, not a meter.
Size the array under your workload
Answer a handful of questions about what your workload actually does. The Sizing Desk proposes a real build on owned flash, with storage on the same fixed line as everything else, and it will say so if you need less than you think.
Size it honestlyYou’ve reached the end.
Put the reading to work
What are
you running?
Tell us about the workload, traffic and recovery requirements. Start with the server builder, or talk through the details with an engineer.
Written by the engineers who build and run the infrastructure it describes.Talk to an engineer