The sticker comparison — "a server costs $8K, an EC2 instance costs $0.40/hour" — is the wrong comparison. The honest one is total cost of ownership: on-prem carries hardware capex and depreciation, data-center or colo space, power and cooling, network and bandwidth, the staff who rack and patch it, the over-provisioning you buy for peak, and a refresh-cycle bill every 3–5 years. AWS replaces most of that with metered opex and elasticity — but adds egress and managed-service premiums of its own. This page builds both stacks line by line, shows when cloud is genuinely cheaper and when on-prem still wins, how to model your own TCO honestly with AWS Migration Evaluator, and how MAP funding pulls the crossover point forward.
The comparison people reach for first — server purchase price vs hourly instance rate — compares one on-prem line item against the entire cloud bill. It is structurally rigged in cloud's favor on the surface and against it underneath. The honest question is total cost of ownership over the life of the workload.
When a finance team says "our data center is cheaper," they are almost always comparing the depreciated cost of hardware they already bought against the full retail on-demand price of AWS. That is not a like-for-like comparison. The hardware figure excludes the building it sits in, the power it draws, the people who operate it, and the capacity sitting idle for the 80% of the day it is not at peak. The AWS figure, meanwhile, is quoted before any commitment discount — the price you would pay if you ran everything on-demand and never touched a Savings Plan.
A correct comparison puts the *whole* on-prem cost stack on one side and the *whole* AWS bill (after realistic commitment discounts and including egress) on the other, normalized to the same workload over the same multi-year horizon. When you do that, the answer is not "cloud is always cheaper" — it is "cloud is cheaper for these shapes of workload, on-prem is cheaper for those, and here is the crossover."
This page is deliberately not a cloud sales pitch. CloudRoute routes companies to AWS partners who run migrations, but a migration you regret because the TCO never crossed over is a bad outcome for everyone. So the goal here is the honest model: every cost line on both sides, the cases where staying on-prem is the right call, and the cases where the elasticity and capex-avoidance dividend is real and large.
One framing that helps: on-prem is a *capacity* purchase and AWS is a *consumption* purchase. On-prem, you buy peak capacity up front and own it whether or not you use it. On AWS, you rent actual consumption by the hour or second. Whether that trade favors you depends almost entirely on the ratio between your average load and your peak load — the lower your average utilization, the more you are paying to own idle iron, and the more cloud elasticity is worth.
Internal "our servers are cheap" estimates usually count one line — the hardware. A defensible on-prem TCO has eight. Here is each one, why it is easy to miss, and roughly how it scales.
The first three lines are the ones most teams remember; the back five are where on-prem TCO quietly inflates past the headline hardware number. Industry rule-of-thumb: the fully-loaded cost of running owned infrastructure is roughly 2.5×–4× the bare hardware price once every line below is counted.
The servers, storage arrays, top-of-rack switches, load balancers, and the spares you keep on the shelf. This is a capital expense: you pay it up front, then amortize it over a useful life (typically 3–5 years for compute, 4–6 for storage and network gear) via depreciation on the books.
The trap is comparing the *depreciated* (near-zero, end-of-life) hardware cost against full cloud retail. The honest figure is the annualized capex — purchase price divided by useful life — plus the cost of the spare capacity you bought but have not lit up yet.
Whether you run your own facility or rent rack/cage space in a colo (Equinix, Digital Realty, regional providers), you pay for floor space, rack units, and a power/cooling allocation. Colo is typically billed per rack or per kW of provisioned power, often $800–$2,000+ per rack per month depending on market and density, before the power you actually draw.
If you own the building, this line balloons into real estate, construction, fire suppression, physical security, and the redundancy (N+1 / 2N) that enterprise uptime SLAs demand. Most mid-market estates land in colo precisely because owning a facility rarely pencils out below hyperscale volume.
Servers draw power to run and more power to stay cool. The standard metric is PUE (Power Usage Effectiveness) — total facility power divided by IT power. A well-run enterprise data center sits around 1.4–1.6 PUE; a hyperscaler like AWS runs closer to 1.1–1.2, which is one of the structural reasons cloud unit-power costs are lower.
Power is also where utilization bites hardest: an idle server still draws 40–60% of its peak wattage. You pay to cool capacity you are not using. This line scales with provisioned capacity, not with useful work — which is exactly the cost elasticity removes.
Internet transit, cross-connects, redundant circuits, DDoS protection, and the on-prem switching/routing fabric. On-prem you over-provision bandwidth for peak just like compute, and redundant carriers are not optional for anything customer-facing.
This is one line that often looks *cheaper* on-prem than cloud, because once you own the pipe, moving data over it is effectively free — which becomes important when we get to AWS egress, the one place cloud frequently loses.
The loaded salaries of the people who rack and stack hardware, patch firmware and operating systems, manage the hypervisor and storage, swap failed drives, run the on-call rotation, and handle capacity planning. For most mid-market estates this is the single largest line in the TCO, and the one most often omitted from "our servers are cheap" math because the people are already on payroll.
The honest accounting allocates the fraction of platform/infrastructure headcount that exists *only because* you run your own metal. On AWS, undifferentiated heavy lifting — drive swaps, firmware, hypervisor patching, data-center ops — moves to AWS, and that headcount either shrinks or redeploys to higher-value work. The cost does not vanish entirely (you still need cloud engineers), but the floor drops.
You must buy on-prem capacity for your *peak* — Black Friday, month-end batch, the marketing spike — and that capacity then sits idle the rest of the time. Typical enterprise server utilization runs 15–35%; the other 65–85% is paid-for headroom you cannot return.
This is the core economic difference. On AWS you scale out for the peak and back in (or to zero) afterward, so you pay for the area under the actual demand curve rather than the area under a flat line drawn at the peak. The lower and spikier your average utilization, the larger this dividend — and it is frequently the single biggest swing in the whole comparison.
Every 3–5 years the hardware ages out: out of warranty, off the vendor support matrix, too slow per watt to keep running. You re-buy the whole estate — another capital event, another procurement cycle, another migration of workloads onto new boxes. Refresh is lumpy, capital-intensive, and easy to leave out of a steady-state cost model precisely because it only hits periodically.
On AWS the refresh is continuous and invisible: AWS retires old hardware generations behind the scenes and you move to newer instance families (often cheaper per unit of performance) with a stop/start. You never write a seven-figure refresh cheque or run a forklift upgrade.
The cash sunk into hardware and facilities is cash that cannot fund product, hiring, or growth — and for a venture-backed company, equity capital is the most expensive money there is to tie up in depreciating servers. CFOs increasingly price this explicitly: capex committed to data centers carries a cost-of-capital drag that opex, paid monthly from revenue, does not.
This is the strategic case for the capex→opex shift independent of the raw arithmetic: even where the cloud run-rate is roughly comparable to on-prem, moving infrastructure off the balance sheet and onto the P&L frees capital and converts a fixed bet on forecast demand into a variable cost that tracks actual demand.
The line-item table matters, but the headline reason finance teams drive cloud migrations is the accounting shift: a large up-front capital commitment becomes a metered monthly operating expense. That changes more than where a number sits on a statement.
On-prem, infrastructure is capex — you commit cash (or debt) up front for capacity you will consume over years, capitalize it, and depreciate it on the balance sheet. AWS infrastructure is opex — you expense it monthly as you consume it, with nothing capitalized. The same compute can move from a multi-year capital bet to a line that scales up and down with usage and revenue.
The practical consequences: (1) you stop forecasting capacity 3–5 years out and buying for the worst case, because you provision on demand; (2) cost tracks usage, so a quiet quarter costs less instead of leaving expensive idle iron on the floor; (3) capital that would have been sunk into depreciating hardware stays free for the business; and (4) for a startup, you avoid a capital event that is hard to justify to a board pre-scale.
The honest caveat is that opex is not free money — an unmanaged AWS bill can drift higher than a well-run, fully-amortized on-prem estate, because the elasticity that saves money when you scale down also lets spend balloon when nobody is watching. The capex→opex shift is a genuine structural advantage *and* a discipline requirement: realizing it depends on right-sizing, commitment coverage (Savings Plans / Reserved Instances), and ongoing cost governance. This is exactly the work CloudRoute's cost-optimization cluster and the landing-zone guardrails are built around.
On-prem buys peak capacity up front as capex and you own the idle headroom; AWS rents actual consumption as opex and you scale the headroom away. The bigger the gap between your peak and your average, the more decisively that trade favors cloud.
The defensible answer is workload-shaped. Cloud wins decisively for some profiles; on-prem still wins on pure run-rate for others. Here is the honest split.
The most common honest outcome is not "all-in cloud" or "stay on-prem" — it is a hybrid that migrates the variable, spiky, and growth workloads to AWS (where elasticity pays) while keeping the few steady high-utilization heavy-compute workloads on-prem or on AWS Outposts until their economics or refresh cycle flips them too. The 7 Rs framework (Rehost, Replatform, Refactor, Relocate, Repurchase, Retain, Retire) explicitly includes Retain for exactly the workloads where on-prem still wins.
Variable or spiky load. Anything with a big gap between peak and average — seasonal e-commerce, event-driven traffic, batch that runs a few hours a day — captures the full elasticity dividend. You stop paying for idle peak capacity.
Early-stage or growing. When you cannot forecast demand 3 years out, buying owned capacity for the worst case is a bad bet. Pay-per-use means cost tracks growth instead of leading it, and you avoid a capital event.
Anything you would over-provision for resilience. Multi-AZ HA, disaster recovery, and burst capacity are cheap to rent on demand and expensive to own as standby iron.
Dev/test/CI environments. These sit idle most of the time on-prem; on AWS you scale them to zero off-hours and pay nothing while they sleep.
Steady, predictable, high-utilization heavy compute. A workload that runs 24/7 at >70% utilization for years — large stable databases, sustained HPC/simulation, steady high-throughput batch — has no elasticity dividend to capture. The capacity is always in use, so renting consumption and buying peak capacity converge, and fully-amortized owned hardware can undercut even 3-year-committed cloud pricing.
Very high sustained egress. A workload that ships enormous volumes of data out continuously (some media, CDN-origin, or data-distribution businesses) can pay more in AWS egress than it ever saves on compute. Owning the pipe wins.
Specialized hardware or strict data-residency / latency constraints. Custom accelerators, microsecond-latency requirements, or regulatory mandates that data never leave a specific facility can make on-prem the only option. AWS Outposts and Local Zones narrow this gap by putting AWS hardware in your facility or city, but a pure-cloud move may not fit.
Fully-depreciated estates near end of a refresh cycle. If the hardware is already paid off and has 1–2 good years left, the run-rate comparison flatters on-prem until the next refresh — at which point the capital event reopens the question. The honest move is to time the migration decision to the refresh, not fight depreciated iron.
A TCO comparison built on guessed utilization and on-demand list prices is worse than no comparison — it manufactures false confidence. The honest method starts from measured utilization and ends in modeled, commitment-aware AWS pricing.
The single biggest error in DIY TCO models is assuming on-prem servers run near their rated capacity. They almost never do — typical utilization is 15–35% — and that gap is precisely the elasticity dividend you are trying to size. So the model has to start from *measured* utilization, not nameplate specs.
AWS provides the tooling to do this properly, and a MAP-eligible partner runs it as the (often free) Assess phase:
The output you want is a multi-year TCO curve for both options on the same axes, with the crossover point marked — the month at which cumulative cloud cost (including the one-time migration spend) drops below cumulative on-prem cost. Two levers move that crossover earlier: realistic commitment coverage on the AWS side, and offsetting the one-time migration cost with funding — which is where MAP comes in.
| On-prem line item | How it is billed on-prem | AWS equivalent | How it changes | Who tends to win |
|---|---|---|---|---|
| Hardware (servers, storage, network) | Capex up front, depreciated 3–5 yrs | EC2 / EBS / S3 metered hourly | Capex → opex; pay for what runs | Cloud (variable) / on-prem (steady) |
| Data-center / colo space | Rack/kW per month + facility | Included in instance price | Disappears from your books | Cloud |
| Power & cooling | kWh + PUE 1.4–1.6 overhead | Included; AWS PUE ~1.1–1.2 | Disappears; AWS is more efficient | Cloud |
| Network & bandwidth | Transit + redundant circuits (own the pipe) | Data transfer + egress per GB | Becomes metered; egress can cost more | On-prem (high egress) / cloud (else) |
| Staff (rack/patch/on-call) | Loaded salaries (largest hidden line) | Folded into managed services | Undifferentiated ops moves to AWS | Cloud |
| Over-provisioning for peak | Buy peak, idle 65–85% of the time | Auto Scaling / scale to zero | Pay area under demand curve, not peak | Cloud (decisively) |
| Hardware refresh (3–5 yr) | Lumpy capital event + forklift upgrade | Continuous, invisible, stop/start | No refresh cheque ever | Cloud |
| Managed databases / clusters | Self-run on owned iron + DBA time | RDS / Aurora / EKS (managed premium) | Higher unit price, lower ops cost | Depends (buys back headcount) |
| Capital tied up | Cash sunk in depreciating assets | Monthly opex from revenue | Frees capital for the business | Cloud |
| Steady-state committed compute | Fully amortized owned hardware | Savings Plans / RIs (1–3 yr, −30–60%) | Converges at high, stable utilization | On-prem (if >70% util, 24/7) |
The one-time cost of migrating is the thing that pushes the cloud TCO crossover later — you pay to move before you start saving. AWS's Migration Acceleration Program (MAP) exists to offset exactly that, which moves the crossover earlier and de-risks the decision.
Even when the steady-state AWS run-rate is clearly lower than on-prem, the migration itself costs money — assessment, dual-running both environments during cutover, partner labor, tooling, and any app changes. That one-time spend sits on top of the cloud curve and delays the month cloud goes cheaper than on-prem cumulatively. MAP is AWS's mechanism for funding that hump.
MAP runs in three phases — Assess (the TCO model and readiness review, often delivered free), Mobilize (landing zone + pilot), and Migrate & Modernize (production cutover). AWS provides credits and funding scaled to the migration size, paid through an AWS partner via the APN. In practice, for a qualifying migration, AWS credits a large share of the migration cost and the partner is paid through MAP — so the customer's net cash cost to migrate can approach $0, which effectively erases the one-time hump and brings the crossover forward to month one.
The honest framing: MAP funding applies to qualifying migrations — typically those that carry a meaningful post-migration AWS-spend commitment, which is what the funded TCO model is sizing in the first place. It is not a universal coupon. Where a workload does not qualify (too small, or the economics favor staying on-prem), CloudRoute is still a vetted-partner referral that de-risks the cutover rather than a funding play. The MAP funding hook ties directly into CloudRoute's AWS credits cluster — the same partner-filed, AWS-funded mechanics that power the credit programs power the migration funding.
Without funding, the cloud TCO line crosses below on-prem only after you have paid back the one-time migration cost. With MAP offsetting that cost (net ≈ $0 for qualifying migrations), there is no payback hump — the steady-state savings start accruing from the first month on AWS. That is the single biggest lever on when, not just whether, cloud is cheaper.
TCO is workload-shaped, so the right answer depends on your utilization, variability, egress, and horizon. This matrix maps the common profiles to the honest verdict — including the cases where staying on-prem (or hybrid) is the right call.
| Workload profile | Utilization / shape | On-prem TCO | AWS TCO | Honest verdict |
|---|---|---|---|---|
| Spiky / seasonal web app | Low average, high peak | High (pay for idle peak) | Low (scale to demand) | AWS — large elasticity dividend |
| Early-stage / fast-growing | Unforecastable | Risky capital bet | Tracks growth, no capex | AWS — avoid the capital event |
| Dev / test / CI | Idle most hours | Pays 24/7 for part-time use | Scale to zero off-hours | AWS — decisively |
| HA / DR / burst standby | Mostly idle standby | Expensive standby iron | Cheap to rent on demand | AWS |
| Steady 24/7 heavy compute | >70% util, predictable, years | Low (fully amortized) | Comparable even committed | On-prem can win — model it |
| Very high sustained egress | Bulk outbound continuously | Free once pipe is owned | Egress can exceed compute savings | On-prem / hybrid (or CloudFront) |
| Data-residency / ultra-low latency | Regulated or microsecond | Meets constraint directly | Outposts/Local Zones narrow gap | On-prem or AWS Outposts |
| Mixed enterprise estate | Mostly variable + a few steady | Inflated by idle headroom | 20–40% lower once modeled | Hybrid — migrate variable, Retain steady |
Situation: Finance believed the data center was "basically free" because the hardware was 3 years depreciated — but a $1.4M refresh was looming, the colo contracts were up for renewal, and two platform engineers spent most of their time on drive swaps, firmware, and capacity planning. Average server utilization was measured at 22%; peak (carrier-integration batch + holiday volume) was 5× the baseline. They needed an honest on-prem-vs-AWS TCO before committing to the refresh capex, not a vendor pitch.
What CloudRoute did: Routed within 20 hours to a US-Central AWS Advanced partner with a data-center-exit and MAP track record. Partner ran AWS Migration Evaluator for 3 weeks to collect real utilization, plus Application Discovery Service to map dependencies. The funded Assess phase produced a side-by-side: fully-loaded on-prem TCO (all eight lines, including the looming refresh and the two FTEs) vs a right-sized AWS target with Savings Plans on the steady baseline, Spot for batch, and CloudFront fronting the high-egress tile/asset delivery to contain egress. Two steady high-utilization database workloads were flagged Retain-then-reassess rather than force-migrated. The partner filed MAP to fund the migration.
Outcome: Modeled TCO came out ~31% lower on AWS over 3 years once the avoided $1.4M refresh and the redeployed FTE time were counted — and because MAP funded the migration (customer net cash cost ≈ $0 for the qualifying scope), the cumulative cloud line crossed below on-prem in month one instead of after a payback hump. The variable + standby + dev/test estate migrated over ~5 months; the two steady DBs stayed on-prem pending their own refresh. CloudRoute's commission was paid by the partner from AWS's engagement funding — the customer paid $0 for the assessment and the routing.
estate: ~190 VMs · measured util: 22% · modeled TCO: −31% over 3 yrs · avoided refresh: $1.4M · migration net cost: ≈$0 (MAP) · crossover: month 1
CloudRoute routes you to a vetted, MAP-eligible AWS partner who runs the assessment (Migration Evaluator, not a sales spreadsheet), models the full TCO both ways, and funds the migration via MAP if the numbers justify it. Assess phase often free. Customer pays $0.