Cloud bills have a way of creeping up. A test server left running, snapshots nobody deletes, an instance sized for a launch that happened two years ago. None of these is dramatic on its own, but together they can make the cloud look far more expensive than it needs to be. The good news is that most businesses can reduce cloud costs noticeably without touching application code. The twelve tactics below are ordered roughly from quickest win to longer-term change.
First, see where the money goes
You cannot optimise what you cannot see. Every major provider has a cost explorer that breaks spending down by service, region and tag. Spend half an hour sorting by cost and you will usually find that a handful of resources account for most of the bill. Start there.
12 tactics to reduce cloud costs
1. Delete what nobody uses
Look for stopped instances still holding paid disks, unattached volumes, old snapshots, idle load balancers and unused static IP addresses (several providers charge for public IPs, and some charge more when they are not attached). These "orphaned" resources often accumulate after projects end.
2. Right-size instances
Check CPU and memory usage over a few weeks. A server that never goes above 15% CPU can usually drop one or two sizes. Do this gradually, one step at a time, and watch performance after each change. Provider tools such as AWS Compute Optimizer and Azure Advisor make recommendations based on real metrics.
3. Switch off non-production at night and weekends
Development, test and staging environments rarely need to run 24 hours a day. Scheduling them to run only during working hours cuts their running time by more than half. A simple scheduled job can do it; for example with the AWS CLI:
# stop all instances tagged env=dev (run from a scheduler at 20:00)
aws ec2 stop-instances --instance-ids $(aws ec2 describe-instances \
--filters "Name=tag:env,Values=dev" "Name=instance-state-name,Values=running" \
--query "Reservations[].Instances[].InstanceId" --output text)4. Commit to steady workloads
For servers and databases that run all the time, reserved instances, savings plans or committed-use discounts trade a one- or three-year commitment for a substantially lower rate. Only commit to your stable baseline, the capacity you are confident you will still need, and leave variable load on demand.
5. Use spot or preemptible capacity for interruptible work
Spot instances (Google calls them Spot VMs, Azure calls them Spot Virtual Machines) use spare capacity at a deep discount but can be reclaimed with short notice. They suit batch processing, CI build agents, rendering and data analysis, not your primary database.
6. Move to newer instance generations
Newer instance families, including ARM-based ones such as AWS Graviton, Azure Cobalt or Google Axion, often provide better performance per unit of cost. Most Linux software runs on ARM without changes, but test your stack first.
7. Put storage in the right tier
Object storage offers several classes: frequently accessed, infrequently accessed and archive. Lifecycle rules can move data automatically as it ages, for example logs to an infrequent tier after 30 days and to archive after 90. Remember that archive tiers charge for retrieval and may have minimum storage durations.
8. Clean up snapshots and backups
Backups are essential, but keeping daily snapshots forever is not. Define a retention policy (for instance 7 daily, 4 weekly, 12 monthly) and apply it automatically. Check that old AMIs or machine images are not quietly holding their snapshots too.
9. Watch data transfer charges
Data leaving the cloud to the internet is charged, and so is traffic between regions and, in some cases, between availability zones. Serving static assets through a CDN, compressing responses, and keeping chatty services in the same zone all help. Our HTTP header checker shows whether your site sends compression and caching headers.
10. Use auto-scaling instead of permanent peak capacity
If traffic varies by time of day or season, scale out when busy and scale in when quiet rather than running peak capacity constantly. Set sensible minimums so you are never caught short, and make sure scale-in actually happens.
11. Prefer managed and serverless where it removes idle time
A small internal API that handles a few thousand requests a day may cost far less as a serverless function than as an always-on VM. Equally, a heavily used service can be cheaper on reserved instances than on serverless. Compare based on your real usage pattern.
12. Tag everything and review monthly
Tags such as project, env and owner let you see which team or customer each cost belongs to. Combine them with budget alerts so someone is notified when spending passes a threshold, and hold a short monthly review. Costs that have a named owner tend to stay under control.
A quick prioritisation table
| Tactic | Effort | Risk |
|---|---|---|
| Delete unused resources | Low | Low (take a final snapshot first) |
| Schedule non-production | Low | Low |
| Storage lifecycle rules | Low | Low to medium (retrieval fees) |
| Right-sizing | Medium | Medium (test performance) |
| Commitments | Low | Medium (you pay even if unused) |
| Spot capacity | Medium | Medium (interruptions) |
| Architecture changes | High | Varies |
Habits that keep costs down
One-off clean-ups help, but bills drift back without good habits. Make cost part of the design conversation for new projects, require tags when resources are created, and give engineers visibility of what their services cost. Infrastructure as code (Terraform, CloudFormation, Bicep) also helps, because resources defined in code are easier to review and harder to forget.
If your bill is large or complex, a structured review by an experienced team can uncover savings faster; our cloud solutions page covers the kind of optimisation work involved.
Key takeaways
- Start with visibility: the cost explorer will show where most of the money goes.
- Quick wins are deleting orphaned resources and switching off non-production outside working hours.
- Right-size before you commit, then commit only to the steady baseline.
- Storage tiers, data transfer and snapshots are frequently overlooked line items.
- Tags, budgets and a monthly review stop costs from creeping back.