/ 目录 / 演练场 / AWS Labs MCP
← 全部服务器 ↗ GitHub
● 官方 awslabs 🔑 需要你的密钥

AWS Labs MCP

作者 awslabs · awslabs/mcp

AWS Labs 官方集合 — 每个服务一个 MCP（S3、Lambda、CloudFormation、ECS、RDS、CloudWatch）。默认只读。

AWS Labs MCP 套件。AWS 不是提供一个巨大服务器，而是推出了一个系列：aws-api（通用 CLI 风格），加上专用于 S3、Lambda、CloudFormation、ECS、RDS、CloudWatch、Cost Explorer 等的专用服务器。全部优先读；写操作需要通过 env 标志显式启用。

▶ 观看演示 📦 安装 💡 使用场景

为什么要用

核心特性

实时演示

实际使用效果

aws.replay ▶ 就绪
0/0

安装

选择你的客户端

~/Library/Application Support/Claude/claude_desktop_config.json  · Windows: %APPDATA%\Claude\claude_desktop_config.json
{
  "mcpServers": {
    "aws": {
      "command": "uvx",
      "args": [
        "awslabs.aws-api-mcp-server"
      ]
    }
  }
}

打开 Claude Desktop → Settings → Developer → Edit Config。保存后重启应用。

~/.cursor/mcp.json · .cursor/mcp.json
{
  "mcpServers": {
    "aws": {
      "command": "uvx",
      "args": [
        "awslabs.aws-api-mcp-server"
      ]
    }
  }
}

Cursor 使用与 Claude Desktop 相同的 mcpServers 格式。项目级配置优先于全局。

VS Code → Cline → MCP Servers → Edit
{
  "mcpServers": {
    "aws": {
      "command": "uvx",
      "args": [
        "awslabs.aws-api-mcp-server"
      ]
    }
  }
}

点击 Cline 侧栏中的 MCP Servers 图标，然后选 "Edit Configuration"。

~/.codeium/windsurf/mcp_config.json
{
  "mcpServers": {
    "aws": {
      "command": "uvx",
      "args": [
        "awslabs.aws-api-mcp-server"
      ]
    }
  }
}

格式与 Claude Desktop 相同。重启 Windsurf 生效。

~/.continue/config.json
{
  "mcpServers": [
    {
      "name": "aws",
      "command": "uvx",
      "args": [
        "awslabs.aws-api-mcp-server"
      ]
    }
  ]
}

Continue 使用服务器对象数组，而非映射。

~/.config/zed/settings.json
{
  "context_servers": {
    "aws": {
      "command": {
        "path": "uvx",
        "args": [
          "awslabs.aws-api-mcp-server"
        ]
      }
    }
  }
}

加入 context_servers。Zed 保存后热重载。

claude mcp add aws -- uvx awslabs.aws-api-mcp-server

一行命令搞定。用 claude mcp list 验证，claude mcp remove 卸载。

使用场景

实战用法： AWS Labs MCP

通过关联日志、指标和最近的部署来分类 CloudWatch 告警

👤 SRE 和值班工程师 ⏱ ~15 min intermediate

何时使用： 告警刚刚触发，你想快速找出'是哪个服务、哪个部署、哪行日志'，而不用在控制台中多个标签页切换。

前置条件
  • 有 CloudWatch + CloudFormation 读权限的 AWS 凭据 — 使用具有 ReadOnlyAccess 托管策略的角色运行 aws sso login
  • aws-cloudwatch-mcp 服务器正在运行 — uvx awslabs.cloudwatch-mcp-server — 或安装完整包
步骤
  1. 获取告警详情和受影响的资源
    描述 CloudWatch 告警 'prod-api-5xx-high'。它监视什么资源，阈值是什么，当前状态如何？✓ 已复制
    → 告警配置加上状态历史（何时触发的）
  2. 查询违规周期内的日志
    对 /aws/ecs/prod-api 日志组运行 Logs Insights 查询，时间范围从告警触发前 10 分钟到现在。找出 ERROR 级别的日志行，按消息模板分组。✓ 已复制
    → 按计数排名的顶级错误模板
  3. 与最近的部署关联
    列出过去 6 小时内对 prod-api 服务的 CodeDeploy 部署。是否有任何部署时间与错误激增时间相关联？✓ 已复制
    → 部署时间线与错误开始的对齐

结果： 一个具体的假设，如'部署 abc123 在 14:22 UTC 与 5xx 错误在 14:23 的出现相关联'，并有证据支持。

注意事项
  • 针对大型日志组的 Logs Insights 查询如果没有时间窗口会花费真实的金钱 — 始终包含窄于 1 小时的 @timestamp 边界；MCP 不会阻止你产生账单
  • 跨账户资源需要正确的凭据配置文件 — 为每个服务器调用设置 AWS_PROFILE env 变量；不要假设默认配置文件就是你想要的
搭配使用： sentry · github

审计 S3 存储桶的公开对象和加密状态

👤 安全工程师、合规审查员 ⏱ ~20 min intermediate

