You can spot cost theatre easily enough: a dashboard everyone has access to and nobody acts on, a quarterly clean-up sprint, and a savings number calculated against list prices you were never going to pay. The bill drops for a while and then creeps back, because nothing changed about how spending decisions get made.

FinOps is the practice that addresses this, by bringing engineering, finance and the business together around the value of cloud spending. Stripped of the vocabulary, we think it comes down to one principle: the people who make spending decisions need to see the cost of those decisions, and be accountable for it. The steps below follow from that.

Tag for allocation, not for completeness

Tagging policies usually fail by asking for too much. Start with a few tags you will really use, such as:

  • owner: the team answerable for the resource.
  • service: the product or application it belongs to.
  • environment: production, staging or development.

Enforce them when resources are created, through infrastructure-as-code checks or provider policies, because retrofitting tags is thankless work that never quite finishes. Some costs can't be tagged, including certain data transfer charges and shared platforms. Agree on a simple rule for splitting those, and don't let it turn into a months-long modelling exercise.

Then track one number: the percentage of spend that can't be allocated to an owner. Until that is low, every other cost conversation lacks a foundation.

Measure unit economics

Total spend alone can't tell you whether things are going well. A bill that rises 20% while customers double is good news, whereas a flat bill during a period of shrinking usage is not.

Pick a unit that matches how the business earns money: cost per customer, per order, per thousand API calls or per active tenant. Combine billing data with a usage metric you already have, and chart it monthly. A rough figure is enough to start, because the trend is what you are after.

This also changes the conversation with engineering. "Spend less" invites arguments, while "cost per order rose after the last release, can you take a look?" is a problem engineers can work on. It also helps with pricing decisions, since you can see which customers or features are expensive to serve.

Right-size before you commit

Do the cheap, safe work first:

  • Delete what is idle. Look for unattached volumes, old snapshots, unused load balancers and forgotten test environments.
  • Schedule non-production. A development environment that runs 10 hours a day on weekdays uses 50 of the 168 hours in a week, about 70% fewer compute hours than running it continuously.
  • Right-size from evidence. Review CPU and memory over several weeks, including peak periods, and look at percentiles rather than averages. Memory often needs an agent to report it.
  • Review storage classes. Lifecycle rules can move data that nobody reads to cheaper tiers, once you have checked retrieval charges and minimum retention periods.
  • Check architecture choices. Chatty cross-zone traffic and verbose logging can cost more than the compute, and no amount of instance resizing will fix them.

Commit carefully

Reservations and savings plans offer substantial discounts in exchange for a term commitment. The discounts are real, but they lock in whatever you commit to, so right-sizing should come first.

Commit only to your stable baseline, the level of usage you are confident will persist. Cover it gradually, perhaps in small tranches, instead of one large purchase. Start with one-year terms unless you are very sure of the workload. Prefer the more flexible commitment types if the discount gap is modest. Someone must also track utilisation and expiries, because an unused commitment is money spent on nothing.

Decide who owns the bill

Finance can report on cloud spending, but it can't change an instance type. A central platform team can recommend, but rarely knows which workloads are safe to touch. That is why ownership should sit with the teams who build and run each service, while finance keeps the overall forecast and a small central function handles commitments, tooling and reporting.

  • Every service has a named cost owner.
  • Each team sees its own costs at least monthly, with the trend and the unit cost.
  • Budgets and anomaly alerts go to the team that can act, not to a shared mailbox.
  • Cost becomes a design consideration when architecture is reviewed.

What to do this week

  1. Sort last month's bill by service and find out what share has no clear owner.
  2. Name an owner for the top five line items.
  3. Find one idle resource and delete it. Then turn on an anomaly alert, which most providers offer.
  4. Choose a unit metric and calculate it by hand for the past three months.

Nothing here needs a new tool. If these steps prove useful and your estate is large, tooling can come afterwards.