Making Cloud Spending a Team Sport
FinOps (a portmanteau of "Finance" and "DevOps") is a cultural practice and operational framework that brings financial accountability to cloud spending. It emerged because cloud computing created a new problem: engineers can now spend company money directly, without going through procurement.
In the old data center world, buying a server required a purchase order, management approval, and a 6-week procurement cycle. In the cloud world, a single aws ec2 run-instances command can spin up a $10,000/month instance in 30 seconds. This speed is powerful but dangerous without visibility and accountability.
The Three Phases of FinOps:
Phase 1: INFORM
→ Visibility: Who is spending what? On which projects? In which environments?
→ Tools: AWS Cost Explorer, GCP Billing Reports, Azure Cost Management
→ Key action: Tag everything. If a resource isn't tagged with team/project/environment,
you can't attribute its cost. Untagged resources are invisible waste.
Phase 2: OPTIMIZE
→ Right-sizing: Is that m5.4xlarge actually using more than 15% CPU? Downsize it.
→ Reserved/Committed: Stable workloads → commit for 1–3 years → save 30–60%.
→ Spot/Preemptible: Fault-tolerant batch jobs → use spot instances → save 60–90%.
→ Waste elimination: Dev environments running 24/7 but only used 8 hours/day.
Phase 3: OPERATE
→ Budgets and alerts: Set per-team monthly budgets with automated alerts at 80%.
→ Showback/Chargeback: Show teams their costs (showback) or actually charge their
department budget (chargeback).
→ Continuous governance: Automated policies that prevent wasteful provisioning.
The phases are sequential. You cannot optimize what you cannot see (Phase 1 before Phase 2), and you cannot sustain optimization without operational processes (Phase 2 before Phase 3).
Practical Quick Wins:
Two checks catch most low-hanging waste. First, find unattached storage volumes — disks that were provisioned for an instance that no longer exists, still billing every month with nobody using them. Second, pull average CPU utilization per instance over the last month; anything sitting well below what it's provisioned for is a right-sizing candidate. Both are cheap, mechanical audits that cloud providers' own cost and monitoring tools surface directly — no custom tooling required, just the discipline to run them regularly.
The Tagging Imperative:
Without resource tags, cost attribution is impossible. A best-practice tagging schema looks like this:
Required tags on every cloud resource:
team: "platform-engineering"
environment: "production" | "staging" | "dev"
project: "checkout-service"
cost-center: "engineering"
owner: "[email protected]"
Enforce tags with AWS Service Control Policies (SCPs) or equivalent guardrails. If a resource can be created without tags, it will be.
A common interview question is: "How would you reduce cloud costs by 30% without impacting performance?" Structure your answer in three tiers: (1) Eliminate waste — kill unused resources, stop dev environments overnight, delete unattached volumes; (2) Right-size — match instance types to actual utilization using CloudWatch metrics; (3) Commit — purchase Reserved Instances or Savings Plans for stable baseline workloads. This shows you understand that cost optimization is a layered discipline with a specific sequence, not a single action.
Key Point: The biggest FinOps insight is cultural, not technical. When engineering teams can see their own costs in real-time and are accountable for them, spending behavior changes dramatically — often reducing costs 20–30% with zero architectural changes. The most effective FinOps implementations make cost a first-class metric on engineering dashboards, right next to latency and error rate. Engineers who can see that their service costs $0.003 per request will naturally look for ways to get it to $0.001. Engineers who can't see the cost have no reason to care.