Your CEO just saw the AWS bill. It’s $847,000 this month, up 40% from last year. The directive comes down: “Cut cloud costs by 30%.”

So you form a FinOps team. They turn off dev environments at night. They right-size a few oversized instances. They buy some reserved instances. The bill drops 15% and everyone declares victory.

Six months later, the bill is back to $847,000 because none of the underlying dynamics changed. The development teams are still spinning up oversized instances because nobody told them what things cost. The architecture still requires 3x the compute it should. And the cost-cutting measures you implemented are being quietly circumvented because they slowed down deployments.

You’re playing whack-a-mole with cloud spend, and the moles are winning. This is cost cutting. It’s not FinOps.

What FinOps Actually Is

FinOps is a cultural practice, not a tool purchase. It’s not a team that audits cloud bills quarterly. It’s a discipline of making cloud spending visible, understood, and optimizable at every level of the organization — from the individual engineer writing code to the CFO reviewing quarterly financials.

The core principle: every engineering team should know what their services cost and be empowered to make cost-informed decisions. Not “told to cut costs” — empowered to balance cost against performance, reliability, and development velocity.

This is fundamentally different from a centralized team issuing cost-cutting mandates. Mandates create compliance behavior: teams reduce costs in the most visible, easiest ways (turning off dev environments) while ignoring the architectural decisions that actually drive the bill (running a synchronous, compute-heavy workflow that could be 10x cheaper as an async batch job).

When the team that builds the service also owns its cost, optimization happens naturally and continuously because the people closest to the technology are the ones making the trade-off decisions.

The Three Phases of FinOps Maturity

Phase 1: Inform — Make Costs Visible

The first phase is visibility. Break down the bill by team, service, environment, and feature. Show engineers what their code costs to run. This sounds obvious, but most engineers have never seen a cloud bill — and when they do, they’re shocked by what they find.

Common discoveries during the Inform phase:

• The forgotten test cluster. A $200/month Kubernetes cluster that someone spun up for a proof of concept six months ago. Nobody remembers it. Nobody uses it. It’s been billing every day.
• The debug logging firehose. A logging pipeline ingesting 10TB/day because someone enabled debug-level logging in production and never turned it off. At $0.50/GB ingestion, that’s $5,000/day — $150,000/month — in logging costs alone.
• The oversized database. A db.r5.4xlarge running at 8% CPU and 12% memory utilization. It was provisioned for a projected load that never materialized. Nobody right-sized it because nobody looked at the metrics.
• The redundant environments. Three staging environments that all do the same thing, created by different teams who didn’t know the others existed.

Visibility alone typically reduces cloud spend by 10-20% — not through optimization, but through elimination of waste that was invisible.

Implementation: Tag every resource with team, service, and environment. Publish daily cost dashboards by team. Send weekly cost reports to engineering managers. Make the bill as visible as the deployment dashboard.

Phase 2: Optimize — Make Costs Efficient

With visibility, optimization becomes systematic rather than reactive. Instead of a centralized team hunting for savings, every team can identify their own optimization opportunities.

Reserved capacity for predictable workloads. Your production database runs 24/7/365. Paying on-demand pricing for a workload with 99.9% uptime predictability is leaving money on the table. Reserved instances or savings plans typically save 30-60% on compute costs for predictable workloads.

Spot instances for fault-tolerant processing. Batch processing, data pipelines, CI/CD builds, and any workload that can tolerate interruption should run on spot instances at 60-90% discount. This requires designing for interruption, but the architectural pattern is well-established.

Right-sizing based on actual utilization. Don’t right-size based on peak load — right-size based on P95 utilization with auto-scaling for peaks. Most instances are 2-4x larger than their workload requires because they were provisioned for worst-case scenarios that happen less than 1% of the time.

Storage tiering. Data that hasn’t been accessed in 90 days doesn’t need to live on hot storage. Automated lifecycle policies that transition data from S3 Standard to S3 Intelligent-Tiering to S3 Glacier can reduce storage costs by 60-80% without operational impact.

