Amazon CloudWatch Omni went GA on September 22, and it is the biggest change to how people actually use CloudWatch since Logs Insights showed up. CloudWatch Omni is a standalone, AI-assisted observability experience with its own URL, its own sign-in, and an investigation agent that is switched on by default. It sits on top of the CloudWatch data you already have, so this is not a migration project. It is a new front door, and it changes who gets to walk through it.
This post is the engineer’s tour: how identity is wired, what a Space really is, where the service topology comes from, how OpenTelemetry fits, and what Amazon DevOps Agent is doing while you sip coffee during an incident. The launch details come from the AWS News Blog announcement.
What CloudWatch Omni actually is
Think of Omni as a layer, not a new datastore. Your logs, metrics, traces and alarms keep living where they live today. AWS is explicit that existing CloudWatch telemetry needs no reconfiguration, and existing alarms, dashboards and APIs are unchanged. Your Terraform that manages aws_cloudwatch_metric_alarm resources does not suddenly rot, and scripts calling the CloudWatch APIs keep working.
What changes is the experience on top:
- A single URL per Omni environment, reachable without the AWS console.
- Enterprise SSO through IAM Identity Center, federated to Okta, Microsoft Entra ID, or any SAML 2.0 IdP.
- Spaces that group services by team or application.
- Auto-discovery of services and their dependency topology.
- Adaptive alarms and SLOs.
- Amazon DevOps Agent embedded in every investigation session.
If you have spent years handing out read-only console roles just so a DBA could look at a latency graph, the first two bullets alone are worth the price of admission.
Identity: IAM Identity Center, not console roles
Omni authenticates people through IAM Identity Center. That matters more than it sounds. The classic console model assumes every human who needs to see a dashboard also gets an IAM principal in the account, which is how you end up with 40 “ReadOnlyForTheDataTeam” roles and nobody remembering who owns them. With Omni, the humans stay in your IdP, Identity Center brokers them in, and the Omni URL is all they need.
Before you enable anything, confirm which Identity Center instance you are working with and that your groups are syncing from the IdP. Group-based access is the pattern you want: map an on-call group to a Space, not individual users.
aws sso-admin list-instances \
--query 'Instances[].{Arn:InstanceArn,Store:IdentityStoreId}' \
--output table
aws identitystore list-groups \
--identity-store-id d-1234567890 \
--query 'Groups[].{Name:DisplayName,Id:GroupId}' \
--output tableIf list-groups comes back empty while your IdP clearly has groups, fix SCIM provisioning first. Omni can only be as organized as the directory feeding it.
Spaces: the unit of team ownership
A Space is a grouping of services, telemetry and people around a team or an application. Checkout gets a Space. Platform gets a Space. The data team gets a Space and finally stops asking you for screenshots. Investigations, alarms and SLOs are scoped to that context, so the payments on-call is not wading through the search indexer’s noise at 2 AM.
Design tip: model Spaces around ownership, not around AWS accounts. Accounts are a blast-radius boundary; Spaces are a “who gets paged” boundary. Those overlap sometimes, but a Space that mirrors your on-call rotation will age far better than one that mirrors your account vending machine.
Auto-discovery and topology
Omni builds a service map for you from two sources: the telemetry itself and AWS Config. Traces tell it which service calls which. Config tells it what the resources are and how they relate: the Lambda behind the API, the RDS cluster behind the Lambda, the queue in between. Put together, you get a dependency topology without hand-drawing boxes in a wiki page that went stale in 2023.
Two practical consequences. First, if AWS Config is not recording in an account or Region, expect thinner topology there. Second, trace coverage is what turns “resources that exist” into “services that talk to each other.” Uninstrumented services show up as islands.
OpenTelemetry and OTLP all the way down
Omni is built on OpenTelemetry and the OTLP protocol. That is the right call, and it means the instrumentation work you do is portable. If you are already running the AWS Distro for OpenTelemetry (ADOT) collector, you are most of the way there. The main thing to get right is resource attributes, because that is how discovery names and groups your services.
receivers:
otlp:
protocols:
grpc:
endpoint: 0.0.0.0:4317
http:
endpoint: 0.0.0.0:4318
processors:
batch: {}
resourcedetection:
detectors: [env, ec2, ecs]
exporters:
awsxray: {}
awsemf:
namespace: checkout
service:
pipelines:
traces:
receivers: [otlp]
processors: [resourcedetection, batch]
exporters: [awsxray]
metrics:
receivers: [otlp]
processors: [resourcedetection, batch]
exporters: [awsemf]On the application side, set OTEL_SERVICE_NAME and add deployment.environment and a team attribute through OTEL_RESOURCE_ATTRIBUTES. Consistent names are the difference between a clean service map and one that lists “unknown_service:python” six times.
DevOps Agent inside investigations
When you open an investigation session in Omni, Amazon DevOps Agent is on by default. Its job is the tedious first 20 minutes of every incident: pull the correlated metrics, scan the logs around the spike, walk the topology to see what is upstream and downstream, and propose hypotheses you can confirm or throw out. You stay the decision-maker; the agent does the tab-juggling.
Two things to keep in mind. The agent is only as good as the telemetry and topology it can see, so the instrumentation work above pays off twice. And “on by default” means your team should agree on how agent findings get recorded in postmortems. Treat its output like a sharp junior engineer’s notes: useful, fast, verified before anyone acts on it.
Adaptive alarms and SLOs
Omni adds adaptive alarms and SLOs on top of the classic static-threshold model. The pitch is fewer “CPU > 80%” alarms that page for a nightly batch job, and more alerting tied to what users feel. Your existing CloudWatch alarms keep firing exactly as before, so you can run both side by side, compare noise over a couple of weeks, and retire the static ones that lose.
What stays in classic CloudWatch
Everything you already use: the console, Logs Insights, metric math, composite alarms, dashboards, the APIs and every IaC definition built on them. Omni reads from the same data. That makes rollout low-risk. Enable it, wire SSO, build one Space for a team that is loud about observability pain, and let them kick the tires. Check the CloudWatch pricing page for how Omni and the investigation features are metered in your Region before you roll it out to every team at once.
If you run generative AI or agent workloads, there is a second half to this launch covering evaluators, Session Explorer and agent topology. AWS covers it in the companion post on agentic observability, and we dig into it this afternoon.
At Enkompass (enkompass.net), this is our home turf. We pressure-test new AWS services in real client environments the week they drop, so you get the upside without becoming the cautionary tale. If you’d rather have seasoned cloud people handle it instead of learning the hard way at 2 AM, let’s talk. Reach out through our contact page or call us directly at +1-828-436-5667 — we’ll help you turn this from a someday-project into a done-deal.