Cloud spending has a management problem that didn’t exist with on-premise infrastructure. When hardware required capital expenditure and procurement approval, cost visibility was built into the process. Cloud flipped that model—any engineer can provision resources instantly, costs accumulate continuously, and the bill arrives weeks later with limited context about what generated it.
FinOps (cloud financial operations) is the practice of giving organizations the visibility, accountability, and processes to make good cloud cost decisions. Most FinOps programs start with tagging and dashboards. The ones that work add accountability—a model where the people making spending decisions have visibility into their impact.
The Visibility Problem
Before accountability can work, you need to know what things cost and who owns them.
Tagging strategy is the foundation. Every cloud resource should carry tags that answer: what team owns this, what application or service does this belong to, what environment is this (prod/staging/dev), and what cost center should be charged. Consistent tagging is harder than it sounds—it requires enforcement (tag policies in AWS Organizations, policies in GCP, tag inheritance in Azure), onboarding new teams correctly, and auditing for untagged resources.
A practical minimum tag set:
teamorowner: the team responsibleserviceorapplication: the product or serviceenvironment: prod, staging, dev, sandboxcost-center: the business unit or budget owner (if you do chargeback)
Without consistent tagging, cost allocation is guesswork. With it, you can answer “how much does the recommendation service cost to run in production?"—which is the question that drives good decisions.
Cost allocation tools: AWS Cost Explorer, GCP Cloud Billing, Azure Cost Management, and third-party tools (Kubecost for Kubernetes cost optimization, Infracost for Terraform-defined infrastructure, CloudHealth, Apptio Cloudability) all need tagged resources to produce useful breakdowns. The tools are only as good as the underlying tagging discipline.
Chargeback vs. Showback
Showback: Teams can see what they spend, but it doesn’t affect their budget or P&L. Finance absorbs the total cloud cost; engineering teams have visibility for information.
Chargeback: Teams are billed internally for their cloud spend, which comes out of their team budget.
Showback is easier to implement and creates awareness. Chargeback creates stronger incentives but requires agreement on allocation methodology (how do you charge for shared infrastructure?) and can create perverse incentives (teams gaming tagging to avoid allocation).
Most organizations start with showback and move to chargeback for larger teams or when leadership wants stronger cost ownership at the team level. Neither works without visibility into what the numbers actually mean—a team that sees “$45,000 cloud spend this month” but can’t decompose it into actionable line items can’t do anything useful with the number.
Unit Economics: The Measure That Matters
Absolute cloud spend is a vanity metric. A company spending $500k/month on cloud that processes 10 billion transactions is doing better than one spending $200k/month for 1 billion transactions. The signal that drives good engineering decisions is unit economics: cost per user, cost per transaction, cost per API call, cost per GB processed.
Define unit metrics that are meaningful for your business and track them alongside absolute spend. When unit cost goes up, something changed—and the change is usually findable. When unit cost goes down after an optimization effort, you’ve proven the optimization worked.
Unit economics also make budget conversations tractable. “We expect to spend $800k this quarter” is a number engineering needs to justify. “We spend $0.0012 per transaction and we’re forecasting 650 million transactions” is a number anyone can evaluate against the business case.
Cost Accountability Without Bottlenecks
The failure mode of cost governance is creating a review and approval process that slows down engineering. A CAB-style review for every resource provisioning request produces two outcomes: engineers work around the process or engineering velocity drops.
The alternative is guardrails, not gates:
Budget alerts, not budget limits: Set alerts at 80% and 100% of expected spend so teams get early warning. Don’t block provisioning—block unknowing overspend.
Anomaly detection: AWS Cost Anomaly Detection, GCP budget alerts, and Azure cost alerts can fire when spending deviates unexpectedly from the trend. A Lambda function that suddenly costs $2,000/day instead of $50/day is anomalous—catch it before the monthly bill arrives.
Rightsize at provisioning: Infracost integrates with CI/CD to show the cost impact of Terraform changes before they’re applied. Engineers see that the PR they’re merging adds $1,200/month of infrastructure spend. Most engineers don’t have this information and would make different decisions if they did.
Reserved instance and savings plan governance: Commitment-based discounts (Reserved Instances, Savings Plans, Committed Use Discounts) require centralized management because they span accounts—which is one reason multi-account AWS strategy matters. A FinOps function that continuously evaluates commitment coverage and purchases discounts as workloads stabilize can reduce compute costs 20–30% with zero engineering effort.
Shared Infrastructure Attribution
Shared infrastructure (EKS clusters, VPC, NAT gateways, shared RDS instances, monitoring infrastructure) is always the hardest part of cost allocation. Options:
Equal split: Divide shared costs equally across teams. Simple, somewhat arbitrary.
Proportional allocation: Allocate based on resource consumption—how much CPU/memory a team’s pods used in the cluster. Kubecost supports this natively. More accurate but requires measurement infrastructure.
Direct attribution: Separate infrastructure per team. Most accurate, most expensive, creates duplication. Only appropriate for large teams with genuinely different scaling requirements.
Most organizations use proportional allocation for Kubernetes and equal split for truly shared networking costs (VPC, NAT gateway, Direct Connect). Document the methodology and apply it consistently.
The FinOps Team
In organizations large enough to need a dedicated FinOps function, the team typically sits at the intersection of engineering and finance. It’s not a finance team reviewing engineering decisions, and it’s not an engineering team trying to manage budgets. It’s a function that:
- Owns the tagging standard and enforces it
- Maintains cost dashboards and unit economics reporting
- Runs commitment discount purchasing (reserved instances, savings plans)
- Identifies and investigates anomalies
- Partners with engineering teams on optimization opportunities
- Translates cloud spend into business context for leadership
The FinOps Foundation (finops.org) has published a maturity model (Crawl/Walk/Run) that’s useful for assessing where an organization is and what to prioritize next. Most organizations are in Crawl (visibility exists but is incomplete, no accountability structure) and need to move to Walk (consistent tagging, team-level visibility, basic commitment discounts) before optimizing further.
Starting Points
If you’re starting a FinOps practice from scratch, prioritize in this order:
- Establish tagging standards and enforce them: Without this, nothing else works
- Set up cost allocation views by team/service in your cloud provider’s cost tooling
- Create weekly cost reviews: A 30-minute meeting where a lead engineer reviews the previous week’s spend against trend with the team
- Purchase savings plans or reserved instances for stable workloads running >3 months: typically 30–40% savings, minimal risk
- Define unit economics metrics for your most important services
- Integrate cost visibility into CI/CD for infrastructure changes
The single highest-ROI action for most teams is savings plan or reserved instance coverage. It doesn’t require any engineering work, and it’s money left on the table for every month you’re running on-demand for predictable workloads.