FinOps and SRE used to be separate conversations. FinOps was about cost optimization — tagging, rightsizing, reserved instance purchasing. SRE was about availability and reliability. The two disciplines coexisted but didn't deeply intersect.
That separation is becoming untenable. Cloud cost is now a reliability concern in ways that weren't true five years ago, and the engineering practices that reduce toil, eliminate waste, and automate operations are the same practices that bend the cost curve. The teams that have figured this out are building joint FinOps+SRE functions. Here's why, and what it looks like in practice.
How Cloud Cost Became a Reliability Concern
The connection runs both directions.
Reliability choices drive cost. High availability architectures are expensive. Multi-AZ deployments, cross-region replication, redundant capacity for N+1 fault tolerance — these are reliability investments that cost money. When cost pressure mounts without SRE input, organizations cut corners that look like savings on a spreadsheet but are actually reductions in reliability. An organization that reduces its cross-AZ capacity to save on data transfer costs has made a reliability trade-off, whether they named it that or not.
Cost pressure creates reliability incidents. When cloud bills grow faster than budget, the response is often hasty: terminate "underutilized" instances that are actually capacity reserves, reduce retention of backups, cut monitoring data. These decisions create gaps in the reliability stack that surface as incidents months later. The engineers who make the cuts often don't know which resources are load-bearing for reliability, because that knowledge lives with SRE.
Runaway costs are an operational emergency. A misconfigured resource that generates $500K in unexpected charges in a week is a business incident that gets the same executive attention as a production outage. SRE response skills — rapid triage, root cause identification, remediation, postmortem — apply directly to cost incidents. Teams that treat cost as purely a finance problem lack the operational discipline to respond quickly.
AI workloads make cost unpredictable in new ways. GPU instance costs, LLM inference token costs, and training run costs can spike dramatically based on usage patterns that weren't anticipated. AI cost incidents — a training run that ran 10x longer than expected, an agent that entered a reasoning loop and consumed $20K in tokens in an hour — are a new category that blends SRE and FinOps.
The Cost Reliability Metrics
Just as SRE tracks availability and latency as reliability signals, cost reliability needs its own metric set:
Cost per unit of business value. Revenue-per-dollar-of-infrastructure is the north star. For a SaaS platform, this might be infrastructure cost per active user or per API call. Tracking this over time tells you whether efficiency is improving as the product scales.
Cost variance against forecast. A budget is a forecast. Variance from forecast — whether positive or negative — is signal. Large variance (more than 15% from monthly forecast) warrants investigation regardless of direction.
Resource utilization distribution. The percentage of your compute spend that is at low utilization (<20% CPU average) is a direct measure of waste. For most organizations, this is 20-40% of compute spend.
Untagged resource spend. Resources without proper cost allocation tags can't be attributed to teams or services, which means they can't be optimized by the people who own them. Untagged spend as a percentage of total spend is an operational health metric.
Cost anomaly detection rate. How quickly does your organization detect a cost anomaly after it starts? A cost spike that runs for a week before detection is much more expensive than one detected in hours.
The Joint FinOps+SRE Playbook
Here's how teams that have integrated these disciplines operate:
Cost tagging as a reliability requirement. Every infrastructure resource must be tagged with the owning team, the service, and the environment (production/staging/dev). This is enforced at the infrastructure level — Terraform modules that don't include required tags fail validation. Resources created without tags are detected and either automatically tagged or terminated.
Without tagging, cost attribution is a finance problem. With tagging, every team can see their own infrastructure costs, own their efficiency, and make trade-offs with full information.
Cost review in the SRE weekly. Cost metrics belong in the same conversation as reliability metrics. If you're reviewing error rates and latency in your weekly SRE sync, cost variance and utilization should be on the same dashboard.
Automated cost anomaly response. Cost spikes follow the same incident response pattern as availability incidents. AWS Cost Anomaly Detection, Google Cloud's anomaly detection, or custom monitoring against billing APIs can trigger alerts. Those alerts route to an on-call rotation that includes both SRE and a FinOps-aware engineer. The response procedure includes: identify the resource/service causing the spike, determine if it's legitimate growth or a misconfiguration, take action (remediate or escalate), and document in a postmortem.
Engineering investment in efficiency. The SRE practice of eliminating toil — investing engineering time to automate away manual work — applies directly to cost efficiency. The 6x cloud cost reduction I described in an earlier post was SRE work: building an LLM agent that identified waste, generating recommendations, and systematically eliminating it. This is as much SRE work as reducing MTTR.
The Unit Economics of Reliability
One of the most useful frames that FinOps brings to SRE: unit economics. What does it actually cost to provide X minutes of availability for Y users?
When you can answer this question, reliability investment decisions become business decisions:
"Moving from 99.9% to 99.99% availability for a checkout service requires $200K/year in additional infrastructure and $150K/year in SRE time. The revenue impact of the downtime we'd prevent at 99.99% vs. 99.9% is approximately $800K/year. The investment has a clear positive return."
Or: "The incremental cost of moving our batch analytics cluster to 99.9% availability (from its current 99.5%) would be $400K/year in infrastructure redundancy. The business impact of analytics availability below 99.9% is difficult to quantify but clearly sub-$400K. This investment doesn't make sense at current scale."
These are business conversations that SREs have better with cost data than without it. FinOps provides the cost numerator; SRE provides the reliability denominator.
AI Cost Governance
The AI budget line is growing fast in most engineering organizations and is often poorly governed. A few patterns that work:
Per-model, per-use-case budgets. Rather than a single "AI API costs" line item, break down costs by model, by use case (incident response agent, cost optimization agent, development tooling), and by team. Each use case should have a budget owner who's accountable for cost efficiency.
Cost per outcome. For an incident response agent, cost per investigation is a meaningful metric. If it costs $2 to run an investigation that reduces MTTR by 23 minutes, that's a straightforward ROI calculation. Track this metric and watch for it growing unexpectedly — it may indicate the agent is running longer reasoning chains or processing larger inputs.
Circuit breakers for runaway agent costs. AI agents that enter reasoning loops or process unexpectedly large inputs can generate costs that spike rapidly. Set per-invocation token limits and per-day cost limits with automatic circuit breaking. A ceiling that terminates an agent invocation that exceeds 50K tokens or $5 in a single run will catch the most egregious runaway cases.
Prompt caching at scale. If you're running high-volume AI workloads with repetitive system prompts (same system prompt across thousands of invocations), prompt caching can reduce costs by 60-80%. This is a meaningful engineering optimization that requires deliberate design — the cache is only effective if the prefix of your requests is deterministic.
The Organizational Model
The FinOps+SRE integration I've seen work best: a small "Cloud Efficiency" function within the broader SRE organization, staffed by engineers with both cost analytics skills (comfortable in Cost Explorer, BigQuery billing export, or equivalent) and infrastructure engineering skills (can read Terraform, understand the reliability implications of a configuration change). They sit at the intersection of reliability engineering and financial accountability.
This function owns: cost anomaly detection and response, efficiency reporting for leadership, engineering projects that improve cost efficiency (the cost optimization agent work falls here), and the tagging and attribution infrastructure that makes everything else possible.
What it doesn't own: cost approval authority (that lives with product teams), architectural decisions (that lives with platform and product engineering). It's an enabling function, not a gatekeeper — which is the same model that works for SRE more broadly.
*Zak Hassan is a Staff SRE specializing in cloud cost optimization, AI-powered infrastructure automation, and data platform reliability. Find him at zakhassan.com or on LinkedIn.*
Topic Paths