Cloud FinOps Check

A rising cloud bill that cannot be clearly assigned is usually a transparency problem. The Cloud FinOps Check creates the overview that is needed: the costs for compute, storage and network in AWS, Azure or GCP are reviewed, and it becomes visible which infrastructure creates value and which only ties up budget. The result is a factual basis for cost decisions and a list of optimisations ordered by impact.

Typical starting points

  • the bill for cloud infrastructure is rising: the review identifies which compute, storage and network costs are driving the increase
  • costs cannot be clearly assigned to teams or products: spend is broken down by the team that causes it
  • a reliable factual basis is missing ahead of a budget decision: the result is a factual basis plus a list of optimisations ordered by impact

Outcomes

The check answers the budget question: what actually drives the cloud infrastructure, which optimisation pays back within which timeframe, and whether a permanent FinOps model is worthwhile. The concrete deliverables are:

  • a list of optimisations ordered by impact
  • a concept for purchasing and cost attribution
  • a model that assigns spend to the teams that cause it

This way the next budget decisions rest on a shared factual basis.

Scope of work

The check examines the cloud bill from three angles and condenses it into a reliable factual basis.

flowchart TD
    accTitle: FinOps flow of the Cloud FinOps Check
    accDescr: From the cloud bill, waste, purchasing and cost attribution are analysed; this produces a factual basis and a prioritised list of optimisations.
    A["Cloud bill<br/>AWS, Azure or GCP"]
    A --> B["Find waste<br/>right-sizing"]
    A --> C["Check purchasing<br/>reserved, savings, spot"]
    A --> D["Assign costs<br/>tagging per team and product"]
    B --> E["Factual basis for cost decisions"]
    C --> E
    D --> E
    E --> F["List of optimisations<br/>by impact, with roadmap"]

Waste analysis (right-sizing) The provisioned capacity is matched against the actual load and ordered by savings potential:

  • unused instances and orphaned storage
  • oversized resources without matching load

Purchasing strategy Purchasing is checked against the real load profile so that discounts are not bought at the expense of flexibility:

  • Reserved Instances and Savings Plans for the base load
  • spot capacity for interruptible work

Cost attribution A tagging scheme assigns spend to the teams that cause it and makes it possible to judge whether an investment serves its purpose:

  • assignment to teams, products and customers
  • unit-economics view per product

Scope boundaries

The check is a one-off analysis with an action plan for infrastructure spend. Ongoing implementation and optimisation belong to Platform and FinOps Management; that is where the support picks up, exactly where the check ends. Architectural changes for cost reduction are not part of the check, nor is the cleanup of the SaaS and licence portfolio, which belongs in Make-or-Buy Consulting.

Key data

The effort depends on the size and nesting of the infrastructure:

  • number of accounts and cloud providers
  • volume of billing data
  • how finely cost attribution should reflect teams, products and customers

A clearly structured single environment is examined quickly, a landscape grown across several providers and many teams calls for more depth. What the check costs in a concrete case depends on exactly these factors. The price range gives the frame for your own environment.

Request pricing

Further information