The first 30 days of a cloud cost reduction program

Quick answer

Week 1: establish a baseline and attribute spend (export billing data, map the top 20 cost lines, measure tag coverage). Week 2: execute the no risk deletions, idle resources, unattached storage, unused IPs and load balancers, and publish the number. Week 3: build the right-sizing candidate list from 14 day p95 metrics and ship the first batch. Week 4: schedule non-production, size commitments against the new baseline, and install a cost gate in CI. Expected outcome by day 30 is a 10 to 20 percent run rate reduction with commitments queued rather than purchased, plus a weekly cost number that has an owner.

Most cost programs fail in the same way: a month spent evaluating tooling, a dashboard nobody opens, and no change to the invoice. The programs that work spend the first 30 days producing a measurable reduction and a repeatable weekly rhythm, and defer every decision that can be deferred. Here is the day by day shape.

The 30 day arc

Week	Focus	Deliverable
1	Baseline and attribution	Cost by team, service, environment
2	Deletions	First saving, published
3	Right-sizing	Candidate list plus first batch shipped
4	Scheduling, commitments, gate	Run rate reduction plus a CI cost check

Days 1 to 7: know the number before you change it

Enable detailed billing export to a queryable store on day one. Then answer four questions with data, not opinion. What is the monthly run rate and its trend over six months. What are the top 20 cost lines by service and account. What percentage of spend carries an owner tag. And what is the split between production and everything else. That last number is usually the surprise: non-production is commonly 30 to 40 percent of the bill.

Tag coverage under 60 percent means attribution work comes first, because you cannot assign a saving to a team that cannot see its own spend. Use the approach in tagging strategy for cost allocation and set a coverage target rather than perfection. Finish the week with a single page showing cost by team, service, and environment, and a stated reduction target with a date.

Days 8 to 14: ship a saving people can see

Credibility comes from an invoice that moved, not from a plan. Spend week two exclusively on deletions that carry no performance risk: unattached block storage, idle public IPs, load balancers with no healthy targets, snapshots past their retention policy, and stopped instances whose volumes still bill. The catalogue is in cloud waste elimination. Expect 5 to 12 percent of total spend on a first sweep.

Protect yourself with process, not caution: tag every candidate, notify owners, wait 14 days, snapshot before deleting anything with data, then delete. Publish the result at the end of the week in absolute dollars per month. One number, one channel, every week from here on.

Days 15 to 21: build the right-sizing pipeline

Right-sizing is where the larger structural money is, and it takes longer because it needs validation. Pull 14 days of p95 CPU and memory for every compute and database resource. Flag anything under 25 percent CPU and 50 percent memory. Rank by dollars saved, not by percentage, so the work goes where the money is.

Ship the first batch this week, starting with non-production where a mistake costs nothing. One size step per resource, one week of observation, explicit rollback. The guardrails are in right-sizing without hurting performance. A realistic week three outcome is 20 to 40 resources resized and a queue of another 100 with owners assigned.

Days 22 to 30: structure, then lock it in

Three things land in week four. First, schedule non-production off outside working hours, which removes roughly 70 percent of its compute runtime and is usually the single largest line item win of the month. Second, model commitments against the new, lower baseline. Model, do not buy: you have changed the shape of the fleet twice this month and the baseline is still settling. A sensible rule is to buy in the second month covering 70 percent of the steady hourly spend, using the laddering approach in commitment laddering.

Third, and the step that decides whether any of this survives the quarter, install a cost gate. Everything you deleted this month entered through a Terraform merge that nobody priced. Putting a cost estimate on every infrastructure pull request means the next oversized instance argues its case before it exists, not after it appears on an invoice. Patterns in cost gates and pull request budgets.

What day 30 looks like

A realistic outcome is a 10 to 20 percent run rate reduction, commitments modelled and queued, a weekly published cost number with a named owner, and a CI check that prices changes. What you should not have is a finished tooling evaluation or a multi year commitment purchased in week two. On a $200,000 a month bill that is $20,000 to $40,000 a month of reduction from work that carries almost no lock in.

The traps

Three common failures: starting with a tool evaluation instead of a deletion sweep, so month one produces nothing visible. Buying commitments before right-sizing, which converts a fixable overspend into a three year obligation. And treating cost as a central team's job rather than publishing per team numbers, which removes the only durable incentive. Start with a number, show the number weekly, and give every team its own. Price new infrastructure against the resource catalog so month two starts ahead rather than back where month one began.

FAQ

What should week one of a cost program produce?

A baseline, not a change. Enable detailed billing export, then answer four questions with data: the monthly run rate and six month trend, the top 20 cost lines by service and account, the percentage of spend carrying an owner tag, and the production versus non-production split. That last number usually surprises people because non-production is commonly 30 to 40 percent of the bill.

Why should deletions come before tooling evaluation?

Because credibility comes from an invoice that moved. A month spent evaluating tools produces a dashboard nobody opens and no change to spend, which is how most cost programs lose sponsorship. Deletions of unattached storage, idle IPs, unused load balancers, and expired snapshots carry no performance risk and return 5 to 12 percent of total spend on a first sweep, in one week.

Should I buy commitments in the first 30 days?

Model them, do not buy them. You have changed the shape of the fleet twice in the month through deletions and right-sizing, so the baseline is still settling and any commitment sized now will over-cover. Buy in month two, covering about 70 percent of steady hourly spend, ideally laddered across terms so renewals do not all land on the same date.

How do I pick right-sizing candidates?

Pull 14 days of p95 CPU and memory for every compute and database resource, flag anything under 25 percent CPU and 50 percent memory, then rank by dollars saved rather than by percentage over-provisioned so the work goes where the money is. Ship non-production first where a mistake costs nothing, one size step per resource, one week of observation, explicit rollback.

What is a realistic result after 30 days?

A 10 to 20 percent run rate reduction, commitments modelled and queued rather than purchased, a weekly published cost number with a named owner, and a CI check that prices infrastructure changes. On a $200,000 a month bill that is $20,000 to $40,000 a month, achieved almost entirely through work that carries no lock in and can be reversed if something breaks.

What makes a cost program fail?

Three things: starting with a tool evaluation instead of a deletion sweep so month one produces nothing visible, buying commitments before right-sizing which converts a fixable overspend into a multi year obligation, and treating cost as a central team's job instead of publishing per team numbers, which removes the only durable incentive for the engineers who actually create the spend.

What to do next

Make month two start ahead of month one. C3X prices Terraform changes in the pull request against a live resource catalog. Start with the quickstart.