AWS团队在ECS Fargate上构建无服务器MCP服务器，让AI智能体访问数据湖
AWS机器学习博客文章介绍，亚马逊北美分拣中心（NASC）团队搭建了一个集中式Model Context Protocol服务器，新增数据集只需提供一个JSON元数据文件，无需为每个数据集编写集成代码。
AI解读：这套系统主要解决的是AI智能体访问企业数据湖时重复对接的问题：多个团队各自把智能体直连数据库和API，各自实现SQL生成、schema知识和访问控制，schema一变就要逐个修改智能体，接入一张新表通常需要多天工程量。
适用范围是亚马逊NASC网络中的规划团队，以及任何MCP兼容客户端（文中举例Amazon Q Developer、IDE插件）；系统部署在支持Amazon Bedrock和Bedrock Knowledge Bases的AWS区域。
使用条件是新增数据集需要提供描述表结构、业务含义、列级语义和样例值的JSON元数据文件，可选加一条业务上下文映射；元数据经流水线同步、用Amazon Titan Text Embeddings生成向量并索引进Bedrock Knowledge Bases后，才对所有已连接智能体可见。
文中给出的效果数据仅限作者团队的测试：端到端交互延迟在 15–20 秒区间，作者称上下文映射缩小检索范围可降低延迟、提升SQL准确性；未给出准确率、并发量或与旧方案对比的公开指标。
限制方面，Athena查询工具只允许SELECT，写入操作在工具层被拒绝；MCP服务器位于私有子网，只有经Cognito鉴权的客户端层请求能转发进来；所有工具调用以结构化JSON记录到CloudWatch。
作者称后续方向包括更细粒度访问控制（表所有者按权限组把敏感列标记为受限，智能体生成SQL时自动排除）和查询失败反馈闭环；这两项属于计划，不是已上线能力。
AWS机器学习博客发布文章，介绍亚马逊北美分拣中心（NASC）网络团队在Amazon ECS上用AWS Fargate构建了一个无服务器Model Context Protocol（MCP）服务器，作为AI智能体与企业数据湖之间的集中式网关。文章作者为Aishwarya Pawar。
文章称，此前多个团队各自为AI助手编写数据集成，每个智能体自带SQL生成逻辑、schema知识和连接处理，schema变更要逐个打补丁；接入一张新表通常需要自定义工具代码、查询验证和重新部署，耗时多日。
元数据文件驱动数据集接入
按文章描述，新增数据集只需一个JSON元数据文件，记录表结构、业务描述、列级语义和样例值，并可选地加一条业务上下文映射。流水线读取文件后用Amazon Titan Text Embeddings生成向量，索引到Amazon Bedrock Knowledge Bases，下一次同步后该表即可被所有已连接的智能体发现，无需手动重建索引或重启服务器。
文章举例说，元数据中的查询提示字段可以写入“在Athena SQL中比较时间戳列时始终用date() 包裹字符串字面量”这类引擎特定提示，以减少SQL校验失败；样例值字段帮助智能体理解真实数据形态，例如warehouse_id存的是FC-EAST-07这类编码而非仓库全名。
架构与安全控制
文章给出的请求路径是：用户从Web聊天、Slack、IDE插件或外部智能体发起请求，经Route 53解析到带HTTPS和AWS WAF的公有子网应用负载均衡器，由Amazon Cognito完成身份验证，进入私有子网的客户端层（ECS Fargate，会话状态存于DynamoDB），再通过内部负载均衡器转发到独立的MCP服务器层。
MCP服务器层运行由Amazon Bedrock驱动的智能体，工具用FastMCP构建，所有模型交互都应用Amazon Bedrock Guardrails。数据层由Amazon Athena、Amazon Redshift执行SQL，Bedrock Knowledge Bases负责语义检索，AWS Lambda处理向Amazon S3和知识库的数据摄取。
安全方面，文章称MCP服务器不暴露于互联网，只有经Cognito鉴权的请求可转发；Athena查询工具只允许SELECT，在工具层拒绝写操作；工具调用以结构化JSON记录到Amazon CloudWatch，作为跨智能体和应用的数据访问审计点。
- 客户端层按CPU利用率 50% 阈值自动伸缩，MCP服务器层按CPU/内存利用率伸缩，Athena按查询并发自动伸缩。
- MCP服务器任务无状态，对话状态保存在DynamoDB，任务可替换或扩缩而不丢数据。
作者测试中的延迟与待办方向
文章称在其测试中，从用户提问到返回自然语言结果的端到端流程在 15–20 秒内完成；上下文映射把检索范围限制在指定表上，可降低噪声并提升SQL生成准确性。这些数字来自作者团队的测试描述，文章未给出查询准确率或并发压力下的表现数据。
文章末尾列出两个后续方向：一是更细粒度的访问控制，表所有者可按权限组将敏感列标记为受限，智能体生成SQL时自动排除这些列；二是收集查询失败或低置信结果的模式，向表描述和查询提示提出改进建议。文章将这两项描述为正在推进的扩展，未说明上线时间。