What Is Amazon CloudWatch Omni? Pricing, Setup, Agents

Amazon CloudWatch Omni is a new way to use CloudWatch, released on September 23, 2026: one sign-in URL for your whole team, your applications and your AI agents on one screen, an assistant that writes the query when you ask a question in plain words, and an AI investigator that opens on every alert. It is not a new data store and not a replacement. It reads the metrics, logs and traces you already send to CloudWatch, and switching it on changes nothing you run today. It is live in three Regions so far: N. Virginia, Oregon and Ireland. This page explains what AWS CloudWatch Omni actually is, how to set it up, what it costs across its three billing dimensions, what it does for agents, who can see what, and the one line on the bill that is not on Omni's own price sheet. If you searched "omni watch" and landed here, note that OmniWatch, the consumer device company, has nothing to do with this; this is Amazon's monitoring service.

Ethan's two-person shop had been running a customer's checkout API on ECS for a year, and Jake had the pager that week. At 2:10 a.m. the error-rate alert fired, and for the first time the alert did not just say "look at the dashboard." It opened an investigation with the dependency map already drawn, the failing service highlighted, and an AI agent's first analysis waiting at the top: a dependency had started timing out eleven minutes earlier, here is the log line, here is the likely cause. Jake fixed it in twenty minutes and went back to sleep impressed. Ethan was impressed too, until he read the fine print in the morning and asked the question this page is built around: "What did that agent cost us, and who switched it on?"

If you are new to the underlying service, our plain-English guide to Amazon CloudWatch is the foundation this page stands on, and the place to learn how CloudWatch works from the ground up: metrics are the pulse, logs are the diary, alarms are the doorbell. Omni does not change any of that. It changes who can see it, how you ask questions of it, and what happens when the doorbell rings.

What CloudWatch Omni actually is, and what it is not

For years the honest complaint about Amazon CloudWatch monitoring was not that it lacked data. It was that the data lived in a console designed around AWS resources, not around your application, and that every engineer who needed to read it needed an AWS console login and a tour. Omni is AWS's answer to that complaint. It is an interface and a set of workflows built on Amazon CloudWatch, reached through a dedicated URL of the form https://your-name.cloudwatch-omni.global.app.aws, signed into with the identities your company already manages, and organized around teams and the applications they run rather than around log groups and namespaces.

Three things make it more than a new coat of paint. First, it is built on OpenTelemetry, the open standard for telemetry, so anything you instrument that way, including workloads on Azure or in your own data center, sends to the same place and shows up beside your AWS services. Second, it discovers your services and the dependencies between them from the telemetry itself, with no configuration, and reports each one's request rate, error rate and duration, the three numbers every on-call engineer wants first. Third, it treats an AI agent as a first-class thing to monitor: a run is a trace, a step is a span, a conversation is a session, and the quality of the answers is scored beside the latency.

Now the "is not" list, because the name invites confusion. It is not a new database; there is a CloudWatch Dataset behind each space, but you keep managing ingestion, retention and log groups exactly where you always did. It is not a replacement for the CloudWatch console; your console pages, alarms, dashboards, Logs Insights queries and APIs all keep working, and enabling Omni disables nothing. It is not free, and it is not one price; the cost has three parts and a fourth that hides. And it is not OmniWatch, the consumer wearable company, nor anything to do with "omni-channel" contact-center software, both of which flood the search results for the plain word.

Domain, space, dataset: the three words you need

Everything about where your data lives and who can reach it comes down to three concepts, and the setup screens assume you know them.

Hold onto the "one space per account per Region" rule. It is the design decision most likely to surprise a team that has grown used to carving one AWS account into many dashboards. If you want a payments team and a search team to see different things, and they share an account, you separate them with grants and data scopes inside the one space, and we will get to what those can and cannot do.

What stays in CloudWatch and what Omni adds

The cleanest way to understand Omni is to know which door each setting lives behind, because after setup you will be working in two places, and the tool does not always tell you which one you need.

Two consequences of that split. Omni alerts and classic CloudWatch alarms are separate systems; there is no migration button, and an alarm you built last year stays an alarm. And data-protection masking policies you set on a log group do not carry into the Dataset, so if you rely on masking to keep card numbers out of the log view, test what an Omni user actually sees before you hand out grants.

