AWS MCP Server GA 了：AI Agent 直接操作 15000+ AWS API，完整接入教程和踩坑

背景

做了个运维 Agent，想让它帮忙查 EC2、看日志、拉监控。结果光写 tool function 就写了两天——describe_instances、get_metric_data、list_objects... 才接了 5 个 API。

AWS 有 200+ 服务，15000+ API。按这速度接完要到明年了。

5 月 6 号，亚马逊云科技正式发布了 AWS MCP Server（GA）。一个托管 MCP 服务器，Agent 通过标准协议就能安全调用全部 15000+ AWS API。不用再一个个手写 tool function。

折腾了一天接上了，记录一下全过程。

架构一览

AI 工具（Claude Code / Kiro / Cursor / 任何 MCP 客户端）
    ↓ MCP 协议（stdio 传输）
mcp-proxy-for-aws（本地代理，SigV4 签名）
    ↓ HTTPS + IAM 认证
AWS MCP Server（亚马逊云科技托管，us-east-1 / eu-central-1）
    ↓ 权限校验
AWS API（15000+）

核心组件：

mcp-proxy-for-aws：本地运行的代理，开源。负责 IAM SigV4 签名。
AWS MCP Server：远程托管，不用自己部署维护。
IAM：Agent 权限边界完全由 IAM Policy 控制。

四个核心工具

MCP Server 给 Agent 暴露了四个工具：

工具名	功能	使用场景
`call_aws`	调用任意 AWS API	核心操作——查资源、改配置、触发任务
`search_documentation`	搜索 AWS 文档	Agent 不确定怎么操作时先查文档
`read_documentation`	阅读文档详情	深入了解某个 API 的参数和行为
`run_script`	执行 Python 脚本（沙箱）	处理 API 返回数据——排序、过滤、计算

Agent 根据用户意图自动选择工具组合。它会先查文档确认 API 用法，再调用，再用脚本处理数据。

接入步骤

1. 安装代理

pip install mcp-proxy-for-aws

# 验证
mcp-proxy-for-aws --version

GitHub 源码：https://github.com/aws/mcp-proxy-for-aws

2. IAM 权限——最关键的一步

Agent 有 15000+ API 的潜在访问能力。IAM 是安全边界。必须最小权限。

我的只读运维 Policy：

{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Sid": "AgentReadOnly",
      "Effect": "Allow",
      "Action": [
        "ec2:Describe*",
        "ecs:Describe*",
        "ecs:List*",
        "cloudwatch:GetMetricData",
        "cloudwatch:ListMetrics",
        "cloudwatch:GetMetricStatistics",
        "logs:GetLogEvents",
        "logs:FilterLogEvents",
        "logs:DescribeLogGroups",
        "s3:ListBucket",
        "s3:GetObject",
        "lambda:ListFunctions",
        "lambda:GetFunction",
        "lambda:GetFunctionConfiguration",
        "rds:DescribeDBInstances",
        "rds:DescribeDBClusters",
        "elasticloadbalancing:DescribeLoadBalancers",
        "elasticloadbalancing:DescribeTargetHealth",
        "iam:GetPolicyVersion",
        "iam:ListAttachedRolePolicies"
      ],
      "Resource": "*"
    }
  ]
}

如果需要写操作（比如重启实例），加 Condition 限制：

{
  "Sid": "AgentDevWrite",
  "Effect": "Allow",
  "Action": ["ec2:StartInstances", "ec2:StopInstances", "ec2:RebootInstances"],
  "Resource": "*",
  "Condition": {
    "StringEquals": {
      "ec2:ResourceTag/Environment": "dev"
    }
  }
}

只能操作 dev 环境。别给 *:*。我第一天测试用了 ReadOnlyAccess，发现 Agent 把所有服务都查了一遍——虽然只是读，但不该看的也看了。后来改成精确 Action 列表。

3. 配置 MCP 客户端

Claude Code（~/.claude/mcp_servers.json）：

{
  "aws": {
    "command": "mcp-proxy-for-aws",
    "args": ["--region", "us-east-1"],
    "env": {
      "AWS_PROFILE": "agent-readonly",
      "AWS_REGION": "us-east-1"
    }
  }
}

Kiro（项目根目录 .kiro/mcp.json）：

{
  "mcpServers": {
    "aws": {
      "command": "mcp-proxy-for-aws",
      "args": ["--region", "us-east-1"],
      "env": {
        "AWS_PROFILE": "agent-readonly"
      }
    }
  }
}

Cursor：Settings → MCP Servers，同样的配置。

4. 验证连通

在 Claude Code 里输入：

帮我列出 us-east-1 所有运行中的 EC2 实例

正常会看到 Agent 调用 call_aws，传 ec2.DescribeInstances，返回实例列表。

实战场景

场景一：生产排查

我：API 响应变慢了，帮我查查

Agent 思考过程：
1. [call_aws: cloudwatch.GetMetricData] → 拉 ALB 延迟指标
   结果：P99 从 200ms 飙到 3.5s
2. [call_aws: ecs.ListTasks] → 查 ECS 任务状态
   结果：4 个任务中 2 个 STOPPED
