§01/Cloud Repatriation
Cloud Repatriation TCO Model
A directional three-year cost model for moving workloads off a hyperscaler onto infrastructure you operate. Every assumption is exposed and adjustable, every default is grounded in published data — and it is explicitly a thinking tool, not a quote.
§01/The rent-vs-own decision
Repatriation is an economics problem before it is an engineering one.
The question is never “cloud or not.” It is which workloads have predictable, high-volume resource consumption that pencils out better on owned hardware once you count egress, managed-service premium, and the value of optionality.
A workload that moves large volumes of data between a managed database, a hosted vector store, and a cloud object layer can generate egress bills that rival its compute cost. Egress is not a pricing quirk; it is an architectural lock-in mechanism. The cost of leaving is, by design, part of the cost of staying — and most TCO conversations never price it.
This model puts that exit tax on the table. You tell it how much of your bill is egress and managed-service premium; it shows you how much of that is structurally removable when the same workload runs on infrastructure you control.
We will not pretend a single number off a slider is a quote. What a transparent model does is locate the decision: it shows whether repatriation is obviously worth modelling in detail, obviously not, or close enough that the answer turns on assumptions worth arguing over. Then we validate those assumptions against your actual invoices in a briefing — which is where a real number comes from.
§A/Your inputs
Share of the bill that is data egress, NAT, and the markup on managed services — the part that largely disappears on owned infrastructure.
What the retained compute/storage costs on owned or colocated hardware, per unit, including amortization and operations. Lower = more efficient self-operation.
Compound demand growth applied to both run-rates — your workload grows whether it runs in the cloud or on your own hardware.
The upfront cost of migrating and standing up the operating model, expressed as months of your current bill.
§B/Three-year model
Projected net savings
$1.10M
Range $943k – $1.26M · 51% of cloud spend
Break-even
Month 7
New monthly run-rate
$20k
Directional model — not a quote
The headline carries a deliberate ±15% band; every default is calibrated to published industry data. Full methodology and sources are in the Methodology section below. We validate it against your actual invoices in a briefing.
§03/Methodology
How the model computes — and where the numbers come from.
Every default is calibrated to published industry data, not invented. Full citations are maintained in our research notes; the figures below are the load-bearing ones.
On-prem unit cost ≈ 50% of cloud (adjustable 35–70%)
Andreessen Horowitz's analysis found repatriation lands equivalent workloads at one-third to one-half of cloud cost at sustained scale. The default uses the conservative end of that range (half), so the model under-claims rather than over-claims; the slider lets you encode your own efficiency.
Source · Andreessen Horowitz, “The Cost of Cloud, a Trillion Dollar Paradox” (Wang & Casado, 2021)
Egress + managed-service premium is the clearest removable cost
Hyperscaler egress runs roughly $0.05–$0.12/GB (AWS $0.09, Azure $0.087, GCP $0.12 first tier) and largely disappears behind flat-rate colocation transit (~$0.01–$0.02/GB effective); managed-service markups — managed databases (~20–40% over self-managed), per-cluster control-plane fees (~$74/mo on EKS), managed load balancers — collapse when you self-operate. The model treats ~85% of this share as structurally removable, with a residual for real egress you still pay.
Source · Public AWS/GCP/Azure egress + EKS pricing; managed-service list pricing
Break-even commonly lands at 12–24 months
The one-time migration and team-ramp cost is amortized against the lower monthly run-rate. The most-cited public repatriation case (37signals) broke even on hardware inside the first year and projects multi-million multi-year savings; complex fleets typically sit in the 12–24 month band.
Source · 37signals / DHH cloud-exit write-ups (2022–2024)
Growth compounds on both sides
Workloads grow whether they run in the cloud or on your own hardware, so the model applies the same compounding monthly growth to both run-rates over 36 months. Repatriation is modelled as a unit-cost change, not a growth freeze.
A deliberate ±15% band, never a false-precision number
The headline saving is shown as a range, not a single figure, to reflect genuine uncertainty in unit costs and migration scope. It is a directional model calibrated to benchmarks — not a quote, and never presented as one.
Full sources and the parameter calibration table are documented in our research notes (research/19-tco-methodology.md).
§04/What it does not do
What the model deliberately leaves out.
Honesty about the boundaries of a model is part of trusting it. This one does not:
Price intangibles
The strategic value of optionality, reduced concentration risk, and audit-grade control is real but not monetized here. It only ever helps the repatriation case; we leave it out so the number stays conservative.
Model latency or performance deltas
Owned hardware can be faster (local NVMe, no noisy neighbours) or slower (no instant elastic burst). That is a workload-specific engineering question, not a line in a cost model.
Encode your financing or depreciation
Capex treatment, leasing, and depreciation schedules materially change the cash-flow picture. The model uses a simple one-time migration cost; we handle the real financial structure in the engagement.
Replace a real assessment
It locates the decision; it does not make it. The number you can defend to a board comes from validating these assumptions against your actual invoices and architecture.
§06/FAQ
Questions, answered plainly.
The questions we hear most from CTOs, engineering directors, and founders considering a sovereignty engagement.
How accurate is a cloud repatriation TCO calculator?
It is directional, not a quote. The model exposes every assumption — your monthly bill, the share that is egress and managed-service premium, the on-premises unit-cost factor, workload growth, and a one-time migration cost — and computes a three-year comparison with a deliberate ±15% band so it never implies false precision. Every default is calibrated to published industry data (a16z's cloud-cost analysis, public egress pricing, the 37signals repatriation case). The output is a starting hypothesis you validate against your actual invoices in an engagement.
Where do the default numbers come from — are they made up?
No. The ~50% on-prem unit-cost factor is calibrated to Andreessen Horowitz's widely-cited analysis that cloud runs 2–3x more expensive than owned infrastructure at sustained scale. The egress figures come from public hyperscaler pricing ($0.05–$0.09/GB). The break-even band reflects documented cases such as 37signals, which broke even on hardware within a year. Full citations are maintained in our research notes and we are happy to walk a prospect through every one.
What costs does cloud repatriation actually remove?
The largest reliably removable line items are data egress fees, NAT and inter-AZ traffic charges, and the markup on managed services (managed databases, load balancers, per-cluster control-plane fees). Steady-state compute and storage do not vanish — they move to owned or colocated hardware at a lower unit cost, which is why the model asks for an on-premises unit-cost factor rather than assuming everything goes to zero.
Does this model account for the cost of running infrastructure yourself?
Yes — partially and honestly. The on-premises unit-cost factor is where you encode the operational reality: hardware amortization, colocation or power, and the engineering time to operate the platform. We default it conservatively. The model deliberately does not pretend self-operation is free, and it explicitly excludes intangibles like optionality that would only strengthen the repatriation case.
Executive Briefing
Thirty minutes to clarify your infrastructure risk
Walk us through your vendor footprint and regulatory constraints. We will tell you honestly where sovereignty creates leverage — and where it does not. No pitch deck. No obligation.