How to set up CloudWatch Omni, step by step

The whole thing is two objects, a domain and a space, and one decision, whether you are setting up one account or an AWS Organization. Treat this as the CloudWatch tutorial for the new front door. I will walk the single-account path first because it is what most readers of this blog run, then the organization differences.

1. Open the CloudWatch console and go to Settings, then Omni, and choose Get started.
2. Pick the domain type. For one account choose Account domain. Enter a domain name: 3 to 63 characters, lowercase letters, numbers and hyphens, unique across all of CloudWatch, and not starting with aws-, amazon-, cloudwatch- or omni-. This becomes your team's URL, so choose it like a company name.
3. Complete the permissions step. Omni creates the IAM roles it needs in your account (listed below).
4. Create the space: a name, and confirm the account and Region. Remember the Region rule: the space belongs to one Region, and if you use IAM Identity Center for sign-in, your Identity Center instance must be in that same Region, or you enable its multi-Region replication first.
5. Connect your identity provider at the domain, through IAM Identity Center, which is how Okta or Microsoft Entra ID users get in. Skip this and your team signs in with IAM users or roles instead, usually through a deep link from the console.
6. Record the domain name and URL somewhere your team can find them. The URL is the front door from now on.

Creating the space silently turns on three CloudWatch capabilities in that account and Region, and you should know their names because each is a real feature with its own behavior: CloudWatch Dataset integration, which forwards your logs and traces into the Dataset; OTel metrics enrichment, which tags your AWS metrics with OpenTelemetry resource attributes so PromQL can query them; and Transaction Search, the account-level switch that makes span ingestion possible. Turning them on costs nothing by itself. Costs start when telemetry flows through them, and Transaction Search in particular is the one to watch, because it is account-wide and it is what makes traces start arriving.

Three IAM roles appear in your account: CloudWatchOmniOperatorRole, the primary role Omni assumes to manage the space and query telemetry, one per account and shared by every space in it; CloudWatchOmniDatasetIntegrationExecutionRole, which the CloudWatch Logs service assumes to forward into the Dataset; and AgentCoreEvaluationRole, used to run online agent evaluations, which is optional and can be pointed at your own role or skipped. Omni also uses an AWS Config recorder to discover resources and draw the map; if you have never turned AWS Config on, read that guide first, because Config has no free tier.

One pleasant detail: on first enablement Omni backfills the space with up to seven days of your existing CloudWatch logs and traces, so the map is not empty on day one. Two exclusions: anything older than seven days, and anything encrypted with a customer-managed KMS key. If your logs are KMS-encrypted, day one starts from now.

The organization path

If you run several accounts, an administrator creates one Organization domain from the AWS Organizations management account, and from then on any member account can create its own space, automatically linked to that domain, with one sign-in URL and one identity-provider configuration for everyone. Two extra rules apply. The organization domain must be created in the same Region as the primary Region of IAM Identity Center, with multi-Region replication enabled for any other Region where member accounts want spaces. And there is a role you create yourself and pass in, CloudWatchOmniDomainAccessRole, plus an integration-enablement role Omni creates in each member account.

Sending telemetry: what shows up on its own and what you must add

The best news in this guide is that if your workload already sends to CloudWatch, there is nothing to do. The CloudWatch agent, OTLP pipelines and the AWS SDKs keep sending exactly as they did, and that telemetry appears in Omni. Lambda functions deliver their own logs and segments with no agent to deploy. If you use the CloudWatch agent on EC2, ECS or EKS, it is the recommended collection path and the one the setup wizard assumes.

For everything else there are three OTLP endpoints, and the authentication rule differs by signal, which trips people up:

Traces are the signal Omni cares about most and the only one with no token path: whatever sends them must sign with short-lived AWS credentials. A workload on AWS compute signs with the role it already has. A workload on an Azure VM or AKS cluster, which Omni supports with a documented procedure, federates for temporary credentials. An on-premises host can use IAM Roles Anywhere to do the same rather than storing a long-lived key. Bearer tokens exist for metrics and logs only, are created from CloudWatch settings as a service-specific credential on a dedicated IAM user, and are meant for clients that genuinely cannot sign. And one line from the documentation deserves bold type: enable Transaction Search in the Region before you send traces, because until it is on, spans do not arrive and you will be debugging a pipeline that is working fine.

