DEV Community: Suresh

The Hidden Cost of Idle AI/ML Infrastructure: SageMaker, AML, and Vertex AI

Suresh — Wed, 08 Apr 2026 10:11:49 +0000

TL;DR: Idle AI/ML endpoints burn $500-$23K per month unnoticed. Here's how to detect them across AWS, Azure, and GCP — and stop them automatically in CI.

Tools like CleanCloud surface these across AWS, Azure, and GCP — and can enforce detection in CI before the bill hits.

AI/ML Waste: The New Blind Spot

For the past several years, the dominant form of cloud waste was infrastructure sprawl — orphaned EBS volumes, idle NAT gateways, stopped VMs that were never deallocated. These resources are expensive in aggregate, but individually small. A forgotten EBS volume costs $10-$40/month. An unattached Elastic IP costs pennies.

AI/ML infrastructure operates at a completely different scale. A single idle SageMaker endpoint backed by a GPU instance can cost more than a thousand stopped EC2 instances. A Vertex AI endpoint running an undeployed model on a high-memory accelerator can burn through $23,000 a month with zero traffic.

This is the new waste category that FinOps dashboards were never designed to catch.

Tools like CleanCloud approach this differently: instead of dashboards, they scan for deterministic signals (like zero invocations over time) and flag idle endpoints directly — making them enforceable in CI/CD rather than something you discover weeks later in billing.

Key stats:

SageMaker GPU endpoint, idle: ~$500/month (minimum)
SageMaker p4d.24xlarge endpoint, idle: $23K+/month
Default idle window before detection: 7 days
Typical "forgotten" endpoint: 6+ weeks of unnoticed billing

The pattern is consistent across all three major clouds. A data scientist spins up an endpoint to serve a model — for a hackathon, a proof-of-concept, a demo. The event ends. The endpoint doesn't. Six weeks later, finance flags an anomaly in the ML budget. By then, the team has scattered, the model is stale, and the endpoint has cost more than the original experiment was worth.

AWS: Idle SageMaker Endpoints

SageMaker endpoints are always-on serving infrastructure. Unlike Lambda or Fargate, an endpoint doesn't scale to zero when traffic stops. The underlying EC2 instance keeps running, and AWS keeps billing — at full on-demand rates, including any attached GPU capacity.

How the rule works

The aws.sagemaker.endpoint.idle rule queries CloudWatch Metrics for InvocationCount across the idle window (default: 7 days). An endpoint with zero invocations over that period is flagged. The confidence level and cost estimate depend on the instance type:

Instance Type	Approx. Monthly Cost (Idle)	Confidence
ml.t3.medium	~$30	MEDIUM
ml.m5.xlarge	~$140	MEDIUM
ml.g4dn.xlarge	~$500	HIGH
ml.g4dn.12xlarge	~$1,800	HIGH
ml.p3.2xlarge	~$2,800	HIGH
ml.p4d.24xlarge	~$23,000+	HIGH

GPU-backed endpoints are rated HIGH confidence because the cost impact is unambiguous — zero invocations over 7 days on a GPU instance is definitively idle waste. CPU-backed endpoints at lower cost tiers are rated MEDIUM because they may be handling low but real traffic below the detection threshold.

Example CleanCloud output

Rule: aws.sagemaker.endpoint.idle
Resource: fraud-detection-v2 (us-east-1)
Instance: ml.g4dn.xlarge
Idle: 14 days (zero InvocationCount)
Confidence: HIGH
Estimated Cost: ~$504/month

Scanning for idle SageMaker endpoints in CI

# .github/workflows/ai-hygiene.yml
name: AI/ML Waste Detection

on:
  schedule:
    - cron: '0 9 * * MON'  # Weekly

jobs:
  scan:
    runs-on: ubuntu-latest
    permissions:
      id-token: write
      contents: read
    steps:
      - uses: actions/checkout@v4

      - uses: aws-actions/configure-aws-credentials@v4
        with:
          role-to-assume: arn:aws:iam::${{ vars.AWS_ACCOUNT_ID }}:role/CleanCloudCIReadOnly
          aws-region: us-east-1

      - uses: cleancloud-io/scan-action@v1
        with:
          provider: aws
          category: ai
          fail-on-cost: 500
          output: json
          output-file: findings.json

      - name: Report to Slack (optional)
        if: failure()
        uses: slackapi/slack-github-action@v1
        with:
          payload: |
            {
              "text": "SageMaker endpoints detected with idle waste ($500+/month): Check findings.json"
            }

