AWS Agent Registry governa gli agenti AI: Bedrock e Graviton5 completano lo stack

🤖 Cosa cambia

• AWS Agent Registry diventa il catalogo governato per agenti, skill, server MCP e risorse distribuite tra team e ambienti enterprise.
• Bedrock amplia retrieval agentico, isolamento multi-tenant, osservabilità e collegamento sicuro degli strumenti MCP con Amazon Quick e AgentCore.
• Graviton5, Kinesis, Glue 6.0, OpenSearch e Redshift rafforzano compute, streaming, ricerca semantica e protezione del livello dati.

Amazon Web Services sta spostando l’AI agentica dalla fase di costruzione alla gestione industriale. La disponibilità generale di AWS Agent Registry introduce un catalogo centrale per agenti, strumenti, skill e server MCP, mentre Amazon Bedrock amplia retrieval, isolamento multi-tenant, osservabilità e accesso controllato ai tool. Parallelamente Amazon Quick può invocare strumenti MCP ospitati su AgentCore, Graviton5 arriva sulle nuove istanze EC2 R9g e R9gd e il livello dati evolve con Kinesis, Glue 6.0, OpenSearch e Redshift. Il filo comune è più importante dei singoli annunci: AWS sta costruendo un’infrastruttura nella quale agenti, dati, identità, strumenti e compute vengono governati come componenti dello stesso sistema enterprise.

AWS Agent Registry trasforma lo sprawl degli agenti in un problema di governance

La novità più strategica è AWS Agent Registry, ora generalmente disponibile e progettato per risolvere un problema che emerge quando un’organizzazione passa da pochi prototipi a centinaia o migliaia di agenti: sapere quali risorse esistono, chi le possiede, quali sono state approvate, quale versione è in produzione e quali utenti o agenti possono effettivamente utilizzarle. Nella presentazione ufficiale di AWS Agent Registry, AWS separa il sistema in due piani. Il Governance Plane contiene l’inventario completo, compresi record non approvati o ancora in revisione, e ospita segnali di compliance, classificazioni, metadati personalizzati e regole di lifecycle; il Discovery Plane espone invece soltanto le risorse che hanno superato il processo di approvazione e che possono essere cercate attraverso modalità lessicali o semantiche. I record supportati appartengono a quattro categorie: server MCP, agent card Agent2Agent, skill descritte attraverso file Markdown con relativi package e risorse Custom espresse in JSON.

L’obiettivo è impedire che ogni team ricostruisca connettori e strumenti già presenti o che si crei una forma di shadow AI difficile da censire. Registry può infatti rilevare automaticamente agenti e server MCP distribuiti su AgentCore Runtime e Gateway negli account di una AWS Organization, importarli come draft e sottoporli al lifecycle configurato dagli amministratori. OAuth e IAM possono essere utilizzati per l’autenticazione, CloudTrail registra le operazioni, EventBridge può attivare workflow di approvazione e PrivateLink permette di mantenere il catalogo raggiungibile anche da ambienti chiusi alla rete pubblica. È un’evoluzione coerente con la necessità di applicare policy deterministiche agli agenti attraverso AgentCore e Dogwood, perché catalogare una capacità senza controllarne lifecycle e autorizzazioni risolverebbe soltanto metà del problema.

Agent Registry debutta in Virginia settentrionale, Oregon, Irlanda, Tokyo e Sydney con tariffazione a consumo e Free Tier. Accanto al prodotto proprietario, AWS sta promuovendo anche Agentic Resource Discovery, specifica aperta Apache 2.0 descritta nel Weekly Roundup del 31 agosto come una sorta di DNS per agenti: la stessa risorsa può essere descritta una volta e resa individuabile attraverso ambienti cloud, on-premises e SaaS differenti. Nello stesso aggiornamento AWS conferma inoltre di avere firmato un accordo definitivo per acquisire DuckLabs, società di Amsterdam dietro DuckDB; non si tratta ancora di un’acquisizione da considerare completata, ma il passaggio rafforza l’interesse di Amazon per tecnologie analitiche aperte capaci di interrogare direttamente Parquet, CSV e JSON. Registry e ARD mostrano quindi due livelli complementari: AWS vuole governare internamente l’inventario aziendale, ma contemporaneamente contribuire a uno standard di discovery capace di superare i confini del singolo provider.

Amazon Bedrock porta retrieval agentico, osservabilità e isolamento multi-tenant nello stesso livello dati

