A cluster that was cheap on machines you own becomes expensive on a rented tier at the same traffic — which design choices explain that?

## Why the same cluster changes price The cost model of a broker you own and a broker you rent are not the same function of the same design. Owning prices **machines**: capacity, disks, failure domains and the people who keep them alive. Renting prices **the structure and the traffic**: what exists, what is stored, what moves and where it moves to. A design that is efficient in machine terms can be inefficient in metered terms, because the two models do not share a single dimension. That is this subject's whole point, and it is why a lift-and-shift of a long-lived on-premises design onto a hosted tier so often arrives with a bill nobody predicted, at traffic that did not change by a record. ## The habits that become line items Each of these costs approximately nothing on hardware you own, and each is a standing line once rented: - **Many small streams.** On your own cluster a stream is a directory. On a tier that prices the structure it is a recurring charge, and an estate that creates one per service per environment has bought a large standing floor. - **A fine-grained partition layout.** Splitting a stream into many parts costs file handles on your own nodes. Rented, the count itself is frequently metered, and it is metered whether the parts carry traffic or not. - **A generous retention policy.** Keeping a month because the disks were already paid for becomes retained bytes times days times replica copies — a product, so it grows faster than intuition expects. - **An extra replica copy.** On owned hardware the marginal copy is disk you already bought. Rented, it multiplies the largest storage line directly. - **Enormous populations of tiny records.** Bytes are cheap; counts are not. Where a dimension meters billed requests or operations, publishing a flood of very small records bills as a flood of operations. Grouping records so that fewer, larger billed requests carry the same bytes moves that line down, though it is a different trade from the byte lines. - **Readers wherever it was convenient.** Inside your own network, a consumer in another rack was free. Rented, a reader on the far side of a boundary the provider charges across adds a per-byte line on every delivery, multiplied by the number of readers there. - **Headroom held permanently.** On a provisioned-capacity tier, spare capacity kept for the quarterly peak is billed every hour of the quarter. ## The reverse: what owning charges that renting does not A senior answer walks the line in both directions, because "renting is dearer" is not a law. | choice | what it costs when you own | what it costs when you rent | |---|---|---| | headroom for a rare peak | machines bought and idle all year | on a consumption-priced tier, only the peak hours | | disks sized for the worst week | bought up front, at the worst case | retained bytes actually held | | a spare failure domain | a standing second set of machines | typically folded into the tier's price | | replacing a dead node at 3 a.m. | a person on a rota | included in the rental | | one more replica copy | disk you already own | a direct multiplier on the storage line | | one more stream | nothing | a standing line | So a workload that is bursty, low-average and modest in stored volume can be genuinely cheaper rented, while a workload that is steady, byte-heavy, long-retained and widely fanned out is where owning still wins on paper — before the staffing it requires is priced. ## Walking a design across the line When someone asks you to predict the rented bill for an existing design, the work is mechanical: 1. **Inventory what will merely exist** — streams, and the parts each is split into — and decide whether the tier meters the count. 2. **Multiply the storage** — bytes written per day, times the days the retention policy keeps them, times the replica copies stored. 3. **Count records, not only bytes** — because one dimension meters operations and a small-record workload is priced there. 4. **Locate every reader relative to the charged boundary**, and multiply delivered bytes by the readers on the far side. 5. **Choose the purchase shape** against the duty cycle of the traffic, since a reservation held is billed whether or not it is filled. Then do the same arithmetic in reverse for what you stop buying: idle machines, spare disk, the standby, the rota. The answer is a comparison, not a number — and being able to produce it in both directions is exactly what separates an engineer who has operated a rented cluster from one who has read a feature page.