Architecture optimization. The biggest savings often come from architectural changes, not instance sizing. Moving a synchronous API to an async queue-based architecture might reduce compute costs by 80%. Replacing a polling mechanism with event-driven triggers eliminates wasted compute entirely.

Phase 3: Operate — Make Costs a Design Input

The final phase integrates cost awareness into the development lifecycle so that cost optimization is continuous rather than periodic.

Cost projections in architecture reviews. Every significant design decision should include an estimated cost at current scale and at 10x scale. “This architecture costs $2,000/month now but $200,000/month at 10x” is a critical signal that changes the design conversation.

Cost alerts in CI/CD. When a pull request introduces a new service or increases resource requirements, the CI/CD pipeline should flag the projected cost impact. Not to block the change — to inform the decision.

Cost per unit of business value. Track cost per API request, cost per user, cost per transaction. These unit economics are far more meaningful than total spend because they normalize for growth.

Quarterly cost reviews by engineering managers. Include cloud cost alongside velocity, quality, and availability metrics in regular team reviews. This normalizes cost as an engineering concern, not a finance concern.

The Unit Economics Insight

The most powerful FinOps metric isn’t total spend — it’s cost per unit of business value. This reframing changes the entire conversation from “how much are we spending?” to “how efficiently are we spending?”

“We spend $500K/month on cloud” is meaningless without context. It might be incredibly efficient or wildly wasteful — you can’t tell from the total alone.

“We spend $0.003 per API request” or “Our infrastructure cost per paying customer is $2.40/month” — now you can have a real conversation. You can compare against industry benchmarks. You can track trends. You can identify when efficiency is improving (growing revenue faster than costs) or deteriorating (costs growing faster than revenue).

If your cost per request is dropping while total spend is rising, you’re scaling efficiently. The total bill is higher because you’re serving more customers, but each customer costs less to serve. This is healthy growth.

If your cost per request is rising, something is architecturally or operationally wrong — and cutting instances won’t fix it. Rising unit costs indicate accumulating technical debt, suboptimal architecture, or resource waste that needs structural attention.

What Most Companies Get Wrong

They Centralize Optimization in a FinOps Team

A small central team can’t optimize spending they didn’t create. The engineers who write the code, choose the instance types, and design the architectures need to own the cost implications. The FinOps team’s job is to provide tools, visibility, guidance, and best practices — not to be the cost police.

When a FinOps team “optimizes” costs by shutting down resources, they frequently cause outages, break development workflows, or create friction that slows engineering velocity. The team that created the resource understands why it exists. The FinOps team often doesn’t.

They Optimize for Cost Instead of Value

Cutting your ML training cluster saves $20K/month. But if that cluster is producing models that generate $200K/month in fraud detection savings, the “optimization” destroyed $180K/month in net value. Always optimize cost relative to business value, never in isolation.

The same logic applies to development velocity. Turning off development environments at 6pm saves $500/day. But if your engineers need those environments at 9pm for a production hotfix, the saved $500 costs $50K in delayed incident resolution.

They Ignore Architecture

You can right-size instances forever, but if the architecture requires 10x more compute than it should, you’re optimizing a fundamentally expensive system. Instance right-sizing yields 10-30% savings. Architectural optimization yields 50-90% savings.

The biggest cost savings come from questioning architectural assumptions: Does this need to run synchronously? Does this data need to be in a relational database? Does this workload need to run 24/7? Can this be processed in batch instead of real-time?

They Treat FinOps as a One-Time Project

FinOps is not a project with a start and end date. It’s an ongoing operational practice — like security or reliability engineering. Cloud environments drift toward waste naturally as teams provision resources for peak loads, forget to decommission experiments, and accumulate technical debt. Without continuous governance, the optimization gains from last quarter erode by next quarter.

---

The Garnet Grid perspective: Cloud cost management is an architectural discipline, not a spreadsheet exercise. We build FinOps practices that tie spending to business outcomes and embed cost awareness into engineering culture. Explore our cloud migration assessment →