The Two-Week Cloud Cost Audit: A FinOps Playbook for Growing Teams

The cloud bill is one of the few line items that grows while nobody is looking at it. Engineering ships features, infrastructure accretes, and the invoice climbs a few percent each month until someone in finance circles it in red. By then the number is big enough to be scary and diffuse enough that no single team feels responsible for it.

Most teams react in one of two unhelpful ways. They either freeze spend with a blunt mandate that slows engineering down, or they kick off a months-long "cloud optimisation initiative" that quietly dies after the first sprint. Neither works, because cloud cost is not a project — it is a feedback loop that has gone missing.

The good news: in nearly every account we have looked at, 20 to 30 percent of the bill is recoverable without touching reliability. You do not need a re-architecture or a vendor migration to get it back. You need two weeks and a structured pass.

Week one: find the money

The first week is pure measurement. No changes, no commitments — just visibility.

Tag and group the spend. Before anything else, the bill has to be readable. Group cost by team, service, and environment. The single most common finding is that nobody can answer "what does feature X cost to run?" because the data was never structured to answer it. Cost allocation tags, or their cloud-specific equivalent, are the foundation everything else stands on.

Find the idle and the orphaned. This is where the fast wins live:

• Compute provisioned for peak that runs at 15% utilisation around the clock
• Non-production environments billing 24/7 that nobody uses outside working hours
• Orphaned disks, unattached IPs, old snapshots, and load balancers pointing at nothing
• Over-sized managed databases bought for a traffic profile that never materialised

Map the shape of demand. Pull a month of utilisation and look at the curve. Spiky, predictable, or flat? The shape dictates the lever. Flat and over-provisioned means rightsizing. Predictable peaks mean autoscaling. Genuinely variable means committed-use discounts are risky and on-demand is the honest choice.

By the end of week one you should have a ranked list: each line item, the recoverable amount, and the effort and risk to recover it. This list is the entire point of the audit. Everything after it is execution.

Week two: take it back, safely

The second week is about banking the low-risk savings and scheduling the rest — in that order, because credibility comes from shipping the easy wins first.

Delete the orphans. Unattached storage and idle load balancers carry zero reliability risk. Remove them on day one. This is free money and it builds trust for the changes that follow.

Schedule non-production. Turning development and staging environments off outside working hours typically cuts their cost by 60 to 70 percent. A simple scheduler does it. Nobody loses anything they were using.

Rightsize with headroom. Bring over-provisioned compute and databases down to a size that fits real demand plus a deliberate safety margin. The margin is the whole discipline here — rightsizing is only dangerous when it is done aggressively and blindly. Done with headroom and good monitoring, it is routine.

Commit only what is stable. Committed-use and reserved-capacity discounts are real money — often 30 to 50 percent — but they are a bet on a baseline. Only commit to the floor of demand you are confident will still exist in a year. Layer on-demand on top for everything above that floor.

The deliberately slow part is anything that trades cost against reliability: aggressive autoscaling, spot or pre-emptible instances for stateful work, storage-tier changes. These belong on the roadmap with an owner and a test plan, not in a two-week sprint.

The part everyone skips: keeping it

An audit that is not wired into a loop decays. Six months later the bill is back where it started, because the same dynamic that inflated it the first time never went away. FinOps is the practice of closing that loop, and it is mostly organisational, not technical:

• Cost is visible to the people who create it. Engineers should see what their services cost, in the same dashboards where they see latency and errors.
• A budget has an owner. Not finance policing engineering — an engineering owner who treats the number as theirs.
• Cost shows up before it ships. A rough cost estimate in the design review is worth more than a hundred optimisation tickets after the fact.

None of that requires a dedicated FinOps team for a company under a few hundred engineers. It requires the loop to exist at all.

Takeaway

You do not have a cloud cost problem — you have a cloud visibility problem, and the cost is the symptom. A focused two-week audit turns an opaque, frightening number into a ranked list of recoverable money, and most of that money carries no reliability risk at all. The hard part is not finding it. The hard part is building the loop that keeps it from coming back.

If your bill is climbing and nobody can tell you why, that is exactly the audit we run — and a good place to start a conversation.