跳转至

将 AWS DevOps Agent 智能运维能力延伸到中国区

Ch11.153 将 AWS DevOps Agent 智能运维能力延伸到中国区

📊 Level ⭐⭐ | 7.3KB | entities/将-aws-devops-agent-智能运维能力延伸到中国区.md

-> 原文存档

标签

aws #devops-agent #china-region #mcp

原文: 将 Aws Devops Agent 智能运维能力延伸到中国区(raw/articles/将-aws-devops-agent-智能运维能力延伸到中国区.md)

相关实体

深度分析

分区隔离是架构级硬约束，非配置问题

AWS Commercial 分区（aws）与 AWS 中国分区（aws-cn）之间的隔离体现在 IAM 信任策略层面：你无法在 aws-cn 的 IAM Role 中信任一个 aws 分区的 Principal，尝试建立跨分区的 AssumeRole 会直接返回 CREATE_FAILED。这意味着任何依赖 IAM Role 跨分区信任的 Agent 管理机制（如 DevOps Agent 原生的 Secondary Account）在 aws-cn 分区物理不可行。本文将 MCP Server 部署在 Commercial 分区侧，正是绕开了 IAM 信任跨分区的限制，转而通过 API 调用（而非直接 Role 模拟）访问中国区资源。

MCP "USB 接口" 模式将跨分区认证转化为接口约定

MCP 协议的核心价值在于将"如何访问中国区"这个问题从 Agent 运行时抽离为一份接口协议。DevOps Agent 只需要知道 MCP Server 的 endpoint 和认证方式，不需要持有任何 aws-cn 凭证；凭证由 MCP Server 在 Commercial 分区本地持有并使用。这意味着即便未来 aws-cn 分区上线 DevOps Agent，架构上也只是换一个 MCP Server endpoint，Agent 配置无需改动。同时，call_aws 单一工具覆盖所有 AWS CLI 命令，相比逐服务注册 MCP 工具的方案，显著降低了工具注册和维护成本。

凭证出境是数据合规的核心争议点

MCP Server 部署在 Commercial 分区时，IAM Roles Anywhere 方案下中国区的临时 STS 凭证会在 Commercial 分区侧被使用——这意味着凭证数据流出了中国区。原文坦承这一限制，并提供了将 MCP Server 直接部署在中国区（使用 EC2/ECS Role）的替代方案。合规要求高的场景应优先选择后者，以实现凭证不离开 aws-cn 分区。但这反过来引入了中国区自管证书（ICP 备案视情况而定）的运维负担。两个方案的本质权衡是：凭证安全/合规 vs. 运维复杂度。

awslabs/aws-api-mcp-server 的两个内置保护机制形成了分层安全模型：READ_OPERATIONS_ONLY 在 MCP Server 层自动拦截所有写操作（基于 AWS Service Authorization Reference 自动判断），而 REQUIRE_MUTATION_CONSENT 在写操作发生时强制要求用户确认。即使 ALB 层的 API Key 认证被绕过、MCP Server 被暴露，攻击者也无法直接执行破坏性操作。更重要的是，这个安全模型是内置的，无需自研。

DevOps Agent 跨境监控与 MCP 桥接是互补而非竞争路径

DevOps Agent 原生支持同一分区内跨 Region 监控（Agent Space 在 us-east-1 可管理 ap-east-1），但这一能力无法延伸到 aws-cn 分区。本文 MCP 桥接方案恰好填补了这一空白：两个机制定位不同，前者解决同分区多 Region 统一管理，后者解决跨分区资源访问。在多分区、多环境的复杂 AWS 架构中，两者可以并存——用原生跨 Region 能力管理 Commercial 分区内的多 Region，用 MCP 桥接访问中国区。

实践启示

  1. 先用 READ_OPERATIONS_ONLY=true 建立基准，再按需扩展 上线初期应启用只读模式，运行 2-4 周观察 Agent 的调用模式和频率，重点关注 call_aws 命令是否涉及敏感操作。只有在业务确认需要写操作（如自动重启异常实例）时才考虑关闭只读，并配套 REQUIRE_Mutation_consent 强制确认。在没有建立基准之前，贸然开放写权限是重大风险。
  2. suggest_aws_commands 是中国区 Agent 能力的"知识补强"关键工具 aws-cn 分区的部分新上线服务（如宁夏区 ap-southeast-2 等）可能不在 DevOps Agent 背后模型的训练数据中。suggest_aws_commands 能根据自然语言查询动态推荐对应 CLI 命令，确保 Agent 对中国区新 API 仍有推理能力。注册 MCP Server 时应同时暴露 call_aws 和 suggest_aws_commands 两个工具，而非只配前者。
  3. ALB 层 Security Group 白名单必须基于 DevOps Agent 出口 IP，而非泛通 0.0.0.0/0 DevOps Agent 出口 IP 是 AWS 官方公布的固定 IP 列表（定期更新）。在 ALB Security Group 中仅放行这些 IP、拒绝其他来源，是成本最低、效果最好的网络层防护。结合 API Key 认证形成两层防护：IP 白名单防外部扫描，API Key 防未授权使用。
  4. MCP Server systemd service 的 HOME 和 PATH 必须显式声明 原文档记录的 ProfileNotFound 和 uvx: not found 两个坑均源于 systemd 默认环境变量与用户 shell 环境不一致。所有 Environment= 声明应包含 HOME=/home/ec2-user、PATH（含 ~/.local/bin）、AWS_CONFIG_FILE 显式路径，而非依赖 systemd 的隐式推断。这是用 uvx 运行 Python MCP 工具的标准配置要求。
  5. 数据合规敏感场景优先选择 MCP Server 部署在中国区 如果业务涉及监管数据（金融、医疗等），或内部安全政策明确禁止数据出境，应选择 MCP Server 部署在 aws-cn 分区（EC2/ECS Role 方案）。代价是需要自管域名证书（中国区 ACM Private CA 或 Digicert 等国内 CA），且证书续期需要纳入运维流程。对于非敏感场景（纯监控元数据、指标数据），Commercial 分区部署 + IAM Roles Anywhere 的快速验证路径更合适。

关联阅读