FinOps Baseline Assessment: Know What You're Spending Before You Optimise

The cloud bill has been growing for six quarters. Nobody can explain why with precision. Finance sees a number that increases month over month. Engineering points to new features, more environments, higher traffic. Both are partially right, but neither can say exactly which services cost what, which teams are responsible for which portion of the spend, or how much of the total is waste versus genuine growth. The bill arrives, it gets paid, and the conversation repeats next month with a slightly larger number.

This is the most common state of cloud cost management we encounter. The problem isn't that organisations are spending too much — some are, some aren't. The problem is that nobody knows. Cost decisions are made without cost data. Resources are provisioned without visibility into what's already running. Optimisation conversations start with tool selection — "should we use this reserved instance calculator?" or "should we turn on this cost management platform?" — before anyone has mapped the current spend in enough detail to know what actually needs optimising.

The FinOps baseline assessment™ is the practice of mapping every cloud dollar to a service, team, environment, and purpose before making a single change. Across 900+ projects delivered, we've seen the same pattern: organisations that start with visibility reduce spend meaningfully. Organisations that start with tools reduce complexity — by adding more of it. The baseline comes first because you cannot optimise what you cannot see.

Why Cloud Costs Grow Without Anyone Noticing

Cloud infrastructure pricing is designed for flexibility, not transparency. A virtual machine costs one rate per hour. Attach storage, add a load balancer, enable logging, replicate across availability zones, and the cost of that single service has multiplied — but the individual line items are small enough that none of them trigger a review. This is how cloud bills grow: not through large, visible decisions, but through hundreds of small, invisible ones.

Three structural factors accelerate this growth.

Environment sprawl. Most organisations maintain development, staging, and production environments. Many also have QA environments, demo environments, performance-testing environments, and environments that were spun up for a specific initiative six months ago and never decommissioned. Each environment replicates some or all of the production infrastructure at some fraction of its scale. The fraction is rarely optimised — a staging database running on the same instance class as production, burning the same hourly rate for a workload that peaks at 2% utilisation, is one of the most common findings in a baseline assessment.

Untagged resources. Cloud providers offer tagging as the primary mechanism for cost attribution. If a resource isn't tagged, it can't be attributed to a team, product, or environment. According to the FinOps Foundation's State of FinOps report, accurate cost allocation remains one of the top challenges for organisations practising FinOps. In our experience, organisations with no tagging strategy typically cannot attribute between 30% and 50% of their cloud spend to a specific owner.

Provisioning defaults. When engineers provision infrastructure, they choose instance sizes, storage types, and network configurations based on what worked last time, what the tutorial recommended, or what avoids the risk of under-provisioning. The result is systematic over-provisioning — instances running at 10-15% average CPU utilisation, storage volumes provisioned at three times actual usage, databases sized for peak loads that occur for twenty minutes a day. Each individual resource looks reasonable. In aggregate, the over-provisioning represents a significant portion of total spend.

None of these factors are failures of engineering discipline. They're consequences of building in an environment where adding resources has no friction and no immediate cost signal. The baseline assessment introduces the cost signal that the cloud billing model omits.

What a FinOps Baseline Assessment Covers

A FinOps baseline assessment is a structured audit of cloud spend that produces a complete, attributed map of where every dollar goes. It is not a tool implementation, a dashboard deployment, or a purchasing exercise. It is a diagnostic that precedes all of those. The assessment typically covers four dimensions.

Spend Attribution by Service, Team, and Environment

The first dimension answers the question: who is spending what, and where? This requires mapping every cloud resource to an owner (team or individual), an environment (production, staging, development, other), and a purpose (core application, supporting service, infrastructure tooling, unused).

For organisations with mature tagging, this is a data-extraction exercise. For organisations without consistent tagging — which is most of them — it requires a combination of billing data analysis, infrastructure inspection, and conversations with engineering teams. The output is a cost map that shows, for the first time, the actual distribution of spend across the organisation.

Waste Identification

The second dimension answers: what are we paying for that we're not using? Waste falls into predictable categories.

Idle resources. Virtual machines running with no traffic. Databases with no active connections. Load balancers with no backends. Storage volumes attached to instances that were terminated months ago. These are resources that serve no current purpose and can be decommissioned immediately.

Oversized resources. Instances provisioned at four times the capacity the workload requires. Databases on instance classes designed for thousands of connections serving applications with dozens. Storage on high-performance tiers for data accessed once a month. These require right-sizing — matching the resource specification to the actual workload.

Orphaned resources. Snapshots accumulating daily with no retention policy. IP addresses allocated but unattached. Elastic IPs held in reserve for infrastructure that no longer exists. These are artefacts of provisioning workflows that create resources without corresponding decommissioning workflows.

The waste identification step produces a prioritised list of immediate savings opportunities — resources that can be decommissioned or right-sized with no impact on application performance or reliability.

Cost Trajectory Analysis

The third dimension answers: where is the spend heading? A point-in-time snapshot is useful, but the trend matters more for planning. The baseline examines spend growth over the preceding six to twelve months, identifies the drivers of that growth (new services, environment expansion, data growth, traffic increase), and projects the trajectory if no changes are made.

