Back to Insights
BlogCost Optimization

5 Common AWS Waste Patterns We See Every Week

After scanning hundreds of AWS accounts, we've identified the most common sources of cloud waste. Here's what to look for.

January 10, 20246 min readBy Sentasity Team

Every week, our scanner analyzes AWS accounts ranging from scrappy startups to enterprise deployments. And every week, we find the same patterns of waste hiding in plain sight.

The frustrating part? Most of this waste is easily fixable. The challenging part? It's often invisible without the right tools and processes to surface it.

Here are the five most common waste patterns we encounter, along with practical guidance on how to identify and eliminate them.

1. Idle and Underutilized EC2 Instances

This is the most common source of waste we find, present in over 80% of accounts we scan.

What It Looks Like

  • Development instances running 24/7 when developers work 8 hours
  • "Temporary" test instances that became permanent
  • Production instances with average CPU utilization under 10%
  • Instances in stopped state still incurring EBS costs

The Real Cost

A single m5.xlarge instance running idle costs approximately $140/month. Most organizations have dozens of these.

How to Find It

Check your EC2 instances for:

  • Average CPU utilization below 10% over 14 days
  • Network I/O consistently near zero
  • No SSH/RDP connections in weeks
  • "test," "dev," or "temp" in the name with no recent activity

The Fix

  1. Implement tagging policies: Require tags for environment, owner, and expiration date
  2. Use Instance Scheduler: Automatically stop dev/test instances outside business hours
  3. Right-size before you commit: Downgrade or terminate before purchasing Reserved Instances
  4. Set up CloudWatch alarms: Alert when instances have low utilization for extended periods

2. Orphaned EBS Volumes

When you terminate an EC2 instance, the attached EBS volumes don't automatically delete unless configured to do so. This creates "orphaned" volumes that accumulate over time.

What It Looks Like

  • EBS volumes in "available" state (not attached to any instance)
  • Snapshots of volumes that no longer exist
  • Volumes created months or years ago with no recent I/O

The Real Cost

A 500GB gp3 volume costs about $40/month. We regularly find accounts with terabytes of orphaned storage.

How to Find It

Look for EBS volumes where:

  • State = "available"
  • No attachments
  • Last I/O operation was months ago

The Fix

  1. Audit regularly: Monthly review of unattached volumes
  2. Enable DeleteOnTermination: Set this for non-critical volumes
  3. Lifecycle policies: Automatically delete volumes unattached for more than X days
  4. Snapshot before delete: If in doubt, snapshot the volume before deletion

3. Oversized RDS Instances

Database instances are often provisioned with plenty of headroom "just in case." That headroom becomes expensive over time.

What It Looks Like

  • Production database running on db.r5.4xlarge with 5% CPU utilization
  • Read replicas sized identically to primary when traffic is much lower
  • Multi-AZ enabled for development databases
  • Provisioned IOPS far exceeding actual requirements

The Real Cost

The difference between db.r5.xlarge and db.r5.4xlarge is over $1,000/month. Multiply by multiple databases and regions.

How to Find It

Check your RDS instances for:

  • CPU utilization consistently below 20%
  • Memory utilization below 40%
  • Provisioned IOPS much higher than consumed IOPS
  • Read replica utilization significantly lower than primary

The Fix

  1. Performance Insights: Use RDS Performance Insights to understand actual resource needs
  2. Right-size incrementally: Drop one instance size at a time and monitor
  3. Review Multi-AZ needs: Development doesn't need Multi-AZ
  4. Consider Aurora Serverless: For variable workloads, pay only for what you use

4. Unattached Elastic IPs

Elastic IPs are free when attached to a running instance. The moment they become unattached—whether because the instance was stopped or terminated—they start costing money.

What It Looks Like

  • Elastic IPs not associated with any resource
  • IPs kept "just in case" for instances that no longer exist
  • IPs from old load balancers or NAT gateways

The Real Cost

$3.60/month per unattached Elastic IP. Sounds small, but we've found accounts with 50+ orphaned IPs.

How to Find It

List all Elastic IPs and check:

  • Association ID is empty
  • Instance ID is empty
  • No recent usage in VPC Flow Logs

The Fix

  1. Regular audits: Monthly review of Elastic IP allocations
  2. Tag with purpose: Know why each IP exists
  3. Release promptly: When an instance is terminated, release the IP
  4. Automation: Script to alert on unattached IPs older than 7 days

5. Forgotten Load Balancers

Load balancers are often created for projects that complete or get abandoned, but the LB remains, quietly charging.

What It Looks Like

  • Application Load Balancers with zero healthy targets
  • Classic Load Balancers from legacy deployments
  • Network Load Balancers routing to terminated instances
  • Multiple LBs that could be consolidated

The Real Cost

An idle Application Load Balancer costs approximately $16/month plus LCU charges. We commonly find 5-10 unnecessary LBs per account.

How to Find It

Check your load balancers for:

  • Zero healthy hosts in target groups
  • No requests processed in 30+ days
  • Listeners with no rules or default actions
  • Associated with security groups of terminated instances

The Fix

  1. Monitor target health: Alert when all targets become unhealthy
  2. Review monthly: Check for LBs with zero traffic
  3. Consolidation: Multiple apps can often share a single ALB with path-based routing
  4. Clean up after projects: Include LB deletion in project teardown checklists

The Bigger Picture

These five patterns account for the majority of waste we find. But they share a common root cause: lack of visibility and accountability.

Without clear ownership (who's responsible for this resource?), expiration (when should this be reviewed?), and monitoring (is this still needed?), waste accumulates naturally.

Building Better Habits

The organizations with the cleanest AWS accounts share these practices:

  1. Mandatory tagging: Every resource has an owner and purpose
  2. Regular reviews: Monthly cost reviews by team leads
  3. Automated cleanup: Scripts and policies that enforce hygiene
  4. Cost allocation: Teams see and own their spending

Key Takeaways

  • Idle EC2 instances are the #1 source of waste—implement scheduling
  • Orphaned EBS volumes accumulate silently—audit monthly
  • Oversized RDS instances waste thousands—right-size based on actual usage
  • Unattached Elastic IPs add up—release what you don't need
  • Forgotten load balancers hide in plain sight—monitor target health

Want to know exactly how much waste is hiding in your AWS account? Start your free scan—our 34 detection policies will find these patterns and more in minutes.

Tags

AWSCost OptimizationCloud WasteFinOps

Ready to Optimize Your AWS Costs?

Start with a free scan to see what you could save.