SaaS COGS Calculator
Measure infra cost as a percentage of MRR, classify against the Bessemer Cloud Index + KeyBanc Private SaaS Survey band, and reveal the gross-margin headroom you can recover by hitting your stage median.
You are at or below the $1M – $10M ARR band median (11.0%). No recoverable headroom — focus on holding the ratio as MRR scales.
| MRR growth | New ratio | Δ pp |
|---|---|---|
| +10% | 9.6% | -0.3pp |
| +20% | 9.4% | -0.5pp |
| +30% | 9.2% | -0.7pp |
| +50% | 8.9% | -1.0pp |
| +100% | 8.4% | -1.5pp |
Bessemer Cloud Index + KeyBanc Private SaaS Survey $1M – $10M ARR cohort.
p59 vs $1M – $10M ARR peers (lower ratio = higher percentile)
Hosting is 69% of infra (50–70% optimal; >85% = lock-in risk)
-1.1pp vs $1M – $10M ARR median
Median 11.0% / p75 8.0% — you are at 9.9%
5 of 6 buckets active — 4+ reduces single-vendor lock-in risk
Already at or below band median — no recoverable headroom
Last reviewed: May 2026
What SaaS COGS Actually Means
Cost of goods sold for a SaaS company is not the wholesale cost of physical inventory — it is the direct cost of delivering one more unit of subscription software to one more customer. The classic SaaS COGS stack is six buckets: cloud hosting (AWS, GCP, Azure), data and storage, bandwidth and CDN egress, third-party APIs that scale with usage (Twilio, Stripe network fees, data providers), observability and monitoring (Datadog, New Relic), and a catch-all "other infra" line. Each of those buckets is a recurring monthly expense that follows the customer for the entire life of the subscription.
That permanence is what makes the saas cogs ratio so load-bearing. Unlike R&D — which capitalizes and amortizes — or sales and marketing — which gets paid back on a CAC payback timeline — every dollar of infra spent this month is gone this month, never recovered. So when CFOs read the board deck, the infrastructure-as-percent-of-MRR ratio is the single fastest signal of whether the unit economics work. This calculator computes it the canonical way: total infra divided by monthly MRR, expressed as a percentage, classified into a stage-adjusted band.
The Infra Cost / MRR Ratio: A Single Number for Cloud Efficiency
One number replaces the entire COGS spreadsheet for the board meeting: total monthly infra spend divided by monthly MRR. The result is interpretable in seconds because the band has four crisp zones — elite ≤8%, healthy 8–15%, concerning 15–25%, broken >25% — and those thresholds are remarkably stable across the widely cited Bessemer Cloud Index and KeyBanc Private SaaS Survey cohorts. The ratio is also calibrated to the way investors and operators actually talk about cloud efficiency in diligence: "we're at 9%" is a complete sentence in a partner meeting in a way that "we spend $48K a month on AWS" is not.
The reason this works as a CFO-grade metric is that it normalizes for company size. A pre-PMF startup at $40K MRR spending $6K on cloud is at 15% — concerning. A late-stage SaaS at $7M MRR spending $700K on cloud is at 10% — healthy. The dollar figures are completely different; the ratio places both companies in the same comparison frame. The hero number in this tool is the ratio, deliberately, because that is the metric every other SaaS finance read translates back into.
SaaS Margin and Cost Structure Benchmarks by Stage
SaaS margin sits inside a saas cost structure that shifts predictably with scale. At <$1M ARR, infra cost runs at a ~13% median — fixed-cost drag dominates because base hosting and monitoring spend doesn't shrink to match tiny MRR. At Series A ($1M–$10M ARR), the median falls to ~11% as MRR grows faster than reserved capacity. By Series B ($10M–$50M) it hits ~10%, and at $50M+ ARR mature multi-tenant SaaS converges around ~8% — which is exactly where the elite band threshold sits.
Top-quartile (p75) cohorts run about 2–3 percentage points tighter at every stage: Series A p75 is ~8%, Series B p75 is ~7%, $50M+ p75 is ~6%. The p90 best-in-class cohorts compress further to 3–6% of MRR depending on stage. Saas margin and saas profit margin both compound off these infra numbers — every point of infra inefficiency translates 1:1 to a gross-margin point lost, which then compresses the SaaS multiple investors apply to the ARR. This calculator positions you against synthetic distributions curve-fit from those datasets, with the percentile computed live as you type.
What Counts as Cost of Goods Sold for SaaS — Line-Item Breakdown
The cost of goods sold saas convention puts six things in the infra line: cloud hosting, data and storage, bandwidth and CDN, third-party APIs with usage-based pricing, monitoring and logs, and miscellaneous infra. Hosting (compute + database) typically dominates, representing 55–70% of total infra spend for healthy multi-tenant SaaS. Data and storage often run 8–15% — Snowflake-style warehouses, S3 lakes, primary database storage. Bandwidth and CDN sit at 4–10% depending on payload size and geographic reach. Third-party APIs vary wildly with product type (Twilio-heavy SaaS hits 15%+, pure-software SaaS lands at 3–5%). Monitoring is usually 3–6%.
The reclassification rules matter as much as the buckets. Sales engineers do not belong in COGS — they support deals, not delivery, so they go to Sales & Marketing. Product R&D engineers never belong in COGS — they are R&D. Office rent (unless it is data-center space) is G&A. Executive compensation is G&A. The single most common first-time founder mistake is bundling sales engineering or R&D headcount into COGS, which pulls the gross margin down by 3–8 percentage points versus the properly-classified number. The companion SaaS Gross Margin Calculator runs the full 8-rule reclassification audit; this tool focuses on the infra-only core.
Hosting, Data, Bandwidth, APIs — The 6-Bucket SaaS Infra Model
Separating infra into six buckets exposes the optimization levers. When hosting is 80%+ of total infra, the calculator flags it as a hosting-concentration risk — a single AWS pricing change can swing the entire ratio, and the architecture probably lacks the diversification to negotiate from. When a bucket like third-party APIs dominates at 30%+ of infra, the problem is rarely cloud spend — it is the unit economics of the API itself (Twilio per-message, Stripe network fees, OpenAI per-token), which means the fix is on the product side, not in DevOps.
The Vendor Diversity score in the report card grades how many of the six buckets are actively in use. A SaaS running 5–6 active buckets is well-diversified — no single vendor outage takes down the cost line. A SaaS running 1–2 buckets is structurally concentrated. The healthy mid-zone is 4 active buckets: hosting + storage + bandwidth + monitoring, with APIs and "other" only firing when the product needs them. The breakdown donut in the main panel shows the split at a glance, with the per-customer infra tile underneath giving the DevOps companion read.
Multi-Tenant vs Single-Tenant: How Architecture Shifts the Benchmark
Architecture changes the band before any optimization work. Multi-tenant SaaS pools compute, storage, and network across all customers, so the unit cost of serving one more customer falls as the platform grows. Single-tenant SaaS dedicates a stack per customer — typical in regulated verticals (healthcare HIPAA, defense FedRAMP, finance SOC 2 Type 2 with strict isolation), or when enterprise contracts explicitly require it. The dedicated-stack model loses the amortization, so it runs roughly +4 percentage points hotter across every band.
In practical terms: multi-tenant elite is ≤8% of MRR, single-tenant elite is ≤12%. Multi-tenant healthy is 8–15%, single-tenant is 12–19%. The calculator toggles the band thresholds and the stage median benchmark when you switch architecture, so the percentile and zone classification stay calibrated. The strategic implication is harder to fix: investors still index against the multi-tenant cohort when applying SaaS valuation multiples — so a single-tenant SaaS at "Elite" 11% of MRR carries the cost narrative of multi-tenant "Concerning" 11% in the partner meeting. The right move is to flag the architecture decision explicitly in the deck, not to hope the band shift speaks for itself.
Gross Margin SaaS vs Gross Margin in Legacy On-Prem Software
Legacy on-prem enterprise software historically reported 90%+ gross margins because the customer ran their own servers — the COGS line was license fulfillment, support, and occasional services, almost nothing else. Gross margin saas looks different by design: cloud delivery is permanently on the COGS line, and a single inefficient hosting decision can knock 5 percentage points off the headline. That structural difference is why a SaaS at 78% gross margin is healthy while an on-prem company at 78% gross margin would be a turnaround candidate.
The flip side is the multiple. Public-market SaaS comps trade at 6–15× ARR depending on growth, retention, and gross margin; on-prem enterprise software trades at 2–4× revenue. The cloud delivery COGS line is the cost of admission to the higher multiple — and that is exactly why getting the infra ratio into the elite or healthy band matters financially, not just operationally. It is the gating threshold for the valuation framework that applies.
How to Recover Gross-Margin Headroom: Reserved Instances, Consolidation, Vendor Negotiation
The GM Headroom number is the dollar amount of annualized gross profit you would recover by hitting your stage band median. Three levers move it. Reserved-instance conversion is usually the fastest — committing 30–70% of steady-state hosting to 1- or 3-year reserved capacity captures a roughly 30% discount on the covered hours. The What-If simulator models this as `(1 − 0.30 × RI fraction)` applied to the hosting line: a 50% RI commit drops hosting 15% immediately, which on a $130K/mo Series B hosting bill is $234K/yr to gross profit.
Multi-region consolidation removes redundant bandwidth and storage when geographic coverage exceeds actual customer distribution — modeled here at 50% efficacy on the bandwidth + storage lines. Vendor rate cuts apply across the board, typically 5–15% from a credible negotiation backed by competitive quotes. Stacking all three plus 30% MRR growth (which delivers ~9pp of sub-linear scaling) is how SaaS at 18% of MRR get to 10% in a year — the simulator lets you model that stack live and read the dollar recovery at the bottom.
The Rule of 40 Implication of Infra Inefficiency
The Rule of 40 (growth rate plus operating margin should sum to 40+) is sensitive to gross margin because operating margin sits below GM in the P&L stack. Every percentage point of infra inefficiency hits gross margin directly, which translates roughly 1:1 to operating margin, which translates 1:1 to the Rule of 40 score. So a Series B SaaS at 14% infra ratio that cuts to the 10% Series B median picks up 4 points of GM, which is 4 points on the Rule of 40 — material when the cutoff for premium valuations is 40 and most public SaaS comps hover in the 30–45 range.
Investor Lens mode in this calculator surfaces the Rule of 40 implication explicitly, alongside a percentile read against the stage cohort. Flip it on if you're pressure-testing the partner-meeting narrative — the commentary is structured the way a VC associate would write the deal memo, not the way an operator would write the engineering retro.
"Infrastructure Costs" vs SaaS-Specific COGS — A Disambiguation
A note on terminology, because the phrase "infrastructure costs" carries a generic IT meaning in most search contexts. In enterprise IT it refers to data-center hardware, networking gear, on-prem servers, and the staff that runs them — closer to capital expense than SaaS cloud delivery. In SaaS, the equivalent term is "cloud infra COGS" or simply "infra ratio," and the dollars are operational cloud spend (AWS, GCP, Azure, the SaaS-on-SaaS API stack). This calculator is built for the SaaS sense — cloud delivery economics for subscription software. If you're looking for general IT infrastructure cost modeling (Cisco gear, VMware licensing, colocation), that's a different category entirely.
Frequently Asked Questions
What is SaaS COGS, and what counts as cost of goods sold for a SaaS company?
SaaS COGS is the direct cost of delivering software to one more customer. It includes cloud hosting (AWS, GCP, Azure), data and storage (S3, Snowflake, DB storage), bandwidth and CDN egress, third-party APIs (Twilio, Stripe network fees, data providers), monitoring (Datadog, New Relic), and any other infrastructure line item that scales with usage. Customer support and customer success are sometimes added depending on policy, but the infra-only core is what this calculator measures.
What's a healthy SaaS profit margin, and where should infra fit?
A healthy SaaS profit margin starts with a healthy gross margin — typically 70–80% — and infra is the single largest controllable input on the COGS side. As a rule of thumb, infra alone should land in the 8–15% of MRR band for multi-tenant SaaS; anything below 8% is elite, 15–25% is concerning, and above 25% is structurally broken. Pull infra into that band and the rest of the SaaS profit margin math (sales efficiency, retention) becomes the leverage point.
What does a normal SaaS cost structure look like by stage?
A normal SaaS cost structure shifts with scale. Sub-$1M ARR companies typically run infra at ~13% of MRR — fixed-cost drag from base hosting dominates at low MRR. Series A ($1M–$10M) median is ~11%, Series B ($10M–$50M) is ~10%, and $50M+ converges around 8% as multi-tenant amortization and reserved-instance commitments compound. Top-quartile (p75) cohorts run 2–3 percentage points tighter at every stage.
What percentage of MRR should hosting (AWS, GCP, Azure) be?
Hosting itself usually represents 55–70% of total infra spend for typical multi-tenant SaaS, which translates to roughly 5–10% of MRR at healthy efficiency. Above 12% of MRR on hosting alone is a flagged diligence item — most teams in that zone can close 25–40% of the gap with reserved-instance conversion (a ~30% discount on covered hours) and multi-tenant consolidation. Note that the broader generic phrase "infrastructure costs" usually refers to data-center hardware and IT spend rather than SaaS cloud delivery — they are different cost categories.
What's the difference between gross margin SaaS vs traditional software gross margin?
Gross margin SaaS includes cloud delivery (hosting, APIs, CDN, monitoring) as a recurring COGS line — the costs follow the customer over the life of the subscription. Traditional on-prem software gross margin excluded those costs entirely (the customer ran their own servers), so legacy enterprise software historically reported 90%+ gross margins. Modern SaaS lands at 70–85% because the cloud delivery infra is permanently on the COGS line, and a single point of infra inefficiency translates 1:1 to a gross-margin point lost.
Is 8% of MRR really the elite band for infra cost?
Yes — 8% maps to the top-quartile threshold for multi-tenant SaaS across the widely cited Bessemer Cloud Index and KeyBanc Private SaaS Survey cohorts. At $50M+ ARR the median itself converges near 8%, which is why mature multi-tenant SaaS like Snowflake-style infra, Cloudflare-style edge caching, and well-tuned AWS reserved capacity all sit in or below that band. Below 8% requires either deep multi-tenancy, heavy reserved-instance commitment (~30% discount on covered hours), or a workload with structurally low cloud delivery cost.
How does single-tenant architecture change the SaaS COGS benchmark?
Single-tenant SaaS dedicates compute, storage, and network to one customer instead of sharing across a pool — so it loses multi-tenant amortization and runs roughly +4 percentage points hotter at every band. Where multi-tenant elite is ≤8% of MRR, single-tenant elite is ≤12%. Healthy shifts from 8–15% to 12–19%. Single-tenant is common in regulated verticals (healthcare, defense, finance) where data isolation is the product requirement; investors still benchmark the headline ratio against the multi-tenant cohort when applying SaaS valuation multiples, so flag the architecture explicitly in the narrative.
How is infra cost per MRR different from AWS cost per customer?
Infra cost per MRR is the CFO ratio — total infra spend divided by recurring revenue, expressed as a single percentage for the board deck. AWS cost per customer is the DevOps ratio — hosting dollars divided by customer count, expressed in $/customer/month for engineering planning. The two tell complementary stories: a $20/customer hosting bill can be elite if MRR per customer is $400 (5% ratio) and broken if MRR per customer is $80 (25% ratio). For DevOps-grade per-customer infra economics, pair this with our AWS Cost per Customer Calculator.
Why does SaaS infra% drop as MRR grows? What's the scaling coefficient?
SaaS infra typically grows at roughly 0.7× the rate of MRR growth — meaning if MRR grows 30%, infra grows ~21%, so the ratio falls. The sub-linear scaling comes from multi-tenant amortization (the same database serves more customers), fixed-cost monitoring and observability spend, and reserved-instance commitments locked in below variable on-demand pricing. The What-If simulator in this calculator uses the 0.7 coefficient explicitly so you can model what your ratio looks like at +30%, +50%, or +100% MRR — the headline often drops 3–5 percentage points purely from scaling, before any optimization.
What's GM headroom and how does this calculator compute it?
GM headroom is the gross profit you'd recover by cutting infra spend down to your stage's band median. The math: (current monthly infra − MRR × stage median %) × 12. So if you're a Series B at 14% of MRR and the median is 10%, the headroom is 4 percentage points of MRR — annualized into dollars. The calculator surfaces this as a single $/yr number because it's the most actionable framing: it converts a percentage gap into an engineer-hire equivalent at $180K loaded cost. A $360K/yr headroom is two senior engineers worth of recoverable gross profit.