一切始于一条账单提醒。

AWS 账单提醒邮件：我的 BillingAlertAbove250 告警显示预估费用 252.61 美元已超过 250 美元阈值

预估费用已超过 250 美元。金额不算惊人，但足以让我查看一番。真正引起我注意的并不是这个数字，而是这条提醒本身。我显然在某个时候设置过这个告警，而且阈值感觉已经过时了。

于是我开始寻找这条提醒的位置。

它来自我 2014 年创建、早已完全忘记的 BillingAlerts CloudFormation 堆栈。所以，一个我已遗忘的东西正在警告我其他所有我遗忘的东西。

我打开堆栈列表，发现它并不孤单。它位于一排堆栈之中，而我对其中一半都不认识。这是多年积累的遗留物，就这么静静地待在那里。

你遗忘的东西不会破坏任何东西。它不会在凌晨两点呼叫你。它只是静静地待在那里，悄无声息地产生费用，直到你查看发票时发现自己对其中一半都不知道是做什么的。遗忘的、仍在运行的资源是造成云支出浪费的最大来源之一，据一些估计，约占平均云预算的四分之一。

我本想更新一条提醒，却发现了一团乱麻。

需要明确的是，这些堆栈实际上并没有花费我太多钱。已停止的实例，一些半删除的遗留物。如果它们产生了那 252 美元，提醒应该每个月都会触发。但这就是问题的关键。在清理掉杂乱之前，你无法判断哪些资源真正产生了费用。

所以提醒可以等等。我想先清理掉这些陈旧的堆栈。

通常这是一项杂务。打开控制台，找到每个堆栈，点击删除，等待，刷新，检查是否成功，或者写出 CLI 命令。这并不难，只是繁琐。这是我一直拖延的任务类型。

而这正是事情的开始。通过控制台进行 ClickOps。我刚刚手动删除了孟买区域的一个旧 Directory Service 目录，点击通过各个屏幕并等待加载动画，这时我突然意识到。手动点击才花了不到十分钟，而我还有一堆堆栈要处理。我不必自己做这些。

我为什么还在点击？

我打开了 Kiro，它带有 AWS Agent Toolkit，然后直接描述了我想要什么。我在博客中谈到了我是如何设置它的：我切换到了 AWS Agent Toolkit。原因如下。

没有控制台。没有 CLI。我与 Agent 聊天，让它处理其余的事情。就像一个好助手！

如果你已安装 AWS CLI，只需运行：

aws configure agent-toolkit

进入全屏模式 退出全屏模式

首先，展示有什么

我首先要求 Agent 列出我所在区域的 CloudFormation 堆栈。

Kiro 聊天界面，Agent 列出了我所在区域的 12 个 CloudFormation 堆栈，显示每个堆栈的名称和状态

它返回了 12 个堆栈。有些我认识，有些很古老，一个 2014 年的账单提醒堆栈，几个 2021 年的修补和合规堆栈，以及 CDK 引导工具包。然后是我真正想要删除的那些。

我挑选了四个堆栈并告诉 Agent 删除它们。

它在删除前询问

这很重要，所以我想先强调一下。

Agent 列出了它即将删除的四个堆栈并要求我确认，警告删除资源后无法轻易撤销

Agent 并没有在我提出请求后立即开始删除。在运行任何操作之前，它将四个堆栈列给我，明确告诉我这将删除它们的所有资源且无法轻易撤销，并要求我确认。

删除基础设施是不可逆的。

我说可以，然后它开始执行。

Agent 确认四个堆栈的删除请求已提交

我获得了“直接处理”的速度，同时也没有放弃对破坏性操作的检查点。

它以代码方式检查结果，无需每秒刷新控制台

删除请求提交后，Agent 编写了一个脚本并在工具包的沙箱中运行，以同时检查所有四个堆栈的状态。

Agent 在工具包沙箱中编写并运行的 Python 脚本，使用 boto3 并行检查所有四个堆栈的删除状态

它并行检查了所有四个堆栈，处理了堆栈可能已经删除的情况，并返回了一个清晰的状态映射。所有这些都在带有 boto3 的远程沙箱中运行。我的机器从未执行过任何操作。

三个堆栈干净地删除了，但有一个拒绝删除。

状态结果显示三个堆栈已干净删除，而 aws-sam-cli-managed-default 返回 DELETE_FAILED

第四个堆栈 aws-sam-cli-managed-default 返回了 DELETE_FAILED。

于是，Agent 拉取了堆栈事件来找出原因。失败指向一个资源，即 SAM 用于部署构件的 S3 存储桶 (SamCliSourceBucket)。消息很具体：

您尝试删除的存储桶不为空。您必须删除存储桶中的所有版本。

这个存储桶启用了版本控制。所以“清空存储桶”是不够的。每个对象版本和每个删除标记都必须删除，否则 CloudFormation 仍然无法删除存储桶。这就是为什么在控制台中快速“清空”有时无法解决问题的原因。

Agent 解释了原因，然后提出正确清空存储桶并重试。我同意了。

整个绕道——记住版本化存储桶的陷阱，查找存储桶名称，意识到删除标记也算数，手动清空它，然后返回重试——这是我通常需要自己慢慢处理的部分。Agent 将失败的删除与满的存储桶联系起来并处理了它。

Agent 清空版本化 S3 存储桶，删除每个对象版本和删除标记，然后重试堆栈删除，因此所有四个堆栈都已删除

所有四个都已删除。

为什么这感觉不同

