aws-waste-radar

Scan an AWS account for storage and EC2 cost-waste findings using purely technical signals (EC2/EBS APIs + CloudWatch). Tag taxonomy is used only to scope remediation — never for detection — and untagged resources are flagged NEEDS_CLASSIFICATION instead of being silently excluded.

Companion to the Hyperscaler Radar suite (aws-radar, gcp-radar, azure-radar, oci-radar).

Install

pip install aws-waste-radar

Usage

Every result set is written as both CSV and JSON (same basename) plus a summary.json. All findings from whichever checks ran are also merged into a single consolidated findings.csv / findings.json (long format: category, source, resource_type, resource_id, name, finding, scope, details).

# Everything
aws-waste-radar --all --profile prod --region us-east-1

# Category flags
aws-waste-radar --storage          # all storage checks
aws-waste-radar --ec2              # all EC2 checks
aws-waste-radar --billing          # daily account cost, by service (Cost Explorer)

# Per-discovery flags (mix and match freely)
aws-waste-radar --snapshots --io2-gp3            # storage: just these two
aws-waste-radar --graviton --spot                # ec2: just these two
aws-waste-radar --unattached --prev-gen --json   # cross-category + JSON summary to stdout

Any EC2 check also produces the full ec2_inventory.{csv,json} and combined ec2_findings.{csv,json}. --billing defaults to a 30-day window; override with --billing-days N.

What it detects

--storage

PVC filesystem utilization needs kubelet stats from inside the cluster; the AWS API only shows capacity. The CSV maps volumes → PVC/namespace so the in-cluster check is a join, not a hunt.

--ec2

--schedule costs nothing and needs no setup. It reads CPUUtilization from basic monitoring — free, automatic (hypervisor-level, no agent), retained 63 days — aggregated to an hour-of-day profile. So it works on existing history immediately; there is no 48-hour wait or customer opt-in. The active window is reported in local time via --schedule-tz-offset (e.g. -5 for US-East). Memory- or disk-based scheduling is the only case that would need the CloudWatch agent — CPU does not.

--billing

Cost Explorer is a global, opt-in service billed at ~$0.01 per request; --billing makes a single call. This view is account-level daily spend — use the daily trend to spot cost creep and the per-service split to see where it lands. (Hourly 24h granularity and per-instance start/stop schedule detection are intentionally not included in this build.)

Scope classification

• SERVICES/LOGS (safe to remediate) — tagged, no customer-data hints
• CUSTOMER_DB (do not touch) — tag values hint at customer/tenant data plane
• NEEDS_CLASSIFICATION — no matching tags: this is itself a tagging-gap finding

IAM permissions

The tool is strictly read-only — it only describes resources and reads metrics, and makes no mutating API calls. The minimal least-privilege policy matching exactly what the code calls is:

{
  "Version": "2012-10-17",
  "Statement": [{
    "Effect": "Allow",
    "Action": [
      "ec2:DescribeInstances",
      "ec2:DescribeVolumes",
      "ec2:DescribeSnapshots",
      "cloudwatch:GetMetricStatistics",
      "dlm:GetLifecyclePolicies",
      "ce:GetCostAndUsage"
    ],
    "Resource": "*"
  }]
}

License

MIT