FinOps in Practice: Getting Real Cloud Cost Visibility
Godfrey Maiwun · December 2025 · Cloud Cost Management · 10 min read
Cloud spending is the budget line that surprises everyone and nobody. Finance knows the invoice is growing. Engineering knows which services they are building on. Neither has a clear picture of why the cost is what it is — and that gap is where the FinOps discipline lives.
Why cloud cost is a visibility problem before it is a spending problem
Most organisations that are overspending on cloud are not overspending because they are running inefficient workloads, though that is often part of it. They are overspending because they cannot see, with sufficient granularity, what is driving cost. When the AWS bill arrives and Finance asks Engineering to explain a 40% month-over-month increase, the conversation that follows is usually a post-mortem on something that could have been caught and corrected weeks earlier — if the right visibility had existed.
FinOps — short for Financial Operations — is the discipline of bringing financial accountability to cloud spending by creating shared visibility between engineering, finance, and business teams. It is not cost-cutting. It is cost-informed decision-making: ensuring that every cloud dollar is a deliberate choice rather than an unexamined outcome.
Tagging: the foundation that most organisations get wrong
Cloud cost attribution starts with tagging — the practice of labelling cloud resources with metadata that indicates who owns them, what they support, and what cost centre they belong to. Done well, tagging enables you to answer "how much does it cost to run Product X?" or "what is our infrastructure cost per transaction?" Done poorly, it produces a billing report that has 60% untagged spend and makes every cost conversation a negotiation over assumptions.
The mistakes that undermine tagging programmes are predictable. First, inconsistent taxonomy: some teams tag with project, others use Project or product, and the cost allocation query returns incomplete results. Second, missing enforcement: tags are advisory rather than mandatory, so new resources spin up untagged until someone notices. Third, wrong granularity: tagging to the team level is better than nothing, but tagging to the service or feature level is what enables meaningful cost conversations with product managers.
A tagging strategy that is not enforced at resource creation is not a tagging strategy. It is a retrospective labelling exercise that will always be incomplete.
Enforcement means using AWS Service Control Policies or Azure Policy to require tags at resource creation. It means running a daily report of untagged resources and routing it to engineering team leads with a deadline. It means making tag compliance a metric that appears in platform team OKRs, not just in the cloud cost dashboard that finance looks at once a month.
A practical starting taxonomy for most organisations: environment (prod/staging/dev), service (the name of the application or microservice), team (the owning team), cost-centre (the budget owner), and managed-by (terraform/manual/cdk). That is five tags. Start there before attempting 20.
Unit economics: the metric that changes the conversation
Aggregate cloud cost is a number that creates anxiety but does not create decisions. Unit economics — cost per customer, cost per transaction, cost per API call, cost per active user — creates decisions. When a product manager can see that their feature costs $0.003 per active user per month, they can compare that against revenue per user and make an informed trade-off. When they can only see "the backend costs $180,000 this month," they cannot.
Cost per customer — the metric that changes the conversation.
Introducing unit economics requires two things: cost attribution granular enough to map to a product or feature (the tagging work above), and an engineering effort to instrument the business metrics that become the denominator. This is not a massive project — for most organisations, a one-time data pipeline that joins billing data with product analytics data produces the first useful unit cost metrics within a few weeks. The ongoing maintenance is modest.
The cultural shift that unit economics enables is more valuable than the metric itself. It moves cloud cost from a finance problem to a product problem — and product teams respond to that framing in ways they never respond to "please reduce your AWS bill."
Running a cost review that produces action
Most organisations that attempt regular cloud cost reviews abandon them within three months because the reviews produce observations but not decisions. "RDS costs went up 20%" is an observation. "RDS costs went up 20% because we onboarded three new customers to the legacy database tier and we need to either migrate them to the new tier or accept this cost as a COGS component" is a decision.
Observations become decisions when the right people are in the room.
A cost review that produces action has four elements. A pre-read that surfaces the week's top cost movers, prepared by the platform or FinOps team, sent 24 hours before the meeting so participants arrive ready to discuss rather than discover. An owner for each cost item — not "engineering" but the specific service team responsible. A clear decision format: accept the cost, optimise the cost, or challenge whether the workload should exist. And action owners and deadlines attached to every optimisation commitment.
The cadence matters. Weekly reviews for teams with rapidly changing cloud spend (high-growth SaaS, teams actively migrating workloads). Monthly reviews for stable environments. Never less than monthly — monthly is the minimum to catch and correct drift before it becomes material.
Common failure modes
The savings plan trap. AWS Savings Plans and Reserved Instances offer meaningful discounts in exchange for commitment. The trap is committing too early, at the wrong instance type, before workload patterns have stabilised. Savings Plans should be sized to your predictable baseline, not to your peak, and they should be purchased after 3–6 months of stable usage data rather than as an upfront gesture of cost consciousness.
Forgotten environments. Development and staging environments are the most common source of unnecessary cloud spend. Resources created for testing that are never terminated, databases running at full size when they serve a tenth of the production load, EC2 instances running around the clock when they are only needed during business hours. A scheduled sweep of non-production environments — turning off instances overnight, scaling down databases, enforcing TTLs on temporary environments — is one of the highest-ROI FinOps activities available.
The politics of chargeback. When cloud costs are charged back to business units, the reaction is often to question the methodology rather than to reduce consumption. Engineering teams challenge whether their allocation is fair. Finance questions whether the unit cost model reflects actual infrastructure economics. This political friction is real, and it is why showback (making costs visible without charging them back) is often a better starting point than chargeback. Visibility changes behaviour; chargeback creates arguments.
Where to start
If you are starting from scratch: enforce five tags at resource creation this month. Run a report of untagged spend for the past 90 days and route it to team leads. Set up a monthly cost review with the three or four people who own the biggest cost centres. This is 80% of the value of a FinOps programme, achieved in weeks rather than quarters.
If you have the basics in place: introduce one unit economics metric for your highest-cost product area. Make it visible to the product manager, not just the platform team. Watch how the conversation changes.
Filed under: Cloud Cost Management