AWS takes CloudWatch Omni's agent observability to eight more regions. Check where each step runs
Amazon CloudWatch Omni, AWS's AI-assisted observability experience with agent tracing across LangGraph, CrewAI and others, expanded to eight regions including Frankfurt, London and São Paulo.
Listen to this article · 4 min
AI-generated narration of the full article.
One customer request to an AI agent can touch five systems: the application’s front end, an orchestration framework, a model endpoint, two or three tools behind it, and a database in another cloud. When the answer is wrong or slow, the evidence is spread across all of them. That is the job observability for agents has to do, and on October 19 AWS made its newest attempt available in many more places.
What expanded
Amazon CloudWatch Omni, an AI-powered observability experience organized around teams and their applications, is now available in eight more AWS regions: Canada (Central); Asia Pacific (Mumbai, Singapore, Sydney and Tokyo); Europe (Frankfurt and London); and South America (São Paulo). It was already available in US East (N. Virginia), US West (Oregon) and Europe (Ireland).
Omni spans AWS accounts, regions and other clouds, including Azure and Google Cloud. It discovers services, maps dependencies and surfaces key metrics automatically, using OpenTelemetry for interoperability. Teams query telemetry through chat, point and click or the Agent Toolkit for AWS, and use AWS DevOps Agent to investigate root cause. For AI agents built on LangGraph, CrewAI, the OpenAI Agents SDK, the Vercel AI SDK and Strands, it provides an evaluation-driven workflow. A VS Code extension, with Cursor and Kiro support, is free; other pricing is on the CloudWatch pricing page.
What this changes
For teams outside the U.S., the practical effect is simple: a tool that could trace an agent across clouds was available only in three regions, and is now available near most large enterprise markets. For organizations that require operational data to stay in the EU or in Brazil, that is often the difference between a pilot and a production option.
The framework coverage also matters. Agent programs rarely standardize on one framework. Observability that reads several through OpenTelemetry, instead of requiring one vendor’s runtime, fits how agent estates actually grow. It also connects with the point we made about Snowflake’s agent observability: a trace that shows a 200 response does not show whether the agent was right, which is why the evaluation-driven workflow is the more interesting part of Omni.
What to check before relying on it
Where the AI steps process data. The announcement lists where Omni is available. It does not say where the AI-assisted investigation runs or where telemetry is processed. Omni relies on AWS DevOps Agent for root cause, and when we covered that agent we noted from AWS’s documentation that inference for U.S. Agent Spaces stays in the U.S. and region-restricting service control policies do not apply to its inference. For a team in Frankfurt or São Paulo, the question to put to AWS is specific: for each feature, which region processes the data and runs the model?
What the telemetry contains. Agent traces carry prompts, tool inputs and outputs, and often personal data. Decide what is redacted before it reaches the observability stack, not after.
How deep each framework integration goes. Supporting five frameworks does not mean equal depth. Check whether tool calls, retries and model parameters are captured for the framework you use.
What a diagnosis is worth. An AI-assisted investigation proposes a cause. As we argued about SRE agents’ findings, a diagnosis is a starting point that someone confirms, not a finding.
For where Omni sits among the other options, see our guide to AI agent observability tools.