CloudWatch Omni swaps threshold tuning for availability and latency targets you declare

Alarm configuration is inverted here. You declare availability targets, latency budgets and error rate thresholds, and Omni discovers services, maps dependencies and adjusts alarms as the system changes, according to AWS ^[6]. AWS says the application topology updates automatically when you deploy new services ^[7]. Both behaviours depend on the service graph being derivable from telemetry, so what has to be right is your OpenTelemetry resource attributes. If two deployments of the same service report different service names, the topology splits them.

The ingest path is plain. Telemetry you already send to CloudWatch appears in Omni with nothing to reconfigure, and any other workload you instrument with OpenTelemetry sends to an OTLP endpoint ^[4]. The adoption cost sits in instrumentation coverage. Amazon DevOps Agent works from the same telemetry the engineers see ^[8], so a service that emits no spans is missing from the graph it reasons over.

The worked incident in the post is a claim about a workload AWS chose. An alarm fires on elevated error rates in a checkout service, and the session opens with the service topology and correlated signals: a deployment ten minutes earlier, and increased latency from a downstream payment API ^[15]. The escalation is the specific bit. The payments engineer joins the same session and sees DevOps Agent's correlation with a configuration change in the payment provider's API gateway ^[16]. For that correlation to show up in your account, a third party's change has to be visible in telemetry you collect. In most stacks a provider's gateway change arrives as a status code or a latency shift, not as a change event in your own traces.

Sign-in moves to your identity provider. Every engineer reaches Omni at a single URL with enterprise SSO through IAM Identity Center, which AWS says supports Okta, Azure AD and other SAML 2.0 providers, and no AWS Console access is required ^[5]. Setup runs the other way: open the CloudWatch console, click "Try CloudWatch Omni", connect the identity provider, then create a Space grouping the applications your team owns and their telemetry ^[14]. The console permission set you keep maintaining is the admin one, and everyday access is decided by IdP group membership.

The budget claim is AWS's. Engineering teams spend a significant portion of their observability time maintaining dashboards, tuning thresholds and switching between tools to piece together what happened during an incident, the post says ^[10], and context crossing team boundaries gets lost in Slack threads and screenshots ^[11]. That is a vendor's characterisation of how its customers spend their week, and I would check it against my own on-call record before repricing anyone's time. AWS also says the investigation history is captured automatically, with no separate incident report needed ^[17]. Whether a session transcript satisfies your incident review process is a question for the people who run it. The post does not include pricing or availability.