Five cloud cost quick wins that don't need a migration
Five changes cut most avoidable cloud spend without a migration: remove resources nobody uses, right-size what you keep based on real usage at your busiest times, switch non-production environments off outside working hours, move rarely read data to cheaper storage and check data transfer, and buy commitments only for steady usage, last. What you save depends on your setup, so this post quotes no figures.
Cloud bills tend to grow quietly. A test server is left running, a database is sized for a launch that never needed it, logs are kept forever. None of it is dramatic, and together it adds up.
These five changes don't need a migration or a redesign. Most can be checked in an afternoon, and they apply whichever cloud provider you use. We deliberately don't quote savings figures: what you save depends entirely on how your account is set up today.
Before you start: know who owns what
Turn on cost reporting by service and, if you can, tag resources by team, product and environment (production, staging, test). Without that, every conversation about cost becomes "whose is this?". Set a budget alert while you are there, so the next surprise is an email rather than an invoice.
1. Remove what nobody uses
Look for:
- Servers or containers with almost no traffic for weeks.
- Disks and volumes not attached to anything.
- Old snapshots and backups beyond your retention policy.
- Unused IP addresses and load balancers with nothing behind them.
- Test environments from projects that have ended.
Check with the owner, take a final backup if in doubt, and delete. This is usually the quickest win because nothing in production changes.
2. Right-size what you keep
Many servers and databases are larger than their workload needs, often because they were sized for a peak that never came. Compare the size you pay for with actual CPU and memory use over a few weeks, including your busiest days.
Step down one size at a time, watch performance, and keep a note of why each size was chosen.
3. Turn off non-production outside working hours
Development, test and staging environments rarely need to run overnight or at weekends. Schedule them to stop in the evening and start in the morning. Leave production alone.
Make sure teams know the schedule and can start an environment on demand, or people will simply turn the schedule off.
4. Fix storage and data transfer
- Storage classes. Data that is rarely read, such as old logs, backups and archives, can move to cheaper, slower storage tiers. Lifecycle rules can do this automatically.
- Log retention. Decide how long each kind of log is actually needed, taking account of any legal or contractual requirement, and set retention to match.
- Data transfer. Moving data between regions, or out to the internet, is often charged. Check whether services that talk to each other a lot sit in the same region, and whether a content delivery network would serve static files more cheaply.
5. Commit only for what is steady
All major providers offer lower prices if you commit to a level of usage for one or more years. That is worth it for workloads that run all the time at a predictable size, and only after steps 1–4, so you don't commit to waste.
Start with a portion of your steady baseline rather than all of it, and review before each renewal.
Making it stick
Quick wins fade if nobody looks again. A light routine helps:
- A monthly look at the bill by team and service.
- Budget alerts per environment.
- A rule that new resources are tagged with an owner.
- A quarterly review of the largest items and of any commitments.
Where to start
Turn on cost reporting and tagging, then work through the list in order: removing unused resources is safest, commitments come last.
If you would rather have someone go through your account with you, our cloud cost review is a fixed-scope, read-only review, and Cloud & DevOps covers cost, reliability and delivery together.
Sources
Want help implementing this?
Book a free 30-minute call about your business. No obligation.