The Ultimate FinOps Goal
When a company is growing 50% year-over-year, its absolute cloud bill will almost certainly grow too. Telling engineering teams to "reduce the cloud bill" while the business is scaling is often the wrong objective — it can lead to under-provisioning, performance degradation, and false economies.
The correct objective is reducing COGS (Cost of Goods Sold) — specifically, the cloud cost component of COGS. COGS is an accounting term for the direct costs required to deliver your product or service to a customer. For a SaaS company, cloud infrastructure is a primary COGS component.
The key metric is not total cloud spend. It is unit economics: cost per user, cost per transaction, cost per GB processed, or cost per API call. If your cloud bill grows from $1M to $1.5M but your user base grows from 100k to 200k, your cost per user dropped from $10 to $7.50 — that is a COGS improvement even though the absolute bill increased.
The COGS Reduction Lifecycle
A structured COGS reduction program follows this sequence:
1. Baseline
Establish your current unit cost. This requires tagging infrastructure by product and correlating cloud costs with business metrics.
- Example: $0.05 per API call, $2.10 per active user per month, $0.003 per GB of video processed.
2. Target
Set an engineering OKR tied to unit cost reduction, not absolute cost reduction.
- Example: "Reduce cost per active user from $2.10 to $1.68 (20% reduction) by Q4."
3. Identify Levers
Common COGS reduction levers, roughly ordered by impact:
| Lever | Typical Impact | Effort |
|---|---|---|
| Right-sizing over-provisioned instances | 15–30% | Low |
| Switching to Graviton/ARM instances | 20–40% | Medium |
| Adding application-layer caching (Redis, CDN) | 30–60% | Medium |
| Moving cold data to cheaper storage tiers | 10–20% | Low |
| Rewriting hot code paths for efficiency | 20–50% | High |
| Adopting Reserved Instances / Savings Plans | 30–60% | Low (commitment risk) |
4. Refactor and Measure
Engineers implement changes. The FinOps team tracks unit cost weekly, not just total spend. This is critical — a refactor that reduces compute cost but increases data transfer cost may be net-negative.
5. Verify
Revenue grows, total bill may grow, but margin improves because COGS per unit decreased. This is the definition of a successful COGS reduction program.
The COGS Trap
A common failure mode: an engineering team reduces the cloud bill by 15% by aggressively right-sizing instances and disabling auto-scaling headroom. Response times increase from 120ms to 800ms. Conversion rate drops 12%. The company loses more in revenue than it saved in infrastructure.
COGS reduction must always be evaluated against its impact on the customer experience metrics that drive revenue. The correct constraint is: "Reduce cost per transaction while maintaining p99 latency below 200ms." Not just "reduce cost."
Interviewers at growth-stage companies often ask: "Our cloud bill is growing 30% per quarter. How do you address that?" The trap answer is "cut costs." The correct answer is: "First, I'd determine whether the growth is proportional to business growth. If revenue is also growing 30%, the bill growth may be fine. I'd establish unit cost metrics (cost per user, cost per transaction), set reduction targets as engineering OKRs, and track margin improvement — not just absolute spend."
Key Point: COGS reduction aligns cloud cost optimization with business profitability. The target metric is unit cost (cost per transaction, cost per user), not absolute spend. A rising cloud bill at a growing company is not inherently a problem — a rising unit cost always is.