Step 7 of 8 - Pricing
You pay for the area, not the rectangle
Provisioned capacity is a flat ceiling sized to the busiest fifteen minutes of the day, plus headroom for the peak you didn't forecast. The gap under that ceiling is hardware you rented and didn't use.
Provisioned capacity left unused
not started
Pick a day above. The ceiling is already drawn: it's sized to a peak of 2,401 vCPU plus 40%, and you pay for all of it whether the workload turns up or not. That's under the 7,184 vCPU the estate runs on today, which was bought a cluster at a time and works at 15.0%, not sized to this curve.
- Provisioned
- 0 vCPU-hours
- Consumed
- 0 vCPU-hours
- Paid for, not used
- 0 vCPU-hours
Read this chart as a table
| Hour | Demand | Provisioned | Unused |
|---|---|---|---|
| 00:00 | 487 | 3,361 | 2,875 |
| 01:00 | 488 | 3,361 | 2,874 |
| 02:00 | 488 | 3,361 | 2,873 |
| 03:00 | 485 | 3,361 | 2,876 |
| 04:00 | 491 | 3,361 | 2,870 |
| 05:00 | 496 | 3,361 | 2,865 |
| 06:00 | 484 | 3,361 | 2,877 |
| 07:00 | 666 | 3,361 | 2,695 |
| 08:00 | 1,126 | 3,361 | 2,235 |
| 09:00 | 1,559 | 3,361 | 1,802 |
| 10:00 | 1,910 | 3,361 | 1,451 |
| 11:00 | 2,153 | 3,361 | 1,208 |
| 12:00 | 2,324 | 3,361 | 1,037 |
| 13:00 | 2,334 | 3,361 | 1,028 |
| 14:00 | 2,223 | 3,361 | 1,139 |
| 15:00 | 2,002 | 3,361 | 1,360 |
| 16:00 | 1,668 | 3,361 | 1,693 |
| 17:00 | 1,238 | 3,361 | 2,123 |
| 18:00 | 794 | 3,361 | 2,568 |
| 19:00 | 486 | 3,361 | 2,875 |
| 20:00 | 493 | 3,361 | 2,868 |
| 21:00 | 488 | 3,361 | 2,873 |
| 22:00 | 489 | 3,361 | 2,872 |
| 23:00 | 490 | 3,361 | 2,871 |
How this is worked out
- Demand is this estate's 1,078 vCPU mean, shaped by the preset you picked, which also drives step 1.
- Capacity is sized at the day's peak of 2,401 vCPU plus the 40% headroom you picked, giving a ceiling of 3,361 vCPU. The headroom is an assumption rather than a published figure, so it's yours to argue with.
- That peak is the 100 clusters' own peaks added up, because a provisioned estate buys each of them separately. Step 1's aggregate peak of 1,210 vCPU is the later, smaller question: what one pool needs once the workloads share it.
- A ceiling that high averages 32.1% CPU across the day, which is the whole day's 67.9% of unused capacity counted the other way round. The pooled cluster on step 1 runs at 36.9% against a 37.5% setpoint. Neither number sets the other: this one is how far above the peak you buy, that one is what a controller is told to hold.
Where the storage number comes from
3 Raft copies at 50% utilization (3/0.5 = 6), on top of the block store's own internal replication.
1.0 TB of logical data becomes 6.0 TB provisioned , a factor of 6× before the cost model sees it.