Where cloud waste hides: 12 places to check first.

Cloud waste is rarely one big mistake. It is dozens of small things that nobody switched off. Native tools such as AWS Cost Explorer and Compute Optimizer, Azure Advisor and Cost Management, and Google Cloud Recommender will point at many of them. What follows is where we look first, how to check each one, and the safest first step.

1. Idle and oversized compute

Check: servers and instances with consistently low CPU and memory use over several weeks. Safe first step: drop one size in a test environment, watch for a week, then repeat in production with the owner's approval.

2. Development and test running around the clock

Check: non-production environments that run through nights and weekends. Safe first step: schedule them to stop outside working hours, starting with the ones nobody uses at weekends.

3. Unattached disks and forgotten volumes

Check: storage volumes with no server attached, left behind when machines were deleted. Safe first step: snapshot, tag with a delete-by date, then remove.

4. Old snapshots and backups

Check: snapshots and backups far older than your retention policy. Safe first step: agree the policy first, then apply automatic expiry so the problem does not return.

5. Idle load balancers and public IP addresses

Check: load balancers with little or no traffic, and reserved IP addresses attached to nothing. Safe first step: confirm with the service owner, then remove.

6. Data transfer and NAT charges

Check: traffic between zones, regions and out to the internet, and per-gigabyte processing charges on network gateways. These are easy to miss because they hide inside many small line items. Safe first step: find the biggest flows, then ask whether the two services could sit closer together or use a private endpoint.

7. Oversized databases

Check: database instances sized for a peak that never came, and read replicas nobody reads. Safe first step: review performance data with the owning team before any change, and schedule the resize in a quiet window.

8. Storage in the wrong tier

Check: rarely accessed data sitting in the most expensive storage class. Safe first step: apply lifecycle rules to one low-risk bucket and check retrieval costs before rolling them out widely.

9. Log and monitoring volume

Check: verbose debug logging in production, and logs kept much longer than anyone reads them. Safe first step: lower the log level and shorten retention for one noisy service.

10. Kubernetes over-requesting

Check: workloads that request far more CPU and memory than they use, which forces extra nodes. Safe first step: compare requests with actual use, adjust the largest gaps first and watch for restarts.

11. Commitments that do not match usage

Check: reservations, savings plans or committed-use discounts that are unused, expiring, or covering the wrong workloads, and steady workloads that have no commitment at all. Safe first step: review coverage monthly and commit only to what has been steady for a long time.

12. Idle GPUs and AI workloads

Check: GPU machines left running between experiments, and AI features whose usage cost nobody can attribute to a team or product. Safe first step: tag every AI workload with an owner, then set budgets and alerts. Our AI cost management page explains the approach.

Rules that keep cleanup safe

• Start read-only. Look first, change later.
• Name an owner for every change, and get their approval.
• Make every change reversible: snapshot first, then remove.
• Agree how you will count the saving before you start, so finance can check it.
• Add guardrails (budgets, alerts, expiry rules) so the waste does not creep back.

If you want a ranked list for your own estate, with the savings counted in a way finance can check, see how our cloud cost optimization work runs.