jsonscraper

AWS CloudWatch Omni Moves Agent Traces Into the Application Operations View

CloudWatch Omni combines agent traces, evaluations and application telemetry, while leaving teams to configure data flows, permissions and budgets.

AWS announced CloudWatch Omni on September 22, 2026, and listed it as generally available on September 23. The dates describe two different events: the announcement and the start of general availability. Omni brings application and AI-agent observability into one experience, with a standalone web interface and IDE extensions as well as CloudWatch integration. aws.amazon.com

That combination addresses a production blind spot: an agent’s request can complete without a conventional service error and still produce a poor answer or choose the wrong tool. AWS’s pitch is that teams can inspect agent traces and evaluations alongside application telemetry. The practical question is whether those signals will be useful in a shared workspace—and what data, access and costs come with routing them there.

The product is broader than agent traces

Omni is an extension of CloudWatch, not a replacement for it. AWS says existing CloudWatch alarms, dashboards, APIs and console workflows continue to work. Telemetry already sent to CloudWatch can appear in Omni without reconfiguration; other instrumented workloads can send data through OpenTelemetry Protocol (OTLP). AWS also describes service discovery and dependency mapping, with spaces that can bring together telemetry across accounts and Regions when configured for that purpose. docs.aws.amazon.com

The experience is not limited to the AWS Management Console. AWS offers a standalone web interface with single sign-on, plus IDE extensions for VS Code, Cursor and Kiro. The September 23 release note lists general availability in US East (N. Virginia), US West (Oregon) and Europe (Ireland). Teams should check regional support before making Omni part of a production design.

For agents, AWS describes trace exploration, evaluation and experimentation across frameworks including OpenAI Agents SDK, LangGraph, CrewAI, Vercel AI SDK and Strands. For application investigations, users can ask questions in natural language or explore telemetry directly; AWS says its AI-assisted investigation features are powered by DevOps Agent. Its application launch post also says DevOps Agent is enabled by default in each Omni investigation session, a behavior administrators should understand when assessing the workflow.

Why putting the signals together could matter

Conventional monitoring can show that a service is responding, how long it takes and whether it is returning errors. It may not reveal that an agent misunderstood a request, selected an unsuitable tool or gave an incorrect answer. Looking at an evaluation result alongside the trace and application signals could help a team trace a quality problem back through the agent’s execution.

That is a plausible operational benefit, not a demonstrated performance result. AWS’s launch materials describe the combined workflow but do not establish that it resolves incidents faster than existing tools. Teams will need to test whether Omni’s evaluations and investigations help on their own workloads.

OpenTelemetry may make it easier to send telemetry from existing instrumentation, but a common protocol does not make observability platforms interchangeable. The OTLP specification defines how telemetry is transmitted; teams still need to check which signals, queries and platform-specific features their workflows depend on.

Centralization takes configuration

Omni can bring together data across accounts and Regions, but teams should not assume that enabling its interface automatically aggregates every account’s telemetry. AWS’s setup documentation describes creating domains and spaces, then configuring how telemetry from multiple accounts is brought into a space. Existing CloudWatch data can be viewed without re-instrumentation, but the organization still needs to set up the intended access and data flow. docs.aws.amazon.com

That distinction matters for both deployment and cost. AWS’s pricing page separates charges for ingesting telemetry, storing it and analyzing it. It also describes charges for additional centralized copies, while the first centralized copy is free under the listed pricing. Query costs depend on scanned data and allowances; agent evaluations are billed at Amazon Bedrock AgentCore Evaluations rates. A useful estimate therefore needs to account for volume, retention, query patterns, copies and evaluation frequency—not just the number of agents.

Trace content and access need review

Agent traces can include prompts, responses, retrieved documents and personal information. AWS says Omni does not automatically detect or redact personally identifiable information. Its sensitive-data guidance recommends choosing where filtering happens; redacting at capture time is the option that prevents sensitive content from leaving the application.

AWS also says Omni does not use customer content to train foundation models or improve Omni itself. That is not the same as saying no content is processed elsewhere: some features send data to services such as Bedrock or AgentCore, and AWS documents cross-Region inference for AI features. Data remains stored in the space’s Region, but AI requests may be processed elsewhere within the same geographic area. Teams should review AWS’s data-use policy and cross-Region inference details, especially if their policies restrict where trace content can be processed.

Access controls deserve the same scrutiny as the telemetry pipeline. AWS says members of a space can read all its telemetry by default; data scopes can narrow which log and trace rows a member sees. But those scopes do not hide fields within a row, so they are not a substitute for redacting content that users should never see. docs.aws.amazon.com

A measured way to evaluate Omni

For teams already using CloudWatch, a contained test can show whether Omni’s shared application-and-agent view helps with a real workflow. Before sending production traces, identify the signals needed, configure filtering, establish account and Region access, and estimate ingestion, storage, analysis and evaluation costs. Then compare the generated investigations and evaluation results with current incident procedures.

For organizations on other observability platforms, the launch is a reason to evaluate the workflow—not, by itself, a reason to migrate. Omni brings agent quality signals closer to application operations, but its value will depend on the usefulness of those investigations, the fit of its controls and the economics of the data flow.

Speedcurve Performance Analytics
Luke Chesser