Michael JohnsonAWS ha annunciato CloudWatch Omni il 22 settembre 2026 e lo ha indicato come disponibile a livello generale dal 23 settembre. Le date descrivono due eventi diversi: l’annuncio e l’inizio della disponibilità generale. Omni riunisce in un’unica esperienza l’osservabilità delle applicazioni e degli agenti di IA, con un’interfaccia web autonoma ed estensioni per IDE, oltre all’integrazione con CloudWatch. L’annuncio di AWS su CloudWatch Omni
Questa combinazione affronta un punto cieco in produzione: la richiesta di un agente può essere completata senza un errore convenzionale del servizio e produrre comunque una risposta scadente o la scelta dello strumento sbagliato. AWS sostiene che i team possano esaminare le tracce e le valutazioni degli agenti insieme alla telemetria delle applicazioni. La domanda pratica è se questi segnali saranno utili in un ambiente di lavoro condiviso e quali dati, autorizzazioni e costi comporta instradarli al suo interno.
Il prodotto va oltre le tracce degli agenti
Omni è un’estensione di CloudWatch, non un suo sostituto. AWS afferma che gli allarmi, i pannelli di controllo, le API e i flussi di lavoro esistenti di CloudWatch continuano a funzionare. La telemetria già inviata a CloudWatch può comparire in Omni senza riconfigurazioni; gli altri carichi di lavoro strumentati possono inviare dati tramite OpenTelemetry Protocol (OTLP). AWS descrive inoltre l’individuazione dei servizi e la mappatura delle dipendenze, con spazi che, se configurati a tale scopo, possono riunire la telemetria di più account e Regioni. La documentazione di CloudWatch Omni
L’esperienza non si limita alla Console di gestione AWS. AWS offre un’interfaccia web autonoma con single sign-on, oltre a estensioni per IDE per VS Code, Cursor e Kiro. La nota di rilascio del 23 settembre indica la disponibilità generale nelle Regioni Stati Uniti orientali (Virginia settentrionale), Stati Uniti occidentali (Oregon) ed Europa (Irlanda). Prima di includere Omni in un’architettura di produzione, i team dovrebbero verificare il supporto nella propria Regione.
Per gli agenti, AWS descrive funzionalità di esplorazione delle tracce, valutazione e sperimentazione con framework tra cui OpenAI Agents SDK, LangGraph, CrewAI, Vercel AI SDK e Strands. Per analizzare le applicazioni, gli utenti possono porre domande in linguaggio naturale o esplorare direttamente la telemetria; AWS afferma che le sue funzionalità di analisi assistita dall’IA sono basate su DevOps Agent. Il post di lancio dedicato alle applicazioni afferma inoltre che DevOps Agent è abilitato per impostazione predefinita in ogni sessione di analisi di Omni: gli amministratori dovrebbero tenere presente questo comportamento quando valutano il flusso di lavoro.
Perché riunire i segnali potrebbe essere importante
Il monitoraggio convenzionale può mostrare se un servizio risponde, quanto tempo impiega e se restituisce errori. Potrebbe non rivelare che un agente ha frainteso una richiesta, selezionato uno strumento inadeguato o fornito una risposta errata. Esaminare il risultato di una valutazione insieme alla traccia e ai segnali dell’applicazione potrebbe aiutare un team a ricondurre un problema di qualità alle fasi di esecuzione dell’agente.
Si tratta di un vantaggio operativo plausibile, non di un risultato prestazionale dimostrato. I materiali di lancio di AWS descrivono il flusso di lavoro integrato, ma non dimostrano che consenta di risolvere gli incidenti più rapidamente degli strumenti esistenti. I team dovranno verificare se le valutazioni e le analisi di Omni sono utili per i propri carichi di lavoro.
OpenTelemetry può semplificare l’invio della telemetria dagli strumenti di monitoraggio già esistenti, ma un protocollo comune non rende intercambiabili le piattaforme di osservabilità. La specifica OTLP definisce le modalità di trasmissione della telemetria; i team devono comunque verificare da quali segnali, query e funzionalità specifiche della piattaforma dipendono i propri flussi di lavoro.
La centralizzazione richiede configurazione
Omni può riunire dati provenienti da più account e Regioni, ma i team non dovrebbero presumere che l’attivazione dell’interfaccia aggreghi automaticamente la telemetria di ogni account. La documentazione di configurazione di AWS descrive la creazione di domini e spazi e la successiva configurazione delle modalità con cui la telemetria di più account viene inserita in uno spazio. I dati CloudWatch esistenti possono essere visualizzati senza una nuova strumentazione, ma l’organizzazione deve comunque configurare le autorizzazioni e i flussi di dati previsti. Le istruzioni di configurazione di Omni
Questa distinzione è importante sia per la distribuzione sia per i costi. La pagina dei prezzi di AWS distingue i costi di acquisizione, archiviazione e analisi della telemetria. Descrive inoltre i costi delle copie centralizzate aggiuntive, mentre la prima copia centralizzata è gratuita secondo i prezzi indicati. I costi delle query dipendono dai dati analizzati e dalle soglie incluse; le valutazioni degli agenti sono fatturate alle tariffe di Amazon Bedrock AgentCore Evaluations. Una stima utile deve quindi tenere conto di volume, conservazione, modelli di query, copie e frequenza delle valutazioni, non solo del numero di agenti.
Tracce e autorizzazioni richiedono una revisione
Le tracce degli agenti possono includere prompt, risposte, documenti recuperati e informazioni personali. AWS afferma che Omni non rileva né oscura automaticamente le informazioni personali identificabili. Le indicazioni di AWS sui dati sensibili raccomandano di scegliere dove applicare il filtraggio; l’oscuramento al momento della raccolta è l’opzione che impedisce ai contenuti sensibili di uscire dall’applicazione.
AWS afferma inoltre che Omni non utilizza i contenuti dei clienti per addestrare modelli di base o migliorare Omni stesso. Questo non significa che i contenuti non vengano elaborati altrove: alcune funzionalità inviano dati a servizi come Bedrock o AgentCore e AWS documenta l’inferenza tra Regioni per le funzionalità di IA. I dati restano archiviati nella Regione dello spazio, ma le richieste di IA possono essere elaborate altrove all’interno della stessa area geografica. Se le loro politiche limitano le aree in cui i contenuti delle tracce possono essere elaborati, i team dovrebbero esaminare la politica di utilizzo dei dati di AWS e i dettagli sull’inferenza tra Regioni.
I controlli degli accessi meritano la stessa attenzione della pipeline di telemetria. AWS afferma che, per impostazione predefinita, i membri di uno spazio possono leggere tutta la telemetria al suo interno; gli ambiti dei dati possono restringere le righe di log e traccia visibili a un membro. Tuttavia, questi ambiti non nascondono i campi all’interno di una riga, quindi non sostituiscono l’oscuramento dei contenuti che gli utenti non dovrebbero mai vedere. Come limitare ciò che vedono i membri
Un approccio ponderato per valutare Omni
Per i team che già utilizzano CloudWatch, una prova circoscritta può mostrare se la vista condivisa di applicazioni e agenti offerta da Omni è utile per un flusso di lavoro reale. Prima di inviare tracce di produzione, occorre individuare i segnali necessari, configurare i filtri, definire gli accessi per account e Regione e stimare i costi di acquisizione, archiviazione, analisi e valutazione. Si possono poi confrontare le analisi generate e i risultati delle valutazioni con le procedure di gestione degli incidenti in uso.
Per le organizzazioni che utilizzano altre piattaforme di osservabilità, il lancio è un motivo per valutare il flusso di lavoro, non, di per sé, un motivo per migrare. Omni avvicina i segnali sulla qualità degli agenti alle operazioni delle applicazioni, ma il suo valore dipenderà dall’utilità delle analisi, dall’adeguatezza dei controlli e dai costi del flusso di dati.
