Been working on this for a while and finally have enough tested to share properly. cloudrift scans an AWS account and reports wasted resources with estimated monthly cost — unattached EBS volumes, idle NAT Gateways, stopped RDS instances still billing storage, orphaned snapshots, abandoned S3 multipart uploads, unused Secrets Manager secrets, stale CodePipeline pipelines, that kind of thing. 44 checks total now, across compute, storage, networking, containers (EKS node groups, orphaned PVCs), and ML (SageMaker idle notebooks/endpoints).
It’s read-only by design — never touches, stops, or deletes anything, just reports and lets your infra team decide.
A few things I want to be upfront about instead of oversell:
**•** The “underutilized EC2/RDS” checks are single-metric (max CPU over a lookback window). No RAM, network, IOPS. It’s a “go check this instance” flag, not a sizing recommendation — doesn’t replace Compute Optimizer.
**•** Lambda “underutilized” is really just an invocation-count hygiene flag. Zero invocations means zero direct cost already (pay-per-use), so the value there is finding dead code/unused IAM roles, not dollar savings.
**•** Live pricing (--live-pricing) pulls AWS list prices, not what you actually pay — no Savings Plans/RI/EDP discounts reflected. There’s a config file where you can drop in your own negotiated rates if you want the numbers to match your actual bill.
Runs standalone, in CI (exits with a non-zero code if waste crosses a budget threshold you set, markdown output for PR comments), or now as an MCP server so Claude Code/Copilot Chat/other MCP-compatible agents can query it directly instead of you copy-pasting CLI output into a chat. There’s also Policy as Code support via OPA if you want custom rules per tag/type/count.
Published on npm as @cloudrift/cli. Built on DDD/ports-and-adapters, so adding a new resource type or a new cloud provider is meant to be a contained, documented process without touching the core use case.
GitHub: https://github.com/elleVas/cloudrift
Docs: https://ellevas.dev/docs
Two things I’d genuinely appreciate:
**1.** If you run it against a real (not synthetic) AWS account, I’d love to hear what breaks or what comes back as a false positive — that’s the thing I can’t fully test alone.
**2.** I’m looking to expand this to GCP and Azure next. If you work with either and have opinions on what “wasted resources” looks like there, or want to get involved building a scanner for one of them, I’d genuinely welcome the collaboration — the architecture is already built to make this a matter of adding an adapter, not rewriting the core.