The application map, the Omni agent, threads and alerts

Once telemetry is flowing, Omni's daily surfaces are four. The application map is the discovered topology: every service, the arrows between them, and each one's request rate, errors and duration, with unhealthy services flagged. Nobody drew it; it comes from the traces. When you centralize across accounts and enable Context Graph in the rules, the map spans accounts, which is how a platform team finally sees that the search service in account B is what the checkout in account A is waiting on.

The Omni agent is the built-in assistant. You ask a question in plain language, it writes the query, in SQL against the Dataset or in PromQL against metrics, runs it against your own telemetry, and shows both the answer and the query so you can learn the syntax by reading over its shoulder. This is the feature for the engineer who has asked how to use CloudWatch without learning Logs Insights, and never will. Threads are investigations kept as a record: the signals you looked at, what you concluded, who was in it, so the postmortem writes itself. Alerts are Omni's own, distinct from CloudWatch alarms, delivered to Slack directly or anywhere else through SNS, and they are what open an investigation. Dashboards and alerts are included in the price, within service quotas, and a CloudWatch dashboard you built last year stays exactly where it is.

There is also a small thing for people who work from a coding agent rather than a browser: Omni ships skills for the Agent Toolkit for AWS, so a coding assistant can query your telemetry and set up ingestion from the terminal. If you have read our OpenShell guides, you will recognize the shape: the agent gets a narrow tool, not a console login.

The DevOps Agent, and the line that is not on Omni's price sheet

Here is the fine print Ethan found. When an alert fires, Omni opens an investigation session pre-loaded with context, and the AWS DevOps Agent provides its initial analysis at the top: correlated signals, the dependency path it suspects, suggested next steps. The launch post says it plainly: the DevOps Agent is enabled by default in every Omni investigation session. It is also a separate AWS service with its own price. It became generally available on March 31, 2026, and it bills at $0.0083 per agent-second for the time it is actively working on a task, with nothing charged while it is idle or waiting. That is about 50 cents a minute, or roughly $30 for an hour of continuous work.

Read Omni's pricing page top to bottom and you will not find that number. The page covers what you ingest, what you store, and what you analyze in Omni. The investigator is priced on the DevOps Agent's own page. So the honest picture of an incident's cost is Omni's query scanning, which is often free within the five-times allowance, plus however many agent-seconds the investigation consumed. AWS's own worked example for a small team is ten investigations a month at eight minutes each, which comes to $39.84. That is not ruinous. It is simply not on the sheet you were reading, and Ethan's question, "who switched it on," has the answer "the default did."

Two softeners, stated fairly. New DevOps Agent customers get a two-month free trial that starts with their first task, including 20 investigation hours a month, so your first incidents cost nothing. And AWS Support plans carry monthly credits toward it: 30% on Business and above, 75% on Enterprise, 100% on Unified Operations. If your shop has Business Support, a third of every investigation is already paid for. If you would rather not have the agent start automatically, that is a setting to look for when you create the space, and a question to ask before you give thirty engineers the URL.

CloudWatch Omni for agents: traces, sessions and quality scores

The half of Omni that is genuinely new, rather than a better front door, is agent observability. If you build anything with an AI agent, on Bedrock AgentCore or LangGraph or CrewAI or Strands or the OpenAI Agents SDK or the Vercel AI SDK, in Python or TypeScript, Omni will show you what it did and score how well it did it. The vocabulary is OpenTelemetry's: a trace is one complete agent run, a span is one step inside it, a model call, a tool call, a retrieval, with its timing, inputs and outputs, and a session is the sequence of traces that make up one conversation. An agent on AgentCore Runtime sends these with almost no setup; anything else connects through the OpenTelemetry SDK, exporting traces directly with no collector in between.