Azure: Idle Machine Learning Compute Clusters

Azure Machine Learning (AML) compute clusters are provisioned clusters that you manage. Unlike serverless options, AML clusters have a minimum node count that stays running even when no training jobs are active.

How the rule works

The azure.ml.compute.idle rule checks:

Cluster has minimum node count > 0
No training jobs submitted in the idle window (default: 14 days)
Cluster is still in "Running" state (not deallocated)

Result: A cluster provisioned for a pilot project that finished months ago is still spinning, still billing.

Cost examples

Cluster Type	Approx. Monthly Cost (Idle)	Confidence
Standard_D2s_v3 (2 CPU, 8GB RAM)	~$60/month	MEDIUM
Standard_NC6_v3 (6 CPU, 1 GPU, 112GB RAM)	~$600/month	HIGH
Standard_ND40rs_v2 (8 GPU, 24 CPU, 948GB RAM)	~$15,000/month	HIGH

Detection in CI

- uses: cleancloud-io/scan-action@v1
  with:
    provider: azure
    category: ai
    fail-on-cost: 500

GCP: Idle Vertex AI Prediction Endpoints

Vertex AI is Google's managed ML platform. Prediction endpoints are always-on infrastructure for real-time model serving. Unlike batch jobs, endpoints don't stop — they keep running and billing even with zero predictions.

How the rule works

The gcp.vertex.prediction.endpoint.idle rule queries Vertex AI metrics for prediction activity over the idle window (default: 14 days). An endpoint with zero or near-zero predictions is flagged. Confidence is HIGH for GPU-backed endpoints.

Cost examples

Instance Type	Approx. Monthly Cost (Idle)	Confidence
n1-standard-4 (CPU)	~$150/month	MEDIUM
nvidia-tesla-k80 (1 GPU)	~$800/month	HIGH
nvidia-tesla-v100 (1 GPU)	~$2,500/month	HIGH
nvidia-tesla-a100 (1 GPU)	~$10,000/month	HIGH

Detection in CI

- uses: cleancloud-io/scan-action@v1
  with:
    provider: gcp
    category: ai
    all-projects: true
    fail-on-cost: 500

Multi-Cloud Detection: A Real Example

One organization ran:

3 idle SageMaker endpoints (ml.g4dn.xlarge) = $1,500/month
1 idle AML cluster (GPU-backed) = $600/month
2 idle Vertex AI endpoints (Tesla K80) = $1,600/month

Total monthly waste: $3,700

Detected by: Single weekly scan across all three clouds

Detecting AI/ML Waste at Scale

Option 1: Weekly scheduled scan (CI-based)

# Runs every Monday at 9am
cleancloud scan --provider aws --category ai --all-regions \
  --provider azure --category ai \
  --provider gcp --category ai --all-projects \
  --fail-on-cost 500 \
  --output json --output-file ai-waste.json

Option 2: Per-deployment scan

Run AI/ML detection before prod deployment to catch new endpoints:

- name: Pre-deploy AI/ML check
  run: |
    cleancloud scan --provider aws --category ai \
      --fail-on-confidence HIGH

Option 3: Policy-as-code enforcement

Suppress intentional AI/ML infrastructure:

# cleancloud.yaml
exceptions:
  - rule_id: aws.sagemaker.endpoint.idle
    resource_id: demo-endpoint-prod
    reason: "Production serving endpoint for customer X"
    expires_at: "2026-12-31"

thresholds:
  fail_on_cost: 500  # CI gate: fail if monthly AI/ML waste > $500

Why This Matters

Data science teams: Spot forgotten endpoints before they blow budgets
Platform teams: Enforce endpoint lifecycle policies automatically
FinOps teams: AI/ML waste visibility in CI/CD, not quarterly surprises
Finance teams: Audit trail of detected waste and enforcement decisions

Getting Started

Step 1: Try the demo

pipx install cleancloud
cleancloud demo --category ai

This shows sample AI/ML waste findings without needing cloud credentials.

Step 2: Scan your cloud

