Cloud Cost Optimization: A Practical FinOps Checklist
A 25-point FinOps checklist for cutting cloud waste without slowing engineering, covering visibility, rightsizing, commitments, storage, Kubernetes and governance.
Cloud cost optimization is the ongoing practice of matching cloud spend to real business value by removing waste, rightsizing resources, buying capacity at the best price and making engineers accountable for what they run. The fastest results usually come from tagging, shutting down idle resources, rightsizing and commitment discounts, sustained through a FinOps operating rhythm.
Cloud bills rarely grow because of one bad decision. They grow through hundreds of small ones: a test cluster left running, a database sized for a launch that never came, logs kept forever. This checklist is the one we use when reviewing AWS, Azure and Google Cloud estates, ordered roughly from quickest wins to structural changes.
Why cloud bills drift upwards
Before the checklist, it helps to understand the usual causes of overspend:
- No ownership. Resources are not tagged to a team or product, so nobody feels responsible for them.
- Provisioning for peak. Instances and databases are sized for the busiest hour and run at low utilisation the rest of the time.
- Non-production running 24x7. Development, testing and staging environments often run all weekend with nobody using them.
- On-demand pricing everywhere. Steady workloads pay list price instead of committed-use rates.
- Data gravity. Storage, snapshots, logs and cross-region or internet egress accumulate quietly.
- Architecture debt. Legacy lift-and-shift workloads were never re-architected to use elastic or managed services.
The cloud cost optimization checklist
Work through these in order. Each item is phrased as a check you can answer yes or no.
Visibility and ownership
- Every resource is tagged with owner, team, environment and product, and untagged resources are blocked or flagged by policy.
- Costs are allocated to teams and products through cost categories, accounts or projects, including shared costs such as networking and support.
- Budgets and anomaly alerts are set per account and team, routed to the people who can act on them.
- A weekly cost dashboard shows spend by team, trend versus last month and top movers, and is reviewed by engineering leads.
- Unit economics are tracked, such as cost per transaction, per active customer or per API call, so growth and waste can be told apart.
Quick wins: eliminate waste
- Idle and orphaned resources are removed: unattached volumes, unused elastic IPs, idle load balancers, old snapshots and forgotten test instances.
- Non-production environments are scheduled to shut down outside working hours and at weekends. Running 12 hours on weekdays instead of 24x7 cuts their compute hours by well over half.
- Old AMIs, images and container registries are cleaned up with lifecycle rules.
- Unused licences and marketplace subscriptions are reviewed and cancelled.
Rightsizing
- Compute is rightsized using at least two to four weeks of CPU and memory data, targeting sensible headroom rather than peak.
- Current-generation and ARM-based instances (such as AWS Graviton) are used where workloads support them, as they often offer better price-performance.
- Databases are rightsized, with read replicas, storage and provisioned IOPS reviewed against actual load.
- Autoscaling is configured for variable workloads, with scale-in actually tested, not only scale-out.
Pricing and commitments
- Steady baseline usage is covered by Savings Plans, Reserved Instances or committed use discounts, starting with conservative one-year terms.
- Commitment coverage and utilisation are reviewed monthly so you neither leave savings unclaimed nor pay for unused commitments.
- Spot or preemptible capacity is used for fault-tolerant workloads such as batch jobs, CI runners and some data processing.
- Enterprise discounts and credits are negotiated and tracked, especially at renewal.
Storage and data transfer
- Storage lifecycle policies move ageing data to cheaper tiers and delete what is no longer needed.
- Log retention is deliberate: verbose logs are kept for days or weeks, not forever, and debug logging is off in production.
- Egress is understood: cross-region and cross-zone traffic, NAT gateway charges and internet egress are measured, and a CDN is used where it reduces cost.
- Data platform spend is controlled with warehouse auto-suspend, query limits and partitioning. See our data lakehouse vs data warehouse comparison for how platform choice affects this.
Containers and Kubernetes
- Pod requests and limits reflect real usage, since over-requested pods force more nodes than needed.
- Cluster autoscaling and bin-packing are in place, with node pools matched to workload profiles and spot nodes for tolerant workloads.
- Kubernetes costs are allocated to namespaces and teams using a cost allocation tool, so shared clusters do not hide waste.
Architecture and governance
- Cost is a design criterion: architecture reviews consider serverless, managed services and caching, and new services include a cost estimate before launch.
Prioritising: effort versus impact
Not everything is worth doing first. This rough matrix reflects what we typically see, although the actual impact varies widely by estate.
| Action | Typical effort | Typical impact | Risk |
|---|---|---|---|
| Tagging and allocation | Medium | Enables everything else | Low |
| Deleting idle and orphaned resources | Low | Medium | Low, with backups checked |
| Scheduling non-production | Low | Medium to high | Low |
| Rightsizing compute and databases | Medium | High | Medium, needs testing |
| Commitment discounts | Low | High for steady workloads | Medium, lock-in to term |
| Spot capacity | Medium | High for suitable workloads | Medium, needs interruption handling |
| Storage and log lifecycle | Low to medium | Medium | Low |
| Re-architecture to managed or serverless | High | High over time | Higher, needs a programme |
A good sequence is: visibility first, then quick wins, then rightsizing, and only then commitments. Buying commitments before rightsizing locks in waste for one to three years.
Making it stick with FinOps
One-off clean-ups decay within months unless behaviour changes. FinOps is the operating model that keeps cloud cost optimisation continuous, built on three phases: inform (visibility and allocation), optimise (acting on opportunities) and operate (governance and continuous improvement).
In practice, that means:
- A small FinOps function, even one person part-time, who owns reporting, commitments and the review rhythm.
- Engineering ownership. Teams see their own costs and have targets, just as they own reliability.
- A monthly cost review covering trends, anomalies, commitment coverage and the top five savings opportunities, each with an owner and date.
- Guardrails in code: tagging policies, allowed instance types and budget alerts defined in infrastructure as code and enforced in CI/CD. Our CI/CD best practices guide covers how to build those checks into pipelines.
- Finance and engineering speaking the same language through unit costs rather than just total spend.
A typical scenario
A mid-size SaaS company sees its cloud bill rising faster than revenue. A two-week review typically finds a familiar pattern: several non-production environments running around the clock, databases sized for projected rather than actual load, no commitment coverage on a stable baseline, and logs retained indefinitely. None of these is dramatic alone. Fixed together, and backed by a monthly review, they usually bend the cost curve meaningfully without touching customer-facing performance.
What does cloud cost optimisation cost?
The effort depends on the size and complexity of your estate, the number of accounts and teams, and how much re-architecture is involved. As a rough guide, an initial assessment and quick-win programme is usually a matter of weeks, while an ongoing FinOps service is typically priced as a monthly managed service. Costs vary widely by scope, so ask any provider to show the savings they identify against the fee.
Frequently asked questions
What is the difference between FinOps and cloud cost optimization?
Cloud cost optimisation is the set of technical actions that reduce spend, such as rightsizing and commitments. FinOps is the broader operating model, bringing finance, engineering and business together so those actions happen continuously and spending decisions reflect business value.
How much can you save with cloud cost optimization?
It varies widely by how mature your current practices are. Estates that have never been reviewed usually have meaningful waste in idle resources, oversized instances and uncommitted steady usage, while well-run estates find smaller, incremental gains. Treat any fixed percentage promised before an assessment with caution.
Should I buy Reserved Instances or Savings Plans first?
On AWS, Compute Savings Plans are usually more flexible because they apply across instance families and some services, while Reserved Instances can suit very stable, specific workloads such as databases. Rightsize first, then commit conservatively on your proven baseline.
What are the best cloud cost optimization tools?
Start with native tools: AWS Cost Explorer and Compute Optimizer, Azure Cost Management and Advisor, and Google Cloud Billing reports and Recommender. Third-party platforms add multi-cloud views, Kubernetes allocation and automation, which help as estates grow.
How often should we review cloud costs?
Look at anomaly alerts daily, team dashboards weekly and hold a structured cost review monthly. Review commitments and architecture quarterly, and before any major launch or migration.
How Sunday Labs can help
Sunday Labs runs cloud management and FinOps as part of our managed services, from an initial cost review to an ongoing monthly optimisation rhythm across AWS, Azure and Google Cloud. Our founder-led model means senior engineers, not junior analysts, review your estate and implement the changes safely. If your cloud bill is growing faster than your business, start a conversation and we will help you find where the money is going.