Then the part error rates cannot give you. An agent can return a well-formed, fast, error-free response that is wrong, and no latency chart will ever show it. Omni scores responses with evaluators, continuously on production traffic or on demand against a dataset, and the score sits on the same trace as the latency and the token count. Three kinds exist. Built-in evaluators cover correctness, helpfulness, coherence, retrieval quality and tool-use quality; some are rule-based, some use a judge model. Third-party evaluators bring the DeepEval and AutoEval open-source libraries, which add multi-turn checks such as knowledge retention and goal accuracy, and safety checks for bias, toxicity and PII leakage; AWS runs them for you but makes no quality claims about them, so validate one against your own traces before you trust it. Custom evaluators are yours: a model-as-judge rubric you write in plain language, a derived evaluator that reruns a built-in one on the judge model you choose, or a Lambda function for checks a rule can decide, such as "the response is valid JSON" or "it cites a real order ID."

Two honest cautions. The documentation is direct that built-in evaluators miss domain-specific failures: a support agent that cheerfully answers an off-topic cooking question scores high on helpfulness and high on policy, and every general criterion is satisfied while the agent has wandered out of scope. You write that rule yourself. And judge-based evaluators send the trace content, the user's words and the agent's answer, to the judge model for inference. If your traces can contain sensitive data, read the data-protection page before you turn on continuous scoring.

Evaluations run through Bedrock AgentCore and are billed at its rates, which Omni's pricing page points to rather than repeats: built-in evaluators cost $0.0024 per 1,000 input tokens and $0.012 per 1,000 output tokens the judge consumes, batch runs get 25% off, and custom evaluators cost $1.50 per 1,000 evaluations plus whatever model you chose to judge with. The pricing example AWS gives for an agent workload, one terabyte of spans, 0.6 terabytes of logs and 4,000 evaluated runs, comes to $657 a month before those evaluation charges.

Two surfaces: the web UI and the IDE extension

Agent monitoring lives in two places that connect to the same space. The Omni web UI is the production surface: fleet-level views, aggregate health, online evaluations, and the evaluation dashboard where a declining pass rate over a week tells you a prompt change regressed something even though every individual score looks fine. The IDE extension for VS Code, Kiro and Cursor is the development surface: instrumenting the agent with help from an assistant, running it locally, managing and versioning prompts, comparing two configurations side by side in the prompt playground, and running experiments against a dataset. Experiments and prompt versioning exist only in the extension; online evaluations and fleet views exist only in the web UI. The extension itself is free and can work locally without the cloud, then connect with a Cloud Login when you want the data kept and shared.

If the security side of running agents is what keeps you up, this pairs with our OpenShell guide: OpenShell decides what an agent may reach, Omni tells you what it did and how well.

Many accounts and Regions: how centralization works

Omni does not aggregate across accounts on its own, and the documentation says so in as many words. A space sees the account and Region that host it. To see more, you use CloudWatch centralization rules: created from the Organizations management account or a delegated administrator, a rule names source accounts and source Regions and a destination account and Region, and you set the destination to the account and Region that host your space. The centralized copies then appear in the space like any other telemetry. That is also how a company with workloads in Mumbai and Sydney uses a service that is only in three Regions: the space lives in Ireland or Virginia, and the rules bring everything to it.

Four things to know before you build on this. Centralization is not retroactive; only telemetry generated after the rule is active is replicated. Trace centralization needs Transaction Search enabled in every source account, after which traces follow the logs automatically. Cross-space queries are not supported, so if two teams need to query across accounts, centralize into one account rather than giving each a space. And centralization has a price: the first centralized copy is free, and each additional copy, a backup Region for example, costs $0.05 per GB, with standard CloudWatch pricing applying to the replicated data. The AWS multi-account pricing example, twelve accounts and three Regions with 30 TB centralized, lands at $12,976 a month, of which the disaster-recovery copy is $500.

CloudWatch Omni pricing, honestly: three dimensions and the fine print

The question "is CloudWatch free?", or its cousin "does CloudWatch cost money?", has always had a two-part answer, and our CloudWatch Logs cost guide covers the classic side. Omni's answer is cleaner to state: enabling it costs nothing, and using it costs in three places, ingest, store and analyze, with a fourth item, the DevOps Agent, on a different sheet. Here are the launch prices for US East (N. Virginia); other Regions differ.