cleancloud scan --provider aws --category ai --all-regions
cleancloud scan --provider azure --category ai
cleancloud scan --provider gcp --category ai --all-projects

Step 3: Add to CI/CD

Copy the workflow example above and commit to .github/workflows/ai-hygiene.yml

Step 4: Use policy-as-code

Add cleancloud.yaml to document which endpoints are intentional (and when they expire).

Next Steps

Learn more:

Full guide: https://www.getcleancloud.com/blog/idle-ai-ml-infrastructure-cost.html
Detection rules: https://github.com/cleancloud-io/cleancloud/blob/main/docs/rules.md
Configuration: https://github.com/cleancloud-io/cleancloud/blob/main/docs/configuration.md
Try it: cleancloud scan --provider aws --category ai --all-regions

GitHub: https://github.com/cleancloud-io/cleancloud

What's your biggest source of AI/ML waste? SageMaker endpoints, AML clusters, or Vertex AI endpoints? Share in the comments.

Originally published on getcleancloud.com

Stop Managing Cloud Exceptions in Spreadsheets — Use Policy-as-Code Instead

Suresh — Wed, 08 Apr 2026 10:07:08 +0000

TL;DR: Cloud exceptions in spreadsheets rot. Policy-as-code puts them in git with automatic expiry dates, git reviews, and cost tracking. Here's how.

Tools like CleanCloud move exceptions into Git with expiry dates, PR reviews, and enforceable cost thresholds.

The Exception Spreadsheet Nobody Trusts

It starts innocently enough. Your team runs a cloud hygiene scan. A bastion host is intentionally stopped. A dev database has been idle for 45 days but is still in use. A NAT gateway with no traffic (seasonal workload). Legitimate exceptions, all of them.

So you create a list.

Three months later:

Nobody knows which exceptions are still valid
Who approved them?
When do they expire?
The spreadsheet hasn't been updated since 2024
You're suppressing the alerts instead of fixing the waste

Stats:

~40% of FinOps exceptions have zero documented expiry
Average exception age before questioned: 6+ months
Typical cost of "forgotten" exceptions: $10-50K+/month

The exceptions spreadsheet is the FinOps equivalent of commenting out a security alert.

The waste is still running.

You've just stopped seeing it.

What If Exceptions Were Code?

This is exactly the problem policy-as-code solves.

Instead of tracking exceptions in spreadsheets or tickets, tools like CleanCloud treat them as version-controlled configuration — living alongside your infrastructure, with built-in expiry, review, and enforcement.

Instead of a spreadsheet, your exceptions live in Git.

cleancloud.yaml (repo root)

# cleancloud.yaml - commit to your repo root

defaults:
  confidence: MEDIUM      # skip low-signal findings
  min_cost: 10            # ignore cheap findings

exceptions:
  - rule_id: aws.ec2.instance.stopped
    resource_id: i-0bastion1234  # bastion host
    reason: "Bastion - started on demand for debugging"
    expires_at: "2026-12-31"      # auto-expires (forces review)

  - rule_id: aws.rds.instance.idle
    resource_id: "db-test-*"      # wildcard (all test databases)
    reason: "Test databases are ephemeral and intentionally idle"

  - rule_id: aws.nat.idle
    resource_id: nat-12345678
    reason: "NAT gateway for seasonal workload (Jan-Mar only)"
    expires_at: "2026-03-31"      # expires after season ends

thresholds:
  fail_on_confidence: HIGH        # CI gate: block on HIGH findings
  fail_on_cost: 500               # CI gate: block if waste > $500/month

Now every exception is:

Reviewable - Show up in pull requests (why is documented)
Auditable - Git history shows who approved what
Self-expiring - No more "forgotten" exceptions (automatic)
Enforceable - CI fails if exceptions are violated
Version-controlled - Treated like infrastructure code (because it is)

How It Works in Practice

1. Run scans with your config

cleancloud scan --provider aws --all-regions
# Automatically picks up cleancloud.yaml from repo root

Without cleancloud.yaml: 47 findings
With cleancloud.yaml: 12 findings (the exceptions are suppressed)

2. Enforce in CI/CD

# .github/workflows/cloud-hygiene.yml
name: Cloud Hygiene Check

on:
  schedule:
    - cron: '0 9 * * MON'  # Weekly scan