This projection is what turns a cost conversation into a business conversation. "Our cloud bill is $40,000 per month" is a fact. "Our cloud bill will be $65,000 per month in twelve months if nothing changes, and $42,000 if we address the identified waste" is a decision framework.

Optimisation Roadmap

The fourth dimension answers: what should we do first? Not everything that can be optimised should be optimised immediately. The baseline produces a prioritised roadmap that sequences optimisation actions by impact and effort.

Quick wins — decommissioning idle resources, deleting orphaned snapshots, removing unused storage — typically require hours of work and deliver immediate savings. Right-sizing exercises require workload analysis and testing but deliver sustained monthly reductions. Architectural changes — moving to reserved instances, adopting spot instances for fault-tolerant workloads, redesigning data storage tiers — require engineering planning and deliver the largest long-term savings but take weeks to implement safely.

How to Run a FinOps Baseline Assessment

The assessment follows a structured sequence that can be completed in two to four weeks depending on the complexity of the cloud environment. Here is the process that works when built into a broader delivery framework.

Step 1: Collect billing and usage data. Export detailed billing data from the cloud provider for the preceding six to twelve months. Collect utilisation metrics for all compute, database, and storage resources. Pull tagging data for every resource. This is data collection, not analysis — the goal is completeness.

Step 2: Build the cost attribution map. Map every resource to an owner, environment, and purpose. Where tagging exists, use it. Where it doesn't, use naming conventions, VPC associations, and team interviews to attribute resources. Flag unattributable spend — the percentage of spend that cannot be attributed to any owner is itself a finding.

Step 3: Identify waste. Analyse utilisation data to find idle and oversized resources. Catalogue orphaned resources. Quantify each item in monthly cost. The output is a table: resource, current cost, recommended action (decommission, right-size, re-tier), projected savings, and implementation effort.

Step 4: Analyse the cost trajectory. Model the spend trend over the preceding period. Decompose growth into its drivers. Project the forward trajectory with and without the identified optimisations. This becomes the business case for the optimisation roadmap.

Step 5: Produce the prioritised roadmap. Sequence the optimisation actions by a combination of savings impact, implementation effort, and risk. Quick wins first. Architectural changes last. Each item has a clear owner, timeline, and expected outcome.

Our ISO 9001 and ISO 27001-certified processes ensure that every step is documented, every finding is traceable to source data, and the roadmap is actionable — not aspirational.

The Cloud Bill That Grew for Eighteen Months

A company's cloud bill had been increasing steadily for a year and a half. Each month's increase was small enough to seem normal — growth, new features, more traffic. Finance flagged the trend but had no way to determine what was driving it. Engineering had no cost visibility beyond the aggregate monthly total.

The FinOps baseline assessment revealed what the aggregate number concealed. Across three environments — production, staging, and a QA environment that had quietly expanded to near-production scale — the assessment identified idle resources accounting for a meaningful share of total spend. Several compute instances in the QA environment had been running continuously for over a year with no active workloads. A staging database was provisioned on the same instance class as production, serving a workload that peaked at single-digit percentage utilisation. Snapshots had been accumulating daily across all environments with no retention policy — hundreds of snapshots, each small, collectively substantial.

Beyond the idle resources, the assessment found systematic over-provisioning. Production instances were sized for peak traffic that occurred for a brief window each day. For the remaining hours, utilisation sat well below capacity. The load balancers were configured for throughput the application had never approached.

The untagged spend was equally revealing. Nearly a third of the total monthly bill could not be attributed to any team or product. Resources had been provisioned by individuals who had since left the company, for projects that had concluded, using naming conventions that followed no standard.

The first optimisation pass — decommissioning idle resources, right-sizing the most over-provisioned instances, implementing a snapshot retention policy, and shutting down the unused portions of the QA environment — reduced monthly spend by roughly a third. No architectural changes. No reserved instance commitments. No new tooling. Just removing what should not have been running and right-sizing what should.

When a FinOps Baseline Is Critical — and When It Can Wait

Invest now if your cloud spend exceeds $10,000 per month and you cannot explain where it goes at the service, team, and environment level. If your bill has been growing and nobody can attribute the growth to specific business decisions, the baseline will reveal why. Any organisation preparing for a cloud cost optimisation initiative — reserved instances, savings plans, architectural changes — needs the baseline first, because optimising without visibility means optimising the wrong things.

It can wait if you're running a single application on a handful of resources with a bill under a few thousand dollars a month. At that scale, the cost of the assessment exceeds the likely savings. But the moment your cloud footprint spans multiple teams, multiple environments, or multiple services — particularly as you scale from concept to production — the baseline becomes the prerequisite for every cost decision that follows.

The transition point is clear: when the cloud bill becomes a line item that someone questions in a meeting and nobody in the room can answer with specifics, you need a baseline. Not a dashboard. Not a tool. A map.

What to Do Next

Pull your cloud bill for the last six months. Identify the top five line items by cost. For each one, ask: which team owns this, which environment is it in, and what is its average utilisation? If you can answer all three for all five, you're ahead of most organisations. If you can't, that gap is where the savings live.

When you're ready to map your cloud spend with the precision that makes optimisation possible, talk to our DevOps team. We build the baseline so every cost decision that follows is grounded in data, not assumption.

Frequently Asked Questions