Amazon CloudWatch Omni: the AI that joins your incident

CloudWatch Omni is generally available as of 23 September 2026, and the most useful sentence in AWS's own launch walkthrough is the one about the human: the on-call SRE confirms the deployment correlation and pulls in the trace view. The AI correlates and suggests. A person still decides. That division is the thing to design your rotation around.

AWS announced the general availability of Amazon CloudWatch Omni, "an evolution of Amazon CloudWatch", in US East (N. Virginia), US West (Oregon) and Europe (Ireland). It is two launches sharing a name: a new operator-facing observability surface, and a separate agent-observability toolchain for teams shipping generative AI. Here is what each one does today, what it does not, and what it costs.

What CloudWatch Omni does today

Omni is a dedicated URL for your organization, deliberately outside the AWS Management Console. Engineers sign in through IAM Identity Center with your existing provider — AWS names Okta and Azure AD — and AWS states plainly that "No AWS Console access is required". For an on-call rotation that includes contractors or a platform team that does not hand out console access, that is a bigger operational change than the AI.

The rest of the surface:

• Automatic topology. Omni "discovers your services, maps dependencies, and adjusts alarms automatically", so the service map is derived rather than maintained by hand.
• Your existing telemetry, unchanged. Logs, metrics, traces and alarms already in CloudWatch are immediately available, and anything else arrives at an OpenTelemetry Protocol (OTLP) endpoint.
• Other environments. Connectors bring in telemetry from elsewhere; the What's New post names cross-account and multi-cloud telemetry across AWS and Azure.
• Plain-English queries. You can ask Omni a question about your applications in English and it analyses the telemetry to answer.

Note what is not in that list: nothing here replaces instrumentation. If your services emit thin traces and unstructured logs today, Omni maps a thin dependency graph and answers questions from thin data. The work of getting good signals out of an estate has not changed, and it is still the expensive part — the same lesson as a large OpenTelemetry migration.

What the Amazon DevOps Agent actually does

AWS describes the behaviour narrowly, and the narrowness is the honest part. When something breaks, Omni opens an investigation session pre-loaded with context, and the agent "participates alongside your team in investigation sessions, correlating signals and suggesting next steps". It identifies correlated events across services and traces root cause paths through the dependency graph. The session captures investigation history automatically, so AWS claims "No separate incident report needed".

Correlate, suggest, record. That is the job. In AWS's own worked example the SRE confirms the correlation the agent proposed and opens the trace view themselves. Nothing in the launch post describes the agent rolling back a deployment, scaling a service or closing an incident on its own authority.

One naming wrinkle worth knowing before you search for documentation: the Omni launch post calls it the Amazon DevOps Agent, while the same capability reached general availability on 31 March 2026 as AWS DevOps Agent. That earlier announcement claims it reduces mean time to resolution "from hours to minutes" — an AWS capability claim, presented without a study behind it, so treat it as marketing until your own incidents say otherwise.

Agent observability is the other half of the launch

The second launch post covers observability for generative AI and agentic workloads, and it is a different product shape: an IDE extension plus an evaluation workflow. Traces appear as you run your agent in VS Code or Kiro, instrumented through OpenInference and ADOT rather than a proprietary SDK. AWS ships 17 built-in evaluators for metrics including coherence, helpfulness, faithfulness and routing correctness, plus third-party evaluators AutoEval and DeepEval, a prompt playground, an experiments view for comparing agent variants, a session explorer and an agent topology view.

Framework coverage is broad — LangChain, LangGraph, CrewAI, the OpenAI SDK, Strands and the Vercel AI SDK, in Python and TypeScript, alongside agents built with Amazon Bedrock AgentCore. AWS also states that "The IDE extension is free to use. You don't need an AWS account to get started", which makes it unusually easy to trial against an agent you already run elsewhere. If you are already tracking sessions and token spend, this covers similar ground to the controls we described in AI agent observability.

What CloudWatch Omni costs

There is no separate charge for Omni itself. The CloudWatch pricing page says standard CloudWatch rates apply for ingestion and storage, and that you pay for what you query above an included allowance. The Omni pricing page puts numbers on it:

Line	Rate	Unit
Application and custom logs, OpenTelemetry metrics	$0.50	per GB ingested
Spans	$0.35 to $0.15	per GB ingested, tiered
Storage (standard / infrequent access / archive instant access)	$0.030 / $0.018 / $0.006	per GB-month
Log and trace analysis	$0.005	per GB scanned
PromQL queries	$0.01	per million samples

The allowance that matters: query volume up to five times your monthly log and span ingestion is free, which covers ordinary dashboarding and leaves you paying for pathological scans. Agent evaluations are billed at Amazon Bedrock AgentCore Evaluations rates rather than a CloudWatch line item.

What is not published, as of 23 September 2026, is a price for the DevOps Agent's participation in an investigation. The Omni pricing page prices telemetry, not the agent's involvement, and the launch post points only at the CloudWatch pricing page. If the agent's time is billed, we could not find the rate card; assume it will appear and ask your account team before you build a rotation around it.

What we would keep human

Our judgement, not AWS's. In the systems we build, an AI that correlates signals is unambiguously useful, because correlation across a dependency graph is a data problem and machines are better at it than a person reading five dashboards at 3am. Three things we would not hand over:

1. The decision to act on production. Rolling back, failing over or shedding load has a blast radius, and a suggestion engine that is right most of the time is exactly the profile that produces a rare, confident, very expensive mistake.
2. Declaring the incident over. An agent that captured the investigation history has an incentive to consider the narrative complete when the signals recover. Recovery and resolution are different events.
3. The write-up that changes the system. Automatic investigation history is a transcript, not a post-incident review. The value of the review is the argument about what to change, and that argument is where your engineers learn the system.

The strongest counter-argument is real: teams that keep a human in every loop simply stay slow, and a 3am human is measurably worse than a rested machine. We would answer it with scope rather than principle — let the agent act unattended on reversible, bounded operations, and require a person for anything that is not both. That is the same line we draw when designing failure drills, as in chaos engineering for payment systems.

If you are evaluating Omni this quarter, the useful experiment is not "can the agent find root cause". It is: run it alongside your existing rotation for a month, and count how often its suggested next step was the step your engineer actually took. That number tells you where to set the boundary. Our infrastructure management and monitoring and DevOps and cloud engineering work starts from the same measurement rather than from the vendor's claim.