TCO & Cloud Economics

A fully-depreciated asset is a sunk cost. The relevant question is: what does it cost to keep running — and how does that compare to cloud?

Hidden on-premises costs (often excluded from naive comparisons):

Cost category	Typical impact
Hardware refresh	Every 3-5 years; servers, storage, networking. Often ≥ initial cost.
Power & cooling	Typically 40-60% of hardware cost as annual overhead (PUE)
Physical security	Physical access controls, security staff, CCTV, cage rental
Stranded capacity	Avg on-prem utilisation: 15-20% of provisioned capacity
Operational staff	SysAdmins, storage admins, network engineers managing hardware
Licensing	VMware hypervisor, management tooling, OS licenses
DR / backup	Secondary site, tape infrastructure, backup software licensing

PUE (Power Usage Effectiveness):
Ratio of total data centre power to IT equipment power. World-class hyperscaler PUE: 1.1-1.2. Typical enterprise DC: 1.6-2.0. All that overhead is pure cost with no compute value.

Stranded capacity example:
You provision 100 servers for peak load (Christmas, month-end). Average utilisation in the remaining 11 months: 18%. You are paying for 100% of those servers 100% of the time. Cloud scales to demand — you pay only for what's running.

Key vocabulary:
• TCO (Total Cost of Ownership) — all costs associated with owning and operating an asset over its useful life
• Sunk cost — a past cost that cannot be recovered; irrelevant to future decisions
• Stranded capacity — provisioned compute that is idle and paid for but delivering no business value
• PUE (Power Usage Effectiveness) — efficiency metric for data centre power overhead

CapEx vs OpEx involves real accounting, tax, and cash-flow differences — neither is universally "better".

CapEx (Capital Expenditure):
• Upfront large payment for long-lived assets (servers, storage, networking)
• Capitalised on balance sheet; depreciated over useful life (e.g., 5 years straight-line)
• Tax treatment: depreciation allowances taken over time, not immediately
• Cash flow: large outflow in year 0; after that, the asset is "free"
• Risk: asset obsolescence; refresh cycle locks in large future spend regardless of business needs

OpEx (Operating Expenditure) — cloud:
• Recurring monthly payment; expensed immediately against P&L
• No balance sheet asset, no depreciation schedule
• Tax treatment: fully deductible in the period incurred (faster tax benefit in many jurisdictions)
• Cash flow: smooth, predictable (with commitments) or variable (on-demand)
• Risk: "bill shock" if usage is uncontrolled; requires FinOps discipline

The CFO framing for cloud:
• Cloud frees capital that was tied up in hardware cycles — capital can be invested in product development, acquisitions, or returned to shareholders
• Variable cost model aligns IT spend to business outcomes: if revenue falls, cloud costs can scale down
• Reserved Instances (1yr/3yr commitment) can appear on balance sheet as operating leases under IFRS 16 / ASC 842 depending on audit treatment

FinOps (Cloud Financial Management):
The practice of bringing engineering, finance, and business together to manage cloud spend. Key practices: unit economics (cost per customer/transaction), showback/chargeback per team, anomaly detection, rightsizing.

Key vocabulary:
• CapEx — large upfront capital investment in long-lived assets; depreciated over time
• OpEx — recurring operational spend; expensed immediately against P&L
• Depreciation — systematic allocation of asset cost over its useful life
• FinOps — discipline of cloud financial management; treats cloud spend as a variable, optimisable cost

Mixing all four pricing models is the optimal cloud cost strategy — each serves a different workload archetype.

Model	Discount	Use case	Risk
On-Demand	Baseline (0%)	Variable workloads, dev/test, spiky traffic	Most expensive; no commitment
Reserved Instances	40-60% (1yr); up to 72% (3yr all-upfront)	Steady-state production workloads	Committed to specific instance family/region
Savings Plans	Up to 66% (Compute SP)	Baseline workloads; want instance-type flexibility	$/hr spend commitment; less flexible than On-Demand
Spot / Preemptible	50-90%	Batch, ML training, big data, CI/CD	Can be reclaimed in 2 min; workload must be fault-tolerant

Optimal strategy (blended):

Baseline steady load   → Reserved Instances or Savings Plans (60-70% of total fleet)
Variable peak traffic  → On-Demand (auto-scaling, on top of committed baseline)
Batch / analytics      → Spot Instances (stateless jobs; retry on interruption)

Key AWS-specific notes:
• Convertible RIs — can be exchanged for different instance types within the same class; slightly lower discount than Standard RIs
• Compute Savings Plans — apply across any instance family, region, OS, enabling maximum flexibility
• EC2 Instance Savings Plans — highest discount but locked to a specific instance family and region
• Azure equivalent for RIs: Reserved VM Instances; for Spot: Azure Spot VMs with Eviction policy

