Cloud bills tend to creep up. A test environment gets left running, a snapshot is never deleted, an instance is bigger than anyone remembers choosing. How much you can save depends on your setup, but the approach is the same almost everywhere: find the waste, fix the basics, then optimise what remains.

The steps below are in the order that usually gives the best return for the least risk. The examples use AWS terms, and Google Cloud has close equivalents.

1. Get visibility first

You cannot reduce what you cannot see. Before changing anything:

  • Tag every resource with at least an owner, an environment (production, staging, development) and a project or product.
  • Turn on cost reporting such as AWS Cost Explorer or Google Cloud Billing reports, and group spend by tag.
  • Set budgets and alerts so a surprise shows up in days, not at the end of the month.

2. Remove idle and oversized resources

This is usually the quickest win, because you are paying for things nobody uses.

  • Delete unattached storage volumes, unused load balancers and old snapshots and images.
  • Schedule development and test environments to shut down outside working hours.
  • Right-size instances using real utilisation data. Tools such as AWS Compute Optimizer or Google Cloud's recommender suggest smaller sizes for consistently under-used machines.
Change one thing at a time and watch performance after each change, so you can roll back quickly if something regresses.

3. Pay less for steady workloads

Once the waste is gone, look at how you buy capacity.

  • Savings Plans, Reserved Instances or committed use discounts trade a commitment for a lower price. Commit only to the baseline you are confident you will keep running, and review coverage regularly. Over-committing replaces one kind of waste with another.
  • Spot or preemptible instances cost much less and can be interrupted, so they suit fault-tolerant work such as batch jobs and build runners.
  • Arm-based instances such as AWS Graviton often offer better price-performance for many workloads. Results vary by application, so benchmark yours before you migrate.

4. Control storage and data transfer

  • Use lifecycle rules to move older objects to cheaper storage classes and to expire what you no longer need, including incomplete uploads.
  • Set retention limits for snapshots and logs.
  • Review data transfer. Traffic through NAT gateways, between availability zones and out to the internet can be a surprisingly large line item. Gateway VPC endpoints for services like S3 and a CDN for cacheable content can reduce it.

5. Make it a habit

One clean-up helps, but costs creep back unless someone owns them. Hold a short monthly review with the owners of each tagged area, set guardrails such as budgets and quotas, and track cost against something meaningful, like cost per customer or per thousand requests. That shows whether you are spending efficiently, not just spending less.

The 12-point checklist

  1. Every resource has owner, environment and project tags.
  2. Budgets and alerts exist for each team or product.
  3. No idle load balancers or unused public IP addresses.
  4. No unattached storage volumes.
  5. Old snapshots and machine images are cleaned up on a schedule.
  6. Stopped instances do not still carry expensive attached storage.
  7. Development and test environments shut down when not in use.
  8. Instance sizes have been checked against real utilisation.
  9. Discount coverage matches your steady baseline, not your peak.
  10. Fault-tolerant workloads use spot or preemptible capacity.
  11. Storage lifecycle rules and log retention limits are in place.
  12. Data transfer and NAT gateway costs have been reviewed.