我构建了一个只读的 AWS/Azure 健康检查扫描器（因为自动删除风险太大）

发布: 1周前 (2025年12月30日 GMT+8 16:08)

10 min read

原文: Dev.to

Source: Dev.to

问题

现代云环境很混乱：

团队不断启动资源
部署会创建和销毁基础设施
实例终止后资源会变成孤儿
没有人知道哪些可以安全删除

大多数云卫生工具分为两类：

自动删除所有 → 对生产环境风险太大
标记所有 → 噪声太大，无法使用

当出现以下情况时，两种方法都会失效：

弹性基础设施（自动伸缩、抢占式实例）
多个团队拥有不同的所有权
看似未使用但实际上很重要的资源

为什么自动删除会失败

我是吃了苦头才学到的。

我们尝试的一个“智能”清理工具：

看到一个数据库已有 7 天没有连接
认为它是孤立的
自动删除了它
结果发现它是一个季度报告数据库

这个错误的代价： 3 天的恢复时间，愤怒的 CFO，失去对自动化的信任。

错误删除资源的影响范围 高出数个数量级，远远超过让它再运行几周的风险。

Source: …

CleanCloud 的方法：先信号，后行动

与其自动化清理，CleanCloud 回答一个更安全的问题：

“哪些资源值得人工审查——我们有多大的信心？”

核心原则

始终只读

// 必需的 AWS 权限 – 注意没有 Delete* 或 Modify*
{
  "Action": [
    "ec2:DescribeVolumes",
    "ec2:DescribeSnapshots",
    "logs:DescribeLogGroups",
    "s3:ListAllMyBuckets"
  ]
}

没有写入权限。永远如此。可安全在生产环境运行。

保守的信号

不仅仅是“是否未挂载？”而是：
- 未挂载多久了？（14 + 天 = 高置信度）
- 需要多个信号（年龄 + 状态 + 标签）
- 明确的置信度等级：低、中、高
示例：
```
🔴 高置信度:   卷已未挂载 45 天
🟡 中置信度: 卷已未挂载 10 天
🟢 低置信度:   卷已未挂载 3 天（可能是自动伸缩产生的）
```
仅供审查的建议

CleanCloud 从不说“删除它”。它会说：

“此卷已未挂载 45 天，没有标签，也不符合任何已知的部署模式。值得审查。”

最终决定由人工做出。

检测内容

AWS 规则（当前 4 条）

未挂载的 EBS 卷（14 天以上 = 高）
旧快照（365 天以上 = 高）
保留期限无限的 CloudWatch 日志（30 天以上 = 高）
未打标签的资源（所有权不明确 = 中）

Azure 规则（当前 4 条）

未挂载的托管磁盘（14 天以上 = 高）
旧快照（90 天以上 = 高）
未使用的公共 IP（立即 = 高）
未打标签的资源（中）

第1周结果

Released last week. Here’s what happened:

统计

300 + downloads (≈170 real users, rest are PyPI mirrors) → 300 + 次下载（≈170 位真实用户，其余为 PyPI 镜像）
0 production incidents (because it’s read‑only) → 0 起生产事故（因为它是只读的）
Most common finding: 15‑30 unattached EBS volumes per AWS account → 最常见的发现：每个 AWS 账户有 15‑30 个未附加的 EBS 卷

用户反馈主题

“Finally, a tool I can trust in production” → “终于有了一个我可以在生产环境中信任的工具”
“Found $2K/month in waste in first scan” → “首次扫描就发现每月 2 K 美元的浪费”
“Love that it explains WHY something was flagged” → “喜欢它解释了 WHY 某些内容被标记”

快速开始

# 安装
pip install cleancloud

# 验证凭证
cleancloud doctor --provider aws

# 扫描单个区域
cleancloud scan --provider aws --region us-east-1

# 扫描所有活跃区域
cleancloud scan --provider aws --all-regions

# 输出为 JSON
cleancloud scan \
  --provider aws \
  --all-regions \
  --output json \
  --output-file results.json

快速开始（Azure）

- name: Set up Azure credentials
  uses: azure/login@v1
  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

无需 AWS_SECRET_ACCESS_KEY 或 AZURE_CLIENT_SECRET。✅

示例输出

$ 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, 100 GB) – ~$10/mo
  • snap-0def456 – Old snapshot (120 days, 500 GB) – ~$25/mo
  • log-group-xyz – Infinite retention (2.1 GB stored) – ~$6/mo

💰 Estimated monthly waste: ~$156

Review findings and decide what to delete.

CI/CD 集成

为具有可预测退出码的流水线而构建：

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

退出码

代码	含义
0	成功（无策略违规）
1	配置错误
2	策略违规（检测到问题）
3	缺少凭证

使用场景

阻止包含 HIGH 置信度问题的 PR
生成每周卫生报告
强制执行标签标准
防止开发环境中的资源泄漏

身份验证：首选 OIDC

不需要长期凭证。

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

什么不是 CleanCloud

不是成本优化工具

不访问计费数据
不推荐资源规模调整
专注于卫生，而非节省

不是 FinOps 平台

没有仪表盘
没有成本跟踪

不是自动修复服务

永不删除任何内容
永不修改资源
永不标记资源

这是一项 战略设计选择，而非限制。

隐私与遥测

CleanCloud 不收集任何遥测。
无分析。无跟踪。无回传。

为什么？

安全工具不应将数据发送到任何地方
可在空气隔离环境中运行
无需选择退出标志
零泄露账户信息的风险

改进来源于：

GitHub 问题
直接反馈
社区贡献

接下来

v0.3.1（刚发布）

完整的文档重构
更智能的 AWS 区域自动检测
增强的诊断功能并加入安全评级
修复了区域检测的错误

即将推出

支持 GCP
额外规则（未使用的 Elastic IP、旧 AMI）
规则过滤（--rules 标志）
历史追踪

未计划

自动清理
成本优化
账单数据访问

CleanCloud 将继续专注于 安全卫生检测，而非自动化。

设计理念

默认保守
- 基于年龄的置信阈值
- 需要多个信号
- 更倾向于假阴性而非假阳性
始终只读
- 没有 Delete* 权限
- 没有 Tag* 权限
- 没有修改 API
仅审查建议
- 发现仅作为审查候选，而非自动化操作
- 为每个发现提供清晰的理由
- 人类保持控制

谁适合？

主要用户

SRE 团队
平台工程师
基础设施团队

利益相关者

安全（只读 = 通过安全审查）
合规（SOC2/ISO27001 友好）
FinOps（在不进行激进优化的情况下识别浪费）

不适用

想要自动清理的团队
将成本优化作为主要目标
激进的节省建议

真话：我为何构建它

我见过太多“智能”自动化工具导致宕机：

自动扩容器在流量激增时把实例缩容到 0
清理工具误删“未使用”的安全组（导致生产环境中断）
成本优化器把数据库降配（性能灾难）

模式： 自动化自信，人工谨慎。生产环境需要谨慎。

CleanCloud 旨在为 重视信任胜于自动化的团队 而设计。

试一试

征求反馈

您目前使用哪些云卫生工具？
只读信号对您的团队有用吗？
哪些功能能让它达到生产就绪的水平？

开源，MIT 许可证。欢迎贡献！

如果您觉得有用

⭐ 给仓库加星
💬 在评论中分享您的云卫生恐怖故事
🐛 报告问题或提出功能建议

为重视信任胜于自动化的 SRE 团队打造。

问题