AWS MCP Server 新增 Lambda 诊断能力：一次调用查清跨服务故障

AWS MCP Server 新增 serverless 诊断能力，让 Claude Code 和 Kiro 等 coding agent 一次调用即可诊断 Lambda 函数的跨服务故障。

AWS MCP Server 新增 Lambda 诊断能力：一次调用查清跨服务故障

AWS MCP Server 新增了 serverless capability，让 Claude Code、Amazon Kiro 等支持 MCP 的 coding agent 能直接诊断 Lambda 函数问题，一次调用覆盖 API Gateway、EventBridge、S3、DynamoDB、SNS、SQS、Step Functions 等关联服务。以前要拼七八个 API 调用才能定位的跨服务故障，现在 agent 一步拿到完整诊断。

作者：CodePass 技术编辑

这个能力解决什么问题

Lambda 函数出问题时，故障原因经常不在 Lambda 本身。一个典型场景：API Gateway 返回 502，你进 Lambda 控制台看日志发现是超时，查下去发现 DynamoDB 读延迟飙了三倍，再查发现是上游 EventBridge 规则变更导致调用量激增。这条链路跨了四个服务，在 AWS Console 里要切四个页面，复制粘贴请求 ID 和时间戳做关联。

AWS MCP Server 的 serverless 诊断能力把这条排查链压缩成一次 MCP 工具调用。agent 发起诊断请求，server 端在 AWS 侧聚合好跨服务数据后一次性返回。对 agent 来说，少了多轮调用意味着省 token；对开发者来说，不需要手动在多个控制台之间跳转。

诊断能力的五个维度

根据 AWS 官方 What's New 公告，这个 capability 覆盖五个诊断维度：

7 天基线对比。拿当前错误信号和过去 7 天的基线做对比，判断是突发异常还是趋势恶化。比如 Lambda cold start 时间从 200ms 涨到 800ms，单看当前值可能觉得"还行"，但和基线一比就知道是退化。

趋势识别。不只看某一时刻的快照，而是识别错误率、延迟、调用量的趋势走向。连续三天错误率每天涨 2%，和突然从 0 跳到 10% 是不同的故障模式，需要不同的排查方向。

部署配置获取。把 Lambda 函数当前的运行时、内存、超时设置、环境变量、VPC 配置等拉出来。配置问题（内存给太小、超时设太短）是 Lambda 故障的常见根因，agent 拿到配置后能直接比对最佳实践。

变更时间线。追踪最近的部署和配置变更，标注时间戳。错误信号和某次部署时间吻合，基本就能定位到那次变更。

跨服务延迟分析。从 Lambda 出发，追踪到它调用的下游服务（DynamoDB、SQS、S3 等），分析每一跳的延迟贡献。定位"慢在哪一环"不需要手动拼 X-Ray trace。

支持的关联服务

Lambda 诊断不只看 Lambda 自身，以下服务的关联数据都在诊断范围内：

  • API Gateway — 入口层的 4xx/5xx 错误、集成延迟
  • EventBridge — 规则触发频率、Dead Letter Queue 堆积
  • S3 — 读写延迟、throttle 错误
  • DynamoDB — 读写容量消耗、throttle、延迟
  • SNS — 发布失败、投递延迟
  • SQS — 消息年龄、Dead Letter Queue 深度
  • Step Functions — 执行失败、状态机超时

覆盖的是 Lambda 最常见的上下游组合。如果你的 Lambda 调用的是 RDS、ElastiCache 或第三方 HTTP 服务，这些目前不在诊断范围内，需要回到传统的 CloudWatch + X-Ray 路径。

怎么启用

两种方式，选一种即可：

方式一：aws configure agent-toolkit。这是 AWS CLI 新增的子命令，交互式引导你配置 agent toolkit，其中包含 MCP Server 的启用选项。适合第一次接入。

方式二：直接启用 AWS MCP Server。如果你已经在用 AWS MCP Server（比如之前配过 CloudFormation 或 EC2 相关能力），serverless 诊断能力是自动包含的新 capability，不需要额外安装。确认 MCP Server 版本是 2026-09-04 之后的即可。

在 Cursor 里接入 MCP Server 的通用流程，可以参考 Browser MCP 怎么接 Cursor 里的 MCP 配置步骤，路径一样：Settings → MCP → 添加 server 配置。

可用区域与成本

AWS MCP Server 本身的托管区域是 us-east-1 和 eu-central-1，但 serverless 诊断能力覆盖所有商业 AWS 区域的 Lambda 函数。你的 Lambda 跑在 ap-southeast-1，诊断请求通过 MCP Server 发到 us-east-1，server 端跨区域聚合数据后返回。

成本方面，这个能力免费。AWS MCP Server 不额外收费，诊断过程中产生的 CloudWatch 查询和 API 调用走正常的 AWS 服务计费，但诊断本身压缩了调用次数，理论上比你手动逐个 API 查还省一些。token 消耗也更低：一次调用返回结构化诊断报告，比 agent 自己发七八个 API 调用再逐个解析要省。

边界与失效场景

这个能力不是万能的，有几个明确的边界：

只覆盖 AWS 原生服务间的关联。Lambda 调用外部 HTTP API（比如 Stripe、Twilio）的延迟和错误不在诊断范围内。agent 能看到 Lambda 本身的 duration 异常，但无法追踪到外部调用那一跳。

依赖 CloudWatch 和 X-Ray 数据。如果你的 Lambda 没开 X-Ray tracing，跨服务延迟分析的精度会下降。CloudWatch Logs 保留期过了的历史数据也查不到。

7 天基线窗口是固定的。不能自定义基线周期。如果你的业务有周期性波动（比如每月 1 号流量翻倍），7 天基线可能把上个月初的尖峰排除在外，误判当前流量为异常。

不替代完整的 Observability 栈。这是一个诊断入口，不是 Datadog 或 New Relic 的替代品。复杂的多服务追踪、自定义 metrics 告警、长期趋势分析仍然需要专业 APM 工具。类似地，Sentry MCP 怎么让 AI 查线上报错解决的是应用层错误追踪，和 AWS MCP Server 的基础设施层诊断互补而非重叠。

参考资料