让我明确说明这里实际改变了什么，因为“我使用 AI 删除了一些堆栈”不是重点。

重点是整个循环都保持在一个地方。我用简单的语言描述了目标。Agent 列出了我账户的真实状态，确认了破坏性步骤，运行代码执行操作，然后在没有我翻阅文档的情况下调试并修复了出现问题的部分。

有几件事使这成为可能：

它安全地运行了真实代码。 工具包为 Agent 提供了一个带有 boto3 的沙箱 Python 运行时。它可以用几行代码检查状态、过滤和执行操作，而无需在我的笔记本电脑上运行任何东西。

它确认了风险部分。 删除是单向的。Agent 这样对待它们，并首先与我确认。

它端到端处理了故障。 控制台不会让我卡在这里。在 DELETE_FAILED 时，它会弹出并让我重试，要么保留存储桶（在我的账户中孤立它），要么跳转到 S3 控制台自己清空它。两者都是上下文切换，而“保留”只是把存储桶留在后面。Agent 跳过了所有这些。它读取了堆栈事件，找到了版本化存储桶，正确清空了它（版本和删除标记），然后重试，而我没有离开聊天或孤立任何东西。

一切都是可审计的。 因为所有这些都通过托管的 AWS MCP Server，每个调用都会记录在 CloudTrail 中。接下来会详细介绍。

我可以在 CloudTrail 中看到每个调用

这是将“我让 Agent 删除我的基础设施”从可怕变成可以接受的部分。

Agent 采取的每个操作都通过托管的 AWS MCP Server，每个调用都会显示在 CloudTrail 中。我去查看了。所有四个 DeleteStack 事件都在我的身份下清晰可见，它们带有清晰的指纹：

eventName:        DeleteStack
userIdentity:     gaonkarr
sourceIPAddress:  aws-mcp.amazonaws.com
userAgent:        aws-mcp.amazonaws.com

进入全屏模式 退出全屏模式

aws-mcp.amazonaws.com 值是区分 Agent 操作与你自己操作的方式。当天早些时候，我在控制台手动删除了一些堆栈，那些事件看起来完全不同：真实的浏览器用户代理和我实际的 IP 地址。所以审计跟踪显示了谁真正做了什么，我的点击与代表我行事的 Agent。

以下是这次清理中的五个 DeleteStack 事件，直接来自 CloudTrail：

时间 (UTC) 堆栈 身份 源 IP 用户代理
14:23:18 CdkPipelineStack gaonkarr aws-mcp.amazonaws.com aws-mcp.amazonaws.com
14:23:18 buildon-sam-app gaonkarr aws-mcp.amazonaws.com aws-mcp.amazonaws.com
14:23:18 aws-sam-cli-managed-default (第一次尝试) gaonkarr aws-mcp.amazonaws.com aws-mcp.amazonaws.com
14:23:19 sam-app gaonkarr aws-mcp.amazonaws.com aws-mcp.amazonaws.com
14:24:19 aws-sam-cli-managed-default (重试) gaonkarr aws-mcp.amazonaws.com aws-mcp.amazonaws.com

重试在跟踪中清晰可见。aws-sam-cli-managed-default 删除显示了两次：一次失败时，以及大约一分钟后 Agent 在清空存储桶后重试时。整个失败然后修复的序列都被保留了。

一个值得知道的诚实警告：DeleteStack 调用是管理事件，CloudTrail 默认记录这些。但实际清空存储桶的 S3 DeleteObjects 调用是数据事件，除非你为该存储桶启用了数据事件日志记录，否则这些不会被记录。所以我可以清楚地看到堆栈删除，但看不到单个对象的删除。如果你想要跟踪中的对象级操作，必须先启用 S3 数据事件。

我接下来要做什么

删除四个堆栈感觉不错。所以我好奇地问了 Agent：

你能扫描我的 AWS 账户并识别任何遗留资源吗？

Agent 扫描常见 AWS 服务以查找遗留资源，首先在默认区域，然后扩展到其他区域

它扫描了我账户中的常见服务。首先是默认区域，然后扩展到其他区域。4 页多的列表。🫣

它发现了大量来自研讨会、演示和旧项目的遗留资源，并给了我一个成本影响摘要。

  • 3 个已停止的 EC2 实例，最早的一个来自 2021 年。

  • 14 个未附加的 EBS 卷，有些创建于 2014 年，仍然在悄无声息地为不附加任何东西的存储计费。

  • 5 个未关联的弹性 IP，大约每月 18 美元用于不做任何工作的地址。

  • 122 个 S3 存储桶，一个我忘记的负载均衡器，16 个 Lambda 函数都在多年前已达到生命周期的运行时上。

没有破坏任何东西。这正是它能存活这么久的原因。

Agent 的成本影响摘要列出了遗留资源：已停止的 EC2 实例，未附加的 EBS 卷，未关联的弹性 IP，S3 存储桶，负载均衡器和旧 Lambda 函数

找到所有这些通常是最困难的部分。点击每个服务，在每个区域，一个控制台接一个控制台，这是我从未做这件事的原因。这是删除任何东西之前数小时的繁琐工作。这次我只问了一次，Agent 就把整个列表交给了我。

这个总是感觉太大而无法开始的任务现在变成了简单的部分。

所以我将借助我的新助手清理它。

如果你的账户和我的一样，它也应该成为你的助手。

告诉我你在里面发现了什么。我敢打赌我不是唯一一个忘记它的人。

关注