何时使用： 在进行渗透测试或审计之前，你想快速了解存储桶的安全状态。

前置条件
  • S3:List 和 S3:GetBucket* 权限 — 附加 SecurityAudit 托管策略（只读）
步骤
  1. 列出存储桶并获取它们的策略
    列出此账户中的所有 S3 存储桶。对每个存储桶，获取：Public Access Block 配置、存储桶 ACL、存储桶策略、默认加密配置。✓ 已复制
    → 按存储桶的安全状态表
  2. 标记风险存储桶
    突出显示任何 Public Access Block 关闭、或加密关闭、或存储桶策略包含 Principal: '*' 的存储桶。✓ 已复制
    → 风险存储桶的简短列表及原因
  3. 从标记的存储桶中抽样几个对象
    对于每个标记的存储桶，列出前 5 个对象并显示它们的 ACL。有任何实际上是世界可读的吗？✓ 已复制
    → 对象级别的确认而不仅仅是存储桶级别

结果： 为你的安全审查提供优先级排列的修复清单。

注意事项
  • 即使 ACL 看起来是私有的，存储桶策略也可以授予公开访问权限 — 同时评估两者；使用 GetPublicAccessBlock 和 GetBucketPolicyStatus API，而不仅仅是 ACL
搭配使用： filesystem

找出这个月 AWS 账单为什么飙升

👤 工程负责人、财务运营 ⏱ ~25 min intermediate

何时使用： 账单上升了 30%，你有 48 小时向财务解释。

前置条件
  • Cost Explorer API 访问权限 — 在计费控制台启用 Cost Explorer；向你的角色授予 ce:GetCostAndUsage
步骤
  1. 获取每日成本变化
    拉取过去 60 天的每日总混合成本。识别任何成本相对于 7 天移动平均值上升超过 20% 的日期。✓ 已复制
    → 每日成本序列加上标记的异常天
  2. 为异常按服务分解
    对于最大异常日，按服务分解成本。哪个服务导致了飙升？✓ 已复制
    → 识别的服务级驱动因素
  3. 进一步按资源分解
    对于那个服务，按使用类型和资源标签分解。哪个特定资源负责？✓ 已复制
    → 资源级别的罪魁祸首 — 例如'us-east-1 中的 NAT 网关处理了 12 TB'

结果： 给财务部门的单段落回答：'飙升是由 X 引起的，修复方案是 Z'。

注意事项
  • Cost Explorer 最多有 24 小时的延迟 — 今天的成本还没有完全出现 — 限制查询至少在 1 天前结束；在答案中明确注明延迟
  • 每个 Cost Explorer API 调用费用 $0.01 — 不要在没有边界的脚本中循环查询；MCP 不会阻止你
搭配使用： filesystem

通过读取最近的调用和日志来调试失败的 Lambda

👤 无服务器工程师 ⏱ ~15 min intermediate

何时使用： Lambda 间歇性抛出错误，你想看到输入、错误和持续时间趋势。

步骤
  1. 描述函数
    描述 Lambda 函数 my-api-handler。运行时是什么，内存是多少，超时是多少，最后修改时间是什么？✓ 已复制
    → 配置快照
  2. 从 CloudWatch Logs 中拉取最近的错误
    Logs Insights：对于 /aws/lambda/my-api-handler 过去 2 小时的日志，显示错误行及其 requestId、持续时间和初始化时间。按错误类型分组。✓ 已复制
    → 错误类别及代表性的 requestId
  3. 端到端获取一个请求
    选择一个失败的 requestId。拉取该调用的完整日志流 — START、所有打印输出、END、REPORT。告诉我发生了什么。✓ 已复制
    → 单个调用的叙述，包括冷启动计时和错误原因

结果： 具体的错误原因加上修复路径（更多内存、依赖升级、重试配置等）。

注意事项
  • 预配置并发歪斜冷启动数字 — 过滤存在 Init Duration 的 REPORT 行 — 那些是冷启动；如果你在调试热启动调用，忽略它们
搭配使用： github · sentry

检测 CloudFormation 堆栈和实时资源之间的漂移

👤 平台工程师、DevOps ⏱ ~30 min advanced

何时使用： 你怀疑有人在控制台点击并在 IaC 之外更改了资源。

步骤
  1. 列出堆栈并触发漂移检测
    列出所有 ACTIVE CloudFormation 堆栈。对每个，启动漂移检测并轮询直到全部完成。✓ 已复制
    → 每个堆栈的漂移状态：IN_SYNC / DRIFTED / NOT_CHECKED
  2. 深入调查漂移的堆栈
    对于每个状态为 DRIFTED 的堆栈，列出哪些资源漂移及哪个属性不同。✓ 已复制
    → 资源级别的差异（例如'SG 允许 0.0.0.0/0 但模板说 10.0.0.0/8'）
  3. 决定：更新模板或回滚
    对于每个漂移，建议：实时状态是有意的（更新模板以匹配）还是意外的（回滚资源）？根据更改的性质进行判断。✓ 已复制
    → 每个漂移的建议及理由

