← 返回目录
A

Amazon ECS MCP Server

官方
AWS 官方维护,管理和排障 Amazon ECS 容器部署
GitHub 源仓库 ↗
★ 9.5k Stars 分类 · 其他 非常热门
70FMRS · B
来源与配置已复核
可靠性
12/20
安全与权限
15/20
维护活跃度
16/20
文档质量
15/20
安装易用性
12/20

AWS 官方 Labs 团队维护,默认 ALLOW_WRITE=false 的安全设计值得肯定;涉及真实云资源创建和删除,风险等级高于一般本地工具,发布信息中已明确列出所有写操作相关工具。评分基于源码与文档静态核验,未实际部署验证。

查看评分与验证方法 →
AWS Labs 官方维护的 MCP Server(awslabs/mcp monorepo 中的 ECS 子项目),覆盖容器化应用到 ECS 部署、故障排查的完整生命周期:容器化最佳实践指导、ECR 镜像构建推送、ECS Express Mode 一键部署(自动配置负载均衡、自动扩缩容、CloudFormation 基础设施)、资源查看和部署故障诊断。AWS 同时提供全托管的远程 ECS MCP 服务,本条目对应可本地运行的开源实现。

工具能力

containerize_app
为应用生成容器化最佳实践指导
build_and_push_image_to_ecr
创建 ECR 仓库并构建、推送 Docker 镜像
validate_ecs_express_mode_prerequisites
部署前校验所需的 IAM 角色和镜像是否已就绪
ecs_resource_management
列出/查看/创建 ECS 资源(集群、服务、任务、任务定义)及 ECR 镜像
wait_for_service_ready
跟踪 ECS 部署进度,等待服务就绪
delete_app
清理 Express Mode 部署创建的全部资源
ecs_troubleshooting_tool
诊断和排查常见的 ECS 部署问题

安装接入

推荐用 `uvx --from awslabs-ecs-mcp-server ecs-mcp-server` 启动(需要预先配置好 AWS CLI profile 和权限)。默认 `ALLOW_WRITE=false` 和 `ALLOW_SENSITIVE_DATA=false`,需要显式开启才允许写操作和访问敏感数据,是刻意设计的安全默认值。AWS 也提供全托管远程版本,文档见 docs.aws.amazon.com。
claude_desktop_config.json
{
  "mcpServers": {
    "awslabs.ecs-mcp-server": {
      "command": "uvx",
      "args": ["--from", "awslabs-ecs-mcp-server", "ecs-mcp-server"],
      "env": {
        "AWS_PROFILE": "<your-aws-profile>",
        "AWS_REGION": "<your-aws-region>",
        "FASTMCP_LOG_LEVEL": "ERROR",
        "ALLOW_WRITE": "false",
        "ALLOW_SENSITIVE_DATA": "false"
      }
    }
  }
}

选型与风险

适合谁

  • 需要 AI 辅助完成 AWS 容器化部署全流程的开发者和运维人员
  • 希望在排障时快速定位 ECS 部署问题根因的场景

不适合谁

  • 没有 AWS 账户或不使用 ECS 的场景
  • 对生产环境自动化部署高度谨慎、不希望 AI 直接创建云资源的团队(应保持 ALLOW_WRITE=false 只做只读排障)

所需权限

  • 需要有效的 AWS 凭据(AWS CLI profile),实际权限范围取决于该 IAM 身份被授予的权限
  • ALLOW_WRITE=true 时可创建/修改/删除 ECS 服务、ECR 仓库等云资源;ALLOW_SENSITIVE_DATA 控制是否可访问日志等敏感数据

风险与副作用

  • 写权限开启后,AI 助手的操作可能直接产生云资源费用或误删生产资源,务必先在非生产账户或加了审批流程的环境测试
  • delete_app 会清理 Express Mode 创建的全部资源,操作不可逆,需谨慎确认目标应用

常见排障

  1. 权限不足报错:检查 AWS CLI profile 对应 IAM 身份是否有所需的 ECS/ECR/IAM 权限
  2. Express Mode 部署失败:先用 validate_ecs_express_mode_prerequisites 检查前置条件是否齐备
  3. 服务一直未就绪:用 wait_for_service_ready 或 ecs_troubleshooting_tool 排查具体阻塞原因

使用场景

把一个 Web 应用容器化并部署到 ECS,无需手写 Dockerfile 和 CloudFormation 模板
让 AI 助手诊断 ECS 服务部署失败或不健康的具体原因
查看当前账户下的 ECS 集群、服务、任务定义等资源清单
清理不再需要的 ECS Express Mode 部署及关联资源

支持客户端

Claude Desktop完整支持
Claude Code完整支持
VS Code完整支持
Cursor完整支持
Windsurf完整支持
Kiro完整支持
Cline完整支持