Finding wasted cloud spend is a scan before it is a fix. This guide gives 22 checks for AWS and Azure. For each check you get where to look on each platform and the evidence to collect. You also get the owner who should confirm it and what could break if you act on it. The aim is findings with owners attached, so nothing changes until someone who knows the workload has seen it. This cloud cost optimization checklist suits IT heads, cloud leads and engineering managers at mid-size companies in India and the GCC.
Last reviewed 2026-11-01 by Manish Sharma.
Cloud Cost Optimization Checklist: The Short Answer
Work through seven groups in order, from ownership and visibility to commitments and governance. Do the scan first and the fixes later. In the scan you record what you find, name the owner, and change nothing yet.
Key Takeaway Scan first, record the evidence and the owner for every finding, and change nothing until the owner confirms it.
How to Use This Cloud Cost Optimization Checklist in One Sitting
This cloud cost optimization checklist works best as a shared job between engineering and finance. Set aside a half day with one person from each. Open the provider’s own cost reports on both platforms and go through the tables in order. For every row, write down what you saw, the evidence and the owner who must confirm it. Evidence can be a screenshot, a report export or a resource ID. Anything you cannot assign to an owner goes on a separate list, because that is a finding in itself.
Our guide on how to reduce cloud costs covers the fixes. It includes the order of work, staged deletes and rollback. The causes behind rising spend are in our explainer on rising cloud costs. For the wider topic, see our post on cloud optimization.
The seven groups, in order:
- Ownership and Visibility: can you see who spends what?
- Idle and Unused Resources: what runs with nothing using it?
- Non-Production Environments: what runs outside working hours?
- Compute and Databases: what is bigger than the work needs?
- Storage, Logs and Backups: what do you keep without a rule?
- Data Transfer: where does data move, and why?
- Commitments and Governance: do discounts and reviews match reality?
What the Latest Data Says
Flexera released the report on 18 March 2026, based on a survey of more than 750 cloud decision-makers and users. Its own summary describes the figure as covering infrastructure and platform services (IaaS and PaaS). It is a survey estimate for the respondents’ estates. Running this cloud cost optimization checklist on your own accounts gives the figure that matters for you.
Cloud Cost Optimization Checklist, Part 1: Ownership and Visibility
Four checks tell you whether you can see the spend and who answers for it. Ownership comes first, because every later finding needs an owner.
| Check | Where to look on AWS | Where to look on Azure | Evidence to collect | Owner | Risk of fixing it |
|---|---|---|---|---|---|
| 1. Every account or subscription has a named owner | AWS Organizations account list | Subscriptions and management groups in the Azure portal | List of accounts or subscriptions with an owner name beside each | Cloud lead | Low: this is record-keeping |
| 2. Tag coverage by owner and environment | Cost Explorer grouped by tag; Tag Editor | Microsoft Cost Management cost analysis grouped by tag; Azure Policy compliance | Share of cost with no owner tag, as a number | Platform team | Low to medium: retroactive tagging takes effort and can miss shared resources |
| 3. Budgets and anomaly alerts reach a person | AWS Budgets; Cost Anomaly Detection | Budgets and anomaly alerts in Microsoft Cost Management | Screenshot of each alert and who receives it | Finance with the platform team | Low |
| 4. Top ten cost lines and their 90-day change | Cost Explorer grouped by service (resource-level data must be switched on and covers the last 14 days) | Cost analysis, grouped by service, then resource | Export of the top ten service lines, each with its change over 90 days | Cloud lead | Low |
A tag only helps if you apply it when you create the resource, so check whether a policy enforces it. On Azure, Azure Policy can require a tag. On AWS, tag policies standardize tag keys and values and can block non-compliant tagging on the resource types you specify. They do not require a tag to exist, and they do not evaluate resources that have no tags.
Some teams alert at 80, 100 and 120 percent of budget, and others at 50, 80 and 100. Budgets and anomaly alerts notify a person, and they do not stop spending.
Cloud Cost Optimization Checklist, Part 2: Idle and Unused Resources
Four checks look for resources that cost money while nothing uses them. Check before you delete anything in this group.
| Check | Where to look on AWS | Where to look on Azure | Evidence to collect | Owner | Risk of fixing it |
|---|---|---|---|---|---|
| 5. Unattached volumes and disks | EC2 volumes in the “available” state; Cost Optimization Hub idle recommendations | Managed disks whose disk state is Unattached | Resource ID, size, created date, last attached date | Resource owner | Medium: a detached disk may hold data a restore plan needs |
| 6. Unassociated public IP addresses | Elastic IP addresses not associated with an instance | Public IP addresses with no associated resource | Address list with creation date and owner | Network team | Low to medium: an address may be allow-listed by a partner |
| 7. Idle load balancers and NAT gateways | Load balancer request and NAT gateway traffic metrics in CloudWatch | Load balancer and NAT gateway metrics in Azure Monitor | Seven days or more of traffic metrics showing little or no use | Platform team | Medium: low traffic may be a standby path |
| 8. Old snapshots, images and backups against retention need | EBS snapshots, AMIs and AWS Backup recovery points | Disk snapshots, images and Azure Backup items | Age, size, source resource and the retention rule that applies | Backup owner | High if removed: they may be restore points or audit evidence |
Check 6 deserves a note. Since 1 February 2024, AWS charges $0.005 per public IPv4 address per hour, with or without a service attached to the address. That rate is current as of November 2026, per the AWS VPC pricing page. Azure also charges a nominal fee for public IPv4 addresses. One address is small, but many across accounts are worth a line in the findings. Stopped compute still carries charges for its disks and addresses, so a stopped server still costs money.
Confirm the owner, check recovery and retention needs, check scheduled jobs, take a snapshot, set a hold period and name the rollback.
Cloud Cost Optimization Checklist, Part 3: Non-Production Environments
Two checks cover environments used for development, test and training. Production does not depend on these environments, so this is a low-risk place to start.
| Check | Where to look on AWS | Where to look on Azure | Evidence to collect | Owner | Risk of fixing it |
|---|---|---|---|---|---|
| 9. Run hours against working hours | Cost Explorer filtered by environment tag (hourly EC2 data, if switched on) | Cost analysis filtered by environment tag; Azure Advisor shutdown recommendations | Running hours per week for each non-production environment, from instance start and stop times | Engineering lead | Low to medium: overnight jobs and warm-up needs |
| 10. Expiry date on temporary environments | Resource tags with an expiry value; account list | Resource group tags and expiry value; Azure Policy | List of temporary environments with no expiry | Engineering lead | Low |
Here is the arithmetic for a schedule. Take an environment that runs 10 hours a day on five days. That is 50 of the 168 hours in a week, so switching it off outside those hours cuts running hours by about 70%. That applies to compute only. Storage, snapshots and IP addresses keep costing money while a machine is off, so the cost saving is smaller than 70%.
Shared services, databases that need warm-up time and batch jobs can all run outside working hours. Check them before you set a schedule.
Cloud Cost Optimization Checklist, Part 4: Compute and Databases
Four checks look for capacity larger than the work needs. Compute and databases carry more risk than the earlier groups, because the resources are in use.
| Check | Where to look on AWS | Where to look on Azure | Evidence to collect | Owner | Risk of fixing it |
|---|---|---|---|---|---|
| 11. Oversized virtual machines, judged on 30 to 90 days of data | Compute Optimizer recommendations; CloudWatch CPU, network and, where collected, memory | Azure Advisor resize recommendations; Azure Monitor metrics | Average and peak CPU, memory and network over the period | Application owner | Medium to high: month-end peaks and performance |
| 12. Databases against current traffic | Compute Optimizer for supported database types; RDS performance metrics | Azure Advisor; database metrics in Azure Monitor | Connections, CPU, memory and storage use against provisioned size | Database owner | High: some changes need a reboot and cause downtime; check memory as well as CPU |
| 13. Auto-scaling minimum and maximum | Auto Scaling group settings and Activity history | Autoscale settings and Run history on virtual machine scale sets | Minimum, maximum and actual size over the period your metrics cover | Application owner | Medium: a low minimum can slow response to a spike |
| 14. Kubernetes requests against real use | Container and node metrics for EKS clusters | Container and node metrics for AKS clusters | Requested CPU and memory against measured use per workload | Platform team | Medium: changing requests affects scheduling and stability |
Use the provider’s recommendation tools as a list of candidates. If you are weighing third-party software, see our comparison of cloud cost management tools. Look at peaks as well as averages, and decide the rollback before the change. On Azure, autoscale with several rules scales out when any rule fires. It scales in only when all of its scale-in conditions hold, so check the scale-in rules as well as the minimum. For the sizing method, see our guide to right-sizing cloud resources. Spot capacity is cheaper for work that tolerates interruption, and it needs checkpointing so a job can resume.
AWS Compute Optimizer analyzes 14 days and Azure Advisor 7 days by default (as of November 2026), and you can lengthen both. Azure Advisor’s savings estimates use retail rates and ignore reservations and savings plans you already hold, so a listed saving can overstate the real one.
Cloud Cost Optimization Checklist, Part 5: Storage, Logs and Backups
Three checks look at data that you keep without a clear reason. This part touches compliance, so involve the people who own the retention rules.
| Check | Where to look on AWS | Where to look on Azure | Evidence to collect | Owner | Risk of fixing it |
|---|---|---|---|---|---|
| 15. Storage tiers by last access | S3 Storage Lens; S3 lifecycle rules | Cost analysis by resource; lifecycle management policies (last-access rules need access-time tracking switched on) | Data volume by last-access age, and the tier it sits in | Data owner | Medium: colder tiers can have retrieval charges and slower access |
| 16. Log retention against compliance need | CloudWatch log groups with no retention period set | Log Analytics workspace retention settings | List of log groups or workspaces, their size and retention setting | Security and platform teams | High if shortened: logs may be required for audit |
| 17. Backup and snapshot retention and replication | AWS Backup plans; snapshot copy settings | Azure Backup policies; replication settings | Retention period and replication targets for each backup set | Backup owner | High: recovery targets must still be met |
On AWS, CloudWatch Logs stores log data indefinitely by default (the console shows “Never expire”) unless you set a retention period on each log group. A retention period that nobody has set is a clear finding to record. On Azure, Log Analytics tables keep data for 30 days by default (90 for a few tables). You can extend that, so look for retention that someone raised and never reviewed.
Changing a retention period needs the compliance owner’s agreement before anyone acts.
Cloud Cost Optimization Checklist, Part 6: Data Transfer
Two checks trace how data moves, which is hard to see at design time. This part needs an architect, because moving a data path changes how services connect. Egress means data leaving the provider’s network, and providers charge for it apart from compute.
| Check | Where to look on AWS | Where to look on Azure | Evidence to collect | Owner | Risk of fixing it |
|---|---|---|---|---|---|
| 18. Cross-zone and cross-region traffic | Cost Explorer filtered by data transfer usage types | Cost analysis grouped by service name, then drilled into the meters | Transfer lines by direction and the services behind them | Architect | High: placing services together can reduce availability |
| 19. NAT, endpoint, CDN and egress paths | NAT gateway metrics; VPC endpoints; CloudFront | NAT gateway metrics; private endpoints; Azure Front Door or CDN | Traffic by path, and which paths could use an endpoint or cache | Network team | Medium: routing changes can break access |
Read each provider’s current rates for the regions you use.
Advantages
Limitations
Cloud Cost Optimization Checklist, Part 7: Commitments and Governance
Three checks look at discounts. The last part also covers the habits that keep savings in place.
| Check | Where to look on AWS | Where to look on Azure | Evidence to collect | Owner | Risk of fixing it |
|---|---|---|---|---|---|
| 20. Commitment coverage and utilization | Savings Plans and Reserved Instances coverage and utilization reports | Reservations and savings plan utilization in Microsoft Cost Management | Coverage and utilization percentages, each with its date | Finance with the platform team | Medium: wrong changes can lock in cost |
| 21. Expiry dates and fit after right-sizing | Commitment expiry list | Reservation and savings plan expiry list | Expiry dates, and whether the covered usage still exists | Finance with the platform team | Medium |
| 22. A recurring review, with cost in engineering review | Calendar and meeting notes; cost estimates in pull requests | Same | Review dates, attendees and decisions made | Cloud lead | Low |
A commitment bought for an oversized baseline locks in that waste at a lower price, so right-size first and then commit. Microsoft quotes “up to” figures for Azure savings plans for compute (65 percent) and reservations (72 percent), as of November 2026. Those are the provider’s maximums, and they should not drive a plan.
Check 22 keeps the others from decaying. A quarterly cost review between engineering and finance works when it has a named attendee list and a standing agenda. FinOps is the practice of bringing engineering, finance and the business together on cloud spend. Our post on FinOps and DevOps covers how engineers can own the cost of what they build.
What to Do With Your Findings
Sort the findings from this cloud cost optimization checklist by risk and owner before anything changes. Then hand the ranked list to the method in the how-to guide. Start with the lowest risk.
Rank Findings by Risk and Effort
Write down the evidence for each finding.
Give each finding an owner who confirms it is real.
Put low-risk, low-effort items first, such as non-production schedules and unassociated addresses. Leave databases, retention and transfer for later.
Pass the ranked list to the method in the how-to guide.
What a Finding Record Holds
For each finding, keep five items: the owner, the baseline cost, the expected effect, the rollback trigger and the validation date. The baseline matters because two overlapping changes can each claim the same saving.
When the Scan Is Not Enough
A scan is not enough when no one owns the cost or when spend rises faster than the business. Commitments nobody can explain are another sign.
Key Takeaway Sort findings by risk and owner first, and only then decide what to change.
What This Article Does Not Cover
This cloud cost optimization checklist is a scan. It does not give the order of work, the staged delete, rollback steps or a 30-day plan. Those are in the how-to guide. The causes are in the explainer on rising cloud costs.
For the wider picture, read about how Signisys helps you reduce cloud costs without losing performance and about cloud cost optimization and FinOps. Signisys provides these services: see cloud services and platform engineering.
References
- Flexera, Flexera Finds Cloud Value is Rising While AI Waste Grows, press release on the State of the Cloud Report 2026, 18 March 2026.
- Microsoft Learn, Optimize your cloud investment with Cost Management.
- AWS documentation, Identifying opportunities with Cost Optimization Hub.
Security Insights, Delivered.
Practical, vendor-neutral analysis of threats, tools, and architecture decisions.