Contesto e motivazioni

Le aziende che costruiscono applicazioni alimentate da intelligenza artificiale (AI) si trovano di fronte a una sfida ricorrente: fornire agli agenti basati su grandi modelli linguistici (LLM) l’accesso a data lake aziendali senza dover replicare la logica di integrazione per ogni agente e per ogni applicazione.

Molti team iniziano collegando direttamente gli agenti a database e API, senza un gateway condiviso come un Model Context Protocol (MCP) server. Ogni nuovo dataset richiede codice personalizzato e ogni agente deve implementare da sé il proprio controllo degli accessi. Con l’aumento del numero di dataset o di agenti, la coerenza delle autorizzazioni si indebolisce e l’onboarding di una nuova fonte dati diventa un’attività ingegneristica di più giorni.

Il nostro team supporta la rete North America Sort Center (NASC) di Amazon, dove i team di pianificazione si affidano a dati operativi per gestire capacità, manodopera e flusso dei pacchi. Per offrire a questi team un accesso conversazionale a tali dati, abbiamo costruito un server Model Context Protocol (MCP) serverless su Amazon Elastic Container Service (ECS) con AWS Fargate, pensato per risolvere il problema di integrazione e controllo centralizzato.

Obiettivi di progetto e requisiti di design

Due sfide interconnesse hanno guidato la progettazione del sistema: pattern di accesso frammentati e modello di onboarding insostenibile.

Integrazione su larga scala

Il nostro data lake contiene migliaia di dataset che spaziano da metriche operative a analisi di business e dati di dominio specifico. Molti team volevano assistenti AI in grado di interrogare questi dati in modo conversazionale, ma ciascuno costruiva la propria integrazione da zero. Ogni agente incorporava logica di generazione SQL, conoscenza dello schema e gestione delle connessioni; un cambiamento dello schema richiedeva la patch di tutti gli agenti. Inoltre, il controllo degli accessi era frammentato, senza un punto unico di audit. L’onboarding di un nuovo dataset richiedeva codice personalizzato, validazione delle query e ridistribuzione, tipicamente un impegno di più giorni per tabella.

Obiettivi di design

    • Accesso al data lake basato su configurazione: aggiungere un dataset richiede solo un file di metadati JSON, non codice.
    • Interfacce agnostiche per gli agenti: qualsiasi client compatibile MCP può invocare gli stessi strumenti.
    • Controllo centralizzato delle autorizzazioni: le policy sono applicate a livello del server MCP.
    • Infrastruttura elastica: il sistema scala in base a carichi di lavoro AI intermittenti.

Panoramica della soluzione

L’architettura separa le preoccupazioni in quattro strati – client, server MCP, strumenti e aggiornamento del knowledge‑base – ognuno scalabile e distribuibile indipendentemente. Un catalogo di metadati sostiene lo strato strumenti, memorizzando descrizioni di schema, semantica a livello di colonna e relazioni tra tabelle che l’agente AI utilizza per generare SQL. Poiché l’agente attinge alla conoscenza dello schema dal catalogo al momento della query, non è necessario codificare strutture di tabella né ridistribuire il servizio quando gli schemi cambiano. Lo strato di aggiornamento del knowledge‑base mantiene il catalogo aggiornato, indicizzando i nuovi metadati non appena arrivano.

Flusso di richiesta dettagliato

Il diagramma sottostante (non mostrato) illustra il percorso della richiesta dall’utente al livello dati attraverso tutti e quattro gli strati.

1. Client: l’utente invia una query da un’applicazione client (chat web, Slack, plugin IDE o agente esterno). La risoluzione DNS avviene tramite Amazon Route 53 e il traffico raggiunge un Application Load Balancer (ALB) pubblico, configurato con HTTPS e AWS WAF.

2. Autenticazione: l’ALB indirizza la richiesta ad Amazon Cognito, che autentica l’utente e arricchisce la richiesta con un JWT.

3. Subnet privata: il traffico autenticato entra in una subnet privata dove il livello client gira su Amazon ECS Fargate. Qui la sessione viene gestita in Amazon DynamoDB e la richiesta viene inoltrata, tramite un ALB interno, al livello server MCP.

4. Server MCP: il server, anch’esso su ECS Fargate, esegue l’orchestrazione completa – analisi della query, selezione e invocazione degli strumenti, generazione della risposta. L’interfaccia JSON‑RPC FastMCP è esposta su /mcp, consentendo a client compatibili (Amazon Q Developer, estensioni IDE) di scoprire e invocare gli strumenti.

5. Strato strumenti: gli strumenti includono query SQL su Amazon Athena e Amazon Redshift, ricerca semantica su Amazon Bedrock Knowledge Bases e ricerca di policy operative.

6. Livello dati: le query SQL vengono eseguite contro il data lake (S3) o Redshift, mentre le ricerche semantiche consultano i Knowledge Bases gestiti da Bedrock. L’ingestione dei dati in S3 e nei Knowledge Bases è gestita da funzioni AWS Lambda.

Livello client MCP: autenticazione e gestione della sessione

Il flusso parte da Route 53, passa per l’ALB pubblico con HTTPS e WAF, e arriva al servizio client su ECS Fargate. Il servizio si integra con Amazon Cognito per l’autenticazione JWT e con DynamoDB per la memorizzazione della sessione.

Una configurazione di mappatura del contesto guida l’arricchimento, limitando ogni query solo alle tabelle rilevanti. Nei test interni, questo scoping mantiene la latenza end‑to‑end tra 15 e 20 secondi. Esempio di configurazione:

