CloudWatch Omni Pricing: Agent Telemetry Volume Is the Real Cost

AWS has introduced Amazon CloudWatch Omni, an observability, evaluation and experimentation product built for generative AI and agentic workloads. AWS describes it as app-centric, AI-powered, built on open standards, and delivered outside the AWS Management Console 4. Most of the launch coverage focuses on debugging agents. The more practical question for teams is what drives the bill, and the answer appears to be how much telemetry their agents generate.

What AWS actually shipped

Omni has two surfaces on top of one data model. Developers get a free extension for VS Code, Cursor and Kiro, where traces appear while an agent runs. Playground and evaluator tools sit one click away 2. There is also a standalone web experience with its own enterprise SSO and access model, so engineers and other users don't need AWS Console access 34.

AWS positions Omni as framework- and provider-agnostic. It is meant to support agents across any model provider, framework or runtime, with built-in evaluators that score quality, correctness and coherence 4. Instrumentation relies on OpenInference and the AWS Distro for OpenTelemetry, and that holds whether agents run on AWS or in another cloud 1. Telemetry arrives over OTLP. Existing CloudWatch logs, metrics and traces appear without reconfiguration 3.

The shared data store is the real bet

Tracing LLM calls is now common, and plenty of startups do it. SiliconANGLE argues that Omni's distinguishing feature is that agent traces, application telemetry and infrastructure signals all live in the same CloudWatch store 1. In practice, an investigation could start with an agent getting a bad tool result, move to an API error from a capacity-limited service, and end at an exhausted database connection pool, all without leaving one system 1.

The architect's write-up on blog.devops.dev makes the same point in structural terms. Telemetry lands in CloudWatch once, every Omni surface reads the same correlated data, and evaluators write their quality scores into that store next to traces and metrics 3. The organizing unit is a "space," created in a central account and scoped to an application, team or set of workloads. A space can pull telemetry from multiple AWS accounts and Regions 3.

Capital One served as a design partner. The company has publicly praised the topology-aware intelligence, natural-language querying across telemetry, and data ownership through OpenTelemetry 1.

Where the money goes

The pricing details explain the cost dynamics. The IDE extension is free and doesn't require an AWS account. Data stays local by default, and developers need only Bedrock credentials or OpenAI/Anthropic keys to run models 2. Charges begin once telemetry ships to AWS, at standard CloudWatch-style ingestion and storage rates. Analytics includes a bundled allowance, which the AWS Builder Center post puts at roughly five times ingested volume at the base tier 2. AWS DevOps Agent, the natural-language root-cause layer, is priced separately 2. The first centralized copy of data is also free, which makes a hub-and-spoke observability account the obvious design 3.

None of these descriptions frames cost around per-user licensing. Every cost line described is tied to data volume. That matters because agentic workloads are unusually verbose. A single user request can fan out into multiple model calls, tool invocations, retries and evaluator runs, and each one can emit spans and logs. If instrumentation captures prompts, tool payloads and evaluation scores by default, ingestion can grow quickly. Adding more engineers to the web UI likely costs little by comparison.

The free local tier is a sensible on-ramp. As the Builder Center post notes, teams can instrument, trace and evaluate an agent without seeing a bill until they decide production telemetry is worth paying for 2. The hard budgeting decisions come at that point: what to sample, which payloads to keep, and how long to retain them.

Open standards, partial portability

Omni's OpenTelemetry foundation lowers switching costs because instrumentation isn't proprietary. SiliconANGLE cautions that open standards lower the lock-in bar without eliminating it 1. The instrumentation may be portable, but the correlated store, the spaces model and the AI-driven investigation layer stay inside AWS. Once a team's debugging workflow depends on following an agent failure down to infrastructure in one place, leaving becomes harder even if the raw data could move.

The takeaway

Omni's strongest argument is architectural: agent behavior, application errors and infrastructure health sit in one queryable place, which addresses the persistent question of why an agent did something. Its economics follow from that design. Teams evaluating Omni should model costs on telemetry volume per agent interaction, not headcount, and should treat sampling and retention policies as first-class engineering decisions from the start.