3. [call_aws: logs.FilterLogEvents filter="ERROR"] → 查错误日志
   结果：OOMKilled
4. [run_script] → 汇总分析

输出：ECS 任务内存不足（512MB），OOM 重启导致可用实例减半，
负载翻倍。建议调高内存到 1024MB。

它串联了 4 个 API + 1 个脚本，10 秒出结论。手动查要翻 3 个控制台。

场景二：安全巡检

我：安全组有没有开放公网的危险端口？

Agent：
1. [call_aws: ec2.DescribeSecurityGroups]
2. [run_script: 过滤 0.0.0.0/0 入站规则]

发现 3 个问题：
- sg-abc123: SSH(22) → 0.0.0.0/0 ← 高危
- sg-def456: MySQL(3306) → 0.0.0.0/0 ← 极高危
- sg-ghi789: HTTPS(443) → 0.0.0.0/0 ← 通常 OK

场景三：Lambda 诊断

我：order-processor 函数最近报错情况

Agent：
1. [call_aws: lambda.GetFunctionConfiguration] → 超时 30s，内存 256MB
2. [call_aws: logs.FilterLogEvents filter="ERROR"] → 最近 24h 12 次错误
3. [run_script: 分类统计]

报错分布：
- TimeoutError: 8 次（函数 P99 执行时间 28s，逼近 30s 上限）
- ConnectionRefusedError: 3 次（下游服务偶发不可用）
- ValidationError: 1 次（输入格式异常）

建议：超时调到 60s，加下游重试机制。

场景四：成本异常

我：这周 Lambda 哪些函数调用量涨最多？

Agent：
1. [call_aws: lambda.ListFunctions]
2. [call_aws: cloudwatch.GetMetricData → Invocations 指标]
3. [run_script: 计算周环比增长率并排序]

Top 3 增长：
1. image-processor: +340%（从 1200/天 到 5280/天）
2. notification-sender: +180%
3. data-sync: +95%

Agent Skills（新特性）

之前的 Agent SOPs（标准操作流程）升级为 Skills。区别在于 Skills 更灵活——Agent 根据上下文调整执行策略，不是照搬固定脚本。比如"EC2 健康检查"这个 Skill，Agent 会根据具体症状决定先查什么。

安全体系

层	机制	作用
认证	IAM SigV4	确认身份
授权	IAM Policy	限制能做什么
审计	CloudTrail	记录做了什么
监控	CloudWatch	异常告警

建议设 CloudWatch 告警：

每日调用量超过阈值
敏感 API 被调用（Delete、Terminate）
错误率突增

踩坑记录

Profile 混淆：我有 dev/staging/prod 三个 Profile。有一次配错了让 Agent 连上了 prod 的只读权限。虽然只是读，但能看到生产数据。后来在配置里写死 Profile。
run_script 无网络：沙箱环境不能 pip install，也不能访问外部 API。只能用标准库处理 call_aws 返回的数据。够用，但别指望在里面跑复杂分析。
Region 问题：MCP Server 部署在 us-east-1 和 eu-central-1。但你可以操作任何 Region 的资源——在 call_aws 里指定 Region 参数就行。
大响应截断：有些 API 返回数据量很大（比如 describe 几百台 EC2），可能被截断。用 run_script 做过滤比直接返回好。

总结

维度	之前	现在
接入	逐个写 tool function	一个 MCP Server
覆盖	写多少有多少	15000+ 开箱即用
安全	代码逻辑控制	IAM + CloudTrail
维护	API 更新要改代码	自动跟进

跟 boto3 脚本的定位差异

	boto3	MCP Server
适用	CI/CD 确定性自动化	运维排查、探索性操作
开发	手写代码	Agent 自动选 API
灵活	完全可控	Agent 决策

不互斥。确定性操作用 boto3，探索性操作用 MCP Server。

参考

官方博客：https://aws.amazon.com/blogs/aws/the-aws-mcp-server-is-now-generally-available/
文档：https://docs.aws.amazon.com/agent-toolkit/latest/userguide/mcp-server.html
代理源码：https://github.com/aws/mcp-proxy-for-aws

AWS 运维 Agent 的门槛低了一个数量级。之前要写几十个 tool function 才能覆盖的场景，现在一个 MCP Server 搞定。免费用，只付底层 API 费。

posted @ 2026-06-30 08:06 亚马逊云开发者阅读(17) 评论(0) 收藏举报

刷新页面返回顶部

亚马逊云开发者

进入亚马逊云科技开发者网站，请锁定 https://dev.amazoncloud.cn 帮助开发者学习成长、交流，链接全球资源，助力开发者成功。

AWS MCP Server GA 了：AI Agent 直接操作 15000+ AWS API，完整接入教程和踩坑

AWS MCP Server GA 了：AI Agent 直接操作 15000+ AWS API，完整接入教程和踩坑

背景

架构一览

四个核心工具

接入步骤

1. 安装代理

2. IAM 权限——最关键的一步

3. 配置 MCP 客户端

4. 验证连通

实战场景

场景一：生产排查

场景二：安全巡检

场景三：Lambda 诊断

场景四：成本异常

Agent Skills（新特性）

安全体系

踩坑记录

总结

跟 boto3 脚本的定位差异

参考

公告