Il catalogo degli agenti serve poco se il dato utilizzato dagli agenti rimane opaco, non misurabile o non correttamente isolato. AWS interviene quindi sulle Managed Knowledge Bases di Amazon Bedrock, che non vengono più trattate soltanto come un meccanismo RAG capace di recuperare documenti e passarli al modello. Nella reference architecture per il retrieval agentico osservabile, un agente può ragionare su una richiesta, scegliere tra più knowledge base, eseguire diversi retrieval e sintetizzare una risposta corredata da citazioni.

L’intera architettura viene distribuita attraverso quattro stack CloudFormation collegati, mentre due dashboard CloudWatch espongono sette livelli di telemetria per osservare latenza, volume delle chiamate, utilizzo degli strumenti, token, dimensione degli indici e qualità del retrieval. AWS aggiunge anche due modelli di valutazione: uno on-demand, indicato per sviluppo e verifiche pre-release, e uno continuo che campiona il traffico reale per individuare regressioni di qualità dopo il deployment.

È un passaggio che prosegue direttamente il percorso con cui AgentCore Observability aveva iniziato a ricostruire strumenti, memoria, token e latenze degli agenti in produzione. Il problema diventa ancora più delicato nelle applicazioni aziendali condivise da molti utenti. La seconda architettura pubblicata da AWS per le chat agentiche multi-tenant parte da un caso apparentemente semplice: ogni utente carica contratti, report o manuali e interroga successivamente quei documenti.

Con il retrieval agentico, tuttavia, una domanda può essere divisa in diverse sotto-query e ogni singolo passaggio deve mantenere il filtro associato al tenant corretto. AWS insiste quindi sul fatto che il confine non deve derivare da un valore dichiarato dal client, ma da un’identità verificata; l’isolamento viene applicato attraverso metadata filtering anche durante i retrieval intermedi. L’ingestion stessa è asincrona: l’API IngestKnowledgeBaseDocuments restituisce inizialmente lo stato STARTING, ma il contenuto diventa interrogabile soltanto dopo parsing, embedding e indicizzazione completa. La combinazione tra queste due reference architecture chiarisce la direzione: Bedrock non viene presentato soltanto come punto di accesso ai foundation model, ma come data plane governato per agenti, nel quale qualità, isolamento, costi e osservabilità devono essere progettati prima che la chat venga esposta agli utenti.

Leggi anche: AWS governa gli agenti AI con Dogwood, architetture aperte e controllo dei costi

Amazon Quick usa AgentCore Gateway per trasformare i server MCP in azioni operative

La terza componente porta gli strumenti direttamente davanti all’utente aziendale. Amazon Quick può ora collegarsi a un server MCP distribuito su Amazon Bedrock AgentCore Runtime e utilizzare le funzioni pubblicate dal server come azioni richiamabili da un chat agent o da un Flow.

La procedura tecnica pubblicata da AWS mostra un’architettura nella quale AgentCore Gateway agisce come ponte tra Quick e il server MCP, separando due flussi di autenticazione: Inbound Auth per verificare e autorizzare la richiesta proveniente da Quick e Outbound Auth per permettere al Gateway di autenticarsi verso il runtime e i servizi finali. Nell’esempio AWS vengono creati due user pool Amazon Cognito, uno per ciascun livello, mentre AgentCore Identity registra il credential provider OAuth usato in uscita. Il server MCP gira con FastMCP in modalità stateless_http=True sul percorso previsto da Runtime e viene quindi registrato nel Gateway; dal lato Quick l’integrazione può usare autenticazione dell’utente oppure autenticazione service-to-service e può essere limitata tramite connettività VPC privata.

Una volta sincronizzate, le funzioni MCP appaiono come strumenti disponibili nell’integrazione Actions, possono essere testate e poi collegate a chat agent e workflow. AWS sta in sostanza eliminando la necessità di scrivere un connettore proprietario per ogni coppia applicazione-tool: il server espone capacità standardizzate attraverso MCP, AgentCore governa identità e traffico, Quick le rende accessibili alle persone e ai flussi operativi. È il passaggio naturale successivo rispetto alla trasformazione di Amazon Quick in piattaforma per analisi, automazioni e agenti creativi. La differenza rispetto a un normale chatbot è sostanziale: l’assistente non deve soltanto rispondere, ma può invocare una funzione che legge o modifica un sistema esterno. Proprio per questo il valore del protocollo cresce insieme al rischio: l’identità dell’utente, il target raggiungibile dal Gateway, gli scope OAuth e i privilegi del tool diventano parte integrante della sicurezza dell’agente. AWS propone TLS end-to-end e separazione dei flussi di autorizzazione, ma l’architettura conferma che il problema centrale dell’AI agentica non è più soltanto decidere quale modello usare. È stabilire quale azione un modello possa innescare, per conto di chi e attraverso quale identità tecnica.