Key vocabulary:
• Reserved Instance (RI) — a 1- or 3-year commitment to a specific instance type in exchange for a significant discount
• Savings Plans — flexible commitment to a $/hr spend level, applied across eligible instance types
• Spot Instance / Preemptible VM — discounted instance using spare cloud capacity; can be interrupted with minimal notice
• Blended rate — the effective hourly cost across all pricing models in your fleet

Rightsizing is data-driven engineering, not guesswork. The concern about "risk" is valid but managed with proper tooling and process.

Why on-premises instances are typically oversized:
• When migrating ("lift-and-shift"), teams map on-prem vCPUs/RAM 1:1 to cloud — but on-prem was provisioned for peak, not average
• Average on-premises server utilisation: 15-20% of provisioned capacity
• Cloud pricing scales linearly with instance size; you pay 4x for a 4x larger instance
• Result: a workload using 4 vCPUs average running on a 16-vCPU instance wastes 75% of cost

Rightsizing tooling:
• AWS Compute Optimizer — analyses EC2, Lambda, ECS, EBS, RDS, ASG configurations using ML; provides Right-Sized, Over-Provisioned, Under-Provisioned recommendations with risk indicators
• AWS Cost Explorer Rightsizing Recommendations — simpler but less ML-driven
• Azure Advisor Cost recommendations — analyses VM utilisation and recommends resize or shutdown
• Infracost / CloudHealth / Apptio Cloudability — third-party FinOps platforms

Safe rightsizing process:

1. Observe: collect 2-4 weeks of CPU, memory, network, disk I/O metrics
2. Analyse: Compute Optimizer recommendation + safety margin (e.g., peak × 1.5)
3. Test: resize in staging → run load tests
4. Implement: resize in maintenance window, with automated rollback alarm
5. Monitor: watch for performance degradation alerts for 2 weeks post-resize

What rightsizing is NOT:
• Not selecting the smallest possible instance
• Not ignoring burst patterns and memory pressure
• Not resizing without a rollback plan

Key vocabulary:
• Rightsizing — adjusting cloud instance types/sizes to match actual workload resource demand plus safety margin
• Compute Optimizer — AWS ML-based service providing rightsizing recommendations for EC2 and other compute services
• Utilisation rate — percentage of provisioned capacity that is actively being used by the workload
• Safety margin — the buffer above measured peak utilisation to allow for traffic spikes without degradation

A credible CFO-ready cloud business case has three financial layers: migration investment, avoided on-prem costs, new cloud costs.

Model structure:

1. Migration cost (one-time, Year 0-1):
• Assessment and discovery tooling (e.g., AWS Migration Evaluator, Cloudamize)
• Migration tooling (AWS MGN, Database Migration Service, partner licences)
• Professional services / SI partner fees
• Internal retraining and certification
• Productivity loss during migration (teams distracted from BAU)
• Dual-run costs (running both on-prem and cloud during parallel operation — typically 3-6 months)

2. Avoided on-premises costs (starting Year 1-2):
• Hardware refresh avoided (savings is realised when the next planned refresh is cancelled)
• Data centre lease, power, cooling — prorated as accounts migrate off
• Operational staff — redeployment or reduction (be cautious; redundancy costs are real)

3. Cloud run-rate costs:
• Compute (blended On-Demand + Reserved + Spot model)
• Storage, data transfer (egress costs are real; often underestimated)
• Managed service premiums (RDS > self-managed MySQL, but operational savings offset it)

Payback period formula:
$$ ext{Payback} = rac{ ext{Total migration cost}}{ ext{Annual on-prem savings} - ext{Annual cloud cost}}$$
Typical range: 18 months to 3 years. Heavily dependent on on-prem refresh timing.

5-year ROI formula:
$$ ext{ROI} = rac{ ext{5-year net savings} - ext{Migration cost}}{ ext{Migration cost}} imes 100%$$
Typical range for well-managed migration: 30-200% depending on starting on-prem cost structure.

Common model mistakes:
• Forgetting egress costs (cloud charges for data leaving the region or cloud)
• Underestimating dual-run period costs
• Assuming 1:1 instance mapping without rightsizing (overstates cloud costs)
• Not accounting for software licensing changes (BYOL vs licence-included)

Key vocabulary:
• Payback period — time until cumulative savings offset total migration investment
• ROI (Return on Investment) — net financial benefit relative to investment, expressed as a percentage
• Dual-run cost — cost of operating both on-premises and cloud environments simultaneously during migration transition
• Egress cost — charges incurred when data is transferred out of a cloud region or to the internet