结果： 你的 IaC 与现实同步，并有决策日志。

注意事项
  • 漂移检测不会捕获每个资源类型的每个属性 — 查看 CloudFormation 文档中的'不支持漂移'列表；用 AWS Config 规则补充以获得全面覆盖
搭配使用： github

组合

与其他 MCP 搭配，撬动十倍杠杆

aws + github

关联部署 PR 与生成的 CloudWatch 告警 — 识别破损提交

CloudWatch 告警 prod-latency-p99 在 14:22 触发。找到最接近该时间并已合并到 main 的 GitHub PR，总结其差异，告诉我哪一块代码最可能导致了回归。✓ 已复制
aws + postgres

对于 RDS 托管的 Postgres，将 AWS 级别的可观察性与 SQL 访问相结合

RDS 告警 'cpu > 80%' 在 prod-db-01 上。与 pg_stat_statements 关联 — 在飙升期间运行了哪些查询最多？✓ 已复制
aws + filesystem

将 AWS 资源库存导出到本地 CSV 以进行合规文档

将每个 S3 存储桶及其加密配置和公开访问设置导出到 /reports/s3-audit-2026-04.csv。✓ 已复制

工具

此 MCP 暴露的能力

工具输入参数何时调用成本
call_aws service: str, operation: str, parameters: object 通用 AWS CLI 等价物 — 任何服务、任何读操作 usually free; some services (CE) bill per call
describe_stack stack_name: str CloudFormation 内省 free
detect_stack_drift / describe_stack_drift_detection_status stack_name: str 检查 IaC 与实时漂移 free
list_functions / get_function / invoke_function Lambda name, payload? 管理和测试 Lambda — 调用是写操作，需要控制 invoke costs per Lambda pricing
list_buckets / get_object / list_objects_v2 S3 params S3 库存和内容访问 standard S3 request pricing
start_query / get_query_results (Logs Insights) logGroupName, queryString, startTime, endTime 跨一个或多个日志组的日志分析 $0.005 per GB scanned
get_metric_data CloudWatch metric query JSON 时间序列指标获取 free tier applies
get_cost_and_usage TimePeriod, Granularity, GroupBy, Metrics Cost Explorer 查询 $0.01 per API call
list_services / describe_services / list_tasks (ECS) cluster params ECS 集群/服务内省 free
describe_db_instances (RDS) identifier? RDS 库存；使用 postgres MCP 进行实际 SQL free

成本与限制

运行它的成本

API 配额
按服务。大多数 describe/list 调用免费；某些 API 按调用计费（Cost Explorer $0.01、Logs Insights $0.005/GB 扫描）
每次调用 Token 数
典型的 200-2000 token；Logs Insights 结果可能很大 — 始终设置行限制
费用
MCP 本身免费。你的 AWS 账单反映代理进行的任何 API 调用。
提示
限制时间窗口、限制结果行、缓存每个会话的 describe-* 输出。不小心对 30 天详细日志的 Logs Insights 循环可能扫描 TB 的数据。

安全

权限、密钥、影响范围

最小权限： arn:aws:iam::aws:policy/ReadOnlyAccess (用于只读使用)
凭据存储： 标准 AWS 凭据链 — env vars、~/.aws/credentials、SSO 或 instance role。永远不要硬编码密钥。
数据出站： 直接到 AWS API 端点（区域性）。无第三方。
切勿授予： AdministratorAccess iam:* write kms:Decrypt on sensitive keys without scoping

故障排查

常见错误与修复

Could not load credentials from any providers

运行 aws sts get-caller-identity — 如果失败，先修复你的 CLI 设置。MCP 使用相同的链。

验证： aws sts get-caller-identity
AccessDenied on a Describe call

你的角色缺少特定权限。读错误消息 — 它列出了缺失的操作。添加到角色或切换配置文件。

Throttling: Rate exceeded

你触及了服务 API 限制（例如 CloudFormation 1 req/s）。退避；大多数 SDK 自动重试，但批量循环会超过。在多调用提示中添加显式睡眠。

uvx can't find awslabs.<server>

包名格式：awslabs.<name>-mcp-server。检查 awslabs/mcp 仓库 README 获取当前列表 — 名称在 2025 年末改变了。

验证： uvx --help | head

替代方案

AWS Labs MCP 对比其他方案

替代方案何时用它替代权衡
Cloudflare MCP你运行在 Cloudflare（Workers/R2/D1）而不是 AWS不同的云；不是即插即用
Terraform MCP (community)你想要跨云的 IaC 优先工作流对实时状态调试的覆盖较少
通过 shell MCP 直接使用 `aws` CLI你想要 Claude 运行任何 CLI 命令，而不仅仅是预批准的攻击面大得多；除非沙箱化否则避免

更多

资源

📖 阅读 GitHub 上的官方 README

🐙 查看未解决的 issue

🔍 浏览全部 400+ MCP 服务器和 Skills