A cloud cost optimization checklist that survives audit

A cost sprint usually works. Someone deletes the orphaned volumes, resizes the over-provisioned instances, buys some committed capacity, and the next invoice drops noticeably. Three months later the number is back where it started, and nobody can explain precisely how.

The reason is that the sprint changed the bill without changing the behaviour that produced it. Environments are still created by hand and never destroyed. Nobody can see which team's spend grew, because nothing is attributed. There is no threshold that alerts anyone, so growth is only visible in an annual review. The saving was a one-off event applied to a system that generates cost continuously.

Optimisation that survives an audit — or simply survives the next two quarters — is structural. It changes what the architecture spends by default, makes every rupee or dollar attributable to an owner, and puts a recurring review in the calendar with a name attached. That is a working practice, not a project. It is also most of what our cloud cost optimization engagements actually consist of.

One-time savings

Worth doing, and usually the fastest way to fund the rest of the work — but each one is a single event that entropy will reverse.

• Rightsizing over-provisioned compute and databases.
• Deleting orphaned resources: unattached volumes, idle load balancers, unused static addresses, stale snapshots, forgotten test environments.
• Committed-use discounts and reserved capacity — real savings, but they lock in a baseline, so buy against demonstrated steady-state usage rather than forecasts.
• Removing duplicate tooling and licences bought by different teams.

Structural savings

These change the shape of the cost curve, so growth in usage no longer means proportional growth in waste.

• Autoscaling that genuinely scales down, and non-production environments that shut themselves off outside working hours.
• Storage lifecycle policies that tier and expire data automatically, so retention costs are bounded by design.
• Architectural changes that remove chronically expensive patterns — chatty cross-region traffic, over-large always-on clusters, per-tenant infrastructure that could be shared safely.
• Environments created and destroyed as code, so nothing persists because a person forgot it existed.
• Cost visibility inside the delivery workflow, so engineers see the price of a design while they are choosing it.

A reasonable rule: spend the first month on one-time savings to build credibility and headroom, then spend the following quarter making sure that saving cannot silently reverse.

You cannot ask a team to reduce a number they cannot see. Until spend is attributable to a service, team or product, every cost conversation is a central function guessing on behalf of people who have the actual context.

• Agree a small tagging standard. Four or five mandatory tags — owner, environment, application, cost centre — beat twenty aspirational ones. Enforce them by policy at resource creation, so untagged resources simply cannot be created.
• Use account and subscription boundaries. Structural separation attributes cost even when tags are missed, and it is far more reliable for shared platform services.
• Deal with shared costs explicitly. Decide up front how networking, observability, security tooling and platform teams are allocated. An unallocated pool that grows every month is where accountability goes to hide.
• Start with showback. Publish each team's spend and its trend before charging anyone. Visibility alone changes behaviour, and it surfaces the data errors you would otherwise be billing on.
• Report in units the business recognises. Cost per order, per active user, per tenant or per transaction tells you whether efficiency is improving. Total spend rising while unit cost falls is usually success, and the raw invoice cannot show that.

Aim for a high but not perfect attribution rate, and track the unattributed percentage as a metric in its own right.

Compute

• Rightsize against observed utilisation over a full business cycle, not peak day.
• Schedule non-production environments off outside working hours.
• Confirm autoscaling policies actually scale in, and test that they do.
• Move suitable spiky or batch workloads to interruptible or serverless capacity models.
• Consolidate under-utilised clusters and check container requests against real usage — over-requested pods reserve capacity nobody uses.
• Buy committed capacity only against a demonstrated stable baseline, and diarise renewals.
• Check processor and instance generation — newer families are often cheaper per unit of work.

Storage

• Apply lifecycle rules to tier and expire objects automatically.
• Delete unattached volumes and expired snapshots on a schedule, not on a whim.
• Match backup retention to the actual policy rather than the default.
• Review log retention specifically — verbose logging with long retention is one of the most common quiet cost centres.
• Check replication and redundancy settings against real recovery requirements.

Data transfer

• Find and eliminate unnecessary cross-region and cross-zone chatter.
• Use private endpoints where they avoid routing internal traffic through egress paths.
• Put caching or a CDN in front of repeatedly served content.
• Review third-party integrations that pull large volumes on a schedule; incremental transfer is usually available and rarely configured.

Licensing

• Check whether existing licences can be brought to the cloud platform.
• Reconcile per-seat subscriptions against active users each quarter.
• Compare licence-inclusive instance pricing with bring-your-own for database and operating system workloads.
• Consolidate overlapping monitoring, security and productivity tooling bought independently by different teams. Our licensing reviews frequently find the same capability paid for two or three times.

Everything above erodes without a control loop. The loop does not need to be elaborate — it needs to be scheduled, owned and visible.

1. Budgets and alerts per team. Set a threshold on each attributed budget and route the alert to the team that owns the spend, not only to finance. An alert nobody can act on is noise.
2. Anomaly detection. Percentage-change detection catches the runaway job, the accidental large instance and the misconfigured log level within a day instead of at month end.
3. A monthly review with an agenda. Spend versus budget, unit cost trend, unattributed percentage, top movers with explanations, and the status of open optimisation actions. Thirty minutes, same attendees, minuted.
4. Quarterly deeper passes. Commitment coverage and expiry, architectural cost reviews for the most expensive services, and re-validation of retention policies.
5. Guardrails at creation time. Policy that blocks untagged resources, restricts the largest instance families to approved requests, and forces default lifecycle rules on new storage.
6. A written record of decisions. When a deliberately expensive choice is made — a redundant region for resilience, say — record the reason. That record is what turns a future audit question into a one-sentence answer.

FinOps is simply the name for running the loop above as an ongoing collaboration between engineering, finance and the business, rather than as a periodic emergency. Its central idea is that the people who create cost are the people best placed to reduce it, provided they can see it and are given the mandate to act.

In practice that means three things:

• Engineering owns efficiency as a normal design consideration, alongside performance and reliability, with cost visible during the change rather than after the invoice.
• Finance provides forecasting and context, translating variable consumption into something the business can plan against.
• Leadership sets the trade-off explicitly. Sometimes the correct decision is to spend more for speed or resilience. Stated openly, that is good governance; left implicit, it becomes an argument every quarter.

A sensible maturity path is unremarkable: get attribution working, publish showback, run the monthly review for two quarters, then start setting unit-cost targets. Teams that treat this as steady-state operational discipline — the same way they treat patching or backup verification, often alongside their managed services arrangements — are the ones whose savings are still there a year later.