Savings playbook
A prioritised, step-by-step programme for reducing your cloud bill, with a 30/60/90-day plan.
Savings playbook: how to reduce your cloud bill
A practical order of work for cutting cloud costs: remove waste first, then right-size, then commit, then improve the architecture. Each step names the CostGlass page that supports it.
- Work in this order: 1. remove waste, 2. schedule non-production, 3. right-size, 4. commit, 5. improve the design. Each step makes the next one safer.
- Commit after you right-size. Otherwise you lock in a bill that was about to fall.
- Do not add up the savings cards. CostGlass counts overlaps once, and so should you.
- Prove each saving on your real bill. A saving you cannot see in Cost Explorer next month has not happened.
- Give every step a named owner and a date.
Four principles
- Safest first
- Start with changes that are easy to reverse and happen away from production: deleting things nobody uses, switching off test servers at night.
- Measure before you change
- Use real utilisation and real billed cost. CostGlass tags every figure with how it was reached (Measured, List price, Cloud estimate or Estimate), so you know which ones to confirm.
- Commit last
- A commitment is a promise you cannot cancel. Make the bill as small and as steady as possible before you promise to pay it.
- Verify on the bill
- CostGlass records what you mark as done, but only your invoice proves the saving.
Before you start
- All your clouds connected and showing data. See Connect your clouds.
- Resource tags that say who owns what. See Tagging strategy; without them you will not know whom to ask before deleting something.
- A baseline: note your last full month’s total in Cost Explorer. You will compare with it.
- A sponsor who can approve small risks and a short list of engineers with time to act.
The programme, step by step
Step 1: Remove waste (quick wins)
Waste is anything you pay for and do not use. It is the cheapest saving because nothing needs to be redesigned.
| What to look for | Where in CostGlass | Safety check |
|---|---|---|
| Unattached disks and volumes, unassigned IP addresses, powered-off servers that still bill, old snapshots | Savings (filter by Low Effort) | Ask the owner. Take a snapshot or backup first if unsure. Snapshot figures are an upper bound. |
| Idle load balancers and idle servers or databases | Savings, Rightsizing (Idle) | Idle means measured low use over 12.5 days or more. Check for monthly or seasonal jobs. |
| A service whose cost jumped and stayed up | Savings (sustained cost increase), Anomalies | It may be a planned launch. Ask what changed. |
| Resources nobody owns | Tag compliance | Find the owner before acting. |
Step 2: Schedule non-production
Development, test and staging servers rarely need to run at night or at weekends. Use the Instance Scheduler to stop them outside working hours (a Growth plan or above, and a one-off permission). Start with a few servers, watch for problems for a week, then roll it out. Do not schedule databases or stateful servers without care.
Step 3: Right-size
Move over-sized servers and databases down one size at a time, using measured CPU and memory. See Rightsizing. It needs about a week of metrics (12.5 days for idle checks), and memory data needs the CloudWatch agent on AWS. Test on non-production, change in a maintenance window, and keep the old size as your rollback.
Step 4: Commit
Once the bill has settled, cover your steady baseline with Savings Plans, Reservations or committed use discounts. Use Commitments to see coverage, utilisation, recommendations and expiry. Aim for the 70% to 85% band, prefer a one-year term at first, and never commit to your peak.
Step 5: Improve the architecture and AI choices
These take the longest and carry the most design risk, so they come last. Examples CostGlass can point to: previous-generation instance types and Graviton or ARM moves (the extra opportunities under Rightsizing), Kubernetes workloads that request far more than they use (Kubernetes costs), and for AI platforms, moving non-urgent work to the Batch API, using prompt caching and choosing a cheaper model tier where quality allows (SaaS and AI spend). The AI savings are labelled estimates, based on stated assumptions. Test quality before switching a model.
A 30/60/90-day plan
| Period | Goal | Actions | Done when |
|---|---|---|---|
| Days 1 to 30 | Visibility and quick wins | Connect everything. Run a full scan. Fix tags. Clear the low-effort waste. Pilot the Instance Scheduler on a few non-production servers. Set a budget and cost alerts. | Waste items are marked done or dismissed with a reason. A baseline is recorded. |
| Days 31 to 60 | Right-size and schedule widely | Roll scheduling out. Work through High-confidence downsize rows, starting in non-production. Install the CloudWatch agent where memory is unknown. Review the Kubernetes and AI items. | Rightsizing savings appear on the bill. No performance incidents from resizing. |
| Days 61 to 90 | Commit and institutionalise | With a settled bill, buy commitments to a safe coverage level. Set renewal reminders. Add a monthly savings review. | Coverage is in the target band with healthy utilisation. A repeatable monthly review exists. |
How to measure progress
- Realized Savings
- On the Savings page, the monthly saving of items you marked Mark done. It records your claim; it does not verify it.
- The bill itself
- In Cost Explorer, compare the month after a change with the month before, for the same service and account. Consider usage growth, so look at cost per unit if you can (Unit economics).
- Commitment health
- Coverage inside 70% to 85% and AWS utilisation at or above 95%.
- Waste trend
- The number and value of Open recommendations falling over time, and not returning after rescans.
Suppose you marked a recommendation done that promised 200 a month. Next month Cost Explorer shows that service fell by only 120, but your traffic also grew. Record the saving you can defend (120), investigate the rest, and carry on. (The figures are only an illustration.)
Avoid counting the same saving twice
A Savings Plan, a rightsizing change and a schedule can all reduce the same servers. If you add the cards, the total can exceed what you spend. CostGlass handles this for you: Potential Savings applies recommendations one after another to each cloud’s bill, so overlapping savings are counted once and the total can never go above the bill. The individual cards will therefore sum to more than the headline. Quote the headline, and keep the order of work in this playbook so each step’s saving is real before you rely on the next. See Savings recommendations for the detail.
Who should own what
| Role | Responsibilities |
|---|---|
| Executive sponsor | Sets the target, unblocks risk decisions, reviews progress monthly. |
| FinOps lead or finance partner | Owns the baseline, the monthly review, commitment decisions (with engineering input) and the budget. |
| Engineering owners (per team or service) | Review and carry out waste, scheduling and rightsizing changes for their own resources. They know what is safe. |
| Platform or DevOps team | Install the CloudWatch agent, deploy the scheduler permission, run Kubernetes and architecture changes. |
| Cloud administrators | Make purchases in the cloud console and keep stacks and permissions up to date. |
Use Team access and Organisation hierarchy so each team sees only its own recommendations.