AWS MCP Server 配置指南：让 Claude 直连你的云环境

想象一下，在终端里输入「显示我们所有活跃的服务器」，然后看着 AI 助手实时从 AWS 环境中拉取真实的基础设施数据——这正是 AWS Model Context Protocol（MCP）Server 所实现的能力。它在你的 AI 助手与云资源之间建立起一座安全、标准化的桥梁，让 Claude 这类工具从「只会聊天」升级为「能读懂并操作你真实架构」的工程伙伴。

本文基于一段 YouTube 教程，梳理通过 OAuth 方式快速接入 AWS MCP Server 的完整流程，并补充其中关于权限、安全边界的关键细节。

为什么需要 AWS MCP Server

MCP 的核心价值在于「上下文」。单纯的大语言模型无法得知你 AWS 账户里跑着哪些 EC2 实例、CloudWatch 指标是否异常。而 MCP Server 充当翻译层：它把你的自然语言请求解析成对应的 AWS API 调用，安全地取回实时数据，再格式化成可读结果返回给你。

这次演示采用的是精简的 OAuth 方法，相比传统方案的最大优势是绕过了复杂的本地代理（proxy）配置。这意味着整个认证与连接过程可以在几分钟内完成，而不必折腾繁琐的中间件。

开始前需要准备三样东西：一个活跃的 AWS 账户、一个配置好的 AWS CLI，以及一个客户端——Claude Code（命令行）或 Claude Desktop（桌面应用）。

MCP（Model Context Protocol）是 Anthropic 于 2024 年底提出的开放标准协议，旨在解决大语言模型与外部数据源、工具之间的「最后一公里」对接问题。其设计思路类似 USB-C 接口的统一化逻辑：无论后端是数据库、API 还是文件系统，只要实现了 MCP Server 规范，任何兼容的 AI 客户端（称为 MCP Host）就能以一致的方式与之交互。在 AWS 场景中，MCP Server 扮演的角色是将自然语言请求映射到 AWS SDK/API 调用，并将返回的 JSON 结构化数据转换为模型可理解的上下文。这与传统的 function calling 有所不同——MCP 是一个独立运行的进程，通过标准化的 JSON-RPC 协议与客户端通信，天然支持多工具聚合与权限隔离，而不需要每次都在 prompt 中手动描述可用工具的 schema。

第一步：验证 AWS CLI 会话

地基要稳。打开终端，运行以下命令确认本地凭证处于活跃状态：

aws sts get-caller-identity

如果命令成功返回你的账户信息，说明本地凭证已经就绪，可以继续下一步。

第二步：清理旧的集成配置

安装之前必须先清场。遗留的旧版 MCP Server 会提供功能重复的工具，这会让 AI agent 混淆、甚至导致任务失败。

打开你的 claude.json 配置文件，查找任何名为 aws.api-mcp-server 或 aws.knowledge-mcp-server 的条目，将这些行整段删除。

干净的配置文件能确保 Claude 只看到我们即将赋予它的工具，避免因为服务器重叠而产生幻觉或执行错误的 AWS 命令。这一步在实战中极易被忽略，却是导致后续调用混乱的常见根源。

第三步：安装官方 AWS MCP Server

清理完毕后就可以安装官方的 AWS MCP Server。命令行用户在终端输入 add 命令，指向 AWS 的 endpoint URL，并指定 HTTP transport 标志。

特别注意 URL 中的 us-east-1——你需要把它替换成自己所在的 AWS 区域，比如 eu-west-1 或 ap-southeast-2，否则会连错区域。

如果你用的是 Claude Desktop 桌面应用，则需要修改前面那个 JSON 配置文件来添加服务器。桌面用户还有一个额外改动：要在网址末尾追加 ?oauth=initialize 参数。

原因在于桌面客户端不像 CLI 那样具备自动发现（automatic discovery）机制，加上这个标志才能在需要认证时强制弹出浏览器登录窗口。只要把客户端指向这个格式正确的 endpoint，本地助手与云环境之间的安全通道就建立起来了。

