On September 23, 2026, Amazon CloudWatch Omni became generally available. AWS describes it as an evolution of CloudWatch that lets you observe and troubleshoot applications and AI agents in one place.
The first impression may be "a new console with a lot of features." The home screen does list many of them. For a hands-on tour, a DevelopersIO post (in Japanese) builds an expense-reporting agent and tries almost everything, so I won't repeat that here.
If you read it only as another new screen, it is easy to miss what changed: who can investigate an incident there. Omni is reached through a dedicated URL for your organization, and people sign in with the accounts you already manage in Okta, Microsoft Entra ID, or a similar identity provider. With that setup, the people using Omni do not need access to the AWS Management Console (the console).
When your team first chose a monitoring tool, there was probably more than one reason. If one of them was "we want people without console access to help investigate incidents," this change is directly relevant. I compared Omni with what CloudWatch already offered, and checked which reasons for choosing a third-party observability platform still hold now that Omni exists.
Three things that changed with Omni
Omni has many features, but three of them matter for this article.
The first is how people get in. Each organization gets its own Omni URL. Accounts managed in Okta, Microsoft Entra ID, and similar providers connect to Omni sign-in through AWS IAM Identity Center. Without an identity provider, members sign in with IAM users or IAM roles. The AWS News Blog says SREs, developers, database engineers, and managers share the same data and investigation context.
The second is the recommended metrics format. The CloudWatch documentation now describes two metrics models: OpenTelemetry Metrics (recommended) and CloudWatch Metrics (Classic). This split did not start with Omni, though. It came with CloudWatch's native support for OpenTelemetry metrics in June 2026, and Omni is built on OpenTelemetry as well. I will come back to this later.
The third is the scope of data Omni works with. Beyond data across AWS accounts and Regions, it also covers workloads on Azure. According to the AWS Cloud Operations Blog, application and agent telemetry from Azure environments can be ingested today, with deeper multicloud support coming.
Collecting data across accounts and Regions is not something Omni does on its own, however. According to the Omni documentation, centralization still happens through CloudWatch centralization rules, and the centralized data then appears in an Omni space.
Your current setup does not change, either. The AWS News Blog describes Omni as extending CloudWatch: existing alarms, dashboards, APIs, and console workflows keep working as before. Existing users are not moved to Omni automatically; you opt in with the "Try CloudWatch Omni" button in the CloudWatch console.
Dashboard sharing has been around since 2020, with limits
The first change, access without the console, sounds new at first. But CloudWatch has long had a way to show data to people without console access: dashboard sharing.
Launched in September 2020, dashboard sharing lets you share dashboards with people who have no direct access to your AWS account. There are three options: share with specific email addresses, share publicly through a link, or share through a third-party single sign-on (SSO) provider.
So if all you needed was to show numbers to people outside the console, you never had to wait for Omni. Some organizations still chose a third-party observability platform over dashboard sharing. One likely reason is that the difference was not whether you could show data, but what people could do once they saw it.
What dashboard sharing hands over is a way to view a prebuilt dashboard. Viewers can look at the prepared graphs, but rewriting queries to find a cause, following traces, or digging into logs is not what it is designed for. During an incident, the most they can usually do is say, "this graph looks wrong."
Permissions are coarse, too. According to the documentation, the permissions needed for sharing include metric retrieval and EC2 tag lookups that cannot be scoped down, so anyone you share a dashboard with can query all metrics in the account and see the names and tags of all EC2 instances. The SSO option shares every dashboard in the account. Logs Insights widgets are not shown to shared users by default, and showing them requires adding permissions to the sharing IAM role.
Good enough for people who only need to see numbers, but not quite enough for people you want to investigate incidents with. That is roughly where dashboard sharing stops.
What Omni moves outside the console: a place to investigate
What Omni moves outside the console is the part dashboard sharing could not cover: investigating the cause of an incident. Side by side, the difference looks like this.
In Omni, you can turn natural-language questions into SQL or PromQL queries, follow traces, and work through root-cause investigations with AWS DevOps Agent. You can create alerts, too. All of this happens behind your organization's URL, without entering the AWS console. Where dashboard sharing was a way to view, Omni puts the place where investigation happens outside the console.
The obvious concern is permission granularity, the weak point of dashboard sharing. Even if you no longer have to hand out console access, if everyone in Omni can see everything, the question of who should see what remains open.
The Omni documentation shows this can be designed much more finely than with dashboard sharing. Members of a space are assigned a permission level: three tiers, Viewer, Editor, and Space Admin, plus Custom, which lists specific actions and resources.
Even Viewer, the most limited of the three tiers, can run queries, read logs, traces, and metrics, and ask the Omni agent questions. What Viewer cannot do is create or change alerts and dashboards; that starts at Editor. Reading data to investigate is available at the lowest tier, and permissions diverge at creating things in the space.
What a member can do also depends on more than their permission level. The IAM role the space uses to reach your AWS resources must allow the action as well. Making someone a Space Admin does not let them do anything that role does not allow.
There is also a way to narrow what data members see. By default, every member can read all telemetry in the space, but a data scope filters log and trace rows at read time.
The same access control documentation is explicit about the limits. Data scopes do not filter metrics. They also do not apply to dataset creation and export, AI-assisted summaries, or prompt playground runs, so a member scoped out of a field in queries can still reach that content by building a dataset over the underlying traces. The documentation asks you to scope those actions separately.
Here is what a data scope does and does not cover.
| Target | Can a data scope narrow it? |
|---|---|
| Log and trace rows | Yes |
| Metrics | No |
| Dataset creation and export | No (restrict the action itself with permissions) |
| AI summaries and prompt playground | No (restrict the action itself with permissions) |
For metrics, the same property as dashboard sharing remains: anyone in the space can see all of them. What Omni makes finer is which actions are allowed and which log and trace rows can be read. If you need to separate metric visibility by person, you will likely have to handle it through how you divide spaces.
Note also that it is the people using Omni who no longer need the AWS console, not the people setting it up. Enabling Omni, creating a domain and a space, and registering the first Space Admins all happen in the CloudWatch console, and adding or removing Space Admins afterward is also done there. If people sign in through IAM Identity Center, its instance must be in the same Region as the domain.
Taking stock: reasons for choosing third-party platforms over CloudWatch
With that in mind, I listed common reasons for choosing a third-party observability platform over CloudWatch, and checked whether each still holds at two points in time: with dashboard sharing, and with Omni. This is a structural look based on public information, not a product-by-product comparison.
The table shows whether CloudWatch at each point could meet each reason. "Yes" means CloudWatch alone can meet it, "Partly" means it can under some conditions, and "No" means it cannot, so the reason still favors a third-party platform. Reasons such as usability, which cannot be judged from specifications, are discussed after the table.
| Reason for choosing a third-party platform | Dashboard sharing (since 2020) | CloudWatch Omni (since Sept 2026) |
|---|---|---|
| Show numbers to people outside the ops team | Yes | Yes |
| Let people investigate incidents without console access | No | Yes |
| Limit what each person can see | No | Partly |
| See non-AWS environments in the same place | No | Partly |
| Build out notification and on-call workflows | Partly | Partly |
Reasons CloudWatch can now meet
The first row, showing numbers to people outside the ops team, was already met by dashboard sharing in 2020. What Omni newly meets is the second row: letting people take part in investigating incidents without console access. For organizations that chose a third-party platform for that reason, CloudWatch alone can now do the same.
"Can meet" does not mean your current platform becomes unnecessary. There are probably still differences in how deep you can investigate and how easy the tools are to use. It means that the next time you review your tooling, this reason carries less weight as the deciding factor for a third-party platform.
Reasons CloudWatch can meet under some conditions
Rows three through five depend on your situation and on the level you need.
For limiting what each person can see, as covered above, log and trace rows can now be narrowed, but metrics cannot. Combining permission levels and data scopes allows a fairly fine-grained design, but you also have to watch for actions such as dataset creation that reach content through another path.
For seeing non-AWS environments, Azure can be ingested today. However, what the Cloud Operations Blog mentions is application and agent telemetry, and deeper multicloud support is still only announced. If you run mainly on AWS and Azure and mostly need application telemetry, you can call it met; otherwise, it is fair to treat it as not yet met.
Notification and on-call workflows are a row Omni does not change. Notifications themselves were already possible before Omni through CloudWatch alarms and Amazon SNS. According to the DevelopersIO post, Omni alerts can notify Slack and SNS. On-call rotation and escalation features do not seem to be available yet. There is a way to send notifications, but running on-call takes extra work, such as combining it with other tools, so both columns say "Partly."
Usability, which the table cannot measure
Another common reason for choosing a third-party platform is a simple interface anyone can use without getting lost. It cannot be judged from specifications, so it is not in the table.
Usability can flip depending on the person or team. For Omni, the DevelopersIO author wrote that the number of features made it hard to know where to start at first, while also saying it seemed convenient to do so much from one screen once you get used to it. Whether a feature-rich screen feels confusing or convenient depends on each person's role and experience.
Comparing specifications will not answer this; you have to try it. The DevelopersIO author also suggests starting with a demo space or sample data.
Switching tools does mean relearning an interface. But that cost applies whenever you move to any tool, so it is not a difference between CloudWatch and third-party platforms, and it is not in the table either.
How you send metrics changed before Omni
Another change happened before Omni: the metrics format, the second of the three changes above. It affects how you send metrics from your applications.
On June 16, 2026, CloudWatch added native support for OpenTelemetry metrics. You send metrics over the OpenTelemetry protocol, query them with PromQL, and pay per GB ingested.
With this, the documentation organizes metrics into two models. OpenTelemetry Metrics is recommended and described as best for new workloads and high-cardinality use cases such as containers, where label values combine in many ways. The traditional format is called CloudWatch Metrics (Classic) and is positioned for existing integrations and lower-cardinality AWS service metrics.
The name "Classic" may suggest the old format is on its way out. However, the documentation states that both models are fully supported and that you choose based on your needs. Nothing here calls for rushing to migrate existing metrics.
The decision matters when you build a new way to send metrics. The CloudWatch documentation itself says that if you send metrics with OpenTelemetry, you can switch destinations with a configuration change rather than a code change. I would expect this to apply beyond CloudWatch: with a third-party platform that supports OpenTelemetry, switching to it later should also be a configuration change.
The reverse also holds, when moving from a third-party platform to CloudWatch. The metrics overview documentation says that OpenTelemetry SDKs and collectors that work with Prometheus, Grafana, and other backends can be used with CloudWatch as they are. Whether you stay with CloudWatch or send to a third-party platform, sending metrics with OpenTelemetry lowers the cost of revisiting the choice. With Omni also built on OpenTelemetry, standardizing how you send metrics on OpenTelemetry and deciding where to send them later has become a more realistic approach.
Region availability as a grace period
As of October 1, 2026, Omni is available in three Regions: US East (N. Virginia), US West (Oregon), and Europe (Ireland). Workloads in other Regions, such as Tokyo, can still be covered by centralizing their telemetry into a supported Region, but organizations that must keep monitoring data in-country cannot take that route. For them, actually using Omni will have to wait until it is offered in their Region. That waiting period is a grace period for the decision.
Still, this article is not about whether to replace tools right away; it is about whether your reasons for choosing a third-party platform still hold. Region coverage tends to expand over time, and if you have already taken stock when Omni arrives, the decision will be faster. The grace period is less a time to wait than a time to get organized.
Even after Omni arrives in your Region, organizations whose current third-party platform works well do not need to hurry. The DevelopersIO post closes on the same note: if your existing tools already work without problems, there is no need to rush a switch.
Organizations running mainly outside AWS and Azure may reasonably wait until support for other clouds becomes concrete.
And for organizations that have no trouble handing out console access, such as small teams where everyone already has AWS access, the reason in the second row of the table never applied. For them, Omni's value is measured by the investigation experience and agent monitoring, not by access.
Things to check before adopting Omni
The analysis so far is based on specifications, but more concrete questions come up when you actually consider adopting Omni.
When dashboard sharing is enough
You may ask whether dashboard sharing is enough if you only need to show numbers. If the audience is executives or other departments who are not expected to investigate, then functionally, yes. The first row of the table was already met by dashboard sharing.
Identity management changes the picture a little, though. Sharing with specific people issues an email address and password per person, which means managing identities separately from Okta or Microsoft Entra ID. The SSO option lets people use your corporate identities, but then every dashboard in the account is shared. You end up giving up either corporate identities or a narrow sharing scope.
With Omni, people sign in with their existing corporate accounts. Even for an audience that only looks at numbers, not having to create extra identities is a point in Omni's favor.
Alerts split across two systems
You might worry about managing alerts in two places. According to the DevelopersIO post, Omni alerts are separate from traditional CloudWatch alarms and did not appear in the console's alarm list. Existing alarms keep working, so nothing breaks, but without deciding what each system monitors, operations are likely to become harder to follow.
Feature breadth and learning cost
Some may worry that Omni has too many features for people outside the ops team to use. This is the usability gap the table cannot measure, mentioned earlier. Not having to hand out console access and being able to investigate right away are separate problems. Omni solved the first; the second is left to how your organization designs access and trains people.
What the narrowed gap means
Omni has narrowed some of the gaps with third-party platforms. That does not mean you should switch right away. Monitoring tool decisions are rarely revisited once made, and as contracts renew and teams get used to an interface, the original reasons for the choice can be forgotten.
While waiting for Omni in your Region, or before your next contract renewal, try writing down why you originally chose your tool. You will see which reasons still hold and which are losing their weight as deciding factors. Whether the gap has narrowed can only be measured if you remember why you chose what you did.
Top comments (0)