back to blog
// post

How to find idle AWS resources without living in the CLI

Victor Grenu·2024-09-24·2 min read

I used to send clients a shell history. CPU near zero. RDS with no connections. Volumes in available. Snapshots older than anyone on the team. It works. It also takes a day, and it is stale the next morning.

If you want the DIY version for one account and one region:

EC2. CloudWatch CPUUtilization and network packets, not a single 5-minute dip. An instance can look idle at noon and busy at 03:00.

RDS. DatabaseConnections at zero for a week is a smell. Confirm it is not a replica you still need.

EBS. Unattached volumes are the easy win:

aws ec2 describe-volumes \
  --query "Volumes[?State=='available'].[VolumeId,Size]" \
  --output table

Logs. Log groups with no retention fill quietly:

aws logs describe-log-groups \
  --query "logGroups[?retentionInDays==null].[logGroupName,storedBytes]" \
  --output table

Repeat that across every enabled region. Then do IAM credential age, Elastic IPs, NAT, load balancers, SageMaker, ElastiCache. This is why the audit became a product.

Why this is a bad weekly ritual

A FinOps engineer can run the CLI. A CTO will not. A platform manager with 40 accounts will not do it every Monday. The miss is always the same: us-west-2 was in the script, eu-central-1 was not, and that is where the demo VPC still lives.

unusd.cloud runs those checks on a schedule with a read-only role. 30+ services, 51+ rules, every region you enabled. Email digest, Slack or Teams for the scan, full report in the app. You still choose what to delete.

Idle resources are also attack surface. An open sandbox with an old key is not only a cost problem.

Connect one account if you are done maintaining the script.

// try unusd

Stop paying for resources nobody is using.

Connect a read-only role. Digest by email, full web report and Navi in the app - minutes to first scan.

Start free scan