jobs:
  scan:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v4

      - name: Scan cloud for waste
        uses: getcleancloud/scan-action@v1
        with:
          provider: aws
          all-regions: true
          fail-on-cost: 500      # Exit code 2 if waste > $500/month

Result: Your build fails if exceptions expire or waste threshold is breached. No surprises.

3. Update exceptions via PR

When your bastion exception expires (2026-12-31), the next scan will fail:

Cloud Hygiene Check: FAILED
  [HIGH] Stopped EC2 instance: i-0bastion1234
  Reason: Exception expired on 2026-12-31

  Action: Remove the exception or update expires_at

Your team reviews the PR, decides whether to renew or delete it. Zero magic. Total visibility.

Real-World Example: Multi-Account Exception

Managing exceptions across your AWS org:

exceptions:
  # Production RDS: kept for failover (intentional)
  - rule_id: aws.rds.instance.idle
    account_id: "123456789012"        # prod account
    region: us-east-1
    resource_id: db-failover
    reason: "Standby RDS in active-passive setup"
    expires_at: "2027-03-31"          # annual review date

  # Staging: ephemeral, safe to ignore
  - rule_id: aws.rds.instance.idle
    account_id: "210987654321"        # staging account
    resource_id: "db-*"               # glob pattern
    reason: "Staging databases are ephemeral"
    # No expires_at = permanent exception (reviewed manually)

The Policy-as-Code Difference

Approach	Exceptions	Audit Trail	Expiry	Cost
Spreadsheet	Unstructured	Slack message	Manual	Free (but $50K waste)
Ticketing	In Jira	Comments	Forgotten	Free (but lost time)
UI Toggle	In vendor SaaS	Dashboard logs	No	Vendor cost
Policy-as-Code	In git	Full history	Automatic	Free (and tighter control)

Getting Started (5 Minutes)

Step 1: Try it without exceptions

pipx install cleancloud
cleancloud demo                    # See sample findings

Step 2: Add a config file

Create cleancloud.yaml in your repo root (the YAML above).

Step 3: Scan with your config

cleancloud scan --provider aws --all-regions
# Now suppresses the exceptions listed in cleancloud.yaml

Step 4: Commit to git

git add cleancloud.yaml
git commit -m "Add cloud hygiene exceptions with expiry dates"
git push

Your exceptions are now:

Version-controlled
Code-reviewed
Automatically expiring
Auditable

Why This Matters for Your Team

Platform teams: Enforce waste thresholds across departments without manual hunting
FinOps teams: Audit trail + expiry dates = zero "forgotten" waste
DevOps/SREs: Exceptions treated like infrastructure code (belong in git)
Security/Compliance: Every exception is a documented, reviewable approval

Next Steps

Learn more:

Full guide: https://www.getcleancloud.com/blog/policy-as-code-cloud-governance.html
Configuration reference: https://github.com/cleancloud-io/cleancloud/blob/main/docs/configuration.md
Try it: cleancloud demo --category ai (also detects idle AI/ML waste)

GitHub: https://github.com/cleancloud-io/cleancloud

What's your current approach to managing exceptions? Spreadsheets, Jira, or something else? Drop a comment below.

Originally published on getcleancloud.com

CleanCloud v0.4.0: How We Made Cloud Hygiene Scanning 10x Faster

Suresh — Fri, 02 Jan 2026 06:15:44 +0000

I just shipped CleanCloud v0.4.0 with major performance improvements through parallel scanning. Here's how we did it.

What's CleanCloud?

If you missed the original announcement, CleanCloud is a read-only CLI tool that scans AWS/Azure for orphaned resources (unattached volumes, old snapshots, infinite CloudWatch log retention).

Unlike aggressive cleanup tools, CleanCloud gives you conservative signals so you can review before taking action. No auto-delete, no risk.

The Performance Problem

v0.3.x had a bottleneck: sequential scanning.

# Old approach (v0.3.x)
findings = []
for region in regions_to_scan:
    click.echo(f"🔍 Scanning region {region}")
    findings.extend(_scan_aws_region(profile, region))

Result: Each region scanned one at a time. For accounts with resources in multiple regions, this added up quickly.

The Solution: Parallel Scanning

v0.4.0 introduces concurrent scanning at two levels:

1. Parallel Region Scanning

