Fifteen practical ways to reduce cloud costs on AWS, Azure and Google Cloud, from rightsizing and scheduling to storage cleanup, commitments, architecture and FinOps habits.
In this article
- 01Why cloud bills keep growing
- 02Start with visibility
- 03Quick wins: remove waste
- 04Rightsizing done safely
- 05Buy smarter: commitments and pricing models
- 06Architecture changes that pay back
- 07Storage, database and logging costs
- 08Kubernetes and container costs
- 09Make savings last with FinOps habits
- 10Common mistakes to avoid
- 11Where to start this month
Why cloud bills keep growing
Cloud platforms make it easy to create resources and just as easy to forget them. Test environments run all weekend, instances chosen during a rushed launch stay oversized, old snapshots pile up and data transfer charges grow quietly with traffic. Most organizations have meaningful savings available without affecting performance or reliability.
The fifteen techniques below are grouped into quick wins, purchasing decisions, architecture changes and lasting habits. They apply to AWS, Azure and Google Cloud, although service names differ. Start with visibility, then work through the list in order of effort and impact.
Start with visibility
You cannot optimize what you cannot see. Before changing anything, make sure costs can be broken down by application, environment and team. That requires consistent tags or labels and a clear account structure. Once spending is visible, the largest and most surprising items usually stand out immediately.
- 1. Enforce tagging for application, environment, team and owner.
- 2. Set budgets and anomaly alerts for each account and team.
- 3. Review the top cost items monthly with engineering leads.
Quick wins: remove waste
The fastest savings come from resources that deliver no value at all. Idle resources are common in every environment, especially after projects end, experiments finish or engineers leave. Cleaning them up requires little engineering work and carries minimal risk when done with owners' agreement.
- 4. Delete unattached storage volumes, old snapshots and unused load balancers.
- 5. Shut down development and test environments outside working hours.
- 6. Rightsize oversized instances and databases based on actual utilization.
- 7. Apply storage lifecycle policies to move old data to cheaper tiers.
Rightsizing done safely
Rightsizing means matching instance and database sizes to real usage. Many resources run at low average utilization because they were sized for worst-case guesses. Review CPU, memory and connection metrics over several weeks, including peak periods, before downsizing, and change one component at a time with monitoring in place.
Newer instance generations often deliver better performance at lower cost, so upgrading generation can be a saving rather than an expense. Processor architectures such as ARM-based instances can reduce costs further for compatible workloads. Test compatibility in staging before switching production.
Buy smarter: commitments and pricing models
Once usage is stable, on-demand pricing is usually the most expensive option. All major providers offer discounts in exchange for commitments, plus spare capacity at reduced prices for interruptible workloads. Commit only after cleaning up waste and rightsizing, otherwise you lock in spending on resources you do not need.
- 8. Use savings plans or reserved capacity for steady baseline workloads.
- 9. Run batch jobs, CI builds and fault-tolerant work on spot or preemptible capacity.
- 10. Review licensing, such as bringing existing Windows or SQL Server licenses where allowed.
Architecture changes that pay back
Some of the largest savings come from design changes rather than configuration. They take more engineering effort but often reduce costs permanently while improving performance and reliability. Prioritize the workloads that dominate your bill. Small services rarely justify major redesign effort.
For variable workloads, auto-scaling adds capacity during peaks and removes it afterwards. For spiky, event-driven tasks, serverless functions can be cheaper than always-on servers, while steady high traffic often favors containers, as our serverless vs containers comparison explains.
- 11. Add autoscaling so capacity follows demand.
- 12. Move suitable workloads to managed or serverless services.
- 13. Reduce data transfer with caching, CDNs and keeping chatty services in the same zone.
Storage, database and logging costs
Storage and databases are often the second largest cost after compute, and they grow steadily as data accumulates. Review which data needs fast, expensive storage and which can move to cheaper archive tiers. Many organizations keep years of backups, snapshots and logs at full price simply because nobody set retention rules.
Databases deserve particular attention. Oversized managed database instances, provisioned capacity that is rarely used and expensive read replicas for light workloads are common findings. Query optimization and caching can reduce database load enough to choose smaller instances, improving performance at the same time.
Logging and monitoring costs can also surprise teams. Verbose debug logs in production, long retention for low-value logs and duplicate collection across tools add up quickly. Agree which logs matter, sample high-volume sources and keep detailed logs only as long as investigations and compliance require.
Kubernetes and container costs
Container platforms hide costs behind shared clusters. Over-generous resource requests leave nodes half empty, and idle namespaces keep running indefinitely. Reviewing requests against actual usage, using cluster autoscaling and consolidating workloads onto fewer, well-utilized nodes often delivers significant savings for teams running Kubernetes.
Make savings last with FinOps habits
One-time cleanups help, but costs creep back without ongoing ownership. FinOps brings engineering, finance and business teams together to manage cloud spending continuously, treating cost as a shared metric alongside performance and reliability. Engineers see the cost impact of their choices, and finance sees why spending changes.
Unit economics, such as cost per customer, per order or per API call, show whether efficiency improves as the business grows. They help product and engineering teams make trade-offs with real numbers rather than guesses.
- 14. Track unit costs per customer, transaction or product.
- 15. Make cost visible to engineers in dashboards and design reviews.
Common mistakes to avoid
Cost optimization can go wrong when it harms reliability or slows teams down. Avoid cutting redundancy for critical systems, deleting resources without confirming owners, or buying long commitments before usage has stabilized. Savings that cause outages or block developers are not real savings.
Another mistake is treating optimization as a one-off project led only by finance. Engineers understand why resources exist and how to change them safely, so they must be part of the process from the start.
Pair each saving with a check that performance and reliability stayed within agreed targets. Publishing these results to the wider team shows that cost work is careful and evidence-based, which builds support for the next round of improvements.
Where to start this month
A practical first month includes enabling tagging and budgets, cleaning up obvious waste, scheduling non-production environments and reviewing the ten largest cost items with their owners. These steps often fund the more complex work that follows. If you want an experienced review of your environment, our cloud cost optimization team works with read-only access to find and prioritize savings by effort and impact.



