Where Your AWS Money Is Really Going: 7 Places Cloud Waste Hides

ABRAR ASLAM — Tue, 13 Oct 2026 11:53:32 +0000

And how to find it in your own account in about 10 minutes, without giving anyone access

Most AWS bills tell a familiar story. They start small, grow with every new project, and at some point someone in finance asks why the cloud costs more this quarter than last. Nobody is quite sure.

You are not alone. In Flexera's 2026 State of the Cloud Report, organisations estimated that 29% of their cloud spend is wasted, up from 27% the year before and the first rise in five years. 85% said managing cloud spend is their top cloud challenge.

The waste is rarely one dramatic mistake. It is dozens of small things that nobody owns, nobody gets an alert for, and nobody has time to look at. Here are the seven places I find it most often, and how to check for each one.

1. Disks left behind after servers are deleted

When you terminate an EC2 instance, its EBS volumes are not always deleted with it. Volumes created separately, or attached with "delete on termination" switched off, stay behind in the available state, attached to nothing and billed every month.

How to check: in the EC2 console, open Volumes and filter by state available. Each one is a candidate for removal. Take a snapshot first if the data might matter.

2. Load balancers and IP addresses that serve nothing

Load balancers have an hourly charge whether or not they handle traffic. It is common to find one that was created for a test, a migration or a service that no longer exists, still running with no registered targets.

Elastic IP addresses that are not attached to anything also cost money, and since AWS began charging for every public IPv4 address, idle addresses add up across accounts and regions.

How to check: look for load balancers whose target groups are empty, and Elastic IPs with no association.

3. Servers far bigger than their workload

This is usually the largest single source of waste. An instance chosen "to be safe" at launch, or sized for a peak that never came, quietly runs at a few percent CPU for months.

How to check: in CloudWatch, look at average and maximum CPU over at least 14 days. An instance averaging under 10% with peaks under 40% is a strong candidate to downsize, stop or schedule. Remember that CPU does not show memory pressure, so check that too before resizing.

Older instance generations are worth a look as well. Datadog's State of Cloud Costs report found that 83% of organisations spend an average of 17% of their EC2 budget on previous-generation instances, which usually cost more for less performance.

4. Databases nobody connects to

RDS instances are easy to forget: a staging database from last year, a copy made for a one-off report, a database for a service that was retired. If it has had zero connections for two weeks, it is a strong candidate to snapshot and remove.

How to check: the CloudWatch metric DatabaseConnections, with the maximum over 14 days.

5. Containers asking for far more than they use

Containers make it easy to over-provision without noticing. Datadog found that 83% of container costs were associated with idle resources, split between clusters with too much spare capacity and workloads requesting more CPU and memory than they need.

How to check: compare your ECS services' or Kubernetes pods' CPU and memory utilisation against what they request. Services that average under 20% CPU and 30% memory are usually oversized.

6. NAT Gateways with almost no traffic

A NAT Gateway has a fixed hourly cost before any data is processed. A gateway that moves only a few gigabytes a month can cost far more than the traffic justifies, especially when there is one per Availability Zone in a quiet environment.

How to check: the BytesOutToDestination and BytesInFromDestination metrics. If the monthly total is tiny, consider consolidating gateways, using VPC endpoints for AWS services, or removing them from non-production environments.

7. Storage that never gets cleaned up

S3 buckets without lifecycle rules keep every object forever in the most expensive storage class, including incomplete multipart uploads you cannot even see in the console. Logs, exports and backups are the usual culprits.

How to check: look for buckets with no lifecycle rules, then agree retention with the owner and add rules to expire old data or move it to cheaper storage classes.

Why waste keeps coming back

Finding waste once is not the hard part. Keeping it gone is. In Harness's 2025 FinOps in Focus report, 48% of organisations said they do not track idle resources, and 86% of developers said it takes at least a week to spot idle, orphaned or unused resources and act on them.

Three habits make the biggest difference:

Tag everything with at least an Owner and an Environment, so every resource has someone to ask.
Set AWS Budgets and anomaly alerts, so a jump in spend is noticed in days, not at the end of the quarter.
Review regularly. A monthly look at the same checks catches new waste before it becomes normal.

And while you are looking: security and backups

In my experience, accounts with forgotten resources often have forgotten risks too: security groups open to the internet on SSH or database ports, users without MFA, unencrypted volumes, and backups that were assumed to exist but do not.

The stakes are real. The UK Government's Cyber Security Breaches Survey 2025/26 found that 43% of UK businesses had a breach or attack in the previous 12 months. And Sophos found that when attackers compromised the backups, median ransomware recovery costs were eight times higher.

So when you check for waste, check the basics of security and recovery at the same time.

Checking all of this in about 10 minutes

You can work through the list above by hand. It takes a while across every region, but it is worth doing.

If you would rather automate it, my team at KloudCare built a free, read-only AWS assessment that runs all of these checks, and more, in about 10 minutes:

It runs inside your own AWS account from a CloudFormation template you can read in full.
It is read-only. It cannot change, stop or delete anything, and it never reads your files, databases or secrets.
The report is saved to your own private S3 bucket. Nothing is sent to us unless you choose to share it.
Every finding shows its evidence and observation period, the recommended action, the risk of making the change, and an estimated monthly saving based on on-demand prices for your region.
Delete the stack and everything is removed.

You can run it here: kloudcare.co.uk/assessment.html

Treat every saving as a candidate, not an instruction. Confirm with the owner, take a snapshot where data matters, and test changes outside production first. An apparently idle resource can still have a purpose, such as disaster recovery.

KloudCare is a UK AWS consultancy helping small and medium-sized businesses keep their AWS accounts cost-efficient, secure and recoverable. Find out more at kloudcare.co.uk.

Sources

Flexera, 2026 State of the Cloud Report: https://www.flexera.com/about-us/press-center/flexera-finds-cloud-value-is-rising-while-ai-waste-grows
Datadog, State of Cloud Costs: https://www.datadoghq.com/state-of-cloud-costs/
Harness, FinOps in Focus 2025: https://harness.io/press-and-news/finops-in-focus-report-2025
UK Government, Cyber Security Breaches Survey 2025/2026: https://www.gov.uk/government/statistics/cyber-security-breaches-survey-20252026/cyber-security-breaches-survey-20252026
Sophos, The Impact of Compromised Backups on Ransomware Outcomes (2024): https://assets.sophos.com/X24WTUEQ/at/539j6fwcmx6wk6whnhxc47/sophos-the-impact-of-compromised-backups-on-ransomware-outcomes-wp.pdf

DEV Community: ABRAR ASLAM