Three observations, because a table is not advice. First, the storage tiers move on their own by access pattern, which is the opposite of classic log groups where you pick a class up front; data you stop reading gets cheaper without you touching it. Second, the analysis allowance is generous for normal use: if you ingest 100 GB of logs a month you can scan 500 GB of queries before the meter starts, and at $0.005 per GB the meter is slow even then. The bill is in ingestion, as it always was with CloudWatch. Third, OpenTelemetry metrics are priced per gigabyte, not per metric per month like classic custom metrics at $0.30 each for the first 10,000. A high-cardinality metric that would have been expensive one way can be cheap the other, and the reverse is also true; if you are moving metrics to OTLP, run the numbers with the CloudWatch pricing calculator before you flip the switch.

The classic CloudWatch free tier, 5 GB of log ingestion and 10 custom metrics a month, still applies to what you send; Omni adds no free tier of its own. There is a trial instead: $1,000 in credits for 30 days, for up to 10 accounts per Organization, and it applies to OpenTelemetry ingestion only. Not storage, not queries, not the DevOps Agent. Read it as "try sending your telemetry for free," not "try Omni for free."

For a sense of scale, AWS's own example of a single application on ECS and Lambda, 3 TB of logs, 1 TB of metrics and 1 TB of spans a month, comes to $2,393, and $2,350 of that is ingestion. If that number looks like more than your whole AWS bill, it probably is, and Omni at that volume is not for you yet; a small shop sending 20 GB of logs a month is looking at about $10 of ingestion plus storage, which is a different conversation. Our list of surprise AWS charges now has a candidate for next year's edition: the investigator that starts by itself.

Who can see what: IAM, grants and the gap between them

This is the section a security reviewer will read twice, and it should. Access to a space is decided in two independent layers, and both apply to every request. IAM decides whether a principal can reach Omni at all and what the service may do in your account; the actions are in the cloudwatch namespace. Grants, evaluated inside the space, decide what a member may do there, at one of four levels: Viewer, Editor, Space Admin, or Custom, which allows exactly the actions it lists. A grant can also carry a data scope that filters telemetry rows at query time, so a contractor sees only the log lines from their service.

Now the gap. Grants only add. A member's effective access is the union of every grant they hold, directly and through groups; the highest tiered level wins, there are no explicit denies, and you cannot take access away by adding a grant, only by removing one. A data scope on one grant does not narrow another: a second grant without a scope, including one inherited through a group, restores the full view. And the scope filters rows, not fields, and only on the telemetry query path; features that reach the same content another way are not filtered by it, which is why the documentation says plainly that a data scope is a convenience, not a security boundary.

The sharper edge is between the layers. A caller using IAM credentials directly, a script with an access key say, is authorized by the IAM policy alone, grant or no grant, unless the policy carries the condition key that ties the two together:

"Condition": {
  "Bool": { "cloudwatch:HasAccessGrant": "true" }
}

Add that to any role a program uses, and the role's Omni permissions are live only while the caller holds a grant for the space. Leave it out, and the grants you carefully arranged in the web UI govern the humans and not the scripts. Two more properties worth knowing for an audit. The space operator role is the ceiling for everything a space can do, and there is exactly one per account shared by every space in it, so you cannot isolate two spaces in one account with different operator roles. And a space always keeps at least one Space Admin: the grant that provides the last one cannot be deleted, and nobody can edit or delete their own grants, which is the right kind of inconvenient.

CloudWatch Omni vs Datadog, Grafana and the rest, briefly

Every "CloudWatch vs Datadog", "CloudWatch vs Grafana" and "CloudWatch vs Splunk" search is going to acquire an Omni chapter, so here is a fair one. What Omni changes in that comparison is the part CloudWatch used to lose on: a single URL with SSO and no console login, an application-centric map that draws itself, a plain-language assistant, and collaborative investigation threads. What it does not change: your data still lives in CloudWatch, in AWS's Regions, priced by AWS's ingestion model, and if your estate is half on another cloud, "supports Azure workloads via OpenTelemetry" is not the same as a vendor whose whole business is being neutral. Grafana remains the choice if you want to keep the data where it is and only rent the glass. Datadog and Dynatrace remain ahead on breadth of integrations and years of polish, at prices that are famously their own kind of surprise. Splunk remains the security team's tool, and Omni is not a SIEM any more than CloudWatch was. Where Omni has no real rival at launch is scoring AI agents' answers beside their latency inside the same product that watches your ECS cluster. If that is your problem, the comparison is short.

