{"slug": "serverless-mcp-server-for-ai-agent-data-lake-access-on-amazon-ecs-fargate", "title": "Serverless MCP server for AI agent data lake access on Amazon ECS Fargate", "summary": "Amazon's North America Sort Center (NASC) team built a serverless Model Context Protocol (MCP) server on Amazon Elastic Container Service (Amazon ECS) with AWS Fargate to give LLM agents a centralized, agent-agnostic gateway to an enterprise data lake containing thousands of datasets. The server enforces access control at the MCP layer and lets teams expose a new dataset by adding only a JSON metadata file that the server discovers on the next pipeline sync, replacing per-table integration code that previously took a multi-day engineering effort per dataset. The architecture separates client, MCP server, tools, and knowledge-base refresh layers, with requests routed through Amazon Route 53 and an Application Load Balancer configured with HTTPS and AWS WAF.", "body_md": "## [Artificial Intelligence](https://aws.amazon.com/blogs/machine-learning/)\n\n# Serverless MCP server for AI agent data lake access on Amazon ECS Fargate\n\nOrganizations building applications powered by artificial intelligence (AI) face a recurring challenge: giving large language model (LLM) agents access to enterprise data lakes without duplicating integration logic across every agent and application. Most teams begin by wiring agents directly to databases and APIs, with no shared gateway such as a Model Context Protocol (MCP) server in between. Each new dataset demands custom code, and each agent reimplements its own access control. As the number of datasets or agents grows, permission enforcement drifts, and onboarding a new data source becomes a multi-day engineering effort.\n\nOur team supports Amazon’s North America Sort Center (NASC) network, where planning teams rely on operational data to manage capacity, labor, and package flow. To give those teams conversational access to that data, we built a serverless [Model Context Protocol (MCP)](https://modelcontextprotocol.io/) server on [Amazon Elastic Container Service (Amazon ECS)](https://aws.amazon.com/fargate/) with AWS Fargate to address this problem for planning teams in NASC. The server acts as a centralized, agent-agnostic gateway between AI agents and our enterprise data lake. Exposing a new dataset requires only a JSON metadata file that the server discovers automatically on the next pipeline sync.\n\nIn this post, we describe the architecture, show how a metadata-driven approach removes the need for per-dataset integration code, and explain how the serverless infrastructure supports multiple agents and applications in a multi-tenant environment.\n\n## Problem statement and design goals\n\nTwo interrelated challenges shaped how we designed this system: fragmented data access patterns and an unsustainable onboarding model.\n\n### Integration challenge at scale\n\nOur data lake contains thousands of datasets spanning operational metrics, business analytics, and domain-specific data. Multiple teams wanted AI assistants that could query this data conversationally, but each built its own integration from scratch. Each agent embedded its own SQL generation logic, schema knowledge, and connection handling, so a schema change meant patching every agent individually. Access control was fragmented, with no single audit point for data access decisions. Onboarding a new dataset required custom tool code, query validation, and redeployment, typically a multi-day effort per table.\n\n### Design goals\n\nWe established four requirements:\n\n- Configuration-driven data lake access. Adding a dataset requires only a metadata file, not code.\n- Agent-agnostic tool interfaces. Any MCP-compatible client can invoke the same tools.\n- Centralized permission enforcement. Access control is enforced at the MCP server layer.\n- Elastic infrastructure. The system scales with bursty AI workload patterns.\n\n## Solution overview\n\nThe architecture separates concerns into four layers (client, MCP server, tools, and knowledge-base refresh), each independently scalable and deployable. A metadata catalog underpins the tools layer, storing schema descriptions, column-level semantics, and table relationships that the AI agent references when generating SQL. Because the agent derives schema knowledge from the catalog at query time, there is no need to hardcode table structures or redeploy when schemas change. The knowledge-base refresh layer keeps that catalog current, indexing new dataset metadata as it arrives. The following sections describe each layer in detail.\n\n## Architecture walkthrough\n\nThe following diagram shows the request flow from user query to data layer across all four layers. A user submits a query from a client application (web chat, Slack, an IDE plugin, or an external agent). The request resolves through Amazon Route 53 for DNS and reaches an Application Load Balancer in a public subnet, configured with HTTPS and AWS WAF. The load balancer routes to Amazon Cognito, which authenticates the user and enriches the request. Authenticated traffic then enters the private subnet, where the client layer runs on Amazon ECS Fargate. This layer handles session state in Amazon DynamoDB and forwards requests through an internal Application Load Balancer to the MCP server layer, also on Amazon ECS Fargate. In the MCP server layer, an AI agent powered by Amazon Bedrock orchestrates tools built with FastMCP (a Python framework for building MCP servers). Amazon Bedrock Guardrails is applied to every model interaction. On the right, the data layer holds the tool backends. Amazon Athena and Amazon Redshift run SQL queries against the data lake, and Amazon Bedrock Knowledge Bases, the fully managed Retrieval Augmented Generation (RAG) capability, handles semantic search. Data ingestion into Amazon Simple Storage Service (Amazon S3) and the knowledge bases is handled by AWS Lambda. Each layer is described in detail in the sections that follow.\n\n### MCP client layer: Authentication and session management\n\nA request flows from the client application through Amazon Route 53 for DNS resolution to an Application Load Balancer configured with HTTPS and [AWS WAF](https://aws.amazon.com/waf/). The load balancer forwards traffic to the Amazon ECS Fargate client service, which integrates with Amazon Cognito for JSON Web Token (JWT) authentication and Amazon DynamoDB for session storage.\n\nA context mapping configuration drives this enrichment, scoping each query to only the relevant tables. In our testing, this scoping keeps end-to-end interaction latency in the 15–20 second range. The following example shows a context mapping configuration:\n\nWhen a context specifies tables, the MCP server narrows its search of the metadata catalog to those tables, reducing noise and improving SQL generation accuracy. Adding a new business domain requires only adding an entry to this mapping.\n\n### MCP server layer: Stateless execution with conversation state\n\nThe MCP server runs on its own ECS Fargate cluster, isolated from the client layer. Requests reach it through Amazon Route 53 and an internal Application Load Balancer in a private subnet. The server handles full orchestration including query analysis, tool selection, execution, and response generation. Through the MCP protocol endpoint (`/mcp`), a FastMCP-powered JSON-RPC interface, external MCP-compatible clients such as Amazon Q Developer or IDE extensions can discover and invoke tools directly.\n\nFargate tasks are stateless with conversation state persisted in DynamoDB, so tasks can be replaced or scaled without data loss. When a request arrives, the agent retrieves session history, analyzes user intent using Amazon Bedrock, discovers and invokes appropriate tools, and streams results back to the user.\n\n### Tools layer and metadata-driven data lake access\n\nEach tool is registered with FastMCP and discoverable at runtime:\n\n| **Sr.no** | **Tool** | **Backend** | **Purpose** | \n| 1 | SQL query tools | Amazon Athena Amazon Redshift | SQL queries against any configured dataset in the data lake and Redshift | \n| 2 | Document and metadata search | Amazon Bedrock Knowledge Bases | Semantic search over internal documentation, table metadata and team wikis | \n| 3 | Policy search | Amazon Bedrock Knowledge Bases | Search operational policies and standard procedures | \n\nThe Athena query tools are the primary interface to the data lake. The agent first queries the metadata catalog to understand available schemas, generates an optimized SQL query through Amazon Bedrock, validates and auto-corrects the SQL for Athena compatibility, then executes it. Results flow back to the orchestrating agent for natural language synthesis.\n\n### Responsible AI controls\n\nAmazon Bedrock Guardrails is applied to all LLM interactions and is designed to filter harmful content, enforce grounding checks, and help block prompt injection attempts. These guardrails operate as production controls at the MCP server layer, so every connected agent benefits from the same content safety policies regardless of how it connects. The Athena query tools enforce `SELECT`-only queries, rejecting write operations at the tool level before they reach the data lake.\n\n### Knowledge base refresh layer: Dataset onboarding with a single JSON file\n\nThe entire system is built around configuration-driven extensibility. Adding a new dataset requires a metadata JSON file describing the table and an optional context mapping entry. The file captures the table’s schema, business context, and column-level semantics. It serves as the single source of truth that the AI agent uses to understand and query the dataset:\n\nThe `business_description_for_the_table` field carries engine-specific query hints, such as “always use `date()` to wrap string literals,” that reduce SQL validation failures. The `column_details` field pairs each `column_name [type]` with a natural language description and sample values, giving the agent both schema awareness and business semantics. The `sample_values` field matters for accurate `WHERE` clause generation because the agent learns real data patterns, for instance that `warehouse_id` holds codes like `FC-EAST-07` rather than spelled-out names like “East region facility.”\n\nThe pipeline picks up metadata files, generates vector embeddings with Amazon Titan Text Embeddings, and indexes them into Amazon Bedrock Knowledge Bases. Once indexed, the table is discoverable by all connected agents without manual re-indexing or server restarts.\n\nTo improve accuracy for specific applications, an engineer can optionally associate the dataset with a business context. This narrows the search scope, so the agent prioritizes the right tables. The following example shows a context mapping entry:\n\nIf no context is specified, the agent searches across all indexed tables. The context mapping reduces latency and improves SQL accuracy by limiting the search space. This scoping is optional and can be added at any time without modifying the metadata files themselves.\n\n### Putting it together: A query in action\n\nWhen a user asks, “What were our top 10 highest-value orders last month?”, the client enriches the request with business context to narrow scope. The agent converts the question into a vector embedding, searches the metadata catalog for matching schemas, and selects the most relevant table via a lightweight LLM call.\n\nUsing the selected schema, column descriptions, and engine-specific query hints, the agent generates a SQL statement such as:\n\nThe SQL is validated and auto-corrected for engine compatibility, then executed against Amazon Athena. The agent formats the results into a natural language response and streams it back to the user. In our testing, this end-to-end flow completes within 15–20 seconds.\n\nThe same orchestration extends beyond pure SQL. Because document search is registered as another tool on the same server, the agent can answer questions that span structured and unstructured sources in a single turn, such as “What was our return rate for Q4, and what does the product team’s analysis say about the root causes?” For that request, the agent runs an Athena query for the return-rate figure and a Knowledge Bases document search for the analysis, then combines both into one response.\n\n## Security and multi-tenant access\n\nThat single-turn orchestration works only because every tool call passes through the same controlled gateway. The architecture uses layered security rather than a single enforcement point. The MCP server runs in private subnets behind an internal Application Load Balancer and is not reachable from the internet. Only the client layer, which sits behind a public-facing Application Load Balancer with AWS WAF, can route requests to it. Amazon Cognito validates user identity at the client layer, and only authenticated, token-bearing requests are forwarded downstream. At the tool level, the Athena query tools enforce `SELECT`-only queries, rejecting write operations before they reach the data lake. All tool invocations are logged to [Amazon CloudWatch](https://aws.amazon.com/cloudwatch/) with struc", "url": "https://wpnews.pro/news/serverless-mcp-server-for-ai-agent-data-lake-access-on-amazon-ecs-fargate", "canonical_source": "https://aws.amazon.com/blogs/machine-learning/serverless-mcp-server-for-ai-agent-data-lake-access-on-amazon-ecs-fargate/", "published_at": "2026-11-06 17:13:13+00:00", "updated_at": "2026-11-06 17:19:35.238279+00:00", "lang": "en", "topics": ["ai-agents", "agent-protocols", "ai-infrastructure", "large-language-models", "mlops"], "entities": ["Amazon", "Amazon Elastic Container Service", "AWS Fargate", "Model Context Protocol", "North America Sort Center", "Amazon Route 53", "AWS WAF"], "also_reported_by": [], "alternates": {"html": "https://wpnews.pro/news/serverless-mcp-server-for-ai-agent-data-lake-access-on-amazon-ecs-fargate", "markdown": "https://wpnews.pro/news/serverless-mcp-server-for-ai-agent-data-lake-access-on-amazon-ecs-fargate.md", "text": "https://wpnews.pro/news/serverless-mcp-server-for-ai-agent-data-lake-access-on-amazon-ecs-fargate.txt", "jsonld": "https://wpnews.pro/news/serverless-mcp-server-for-ai-agent-data-lake-access-on-amazon-ecs-fargate.jsonld"}}