第四步：测试连接与 OAuth 授权

现在来验证连接。回到 Claude，直接问一个关于基础设施的问题，比如「有哪些可用的 AWS 区域？」

由于这是首次对外连接，Claude 会自动打开浏览器窗口，把你导向 AWS 登录页。输入现有的 AWS 凭证，在授权界面点击「允许」，为服务器授予所需权限。

这些权限与一个**临时会话令牌（session token）**绑定。如果你的 agent 在某个时间点突然不响应了，过期的会话几乎总是罪魁祸首。解决办法很简单：回到终端运行 AWS 登录命令刷新凭证即可。

依赖短生命周期令牌的设计有其深意——它保证 AI 的持续访问始终严格绑定在你当前已认证的「人类同意」之上，而不会无限期开放。

这里使用的 OAuth 流程遵循 OAuth 2.0 授权码模式（Authorization Code Flow）。当 Claude 首次发起请求时，MCP Server 检测到尚无有效令牌，便将浏览器重定向到 AWS 的身份提供商（IdP）完成人机验证。用户登录并点击「允许」后，服务端签发一个短生命周期的访问令牌（Access Token）和刷新令牌（Refresh Token）。访问令牌通常有效期为 1 小时，过期后客户端需要用刷新令牌换取新令牌，或重新走一遍登录流程。这种设计的安全意义在于：即便令牌被截获，攻击窗口也极为有限；同时每一次令牌颁发都留有审计记录，可在 AWS CloudTrail 中追溯。相比长期有效的 Access Key/Secret Key 方案，短生命周期令牌大幅降低了凭证泄露的爆炸半径。

第五步：执行真实任务

在 Claude Code 界面输入 /mcp 命令查看活跃的服务器状态，你应该能看到 aws-mcp 显示为 connected 状态。

接下来交给它一个真实任务：列出当前所有正在运行的 EC2 实例名称。Claude 会解析你的英文请求，翻译成正确的 AWS API 调用，安全地取回实时数据，并整理成可读列表。

想验证结果？打开 AWS 管理控制台的 EC2 面板对照一下。当两份列表完全一致时，就说明集成已经生效——Claude 现在真正在读取并理解你的实时云基础设施。

连接建立后，可玩的事情还很多：分析 CloudWatch 指标、排查日志、定位权限错误，甚至根据现有架构生成 CDK 基础设施代码。

安全边界：Agent 不会越权

一个关键的安全前提是：agent 完全运行在你个人的 IAM 权限边界之内。它无法访问任何你本人无权访问的数据，也无法执行任何你本人无权执行的命令。

如果想设置更严格的限制，可以配置 IAM condition keys，把 agent 限定为只读访问——让它能分析环境却无法修改。对于复杂的跨账户工作流，官方的 AWS Agent Toolkit 文档还介绍了 SIGV4 proxy 等替代认证方式。

通过 AWS MCP Server 把 AI 助手接入你的云环境，本质上是给了它成为一名真正称职的工程伙伴所需的上下文。它不再是旁观者，而是能够读取、分析、协助操作的参与者——前提是始终在你授权的权限框架之内。

IAM（Identity and Access Management）是 AWS 的核心权限管理系统，通过策略（Policy）定义「谁」可以对「哪些资源」执行「哪些操作」。IAM condition keys 是策略语句中的附加条件，可以进一步约束权限生效的场景。例如，可以添加 "aws:RequestedRegion": "us-east-1" 限制 agent 只能操作特定区域，或者用 "iam:PermissionsBoundary" 设置权限上限，确保即使策略本身权限较宽，实际生效的权限也不会超过边界。对于希望让 AI agent 仅做只读分析的团队，一个实用做法是专门创建一个附加 ReadOnlyAccess 托管策略的 IAM 角色，让 MCP Server 以该角色的身份运行，从根本上切断写操作的可能性，而不仅仅依赖 agent 的「自我约束」。