---
title: "Startup Burn Rate Modeling When AWS Costs Go Non-Linear"
published: true
description: "Flat runway models miss non-linear AWS cost spikes. Learn how spot reclamation, reserved capacity cliffs, and autoscaling steps can double your bill overnight."
tags: [cloud, devops, architecture, performance]
canonical_url: https://mvpfactory.co/blog/startup-burn-rate-aws-non-linear
---
What We Are Building
By the end of this article you will have a stress-tested runway model that accounts for spot instance reclamation, reserved capacity commitment cliffs, and autoscaling threshold multipliers. The flat runway = cash / average_monthly_burn formula will get you killed. Let me show you a pattern I use in every infrastructure cost review.
Prerequisites
- Basic familiarity with AWS compute pricing (on-demand, reserved, spot)
- Access to AWS Cost Explorer
- A spreadsheet or the willingness to wire up a simple model
The Problem With the Flat Model
Every seed-stage finance deck has the same slide: runway = cash / average_monthly_burn. It is clean, it is fundable, and it is dangerously wrong once your infrastructure spend goes non-linear.
The real formula looks like this:
effective_monthly_burn(t) =
fixed_costs
+ reserved_capacity_cost (committed, regardless of usage)
+ on_demand_fill_rate(t) * on_demand_unit_price
+ spot_reclamation_overhead(t)
The last two terms are non-linear functions of traffic. That is not a rounding difference — it is a different class of problem.
Step 1 — Understand the Three Cost Levers
Lever 1: Spot instance mix and reclamation risk
Spot instances run at 60–90% discount. The catch: at high-utilization periods, AWS reclaims spot capacity with a two-minute warning. Your autoscaler frantically provisions on-demand replacements at full price, typically over-provisioning by 20–40% to cover cold-start time. A 10% reclamation event during a spike does not cost you 10% more — it costs you the full on-demand rate for the replacement fleet plus the overprovision buffer.
Lever 2: Reserved capacity commitment cliffs
Reserved instances are paid for whether you use them or not. Most teams buy 1-year reservations sized for their P75 traffic. Here is what that looks like in practice:
| Traffic scenario | Reserved coverage | On-demand spillover |
|---|---|---|
| Normal day (P50) | Overprovisioned (~30% idle) | $0 |
| Busy day (P75) | ~100% (target) | $0 |
| Traffic spike (P95+) | ~60% covered | 40% on-demand at 3–4x unit cost |
| Spike + spot reclaim | ~60% covered | 60–80% on-demand |
The P95 spike does not cost you 33% more than the P75 day. It can cost 2–3x more because on-demand pricing is not linear with the reserved baseline.
Lever 3: Autoscaling threshold multipliers
Autoscaling triggers at thresholds — say, 70% CPU — but instance provisioning is not granular. You add a full instance. Crossing the 70% threshold for a compute-heavy workload might mean spinning up 4 instances to handle 15% more traffic. The cost curve is a staircase, not a ramp.
Step 2 — Run the Worked Example
Take a B2B SaaS running on AWS at $50k MRR. Infrastructure is sitting at $8,000/month — a healthy 16% COGS ratio. Fleet mix: 60% reserved, 30% spot, 10% on-demand baseline.
One large enterprise customer runs an automated batch job generating 3x normal API traffic for 18 hours:
Normal baseline: $8,000/mo ($267/day)
Spike day observed cost: $1,100 (single day, vs. $267 baseline)
— 4x the daily rate on one day alone
Projected monthly impact: 2–3x if this pattern recurs regularly
The spike triggers spot reclamation, which forces on-demand provisioning, which crosses two autoscaling thresholds in sequence. One customer, one day, doubles the AWS invoice.
The flat runway model showed 18 months. The corrected model — accounting for P95 cost scenarios weighted by probability of enterprise customer growth — shows 13 months. That is a five-month gap and a Series A conversation.
Step 3 — Build the Stress-Tested Runway Formula
Here is the minimal setup to get this working:
stress_tested_runway =
cash / weighted_monthly_burn
where:
weighted_monthly_burn =
(P50_infra * 0.60) +
(P75_infra * 0.30) +
(P95_infra * 0.10) +
fixed_opex
Weight your infrastructure cost scenarios by probability. Build the P95 scenario explicitly — run a load test at 3–5x normal traffic, observe your autoscaling behavior, and price the spike before your enterprise pipeline forces it on you in production.
Gotchas
The docs do not mention this, but AWS Cost Explorer's reservation coverage reports make the spot/reserved/on-demand audit a one-hour exercise — not a week-long project. Run it quarterly. A ratio that was efficient at $5k MRR may be actively wasteful at $50k MRR.
Here is the gotcha that will save you hours: autoscaling thresholds calibrated to protect P99 latency may be triggering expensive scale-out events for routine traffic variance. Instrument the cost-per-scale-event. Tune the threshold with cost awareness, not just latency SLAs.
Do not weight your P95 scenario at zero. The five-month runway gap and 2–3x cost variance on P95 days are the expected outcome for a growing B2B SaaS that never stress-tested its cost curve. They are not edge cases.
Conclusion
Linear burn models are a seed-stage convenience that becomes a Series A liability. Model P95 infrastructure cost explicitly, audit your instance mix quarterly, and set autoscaling thresholds with cost awareness baked in. The formula above is not a finance exercise — it is operational survival.
Further reading: AWS Cost Explorer reservation coverage reports | EC2 Spot Instance best practices
Top comments (0)