# New approach (v0.4.0)
from concurrent.futures import ThreadPoolExecutor, as_completed

def scan_aws_regions(profile: Optional[str], regions_to_scan: List[str]) -> List[Finding]:
    findings = []

    with ThreadPoolExecutor(max_workers=min(5, len(regions_to_scan))) as executor:
        futures = {
            executor.submit(_scan_aws_region, profile, region): region 
            for region in regions_to_scan
        }

        for future in as_completed(futures):
            region = futures[future]
            click.echo(f"✅ Completed region {region}")
            findings.extend(future.result())

    return findings

Key decisions:

max_workers=min(5, len(regions_to_scan)) - Limits parallelism to avoid rate limits
as_completed() - Shows progress as regions complete
Thread-safe result collection

2. Parallel Rule Execution

Within each region, we also parallelized individual rules:

AWS_RULES = [
    find_unattached_ebs_volumes,
    find_old_ebs_snapshots,
    find_inactive_cloudwatch_logs,
    find_aws_untagged_resources,
]

def _scan_aws_region(profile: Optional[str], region: str) -> List[Finding]:
    session = create_aws_session(profile=profile, region=region)
    findings = []

    with ThreadPoolExecutor(max_workers=min(4, len(AWS_RULES))) as executor:
        futures = [executor.submit(rule, session, region) for rule in AWS_RULES]

        for future in as_completed(futures):
            try:
                rule_findings = future.result()
                findings.extend(rule_findings)
            except Exception as e:
                # Never fail entire scan due to one rule
                click.echo(f"⚠️ Rule failed in {region}: {e}")

    return findings

Benefits:

