Serverless MCP server connects AI agents to data lakes on AWS

Amazon Web Services has published a reference architecture for building serverless Model Context Protocol (MCP) servers that connect artificial intelligence agents to enterprise data lakes. The design, implemented for Amazon’s North America Sort Center network, uses Amazon Elastic Container Service with AWS Fargate to provide a centralized gateway for conversational data access. This approach aims to eliminate the need for custom integration code for every new dataset or agent.

What happened

Organizations often struggle to give large language model agents secure access to internal data without duplicating effort. Teams typically wire agents directly to databases, embedding unique SQL generation logic and access controls in each application. As the number of datasets grows, this fragmented approach leads to permission drift and makes onboarding new data sources a multi-day engineering task. To address this, AWS engineers built a shared MCP server that acts as an agent-agnostic interface to their operational data lake.

The solution separates concerns into four distinct layers: client, MCP server, tools, and knowledge-base refresh. This structure allows each component to scale independently while maintaining strict security boundaries. By centralizing the connection to the data lake, the team ensured that any MCP-compatible client could query operational metrics, business analytics, and domain-specific data without reimplementing core integration logic. The system supports multiple tenants and applications, providing a consistent experience across different user interfaces such as web chats or IDE plugins.

A key feature of this implementation is its metadata-driven design. Instead of writing code to define how an agent interacts with a specific table, engineers add a JSON metadata file. The server automatically discovers these files during pipeline syncs, making new datasets available to all connected agents immediately. This configuration-driven approach reduces the time required to onboard a new data source from days to minutes, removing the bottleneck of custom tool development for each schema change.

How it works

The architecture relies on a stateless execution model powered by Amazon ECS Fargate. When a user submits a query, it passes through an Application Load Balancer and Amazon Cognito for authentication. The request is enriched with context mapping configurations that scope the query to relevant tables, reducing noise and improving accuracy. The MCP server, built with the FastMCP Python framework, orchestrates the interaction between the agent and the data tools. It retrieves session history from Amazon DynamoDB and uses Amazon Bedrock to analyze intent and select the appropriate tools.

Data access is managed through a metadata catalog that stores schema descriptions, column semantics, and table relationships. When an agent needs to query a dataset, it first consults this catalog to understand the structure. The agent then generates a SQL query, which is validated for safety and compatibility before execution on Amazon Athena or Amazon Redshift. This process ensures that only read-only operations reach the data lake, preventing accidental writes or deletions. The metadata files include business descriptions and sample values, helping the agent generate accurate WHERE clauses and understand engine-specific syntax requirements.

Key details

• The system uses Amazon ECS Fargate for both the client and MCP server layers, ensuring elastic scaling for bursty AI workloads.
• Dataset onboarding requires only a JSON metadata file, which captures schema, business context, and column-level semantics.
• Amazon Bedrock Guardrails are applied to all model interactions to filter harmful content and block prompt injection attempts.
• Context mapping configurations allow engineers to scope queries to specific tables, keeping end-to-end latency between 15 and 20 seconds.
• The tools layer includes SQL query tools for Amazon Athena and Redshift, as well as semantic search via Amazon Bedrock Knowledge Bases.
• Session state is persisted in Amazon DynamoDB, allowing Fargate tasks to remain stateless and easily replaceable.

Why it matters

For software engineers building AI applications, this architecture offers a blueprint for managing complexity at scale. By decoupling the agent logic from the data access layer, teams can avoid the maintenance burden of updating every agent when a database schema changes. The centralized enforcement of access controls also addresses a critical security concern, ensuring that permission policies are applied consistently regardless of which client or agent is making the request. This reduces the risk of unauthorized data exposure in multi-tenant environments.

The metadata-driven approach significantly lowers the barrier to entry for adding new data sources. Instead of requiring deep knowledge of SQL generation or API integration, engineers can focus on defining clear business semantics in JSON files. This shift enables faster iteration and allows non-engineering stakeholders to contribute to the agent’s knowledge base by providing accurate descriptions and sample data. As AI agents become more prevalent in enterprise settings, such standardized gateways will be essential for maintaining governance and operational efficiency.

What you can do

• Evaluate your current agent integrations to identify duplicated data access logic that could be centralized.
• Define a standard JSON schema for metadata files that includes business descriptions and sample values for your datasets.
• Implement context mapping configurations to scope agent queries and reduce latency in high-volume scenarios.
• Use serverless containers like AWS Fargate to handle the variable load patterns typical of AI agent interactions.
• Apply guardrails at the server level to ensure consistent content safety and prevent prompt injection across all clients.
• Store session state in a durable, low-latency database like DynamoDB to support stateless server architectures.