Cloud TCO formulas that aren't lies (with a worked spreadsheet)
TCO formulas that include the line items vendor calculators conveniently omit — committed compute, real egress, ops time, migration cost, opportunity cost.
Vendor TCO calculators all do the same thing: pick a single VM, multiply by 730 hours, claim a savings number, ignore everything else. After living through dozens of these comparisons, here is the formula I actually use to model cloud workload total cost honestly.
The components of cloud TCO that actually matter
Total monthly cost = (1) compute + (2) storage + (3) network + (4) managed services + (5) operations + (6) migration amortized + (7) opportunity cost.
Skip any of these and your model is wrong.
1. Compute
Easy on the surface, traps in the corners.
compute = sum(instance_hourly * hours_per_month) for each instance type
* (1 - commitment_discount)
* environment_multiplier
+ autoscale_burst_capacity_overheadThe traps:
- commitment_discount: the effective discount you actually realise. Headline RI savings are 30-72%; effective average is 25-40% across a portfolio that has churn.
- environment_multiplier: dev + staging + DR usually adds 30-50% to production compute. Don't price production in isolation.
- autoscale burst overhead: any auto-scaling group with a min < max has headroom you pay for. A "minimum 2 instances" web tier is paying for 1 instance of unused capacity 80% of the time.
2. Storage
storage = block_gb * $/GB-month
+ provisioned_iops * $/IOPS-month
+ provisioned_throughput * $/MB/s-month
+ snapshot_storage_gb * $/GB-month
+ object_storage_gb * tier_rate
+ (object_retrievals / 1000) * $/1000-requestsThe hidden lines: provisioned IOPS above baseline, snapshots that accumulate forever, object retrieval costs in cold tiers. More on storage tier traps here.
3. Network
The single biggest divergence point between providers.
network = egress_gb * $/GB
+ inter_az_gb * 2 * $0.01 (AWS specific, both directions)
+ inter_region_gb * $/GB
+ nat_gateway_hours * $/hour
+ nat_gateway_data_gb * $/GB
+ load_balancer_base + lcu_consumption
- cdn_offload_pct * egress_gb * $/GBThe CDN offload is the most underused variable. Putting Cloudflare in front of static assets cuts the egress line by 60-90% on average. Egress trap details.
4. Managed services
The most provider-specific line. Each managed service has its own pricing model.
managed_services = rds_instance_hourly * (1 + multi_az_premium)
* (1 - rds_ri_discount)
+ rds_storage + rds_iops
+ rds_backup_above_storage_size
+ elasticache_instance_hourly * (1 - cache_ri_discount)
+ lambda_invocations * $/invocation
+ lambda_compute_gb_seconds * $/GB-second
+ dynamodb_read_capacity + dynamodb_write_capacity
+ dynamodb_storage_gb * $/GBFor most workloads, managed services are 30-50% of the total cloud bill. They're also the stickiest, because the alternative is "run it yourself".
5. Operations
The line everyone leaves out.
operations = sre_fte * $/hr * 160_hours_per_month * operational_complexity_factor
+ on_call_compensation
+ tooling_subscriptions (Datadog, NewRelic, PagerDuty, etc.)operational_complexity_factor = (number_of_managed_services_in_use × 0.05) + (1 if self-hosting databases else 0) + (0.5 if multi-region else 0) + (1 if multi-cloud else 0)
A team running pure-managed AWS with no Kubernetes might need 0.2 FTE of SRE per workload. Running self-hosted Postgres + Kafka on Hetzner across two regions = 1 FTE. The operational cost difference is real and dwarfs the infra delta for small workloads.
6. Migration amortized
If you're modelling a change, include the migration cost.
migration_amortized = (engineering_weeks * 40 * $/hour) / amortization_period_monthsFor a typical 8-week migration project at $100/hour engineering cost, that's $32,000 total. Amortized over 24 months: $1,333/month. The new infra has to beat the old infra by more than $1,333/month for the migration to pay back in 2 years.
7. Opportunity cost
The dollar value of "what else could the team do with this time"?
If your team is bandwidth-constrained on shipping features that drive revenue, spending 200 engineer-hours migrating off AWS to save $300/month is bad opportunity-cost economics. If your team is overstaffed and bored, the same migration is fine.
Quantify this:
opportunity_cost = migration_hours * (revenue_per_engineer_hour_on_features - revenue_per_engineer_hour_on_infra)Hard to measure, but most engineering managers can estimate within 30%.
Worked example
Workload: small SaaS. Current AWS bill: $14,000/month list, $11,000 with RIs.
Proposed move: hybrid Hetzner + AWS RDS, as described in multi-cloud arbitrage in practice.
| Line | AWS | Hybrid |
|---|---|---|
| Compute | $5,000 | $400 |
| Storage | $1,200 | $1,100 (S3 + R2 + Hetzner volumes) |
| Network (incl. egress) | $2,700 | $350 (CDN absorbs most) |
| Managed services (RDS, ElastiCache, etc.) | $3,400 | $3,400 (unchanged) |
| CloudWatch + tools | $450 | $250 |
| Operations FTE (0.3 FTE today) | $1,200 | $2,000 (0.5 FTE) |
| Migration amortized (8 weeks, 24-month payback) | $0 | $1,333 |
| Total monthly | $13,950 | $8,833 |
Saving: $5,100/month. Annual: $61,200. Payback on migration: ~6 weeks.
Note how including operations FTE (the line every vendor calculator omits) reduces the apparent savings by $800/month — but the project is still strongly positive.
What vendor calculators leave out
AWS Pricing Calculator: ignores realistic commitment discounts, ignores operations cost, ignores migration cost, optimistic on egress.
GCP Pricing Calculator: similar. Better at modelling CUDs accurately.
Azure TCO Calculator: explicitly designed for "moving FROM AWS" sales pitches, so the AWS side is steelmanned cheaply on managed services.
Provider TCO calculators are sales tools, not honest cost models. Build your own using the formulas above.
The "right" amortization period
If your project plan has a 3-year horizon, amortize migration over 24 months (allow some headroom). For shorter horizons, amortize over 12 months. For "we'll keep it forever" workloads, 36 months is reasonable.
Anything beyond 36 months and the technology landscape has changed enough that the comparison is moot.
The cloudprice approach
The cloudprice TCO calculator handles compute + storage + egress in a single side-by-side view. For the operations + migration + opportunity-cost lines, you have to do the math yourself — they're workload-specific. But starting from a clean compute + network model is the right place to begin.
External reading: FinOps Framework on showback/chargeback, and AWS Well-Architected Cost Optimization pillar for the AWS-specific levers.