Own your compute, rent your durability

If you have read anything else I have written, you already know I move steady workloads off hyperscalers and onto machines the client owns. So people expect me to say the same thing about backups, and I do not. My backups sit with a provider I will never own a rack of, on purpose, and I would put yours there too.

That is not an inconsistency. It is the same rule applied twice, and the rule is this: own the layer where you are paying a premium for elasticity you do not use, and rent the layer where the premium buys something you genuinely cannot build. Compute for a steady workload is the first case. Durability is the second. One principle, two opposite answers — and a principle that only ever produces one answer is not doing any work.

The premium you are paying, and what it is for

Every managed service charges you above the cost of the underlying hardware. The interesting question is never whether there is a premium. It is what the premium buys, and whether you are using it.

On compute, the premium buys elasticity. You pay a per-hour rate that is high relative to owning the machine, and in exchange you can have four hundred of them at nine in the morning and none at midnight. For a workload that genuinely does that, this is an extraordinary deal and you should keep paying it. For a workload that runs at roughly the same size at 3am on a Sunday as it does at 10am on a Wednesday, you are paying the option price on an option you never exercise. That is the entire economic case for moving steady workloads onto hardware you own, and it is why the first thing I do on an assessment is separate the baseline from the spiky part rather than quoting a migration for everything.

On durability, the premium buys something quite different. It buys eleven nines of object survival across independent facilities, a replication story that has been tested at a scale you will never reach, and — the part people undervalue — a completely different set of failure modes from the ones threatening your primary copy. You cannot build that on two more disks. You cannot build it on six more. The premium is buying the thing itself, not an option on the thing.

Run the same test twice and it produces opposite answers. That is how you can tell it is a test rather than a slogan.

Durability is the product, not a feature of the storage

Here is the part that took me longest to internalise. When you buy object storage for backups, the bytes are almost free. The durability is the product.

You can see this directly in what the providers charge for. Storage per terabyte per month is the number everyone compares — and across the credible options it varies by maybe four times, which sounds like a lot until you look at the second number. What actually separates them is what happens when you try to get your data back.

One provider will charge you nothing to retrieve, ever. Another gives you a generous monthly allowance that no realistic restore will exhaust. A third charges around nine cents a gigabyte, which turns a full restore of a modest estate into a three-figure bill arriving in the same week as an outage. Same bytes. Same durability guarantee. Wildly different behaviour at exactly the moment you need the thing you paid for.

That asymmetry tells you what you are actually buying, and it should reorder how you choose between providers. Storage price is what you pay every month for something you hope never matters. Retrieval price is what you pay on the worst day of your year. Optimising the first while ignoring the second is how teams end up with backups they are financially reluctant to test. (The named providers and current numbers belong in the backups-and-DR playbook I am writing separately; what matters here is the shape.)

The deep-archive trap

The cheapest storage tiers make this worse in a way that is easy to miss, and I have watched it catch people who were doing everything else right.

Archive tiers price storage very low and retrieval very high, often with hours of latency before the first byte moves. On a spreadsheet that is a clear win: your backup line item drops by most of its value. In practice it does something corrosive. It makes a test restore expensive and slow, which means the test restore does not happen, which means the only time you find out whether the backup works is during the incident you took it for.

A backup you have not restored from is a hypothesis. Archive tiers are a mechanism for never testing the hypothesis, sold to you as a discount. If you use them, use them for the third copy — the one you keep for regulatory reasons and genuinely do not plan to touch — and keep a tier you can actually exercise for the copy you would reach for first.

What the rented layer has to give you that your own hardware cannot

If durability is the product, then the specification is not “somewhere else.” Three things matter, and only one of them is about the bytes.

A different failure domain. This is the whole point, and the one most commonly violated by accident rather than by choice. If your primary object store and your backup of it sit with the same provider, in the same account, reachable with the same credentials, you have two copies that are really one. I ran a backup review across my own estate recently and found a production store with no second copy at all. The tempting fix was to put the copy in the same object store the primary already lived in — which would have produced two copies that were really one. Writing the rule down was the useful part: that store’s second copy goes somewhere else, permanently, and no future version of me gets to be efficient about it.

Immutability that survives your own credentials. A retention window during which an object cannot be deleted or overwritten even by someone holding valid keys. That is the line between a backup that survives an accident and one that survives an adversary, and I now treat it as non-negotiable. It has a sharp implication for vendor choice: a provider whose only advantage is free retrieval, but which cannot offer write-once retention, does not qualify for this role however good the pricing looks.

Credentials that live nowhere near your primary. A key scoped to write and read but not delete, held somewhere your production automation cannot reach. If compromising your cluster also yields the keys to the backup, the backup is decorative.

You do not get any of that by owning more hardware, and you get all of it from a rented durability layer for a few dollars a terabyte a month. The implementation — which providers, what they cost, how to structure the keys, and how to run the restore drill — is the backups-and-DR playbook, coming separately. This post is about why the layer has to be rented at all.

Where the line actually falls

Put the two halves together and the architecture states itself.

Own the steady compute. The baseline that runs flat, the databases that do not scale to zero, the always-on services — these are paying an elasticity premium against an option they never use, and they are the cheapest things in your estate to bring in-house.

Rent the durability. Object storage with immutability, in a different failure domain, with a retrieval price you can afford to exercise. Rent this even after you own everything else, and especially then — the moment you own the primary, you have also taken on being the only person who can lose it.

Keep renting the elasticity you actually use. The traffic that spikes and subsides, the batch that runs once a quarter, the workload whose shape you genuinely cannot predict. The premium is doing real work there. Nothing about owning your baseline requires you to own your peaks.

The version of this argument I distrust is the one that ends with everything in one place. If somebody tells you the answer is to own it all, ask them what their backups run on. If they tell you the answer is to rent it all, ask them what fraction of their compute bill is buying elasticity they use. Both answers fall out of the same question, and a position that cannot produce both is not a position — it is a taste.

The uncomfortable corollary

There is a version of this that costs you something, and I will state it plainly rather than leave it implied.

Owning your compute makes you the only person who can lose your data. The hyperscaler was, among other things, an insurance policy you were paying for without itemising it. When you take the workload onto your own machines, that policy lapses — and if you do not deliberately buy it back in the form of a rented, immutable, differently-failing durability layer, you have not saved money. You have moved a cost from a line item onto a risk register, where it will not appear until it appears all at once.

That is why I do not treat “rent your durability” as a caveat on the migration argument. It is the second half of it. A cloud exit that does not include it is not finished.