AWS team details a serverless MCP server that gives AI agents data lake access on ECS Fargate

What happened

AWS published a technical how-to on 6 November 2026 on its Machine Learning Blog. In the company's own post, a team that supports Amazon's North America Sort Center (NASC) network describes a serverless Model Context Protocol (MCP) server. It runs on Amazon ECS with AWS Fargate.

The server sits between AI agents and an enterprise data lake. The team built it so planning teams could ask questions of operational data in plain language, without every agent carrying its own integration code.

The post includes Figure 1, an architecture diagram of the request flow. In short: a user query comes from a client app such as web chat, Slack, an IDE plugin or an external agent. It passes Route 53 and a load balancer with HTTPS and AWS WAF, and Cognito authenticates it. The client layer on Fargate keeps session state in DynamoDB and forwards the request to the MCP server layer, also on Fargate. There, a Bedrock-powered agent calls FastMCP tools that reach Athena, Redshift and Bedrock Knowledge Bases. Lambda handles ingestion into S3 and the knowledge bases.

Key details

• Problem: Agents were wired straight to databases and APIs. Each had its own SQL generation, schema knowledge and access control. Onboarding one table was typically a multi-day effort, the authors say.
• Design goals: configuration-driven data access, agent-agnostic tools, permissions enforced at the MCP server, and elastic infrastructure.
• Four layers: client, MCP server, tools, and knowledge-base refresh. Each scales and deploys independently.
• Stack: the tools are built with FastMCP, a Python framework. Amazon Bedrock powers the agent.
• Statelessness: Fargate tasks keep no state, so they can be replaced or scaled without data loss.
• Safety: Bedrock Guardrails applies to every model interaction. The Athena query tools accept only SELECT queries and reject writes.
• Latency: the authors say that in their testing, scoping queries to relevant tables keeps end-to-end latency at 15–20 seconds.
• Onboarding: a new dataset needs a JSON metadata file, which the server picks up on the next pipeline sync.

Tool	Backend	Purpose
SQL query tools	Amazon Athena, Amazon Redshift	Run SQL against configured datasets
Document and metadata search	Bedrock Knowledge Bases	Semantic search over docs, table metadata and wikis
Policy search	Bedrock Knowledge Bases	Search operational policies and procedures

Try it

The post uses a context mapping file to limit each query to relevant tables. Adding a business domain means adding an entry:

{
  "package_data": {
    "description": "Package tracking and delivery information",
    "tables": ["analytics_db.regional_order_summary", "operations_gold.load_summary"],
    "sources": {"wiki": [], "quip": []}
  },
  "labor_planning": {
    "description": "Workforce management and capacity planning",
    "tables": ["workforce.capacity_details"],
    "sources": {"wiki": [], "quip": []}
  }
}

Why it matters

The post is a vendor's own account of an internal system, not an independent test. Still, it shows one way to centralise access control and schema knowledge for several agents. External MCP-compatible clients, such as Amazon Q Developer or IDE extensions, can discover and call the same tools through the /mcp endpoint, according to the authors.

Read the full AWS post to see Figure 1 and the metadata file format.

FAQ

What does the MCP server do in this design? It acts as a shared gateway between AI agents and the data lake. It handles tool discovery, query execution and permission checks in one place.

How do you add a new dataset? You write a JSON metadata file for the table, plus an optional context mapping entry. The server finds it on the next pipeline sync, with no new tool code.

Can agents write to the data lake through it? Not through the Athena query tools. They allow only SELECT queries and reject write operations before they reach the data lake.