Graviton5 porta le istanze R9g fino a 192 vCPU e 1,5 TiB di memoria

Sotto il livello degli agenti AWS continua contemporaneamente a specializzare il silicio. Le nuove Amazon EC2 R9g e R9gd, ora generalmente disponibili, utilizzano processori AWS Graviton5 e sono pensate per database, cache, analytics real-time e workload fortemente dipendenti dalla memoria. Secondo l’annuncio ufficiale delle istanze R9g e R9gd, Graviton5 fornisce fino al 25% di prestazioni compute in più per vCPU rispetto a Graviton4, memoria DDR5 a 8.800 MT/s invece di 5.600, cache L3 cinque volte più grande, fino al doppio della banda di rete e Amazon EBS sulle configurazioni maggiori e fino a tre volte le prestazioni nel packet processing. Le istanze arrivano a 192 vCPU, 1.536 GiB di RAM, 100 Gbps di rete e 72 Gbps verso EBS. R9gd mantiene la stessa capacità compute ma aggiunge SSD NVMe locali, fino a tre unità da 3,8 TB nella configurazione 48xlarge e bare metal. AWS introduce inoltre Instance Bandwidth Configuration, che permette di spostare del 25% l’allocazione tra banda EBS e networking VPC in funzione del workload. Tutta la famiglia opera sul Nitro System e utilizza il Nitro Isolation Engine, componente per il quale AWS rivendica verifiche formali delle proprietà di isolamento. Per le organizzazioni già su R8g la migrazione dovrebbe richiedere poche modifiche nelle applicazioni Arm64, mentre container e distribuzioni Linux principali restano supportati. Le istanze sono inizialmente disponibili in Virginia settentrionale, Ohio, Oregon e Francoforte con modelli On-Demand, Spot, Savings Plans e host dedicati. Il debutto arriva pochi giorni dopo il ventesimo anniversario di EC2, quando AWS aveva ricordato il passaggio dalla singola macchina virtuale del 2006 a oltre 1.200 tipologie di istanza e una crescente specializzazione tra Nitro, Graviton, GPU e acceleratori. La funzione di Graviton5 nella strategia agentica è indiretta ma essenziale: modelli e agenti attirano l’attenzione, però retrieval, database, cache, metadata e sistemi di supporto continuano a richiedere compute general purpose ad alta efficienza, soprattutto quando l’AI viene distribuita su scala aziendale.

Kinesis e Glue 6.0 accorciano il percorso tra evento in tempo reale e lakehouse Iceberg

La strategia AWS diventa ancora più leggibile osservando il livello streaming. Amazon Kinesis Data Streams può ora consegnare direttamente eventi verso streaming tables basate su Apache Iceberg, riducendo la necessità di mantenere consumer, connector e pipeline dedicate tra il flusso e il data lake. Nel modello illustrato dal team Kinesis, la capacità è integrata direttamente nel servizio: il sistema coordina le scritture tra gli shard, offre semantica exactly once, scala fino a gigabyte al secondo e applica compaction durante l’ingestion per produrre file Parquet più efficienti. AWS dichiara che la riduzione del problema dei small file può abbassare fino al 30% i costi delle query downstream rispetto a una consegna non compattata.

I dati vengono materializzati come tabelle Iceberg read-only in S3 Tables e possono essere interrogati da Athena, Redshift, EMR Spark o Flink; un Kinesis Data Streams Agent Skill consente inoltre a un agente di configurare la pipeline, verificare IAM e proporre operazioni successive. Il prezzo dichiarato è di 14 dollari per TB verso S3 Tables e 11 dollari per TB verso normali bucket S3, con disponibilità nelle regioni che offrono Kinesis Data Streams. Sul percorso di elaborazione interviene AWS Glue 6.0, già basato su Spark 4.1 e Iceberg v3, ma ora utilizzato da AWS per mostrare una pipeline nella quale dati finanziari eterogenei vengono trattati a latenze differenti.