{

"package_data": {


"description": "Informazioni su tracciamento e consegna dei pacchi",


"tables": ["analyticsdb.regionalordersummary", "operationsgold.load_summary"],


"sources": {"wiki": [], "quip": []}


},


"labor_planning": {


"description": "Gestione della forza lavoro e pianificazione capacità",


"tables": ["workforce.capacity_details"],


"sources": {"wiki": [], "quip": []}


}


}

Quando il contesto specifica le tabelle, il server MCP restringe la ricerca nel catalogo di metadati a quelle tabelle, riducendo rumore e migliorando l’accuratezza della generazione SQL. Aggiungere un nuovo dominio di business richiede solo l’inserimento di una voce in questa mappatura.

Livello server MCP: esecuzione senza stato con stato della conversazione

Il server MCP opera su un cluster ECS Fargate separato, isolato dal livello client. Le richieste lo raggiungono tramite Route 53 e un ALB interno nella subnet privata. Il server gestisce l’intera orchestrazione: analisi della query, selezione degli strumenti, esecuzione e generazione della risposta.

Il punto finale MCP (/mcp) espone un’interfaccia JSON‑RPC basata su FastMCP. Client esterni compatibili (Amazon Q Developer, estensioni IDE) possono scoprire e invocare gli strumenti direttamente.

Le attività Fargate sono senza stato; lo stato della conversazione è persistito in DynamoDB, così i task possono essere sostituiti o scalati senza perdita di dati. Quando arriva una richiesta, l’agente recupera la cronologia della sessione, analizza l’intento dell’utente con Amazon Bedrock, individua e invoca gli strumenti appropriati, e trasmette i risultati in streaming all’utente.

Strato strumenti e accesso al data lake guidato da metadati

Ogni strumento è registrato con FastMCP e scoperto a runtime. Di seguito la tabella riassuntiva:

    • Nr. 1 – Strumenti di query SQL – Backend: Amazon Athena, Amazon Redshift – Scopo: eseguire query SQL su qualsiasi dataset configurato nel data lake e Redshift.
    • Nr. 2 – Ricerca documenti e metadati – Backend: Amazon Bedrock Knowledge Bases – Scopo: ricerca semantica su documentazione interna, metadati delle tabelle e wiki dei team.
    • Nr. 3 – Ricerca policy – Backend: Amazon Bedrock Knowledge Bases – Scopo: ricerca di politiche operative e procedure standard.

Gli strumenti di query Athena costituiscono l’interfaccia primaria verso il data lake. L’agente prima interroga il catalogo di metadati per comprendere gli schemi disponibili, genera una query SQL ottimizzata tramite Amazon Bedrock, la valida e la corregge automaticamente per la compatibilità con Athena, quindi la esegue. I risultati fluiscono nuovamente all’agente, che li sintetizza in linguaggio naturale.

Intelligenza artificiale responsabile (Responsible AI)

Per garantire un utilizzo sicuro e conforme, tutti i modelli Bedrock sono soggetti a Guardrails, che applicano policy di contenuto, limitano la generazione di informazioni sensibili e forniscono audit trail per le decisioni di accesso. Inoltre, il controllo centralizzato delle autorizzazioni a livello MCP consente di revocare o modificare i permessi in modo atomico, riducendo il rischio di esposizione involontaria dei dati.

Benefici e risultati ottenuti

Il passaggio a un server MCP serverless ha prodotto risultati misurabili:

    • Riduzione del tempo di onboarding: l’aggiunta di un nuovo dataset è passata da giorni a minuti, poiché basta caricare un file JSON di metadati.
    • Coerenza dei permessi: tutte le richieste passano per un unico punto di controllo, semplificando audit e conformità.
    • Scalabilità elastica: Fargate scala automaticamente in risposta a picchi di richieste AI, mantenendo la latenza entro i 20 secondi target.
    • Mantenimento della compatibilità schema‑first: le modifiche agli schemi non richiedono ridistribuzioni di codice, poiché il catalogo di metadati è sempre aggiornato.

Considerazioni operative e best practice

Durante la realizzazione del sistema, abbiamo identificato alcune pratiche chiave:

    • Versionare i file di metadati: utilizzare un repository Git per gestire le modifiche e garantire rollback rapidi.
    • Monitorare le metriche Fargate: CPU, memoria e durata dei task devono essere osservati per ottimizzare i parametri di scaling.
    • Applicare policy WAF granulari: limitare le origini consentite e proteggere da payload maligni.
    • Abilitare logging centralizzato: CloudWatch Logs per tutti i componenti (Cognito, DynamoDB, Lambda, Athena) facilita il debugging.
    • Validare le policy IAM: concedere al server MCP solo i permessi strettamente necessari per Athena, Redshift e Bedrock.

Prospettive future

Il modello serverless MCP può essere esteso per includere nuovi tipi di strumenti, come l’esecuzione di job Spark su Amazon EMR o l’interrogazione di grafi tramite Amazon Neptune. Inoltre, l’integrazione con Amazon Q Developer consentirà a sviluppatori di terze parti di costruire rapidamente plugin personalizzati che sfruttano lo stesso catalogo di metadati.

In sintesi, la combinazione di un server MCP serverless, un catalogo di metadati guidato da JSON e un’infrastruttura basata su ECS Fargate fornisce una soluzione robusta, scalabile e sicura per consentire agli agenti AI di accedere ai data lake aziendali senza duplicare logica di integrazione o frammentare i controlli di accesso.