Should you turn it on? A decision by team size

One person, one account, a few services. Yes, because it costs nothing to enable, the map and the plain-language queries are a real upgrade over Logs Insights, and your ingestion is what it already was. Check one thing first: whether Transaction Search and Config were already on, because those start meters. Consider whether you want the DevOps Agent starting on every alert, and use the trial to find out what your incidents cost.

A small team, several accounts. Yes, with an Organization domain, and plan the centralization rules before the spaces, because centralization is not retroactive and the first copy is free. Put the space in one of the three launch Regions and bring everything to it. Decide who gets Space Admin, add the condition key to any automation role, and write down the operator-role ceiling.

A regulated shop. Probably, but read the access section with your reviewer, test that masking policies are not silently absent from the Dataset view, decide whether judge-based evaluators may see trace content, and bring your own KMS key to the space at creation time, in the same account and Region, with both decrypt and generate-data-key permission or the attach fails. And remember the one-space-per-account-per-Region rule when you draw the org chart.

Anyone running AI agents in production. This is the group Omni was built for, and the evaluation loop, instrument, analyze, score, experiment, monitor, then back around when a regression shows up, is the thing nobody else on AWS gives you in one place today.

The gotchas, in one list

1. One space per account per Region. Plan separation by account, not by dashboard.
2. Identity Center must be in the space's Region, or enable multi-Region replication first.
3. Space creation switches on Transaction Search, OTel enrichment and Dataset forwarding for the whole account and Region. Free until data flows; then not.
4. Masking policies on log groups do not carry into the Dataset.
5. Backfill is seven days and skips KMS-encrypted data.
6. Traces need Transaction Search on before you send; otherwise spans vanish silently.
7. Traces accept SigV4 only; bearer tokens are for metrics and logs.
8. Centralization is not retroactive; cross-space queries do not exist.
9. Grants only add; scripts bypass them without the condition key.
10. The DevOps Agent starts by default and bills by the second on its own price sheet.

For teams and IT: a rollout you can defend

1. Inventory the meters before the switch. Note whether Transaction Search, OTel enrichment and AWS Config are already on in the target account and Region. Omni turns them on; you should know the before state.
2. Create the domain from the management account, in the Identity Center Region, and connect the identity provider once. Do not let individual accounts create their own domains if you ever intend to run an organization.
3. Draft the centralization rules first, destination equal to the space's account and Region, and turn on Transaction Search in every source account, so day one of the space has data flowing.
4. Grants by group, scopes by service, and the condition key on every automation role. Write down which humans hold Space Admin and why.
5. Decide the DevOps Agent policy explicitly. On by default for everyone, on for the on-call role only, or off until the trial data comes back. Put the answer in the runbook.
6. Watch the first bill line by line in Cost Explorer: CloudWatch ingestion, Config, AgentCore evaluations, and the DevOps Agent as its own service.

If you take one habit from this page, let it be Ethan's morning question, asked before the incident rather than after: what starts by itself, and what does it cost when it does? Omni is a genuinely good front door on a service that badly needed one, and the agent-quality work is the first of its kind on AWS. It also switches on three meters at setup and a fourth on every alert, and none of that is hidden if you know where to look. Now you do. Enable it, watch the first bill line by line, and give Jake the URL; he earned it at 2 a.m.

Revision note. Written September 29, 2026, six days after CloudWatch Omni's general availability, from AWS's announcement, the Omni user guide, the Omni and DevOps Agent pricing pages and the AgentCore pricing page, all read that day. Prices are US East (N. Virginia) launch prices and will move; the Region list, the trial terms and the DevOps Agent default are as published on that date. If AWS adds Regions or changes the investigation default, this page gets a dated append.