La reference architecture Spark Real-Time Mode separa un ramo real-time, un percorso near-real-time e un layer batch: il primo legge eventi Kafka e applica trasformazioni stateless con latenza sub-secondo, il secondo conserva la cronologia in Iceberg e il terzo esegue calcoli più pesanti come il Value at Risk. Il parametro Trigger.RealTime("1 minute") non definisce una finestra di elaborazione di un minuto, ma la frequenza dei checkpoint; i record continuano a fluire mentre arrivano. AWS precisa tuttavia limiti importanti: RTM supporta attualmente sorgenti Kafka, workload Scala stateless, numero fisso di worker e modalità di output update, quindi non sostituisce automaticamente ogni pipeline Spark Streaming. Le colonne Variant e il relativo shredding permettono nel frattempo di conservare strutture JSON differenti e trasformare automaticamente i campi osservati in colonne Parquet tipizzate. La traiettoria sviluppa quanto già emerso quando AWS aveva collegato pagamenti agentici, streaming e OpenSearch nello stesso livello dati: se un agente deve reagire a un evento, il vero collo di bottiglia non è necessariamente il ragionamento del modello, ma la velocità con cui il dato diventa disponibile, interrogabile e governato.

Continua con:

• AWS abbassa i costi dei dati e porta l’AI agentica dentro i processi enterprise
• AWS porta agenti AI, fine-tuning e Kafka verso una piattaforma enterprise integrata

OpenSearch e Redshift chiudono il cerchio tra qualità del retrieval, identità e rete privata

Il livello finale riguarda la qualità con cui le informazioni vengono trovate e la rete attraverso la quale vengono raggiunte. Amazon OpenSearch Service introduce un metodo più strutturato per misurare se una ricerca semantica o ibrida produce davvero risultati migliori, anziché affidarsi a valutazioni qualitative.

Nella guida dedicata alla Search Relevance Workbench, AWS utilizza User Behavior Insights per raccogliere query e azioni degli utenti in indici dedicati, collegandole attraverso un query_id, e trasforma poi questi segnali in esperimenti confrontabili. Search Relevance Workbench, generalmente disponibile nell’interfaccia di OpenSearch Service dalla versione 3.5, permette di definire query set, configurazioni candidate e judgment list e di misurare Coverage, Precision, MAP e NDCG. Un team può quindi confrontare retrieval lessicale, ricerca semantica, approcci ibridi o reranking con cross-encoder prima di modificare il comportamento della produzione.

È un passaggio fondamentale per l’AI agentica: retrieval più sofisticato non significa necessariamente retrieval migliore, e senza un ground truth misurabile un agente può produrre risposte linguisticamente convincenti a partire da documenti selezionati male. Il tema sviluppa la stessa evoluzione già osservata quando AWS aveva unito MCP stateless, agenti specializzati, migrazioni Spark e ricerca semantica su OpenSearch. Amazon Redshift affronta invece la sicurezza del percorso di autenticazione.

La nuova configurazione con IAM Identity Center ed enhanced VPC routing permette alle chiamate effettuate da Redshift verso gli endpoint OIDC e l’identity store di IAM Identity Center di rimanere all’interno della rete AWS attraverso interface VPC endpoints e PrivateLink. Quando l’utente accede da Query Editor V2 o da un client SQL, Redshift non si limita ad accettare il token ricevuto: lo verifica contro l’endpoint OIDC, effettua lo scambio per un token con scope appropriato e risolve identità e gruppi dell’utente. Con enhanced VPC routing attivo questi passaggi devono avere un percorso privato esplicito, perché un cluster senza IP pubblico non dispone automaticamente di una route Internet verso IAM Identity Center. La configurazione richiede patch 204 o successiva, cluster o workgroup non pubblicamente accessibili e gli endpoint dedicati; Glue, Lake Formation e S3 possono essere aggiunti per mantenere privato anche il percorso verso lake e lakehouse. I dieci aggiornamenti AWS del 31 agosto finiscono così per convergere sullo stesso modello architetturale. Agent Registry stabilisce quali capacità esistono e quali sono approvate; Bedrock stabilisce come gli agenti recuperano informazioni e come vengono osservati; AgentCore governa identità e strumenti; Quick porta quelle capacità all’utente; Kinesis e Glue rendono il dato disponibile con latenze inferiori; OpenSearch misura la qualità del retrieval; Redshift mantiene identità e traffico nel perimetro privato; Graviton5 fornisce il compute sottostante. L’agente AI smette quindi di essere il centro esclusivo dell’architettura. Il vero prodotto che AWS sta costruendo è uno stack operativo nel quale autonomia, discovery, dati, rete, sicurezza, hardware e osservabilità diventano inseparabili, perché soltanto questa combinazione permette di trasformare gli agenti da demo convincenti a infrastrutture aziendali controllabili.