Private vs. Public Cloud: A Real TCO Comparison

The sticker price is the smallest number on the invoice

Most private-versus-public cloud comparisons collapse into a single misleading gesture: someone puts an on-demand instance price next to a server quote and declares a winner. That comparison is wrong before it starts, because it prices two different things. A public cloud line item is a fully loaded rental — power, cooling, hardware refresh, facilities, and a margin, all bundled into an hourly rate. A server quote is a bare asset that does nothing until you add space, power, people, and a network to run it on.

Total cost of ownership is the discipline of putting both sides on the same footing: every recurring and one-time cost, over the full life of the workload, at the utilization you actually run — not the peak you imagine. Do that honestly and the answer is rarely a blowout in either direction. It is a break-even line that different workloads sit on different sides of. This is how we model it for clients, without a thumb on the scale.

The full cost picture on both sides

The reason TCO surprises people is that the biggest costs are the ones missing from the headline number. Both models hide expenses, just in different places.

Figure: the sticker price is the visible tip of each stack — egress, licensing, waste, staff, and facilities are where the real spread between the two models lives.

Public cloud (opex) — the costs beneath the compute line

• Data egress and cross-zone transfer. Moving data out of the provider, and often between its own zones, is metered. For data-heavy systems — analytics, media, backups leaving the platform — this line quietly grows into a larger swing than compute itself.
• Managed-service premium. A managed database, queue, or search cluster is priced well above the raw compute and storage underneath it. You are buying the operational labor back, which is often worth it — but it is a real premium to count.
• Waste. Idle instances, oversized types, forgotten dev environments, and unattached storage are routinely 20 to 30 percent of a cloud bill before anyone optimizes. TCO has to model your actual footprint, not the tidy one in the architecture diagram.
• Commitment discounts you can truly capture. Reserved instances and savings plans are real money, but only for the steady baseline you are confident enough to commit for one to three years. Discount the discount by how much you will realistically lock in.

Private cloud and colocation (capex) — the costs beneath the hardware

• Capital and refresh. Servers, storage, and network gear, amortized over a realistic three-to-five-year life. A single month tells you nothing; the amortization window is the unit of comparison.
• Facilities. Colocation rack space, power, cooling, and cross-connects — or the fully loaded cost of your own space if you genuinely run one. Power draw, not rack units, is usually the binding constraint.
• People. The engineering time to rack, patch, monitor, and replace hardware. This is the line most private-cloud pitches quietly omit, and it is precisely the cost the public model was built to remove.
• Software licensing. Hypervisor, operating system, backup, and management licensing that the cloud folds invisibly into its rate. Per-core licensing in particular can rival the hardware cost on dense nodes.
• Resilience. Redundant power and links, spare capacity, and a real disaster-recovery target elsewhere. Private capacity that skips this looks cheaper only because it is not actually equivalent to what the cloud sells.

Modern "private" rarely means a closet in your office. It usually means a managed private cloud on colocated or dedicated hardware — someone else's building, power, and physical security, your tenancy and your control plane.

Utilization is the variable that decides everything

If you take one number from this, take utilization. It is the single input that moves the answer more than any other, because it changes the per-unit cost of owned capacity while leaving rented capacity almost flat.

Owned hardware has a nearly fixed cost whether it runs at 10 percent or 90 percent. Divide that fixed cost across more work and the unit price falls; leave it idle and it is pure waste. Public cloud is the inverse — you pay per unit of consumption, so the price per unit barely moves with how busy you are.

The practical consequence:

• A fleet that runs at 60 to 80 percent utilization around the clock is close to the best case for owned hardware and close to the worst case for on-demand cloud pricing.
• A fleet that runs at 15 to 25 percent with sharp, unpredictable spikes is the opposite — the cloud's pay-per-use model is a bargain and owned capacity is mostly paying to sit idle.

This is why "the cloud is expensive" and "the cloud is cheap" are both true statements about different workloads, and why any comparison that does not name a utilization number is not a comparison at all.

Where each model actually wins

Once the full cost picture and real utilization are on the table, the placement rules are fairly clean.

The public cloud wins when you are paying for flexibility you use:

• Spiky or unpredictable demand where peak is many times the baseline and arrives without warning — sizing owned gear for that peak means buying idle capacity.
• Global, low-latency reach on day one, which is config in the cloud versus months of contracts and shipping for physical gear.
• New or uncertain products you should not attach a three-year hardware commitment to before the demand curve is legible.
• Managed services that genuinely replace headcount, where the labor saved exceeds the compute premium.

Private or colocated capacity wins when demand has stopped being a question:

• Steady-state baseline compute at high, round-the-clock utilization.
• Data-heavy and egress-heavy systems, where transfer fees dominate and moving the workload removes them.
• Sustained high-performance compute — GPU and dense-CPU jobs that run continuously are expensive to rent by the hour, and owned high-performance servers amortize far below sustained on-demand rates.
• Predictable storage kept for years, cheaper to own than to rent indefinitely, with no retrieval or egress toll on the way out.

How to actually build the model

A defensible TCO model is a short, disciplined exercise, not a hundred-tab spreadsheet. Work it in this order.

1. Pick the amortization window. Match it to hardware life — typically three to five years. Every number that follows is expressed over this same period.
2. Instrument real utilization. You cannot model what you have not measured. Tag spend and pull actual CPU, memory, storage, and egress at the workload level. Peak-based sizing is where these models go wrong.
3. Cost the public side in full. Compute plus storage plus egress plus managed-service premiums plus realistic waste, minus only the commitment discounts you will actually capture.
4. Cost the private side in full. Amortized capital plus facilities plus licensing plus resilience plus the loaded engineering hours to operate it.
5. Compare per unit at true utilization, over the full window. Not one month, not the theoretical peak. The point where the two curves cross is your break-even. Above it, ownership wins; below it, renting does.
6. Re-run it on a schedule. The break-even line moves as your demand grows, your hardware ages, and provider pricing shifts. A placement decision made once and never revisited is a decision that is slowly going stale.

A short checklist for sanity: did you count egress, licensing, waste, staff time, and resilience on the side each is easy to forget? Miss any one of those and the model tilts by exactly the amount you left out.

Hybrid is usually where the math lands

For most organizations the honest output of this exercise is not a migration in either direction — it is placement. Put the predictable, high-utilization baseline on owned or colocated capacity. Keep the spiky, seasonal, and experimental workloads in the public cloud where its elasticity absorbs the bursts. Then connect the two with consistent networking, identity, and observability so moving a workload is an operating decision, not an architectural rewrite.

A well-run hybrid cloud protects you from the two failure modes at the extremes: the surprise bill when a workload matures into a steady, expensive tenant that should have been repatriated, and the capacity wall when a private system suddenly needs five times its normal load. The discipline that makes any of it work is measurement — you cannot right-place what you have not instrumented.

If you want an independent TCO model for your own environment and a placement plan across public, private, and colocated capacity, our cloud infrastructure team will run the numbers both ways and tell you where the math actually lands — or contact us to start with an assessment of the workloads you are least sure about.