All 4 rules run concurrently per region
Exception isolation (one failing rule doesn't break the scan)
Better resource utilization

Performance Improvements

Real-world results from testing:

Single region scan:

Before: ~20-25 seconds
After: ~15-18 seconds
Improvement: ~30% faster

Multi-region scan (5 regions):

Before: ~100-120 seconds (sequential)
After: ~20-25 seconds (parallel)
Improvement: ~5x faster

The key insight: The more regions you scan, the bigger the improvement. Parallel execution shines when there's actual work to parallelize.

Azure Gets the Same Treatment

Azure subscriptions are now scanned in parallel too:

def scan_azure_subscriptions(
    subscription_ids: List[str],
    credential,
    region_filter: Optional[str],
) -> List[Finding]:
    all_findings = []

    with ThreadPoolExecutor(max_workers=min(4, len(subscription_ids))) as executor:
        futures = {
            executor.submit(
                _scan_azure_subscription,
                subscription_id=sub_id,
                credential=credential,
                region_filter=region_filter,
            ): sub_id
            for sub_id in subscription_ids
        }

        for future in as_completed(futures):
            sub_id = futures[future]
            click.echo(f"✅ Completed subscription {sub_id}")
            try:
                all_findings.extend(future.result())
            except Exception as e:
                click.echo(f"⚠️ Subscription {sub_id} failed: {e}")

    return all_findings

Same benefits for Azure users with multiple subscriptions.

Other v0.4.0 Improvements

🔒 Safety Integration Tests

We now have automated tests that verify CleanCloud's read-only guarantees:

def test_scan_is_read_only():
    """Ensure no write operations during scan."""
    # Run full scan
    scan_result = scan_all_regions()

    # Check CloudTrail for write operations
    cloudtrail_events = get_recent_events()
    write_events = [e for e in cloudtrail_events 
                    if e['EventName'] not in READ_ONLY_OPERATIONS]

    # Fail if ANY writes detected
    assert len(write_events) == 0, f"Write operations detected: {write_events}"

These run in CI on every PR against real AWS/Azure accounts. If CleanCloud ever tries to write, the build fails.

Why this matters: You can trust that CleanCloud is truly read-only, not just claiming to be.

🩺 Enhanced Doctor Command

The cleancloud doctor command now provides actionable IAM diagnostics:

cleancloud doctor --provider aws

# Before (v0.3.x):
❌ Permission denied

# After (v0.4.0):
❌ Missing IAM permission: ec2:DescribeVolumes

Suggested IAM policy:
{
  "Version": "2012-10-17",
  "Statement": [{
    "Effect": "Allow",
    "Action": ["ec2:DescribeVolumes"],
    "Resource": "*"
  }]
}

Much more helpful for debugging permission issues.

📊 Post-Scan Feedback

After each scan, you'll see a feedback prompt (disabled in CI/CD with --no-feedback):

--- Scan Summary ---
Total findings: 23

CleanCloud feedback
-------------------
If this scan surfaced useful findings, we'd love to hear about it.

Share feedback: https://github.com/cleancloud-io/cleancloud/discussions

This helps us improve detection rules based on real user feedback.

Real-World Impact

Since launch, CleanCloud users have reported finding:

💰 Cost Savings:

$8K-12K/year in forgotten CloudWatch logs (infinite retention)
$500-2K/year in unattached EBS volumes
$300-1K/year in old snapshots

🎯 Common Findings:

50-100 unattached volumes per account
100-300 old snapshots from deleted instances
20-50 log groups with infinite retention

⏱️ Time to Value:

Scan time: 20-30 seconds (v0.4.0)
Review time: 5-10 minutes
First cleanup: Same day
ROI: Immediate

Installation & Usage

# Install
pip install cleancloud

# Scan all active AWS regions (auto-detects which have resources)
cleancloud scan --provider aws --all-regions

# Check IAM permissions
cleancloud doctor --provider aws

# Scan specific region
cleancloud scan --provider aws --region us-east-1

# Scan Azure
cleancloud scan --provider azure

Example output:

🔍 Starting CleanCloud scan...

Provider: aws

🔍 Auto-detecting regions with resources...
✓ Found 3 active regions: us-east-1, us-west-2, eu-west-1

✅ Completed region us-east-1
✅ Completed region us-west-2
✅ Completed region eu-west-1

--- Scan Summary ---
Total findings: 47
By confidence: {'HIGH': 12, 'MEDIUM': 23, 'LOW': 12}
Regions scanned: us-east-1, us-west-2, eu-west-1

Technical Deep Dive: Threading Challenges

Building the parallel scanning wasn't trivial. Here are some challenges we hit:

1. Thread Safety with boto3

boto3 clients are not thread-safe. We had to create separate sessions per thread:

def _scan_aws_region(profile: Optional[str], region: str) -> List[Finding]:
    # Create NEW session per thread
    session = create_aws_session(profile=profile, region=region)

    # Now safe to use in this thread
    findings = []
    # ... scanning logic
    return findings

Lesson: Never share boto3 clients across threads. Create new sessions per worker.

2. Rate Limiting

Running 5 regions in parallel meant more concurrent API calls. We had to be smart about worker limits:

# Limit parallelism to avoid throttling
max_workers = min(5, len(regions_to_scan))  # Cap at 5 workers

Also: boto3's built-in retry logic with adaptive mode handles most throttling gracefully.

3. Error Isolation

One region failing shouldn't kill the entire scan:

for future in as_completed(futures):
    try:
        rule_findings = future.result()
        findings.extend(rule_findings)
    except Exception as e:
        # Log error but continue
        click.echo(f"⚠️ Rule failed: {e}")

Result: Partial results if some regions fail. Trust-first means never failing the entire scan.

4. Progress Feedback

Users need to know what's happening during parallel scans:

for future in as_completed(futures):
    region = futures[future]
    click.echo(f"✅ Completed region {region}")

Better UX: Show progress as regions complete, not just at the end.

What's Next

Roadmap for v0.5.0:

🌐 GCP support - Extend beyond AWS/Azure
⚙️ Configurable thresholds - Adjust age/confidence per environment
💵 Cost calculations - Show potential savings in dollars
🔗 CI/CD templates - GitHub Actions, GitLab CI examples
📊 JSON export improvements - Better integration with other tools

Want to contribute? We welcome PRs! Check out the issues.

Why Open Source?

CleanCloud is MIT licensed with:

✅ Zero telemetry
✅ No phone-home
✅ No tracking
✅ All code visible

Why?

Trust is critical for cloud security tools. Open source means you can verify CleanCloud is truly read-only. No need to trust my promises - read the code.

Plus: Building in public creates better software through community feedback.

Try It Out

pip install cleancloud
cleancloud scan --provider aws --all-regions

Links:

📦 PyPI: https://pypi.org/project/cleancloud
💻 GitHub: https://github.com/cleancloud-io/cleancloud
📖 Docs: https://github.com/cleancloud-io/cleancloud#readme

Feedback Welcome!

What cloud hygiene checks would be useful? What other resources should CleanCloud scan?

Drop a comment or open an issue on GitHub. Would love to hear what you find! 🚀

I built a read-only AWS/Azure hygiene scanner (because auto-delete is too risky)

Suresh — Tue, 30 Dec 2025 08:08:51 +0000

After getting burned by an auto-cleanup tool that deleted a "test" database (it wasn't a test), I built CleanCloud.

The Problem

Modern cloud environments are messy:

Teams spin up resources constantly
Deployments create and destroy infrastructure
Resources get orphaned when instances are terminated
Nobody knows what's safe to delete

Most cloud hygiene tools fall into two camps:

Auto-delete everything → Too dangerous for production
Flag everything → Too noisy to be useful

Both approaches fail when you have:

Elastic infrastructure (autoscaling, spot instances)
Multiple teams with different ownership
Resources that look unused but are actually important

Why Auto-Delete Fails

I learned this the hard way.

A "smart" cleanup tool we tried:

Saw a database with no connections for 7 days
Assumed it was orphaned
Deleted it automatically
Turned out it was a quarterly reporting database

Cost of that mistake: 3 days of recovery, angry CFO, lost trust in automation.

The blast radius of deleting the wrong resource is orders of magnitude higher than leaving it running for a few more weeks.

CleanCloud's Approach: Signal First, Act Later

Instead of automating cleanup, CleanCloud answers a safer question:

"Which resources deserve human review — and how confident are we?"

Core principles:

1. Read-Only Always

# Required AWS permissions - notice no Delete* or Modify*
{
  "Action": [
    "ec2:DescribeVolumes",
    "ec2:DescribeSnapshots",
    "logs:DescribeLogGroups",
    "s3:ListAllMyBuckets"
  ]
}

No write permissions. Ever. Safe to run in production.

2. Conservative Signals

Not just "is this unattached?" but:

How long has it been unattached? (14+ days = HIGH confidence)
Multiple signals required (age + state + tags)
Explicit confidence levels: LOW, MEDIUM, HIGH

Example:

🔴 HIGH confidence: Volume unattached for 45 days
🟡 MEDIUM confidence: Volume unattached for 10 days  
🟢 LOW confidence: Volume unattached for 3 days (probably autoscaling)

3. Review-Only Recommendations

CleanCloud never says "delete this." It says:

"This volume has been unattached for 45 days, has no tags, and doesn't match any known deployment patterns. Worth reviewing."

Humans make the final call.

What It Detects

AWS Rules (4 currently)

Unattached EBS volumes (14+ days = HIGH confidence)
Old snapshots (365+ days = HIGH confidence)
CloudWatch logs with infinite retention (30+ days = HIGH confidence)
Untagged resources (ownership unclear = MEDIUM confidence)

Azure Rules (4 currently)

Unattached managed disks (14+ days = HIGH confidence)
Old snapshots (90+ days = HIGH confidence)
Unused public IPs (immediate = HIGH confidence)
Untagged resources (MEDIUM confidence)

Week 1 Results

Released last week. Here's what happened:

Stats:

300+ downloads (170 real users, rest are PyPI mirrors)
0 production incidents (because read-only!)
Most common finding: 15-30 unattached EBS volumes per AWS account

User feedback themes:

"Finally, a tool I can trust in production"
"Found $2K/month in waste in first scan"
"Love that it explains WHY something was flagged"

Quick Start

# Install
pip install cleancloud

# Validate credentials
cleancloud doctor --provider aws

# Scan single region
cleancloud scan --provider aws --region us-east-1

# Scan all active regions
cleancloud scan --provider aws --all-regions

# Output to JSON
cleancloud scan \
  --provider aws \
  --all-regions \
  --output json \
  --output-file results.json

Example Output

$ cleancloud scan --provider aws --region us-east-1

🔍 Scanning region us-east-1

Found 12 findings:
  HIGH confidence: 8
  MEDIUM confidence: 4

Top findings:
  • vol-0abc123 - Unattached volume (45 days, 100GB) - ~$10/mo
  • snap-0def456 - Old snapshot (120 days, 500GB) - ~$25/mo
  • log-group-xyz - Infinite retention (2.1GB stored) - ~$6/mo

💰 Estimated monthly waste: ~$156

Review findings and decide what to delete.

CI/CD Integration

Built for pipelines with predictable exit codes:

# GitHub Actions example
- name: Run hygiene scan
  run: |
    pip install cleancloud
    cleancloud scan \
      --provider aws \
      --all-regions \
      --fail-on-confidence HIGH

Exit codes:

0 = Success (no policy violations)
1 = Configuration error
2 = Policy violation (findings detected)
3 = Missing credentials

Use cases:

Block PRs with HIGH confidence findings
Generate weekly hygiene reports
Enforce tagging standards
Prevent resource leaks in development

Authentication: OIDC First

No long-lived credentials needed:

AWS (GitHub Actions)

- name: Configure AWS credentials (OIDC)
  uses: aws-actions/configure-aws-credentials@v4
  with:
    role-to-assume: arn:aws:iam::ACCOUNT:role/CleanCloudReadOnly
    aws-region: us-east-1

- name: Scan
  run: cleancloud scan --provider aws

Azure (GitHub Actions)

- name: Azure Login (OIDC)
  uses: azure/login@v2
  with:
    client-id: ${{ secrets.AZURE_CLIENT_ID }}
    tenant-id: ${{ secrets.AZURE_TENANT_ID }}
    subscription-id: ${{ secrets.AZURE_SUBSCRIPTION_ID }}

- name: Scan
  run: cleancloud scan --provider azure

No AWS_SECRET_ACCESS_KEY or AZURE_CLIENT_SECRET needed. ✅

What CleanCloud is NOT

Not a cost optimization tool

Doesn't access billing data
Doesn't recommend rightsizing
Focuses on hygiene, not savings

Not a FinOps platform

No dashboards
No cost tracking
Just clean signals

Not an auto-remediation service

Will never delete anything
Will never modify resources
Will never tag resources

This is a strategic design choice, not a limitation.

Privacy & Telemetry

CleanCloud collects zero telemetry.

No analytics. No tracking. No phone-home.

Why?

Security tools shouldn't send data anywhere
Works in air-gapped environments
No opt-out flags needed
Zero risk of leaking account info

We improve based on:

GitHub issues
Direct feedback
Community contributions

What's Next

v0.3.1 just shipped with:

Complete documentation overhaul
Smarter AWS region auto-detection
Enhanced diagnostics with security grading
Fixed region detection bugs

Coming soon:

GCP support
Additional rules (unused Elastic IPs, old AMIs)
Rule filtering (--rules flag)
Historical tracking

Not planned:

Automated cleanup
Cost optimization
Billing data access

CleanCloud will remain focused on safe hygiene detection, not automation.

Design Philosophy

Three core principles:

1. Conservative by Default

Age-based confidence thresholds
Multiple signals required
Prefer false negatives over false positives

2. Read-Only Always

No Delete* permissions
No Tag* permissions
No modification APIs
Safe for production

3. Review-Only Recommendations

Findings are candidates for review, not automated action
Clear reasoning for each finding
Humans stay in control

Who Is This For?

Primary users:

SRE teams
Platform engineers
Infrastructure teams

Stakeholders:

Security (read-only = passes security reviews)
Compliance (SOC2/ISO27001 friendly)
FinOps (identifies waste without aggressive optimization)

Not for:

Teams wanting auto-cleanup
Cost optimization as primary goal
Aggressive savings recommendations

Real Talk: Why I Built This

I've seen too many "smart" automation tools cause outages:

Auto-scaler that scaled to zero during a traffic spike
Cleanup tool that deleted "unused" security groups (broke production)
Cost optimizer that downsized a database (performance disaster)

The pattern: Automation is confident. Humans are cautious. Production requires caution.

CleanCloud is designed for teams who value trust over automation.

Try It

GitHub: https://github.com/cleancloud-io/cleancloud

Install: pip install cleancloud

Docs: Complete setup guides for AWS and Azure

Looking for feedback:

What cloud hygiene tools do you currently use?
Would read-only signals be useful for your team?
What features would make this production-ready for you?

Open source, MIT license. Contributions welcome!

If you found this useful:

⭐ Star the repo
💬 Share your cloud hygiene horror stories in the comments
🐛 Report issues or suggest features

Built for SRE teams who value trust over automation.