AWS MCP Server：让 AI 助手安全驾驭 AWS 全套 200+ 服务

从手动查文档到"张嘴就来"：云管工程师的日常噩梦

想象一下这个场景：凌晨两点，告警响起——某台 EC2 实例 CPU 飙到了 95%。你打开终端，开始在 AWS 文档海洋里搜索正确的 CLI 命令。"是 aws ec2 describe-instance-status 还是 aws ec2 describe-instances？""实例状态"和"实例信息"有什么区别？"你一边查文档，一边小心翼翼地敲命令，生怕敲错一个参数把生产环境搞崩。

更痛苦的是，当你试图让 AI 助手（比如 Claude）帮你做这件事时，AI 只能泛泛地回答"你可以试试 aws ec2 describe-instances"。它不知道你具体用的是哪个实例 ID、哪个 region，更不知道你账号里有没有设置特殊的 IAM 策略。

AWS MCP Server 解决的就是这个痛点——它把 AWS CLI 的全部能力，通过 MCP（Model Context Protocol）协议，桥接到 Claude、Cursor、Windsurf 等 AI 助手中，让 AI 助手能够真正地、精确地操作你的 AWS 账户，而不是纸上谈兵。

一行命令，Claude 就能操控整个 AWS

AWS MCP Server 的核心思路非常巧妙：它不逐个封装 AWS API，而是直接包装整个 AWS CLI。

这样做有一个巨大的好处：AWS CLI 本身就支持 200+ 服务、数千个命令，且随着 AWS 更新持续同步。开发者不需要为每个新 API 单独写封装代码，Claude 只需要用 --help 按需学习命令用法，就能获得完整的操作能力。

项目提供两个 MCP 工具：

• aws_cli_help：查询任意 AWS CLI 命令的文档，帮助 AI 理解某个命令的用法和参数
• aws_cli_pipeline：执行 AWS CLI 命令，支持管道操作（如 jq、grep），并可设置超时时间

Claude 使用时的典型流程：先用 aws_cli_help 了解命令用法，再用 aws_cli_pipeline 执行，最后返回人类可读的格式化结果。整个过程受 IAM 策略约束——AI 能做什么、不能做什么，完全由你账号的 IAM 权限决定。

沙箱隔离：安全第一

既然要让 AI 执行真实的 AWS 命令，安全问题就无法回避。项目作者显然也想到了这一点，专门实现了操作系统级进程隔离：

• Linux 端：优先使用 Landlock LSM（Linux 内核 5.13+ 引入的安全模块），若内核版本过低则回退到 bubblewrap。限制文件系统只读访问，允许读写 /tmp 和当前工作目录。
• macOS 端：通过 ctypes 调用 Seatbelt（sandbox-exec）实现类似隔离。

此外，docker-compose 部署模板还强制开启了一系列安全加固措施：read_only: true（只读根文件系统）、cap_drop: ALL（丢弃所有 Linux capabilities）、no-new-privileges: true（禁止提权）、以及 pids_limit: 100（限制进程数）。这些措施叠加在一起，即使 AI 生成的命令出现问题，攻击面也被压缩到最小。

架构解析：代码结构与技术选型

源码位于 src/aws_mcp_server/，共 9 个模块：

技术栈选型相当现代：Python ≥ 3.13、FastMCP 2.x（MCP 官方 Python SDK）、boto3（AWS SDK）。代码规范使用 Ruff（linter + formatter），目标版本直指 Python 3.13，充分利用结构化模式匹配等新语法特性。

测试方面，单元测试用 pytest + pytest-asyncio，集成测试依赖 moto（AWS 模拟库），在不需要真实 AWS 凭证的环境下也能跑完整测试链路。

部署：Docker 一键运行

项目提供完整的 Docker 部署方案，核心文件在 deploy/docker/ 目录下：

• Dockerfile：基于 python:3.13-slim，自动根据 TARGETARCH 安装对应架构的 AWS CLI（x86_64 / arm64），并安装 Session Manager 插件（x86_64 only）
• docker-compose.yml：开箱即用的编排模板，配置了 AWS credentials 只读挂载、安全加固和临时存储限制

# 最简部署（需先配置 ~/.aws/ 凭证）
cd deploy/docker
docker compose up -d

# 通过 MCP 客户端连接（以 Claude Desktop 为例）
# 在 claude_desktop_config.json 中添加：
{
  "mcpServers": {
    "aws": {
      "command": "docker",
      "args": ["run", "--rm", "-i", 
        "-v", "$HOME/.aws:/home/appuser/.aws:ro",
        "ghcr.io/alexei-led/aws-mcp-server:latest"]
    }
  }
}

部署本身非常简单，5 分钟内可以完成。但需要注意的是，它是一个 MCP Server 而非 Web 应用，需要配合 Claude Desktop、Cursor 或其他 MCP 客户端使用，对普通用户来说有一定上手门槛。

局限与挑战

尽管设计巧妙，这个项目也存在一些值得关注的局限：

1. AI 生成命令的正确性依赖模型能力。AWS CLI 命令复杂多样（尤其涉及管道和复杂参数时），AI 生成的命令可能不符合预期，甚至因理解偏差产生破坏性操作。虽然有 IAM 兜底，但 IAM 配置不当同样危险。

2. Landlock 在某些环境下受限。Landlock 需要内核 5.13+，在较老的 Linux 发行版或某些容器环境中可能无法启用，回退到 bubblewrap 后行为可能不一致。

3. 对 AWS CLI 本身的依赖。项目本身不处理 AWS API 直接调用，所有能力边界受限于 AWS CLI 支持的范围。如果某个 AWS 服务尚未被 CLI 支持，MCP Server 也无能为力。

4. 集成测试需要真实 AWS 凭证。测试套件中标记为 @pytest.mark.integration 的用例需要真实的 AWS 凭证才能运行，在 CI/CD 环境中配置不便。

行业意义与未来趋势

AWS MCP Server 代表了一个正在快速兴起的技术方向——AI + 云基础设施的深度集成。随着 Claude、Cursor 等 AI 编程助手的能力持续进化，让 AI 直接操作系统级工具（而非 API 封装层）已成为更自然的路径。

这种"让 AI 使用人类工具"而非"为 AI 构建专用 API"的思路，减少了维护成本，也保证了能力的同步性。可以预见，未来会有更多类似的"工具桥接层"出现，让 AI 助手能够驾驭 Kubernetes CLI、Docker CLI、Terraform 等各类运维工具。

对于 DevOps 工程师和云架构师而言，这个项目提供了一个值得参考的范式：如何安全地让 AI 操作生产级云资源，而非仅仅让 AI 帮忙写脚本。

项目链接：https://github.com/alexei-led/cloud-mcp-server
Stars：185 | Forks：34 | License：MIT | 主语言：Python
核心依赖：fastmcp ≥ 2.13.0、mcp ≥ 1.22.0、boto3 ≥ 1.41.0
部署方式：Docker + docker-compose
上线时间：2025 年 3 月