AWS vs. On-Premises Costs: A Practical TCO Model for Modernization
Published on · Updated on
Rebuilt the comparison around matched service levels, avoidable and sunk costs, utilization and commitments, network and operations charges, migration and dual-run costs, and an illustrative break-even model; removed unsupported savings claims and stale citations.
An AWS vs. on-premises cost analysis is useful only when both options deliver the same workload, service level, security controls, recovery objectives, and time period. AWS can move spending from owned equipment to metered services, but it does not guarantee a lower total cost. The result depends on utilization, architecture, commitments, data movement, licensing, operations, and the cost of getting there.
This guide gives engineers a practical way to compare the alternatives. It separates accounting from cash flow, distinguishes sunk costs from avoidable costs, includes the charges that are easy to miss, and shows how to calculate a break-even point. Every dollar in the worked example is an illustrative assumption, not a quote or a measured result.
Why simple AWS versus on-premises comparisons fail
“CapEx versus OpEx” describes how a cost is recorded or paid; it does not decide which option is cheaper. A server bought last year may be a sunk cost for a new decision but still have depreciation, support, power, and refresh consequences. An AWS bill may be variable, while a Savings Plan or reserved capacity creates a usage commitment. Compare the costs that the decision can change and show accounting and cash views separately.
First fix the comparison boundary. State the workload volume, regions or data-center locations, availability target, latency, RTO and RPO, retention, compliance controls, support coverage, and operating period. A rehosted EC2 instance, a managed database, and a refactored serverless workflow have different responsibility boundaries. Match the outcome and service level before comparing the components that produce it.
| Cost area | AWS model | On-premises model |
|---|---|---|
| Compute and capacity | Compute, managed-service capacity, autoscaling minimums, and storage performance charged by usage or provisioned capacity. | Servers, hypervisor capacity, spares, refreshes, maintenance, and capacity held for peaks and failures. |
| Storage and data protection | Block, object, database, snapshot, backup, restore, replication, and retention charges. | Arrays, media, backup software, copies, off-site storage, and restore-test infrastructure. |
| Network | Data transfer, cross-Availability-Zone traffic, NAT gateways, public IPv4 addresses, load balancing, VPN or Direct Connect, and connectivity. | Circuits, firewalls, routers, ports, colocation, egress, and network staff. |
| Software and licensing | License-included rates, BYOL obligations, Marketplace software, operating systems, database editions, and vendor support. | Perpetual or subscription licenses, support contracts, virtualization rights, and compliance tracking. |
| Operations | Engineering and on-call work that remains after AWS manages selected infrastructure, plus AWS Support and observability. | Administration, facilities, hardware, patching, monitoring, security, and incident response. |
| Migration and transition | Discovery, design, data transfer, testing, training, temporary environments, cutover, and dual-run capacity. | Coexistence, decommissioning, contract termination, and the cost of keeping the source available during cutover. |
Cost elements to include in both models
Use the same workload demand and service-level tests for every line. A service-level change can be valuable, but it belongs in the value case as a separate benefit instead of being counted as a cost saving.
Hardware, facilities, and people
For on-premises infrastructure, include the portion of hardware purchases or leases, warranty and maintenance, rack or colocation fees, electricity, cooling, physical security, spares, and facility labor that would change if the workload moved. Include staff time for systems, network, storage, database, security, backup, and incident work. Shared staff and facilities need a stated allocation method; otherwise the comparison can simply move a cost out of the model.
For AWS, include the work that remains: account and network operations, IAM, patching where the customer owns the guest or runtime, deployment, security controls, incident response, backup and restore tests, cost management, and on-call coverage. Managed services reduce some infrastructure work; they do not make application ownership or operational readiness free.
Utilization, peaks, and pricing commitments
Measure normal load, peaks, batch windows, seasonal demand, recovery capacity, and the minimum capacity needed to meet the service level. Compare useful work with capacity that exists only for a rare peak. A cloud autoscaling policy can reduce idle capacity, but its minimum instances, warm capacity, load balancer, storage, database, logs, and data transfer still cost money.
Start an uncertain AWS workload with On-Demand assumptions. For steady eligible usage, model a Savings Plan or a service-specific reservation after measuring usage. Savings Plans exchange a one- or three-year commitment to a consistent hourly spend for discounted eligible usage; the commitment can be underused if the workload shrinks. Spot Instances suit interruptible work and should be compared with the engineering and recovery behavior needed to handle interruption. On-premises models should likewise include the cost of capacity reserved for peaks and the cash timing of a refresh rather than assuming every server runs at full utilization.
Our EC2 right-sizing guide explains how to use representative CPU, memory, storage, network, and application data before choosing an instance size or commitment.
Separate sunk cost, depreciation, and cash flow
Show at least two views:
- Run-rate view: the avoidable annual cost of operating the workload after the migration or refresh.
- Cash-flow view: when hardware purchases, AWS commitments, migration work, and decommissioning payments are actually paid.
Depreciation is an accounting expense rather than a cash payment in the period it is recorded. It can matter for financial reporting, but it should not be added to a cash purchase a second time. Conversely, excluding an already purchased server from the future run-rate does not mean its electricity, maintenance, renewal, or replacement is free. Record the useful life, remaining book value, salvage or termination cost, and refresh date so finance can apply its own accounting treatment.
Licensing, support, and shared services
Identify the exact operating system, database edition, middleware, security products, agents, and commercial applications. AWS may offer a license-included rate, or the design may use BYOL with eligibility and mobility obligations. For example, Amazon RDS for SQL Server documents both License Included and Bring Your Own Media models; other engines and products have different rules. Include software assurance, Marketplace charges, vendor support, and license-management work in whichever option requires them.
Basic AWS Support is included, while paid support plans add technical access and other features. Include the support plan appropriate to the service level and account structure; current terms and prices are on the AWS Support pricing page. The on-premises alternative should include hardware, software, and specialist support contracts that would be kept or removed.
Network, public IPv4, and observability
Network costs are often the difference between a credible model and an optimistic one. Estimate traffic by direction and location, including internet egress, cross-Region replication, cross-Availability-Zone calls, VPN or Direct Connect, and transfers between the application and data tiers. The AWS estimate should include the data path, not just the service at each endpoint.
A NAT gateway is charged for the hours it is provisioned and the gigabytes it processes, with standard data-transfer charges also possible. Cross-Availability-Zone placement can add transfer charges. AWS documents the calculation and endpoint alternatives in its NAT gateway pricing guidance. Public IPv4 addresses also have a charge; count addresses attached to resources, NAT gateways, and idle allocations using the current Amazon VPC pricing.
Observability is a cost in both models. Include log and metric ingestion, retention, traces, dashboards, queries, exports, agents, and the storage and staff required to operate them. CloudWatch pricing varies by Region and usage dimension, so use expected telemetry volume rather than a placeholder “monitoring” percentage.
Backup, recovery, and availability
Match the same RTO, RPO, retention, encryption, restore-test frequency, and number of failure domains. AWS Backup can charge for backup storage, restores, restore testing, cross-Region transfer, and Audit Manager; see the AWS Backup overview. Include snapshots, replicas, standby capacity, and the runbook work needed to prove recovery. On-premises costs may include a second site, duplicate hardware, backup media, replication links, and the people who test restores. High availability and disaster recovery are service-level choices, not automatic savings from either platform.
Build a comparable TCO model
Choose a period long enough to include a planned refresh or commitment. A three-year horizon is common, but it is only useful when both options are modeled over the same three years. Define the unit of comparison—one application, a workload portfolio, or a service—and keep the scope stable.
Use these formulas, with each term documented in an assumption register:
TCOon-prem = avoidable hardware/facilities + software/licenses + operations + network + backup/DR + support + transitionTCOAWS = core AWS resource charges (compute/storage/database) + network + observability + backup/DR + support + license fees + remaining operations + migration/dual-runBreak-even months = one-time migration and transition cost / monthly run-rate difference, when the AWS run rate is lower.
Make the categories disjoint and count each meter or shared cost once. For example, exclude separately modeled network, observability, backup, support, and license fees from “core AWS resource charges”; use either a license-included rate or a separate license fee, never both. Do not mix a fully loaded on-premises number with an AWS service-only number. Add shared costs using the same allocation logic, and label taxes, financing, internal chargebacks, credits, and business benefits separately.
Illustrative example: a break-even point, not a promise
Assume one workload has the same availability, performance, data retention, security controls, and recovery objectives in both designs. These rounded USD figures are deliberately illustrative assumptions for showing the arithmetic; they are not current AWS prices or an observed customer result.
| Annual run-rate assumption | On-premises | AWS |
|---|---|---|
| Compute, storage, and database capacity | $96,000 | $156,000 |
| Facilities, power, and cooling / network and public addresses | $36,000 | $42,000 |
| Software, licensing, backup, and observability | $72,000 | $54,000 |
| Operations and support staff | $120,000 | $48,000 |
| Annual run rate | $324,000 | $300,000 |
In this assumption set, the on-premises three-year run rate is 3 × $324,000 = $972,000. AWS adds an assumed $180,000 for migration and $60,000 for temporary dual-run capacity, so its three-year total is 3 × $300,000 + $180,000 + $60,000 = $1,140,000. On-premises is $972,000 over the same period, so AWS is $168,000 higher in this simple three-year nominal comparison even though its steady-state run rate is lower.
The annual run-rate difference is $324,000 − $300,000 = $24,000, or $2,000 per month. The transition cost is $180,000 + $60,000 = $240,000. Break-even is therefore $240,000 / $2,000 = 120 months, or 10 years, assuming demand and nominal costs stay constant. This simple break-even ignores discounting and the timing of cash payments; a long-horizon decision needs a dated cash-flow model and an agreed financial method. The result may support a redesign of the migration scope, a different target architecture, or a decision to retain the workload; it does not support a universal AWS savings claim.
Test scenarios and sensitivity
Change the assumptions most likely to move the result and keep the service level fixed:
- Higher AWS utilization or better purchasing: if the AWS run rate falls to $260,000, the annual difference is $64,000 and break-even is
$240,000 / ($64,000 / 12) = 45 months. - Lower or burstier demand: if the AWS run rate falls to $220,000 through measured scaling, break-even is
$240,000 / ($104,000 / 12) ≈ 28 months. - More network, logging, or support use: if the AWS run rate rises to $340,000, it is higher than on-premises before transition costs; there is no positive run-rate break-even under those assumptions.
Run the scenarios with actual inventory and usage data before making a commitment. Include a sensitivity for workload growth, egress volume, database capacity, support level, license model, staffing assumptions, refresh timing, and the amount of capacity kept during dual-run. If modernization changes latency, availability, deployment speed, or resilience, report those outcomes beside the cost model rather than hiding them inside a single percentage.
Include modernization and migration timing
Migration is an investment with a transition period
Migration work can include discovery, dependency mapping, landing-zone and network design, application changes, data transfer, testing, security review, training, cutover, rollback preparation, and decommissioning. During a phased move, both environments may run together. Model temporary AWS resources, source capacity, replication, licenses, connectivity, and staff time until the old system is actually retired.
Use AWS Migration Evaluator to build a data-driven business case from existing environment information when it fits the assessment. It can inform a scenario; its output is not a guarantee that every workload will cost less. For AWS service estimates, the AWS Pricing Calculator documentation describes the available calculator experiences. Select the relevant Region, services, usage, purchase options, and eligible discounts for your estimate, then verify account-specific agreements separately. The calculator estimate is not an invoice and does not replace measured usage.
Our content migration guide covers inventory, transfer, verification, cutover, and rollback decisions that should appear in the migration budget and schedule.
Compare controls and service levels explicitly
Compliance is not a generic AWS discount. Record the controls the workload needs: identity and access, encryption and key management, audit retention, vulnerability management, data location, recovery tests, and incident response. AWS operates some underlying controls under its shared responsibility model; the customer still designs and operates the controls that apply to the workload. Compare the labor, tooling, attestations, and evidence required in each environment.
Modernization also changes the boundary of responsibility. Moving a database to a managed service may reduce patching and hardware work but add service-specific capacity, backup, network, licensing, and monitoring costs. Moving a batch job to Lambda may replace idle servers with per-invocation billing but add event, logging, and downstream-capacity considerations. Compare each target with a matched workload and service level. Our serverless migration guide describes how to test runtime fit, downstream limits, rollback, and measured cost.
Manage the actual cost after migration
A business case becomes useful only when its assumptions can be checked against the bill and service outcomes. Use AWS Cost Explorer for trends and dimensions, AWS Budgets for alerts, and the Cost and Usage Report or Data Exports for detailed line items. Activate cost allocation tags and use Cost Categories to assign shared charges to applications, teams, or environments. Keep unallocated costs visible.
Review actual cost against the same workload volume, service level, and comparison period used in the business case. Investigate usage growth, idle capacity, data paths, unneeded public addresses, NAT processing, log retention, backup copies, database capacity, license changes, and commitment coverage. Revisit a Savings Plan or other commitment only after demand is stable enough to carry the term.
Cost optimization changes should preserve performance, security, availability, retention, and recovery requirements. A lower bill that misses an agreed service objective is a changed service, not a like-for-like saving.
A practical decision sequence
- Define the workload, service level, comparison period, and decision boundary.
- Collect measured on-premises inventory, utilization, traffic, licenses, staffing, facilities, support, backup, and recovery costs.
- Model AWS services, data paths, observability, support, licensing, commitments, migration, and dual-run costs with current regional inputs.
- Separate avoidable run rate, sunk cost, depreciation, and cash timing.
- Run base, upside, and downside scenarios; calculate break-even from the run-rate difference and transition cost.
- Validate the chosen scenario with a representative pilot and compare actual cost and service outcomes after cutover.
For a broader cost-practice reference, see our AWS cost optimization strategies guide for attribution, rightsizing, purchase options, and post-migration review.
Conclusion
AWS may be the better financial choice when elasticity, managed operations, or a modernization outcome removes enough avoidable cost to repay the transition investment. On-premises may remain cheaper for stable, highly utilized workloads with existing paid-for capacity, low network movement, favorable licenses, and a well-run facility. A defensible decision shows both outcomes, the assumptions that drive them, and the point at which those assumptions change.
FAQs
What should AWS TCO include?
Include AWS service charges and commitments, support, software or license costs, data transfer and network components, observability, backup and recovery, remaining engineering and operations work, migration, dual-run, and decommissioning. Compare the same workload, service level, period, and allocation basis in the on-premises model.
Is cloud computing always cheaper than on-premises infrastructure?
No. Cloud can lower avoidable costs for variable workloads or reduce infrastructure work through managed services, but steady workloads can be more expensive when utilization, data transfer, support, licensing, or commitments are modeled poorly. Use workload evidence and scenarios instead of a fixed savings percentage.
Which AWS tools help compare costs?
Use the AWS Pricing Calculator for a service estimate and Migration Evaluator for a data-driven migration business case when the service fits your assessment. Use Cost Explorer, Budgets, cost allocation tags, and detailed cost and usage data after migration to compare assumptions with actual spend. Prices, service features, and support terms change, so check the linked AWS pages for the Region and date of your estimate.
How do I calculate the cloud break-even point?
Subtract the AWS steady-state monthly run rate from the on-premises steady-state monthly run rate. Divide the one-time migration and transition cost by that positive monthly difference. If AWS has the higher run rate, there is no positive break-even under those assumptions; change the architecture or keep the workload where it is until the evidence changes.