Cloud Waste Hunter · Serverless FinOps
How Cloud Waste Hunter works.
Eight steps, in order — from the moment a customer connects an AWS account to the moment a remediation lands in their inbox. Every step is a real piece of the production stack, not a sales diagram.
Memory
This system's evolution
The architectural events the registry remembers about this project. On desktop, drag the scrubber, step with arrows, or hit play to advance the cursor back through time. On mobile, tap each marker to read its rationale. The architecture below remains the latest snapshot regardless of cursor position — this surface is companion, not replacement. The full archive lives at /evolution?system=cloud-waste-hunter.
cursorCWH topology engine transplanted onto the homepage
2026
Step 01 · Cognito
A visitor signs up.
AWS Cognito user pool with Google IdP federation and a custom email Lambda for verification. The account exists in the SaaS before a single resource in the customer's AWS estate is touched — credentials never travel through the marketing site.
Step 02 · STS AssumeRole
They connect an AWS account.
The customer launches a CloudFormation template that creates a read-only IAM role bound to the SaaS principal via a per-customer external id. The scanner assumes that role via STS — temporary credentials, scoped policy, no long-lived secret to leak, ever.
Step 03 · Lambda
The scanner Lambda triggers.
A FastAPI container image runs as a Lambda behind API Gateway. The scan endpoint returns immediately and the Lambda self-invokes via the AWS SDK — that detail is how we bypass the 30-second API Gateway hard timeout and still keep the request path entirely serverless.
Step 04 · ThreadPool(32)
Multi-region fan-out.
Inside the Lambda, a ThreadPoolExecutor with 32 workers scans every configured region in parallel — EC2, EBS, RDS, NAT, EIP, ELB, snapshots, the lot. Hundreds of resources inventoried in seconds instead of minutes, with cost-per-region attribution preserved through the pipeline.
Step 05 · DynamoDB
Findings land in DynamoDB.
Six tables — accounts, scans, findings, billing, sessions, audit — capture the inventory. Cost figures are anchored to AWS Cost and Usage Report 2.0 via a Glue catalogue + Athena, so every dollar figure in the dashboard is reconcilable against a real CUR line item.
Step 06 · Bedrock
Claude generates remediation.
Claude 3.5 Haiku on AWS Bedrock streams an explanation, the risk, and the exact CLI or Terraform snippet to fix each finding. The model is grounded in the scan data — never invents resource ids or costs — and chat streaming goes through a Lambda Function URL to bypass the API Gateway timeout entirely.
Step 07 · Dashboard
The customer sees the savings.
Waste quantified by service, prioritised by dollar impact, with one-tap remediation buttons that fire deterministic playbook commands — not LLM-generated ones. The customer sees the number, the cause, and the exact action that closes the gap, in one screen.
Step 08 · EventBridge
The loop recurs.
EventBridge cron schedules + SQS-decoupled dispatch re-run every customer's scan on cadence. New waste is caught within minutes of being created and a Slack notification fires before the bill closes. The loop — not any individual scan — is the product.
CWH Pro · cloudwastehunter.io
Want the same scanner pointed at your own AWS account?
Same scanner, same Bedrock remediation, same EventBridge schedule. Plus and Pro tiers add multi-account, API access, and SSO; Free starts you on a single account with no card required.
