Amazon introduced CloudWatch Omni, an AI‑powered observability layer that sits on top of existing CloudWatch telemetry and is accessed through a dedicated URL rather than the AWS Management Console. Engineers get a shared workspace, automatic service discovery, and an AI assistant that surfaces correlated signals during an incident.
Key Changes in CloudWatch Omni
Omni re‑organizes observability around applications instead of individual metrics or logs. The service automatically discovers services, maps dependencies, and updates alarms when new components are deployed. Access is mediated by enterprise SSO via IAM Identity Center, supporting providers such as Okta and Azure AD, so no separate AWS console credentials are required.
The AI component, called Amazon DevOps Agent, joins investigation sessions, correlates signals, suggests next steps, and records the investigation history automatically.
Implications for Architecture and Operations
Because Omni consumes the same OpenTelemetry data that CloudWatch already receives, existing instrumentation does not need to change. Any workload that sends data to an OpenTelemetry Protocol (OTLP) endpoint will appear in Omni without additional configuration.
- Telemetry pipeline: Teams can continue using their current OpenTelemetry SDKs and exporters; Omni adds an OTLP endpoint for any new workloads.
- Service topology: Automatic discovery removes the need for manually curated dependency maps, which can simplify CI/CD pipelines that previously generated topology data.
- Incident workflow: An alarm triggers an investigation session pre‑populated with relevant traces, logs, and the DevOps Agent’s analysis, reducing the time spent gathering context.
- Spaces: A Space groups the applications a team owns, providing a logical boundary for telemetry and AI assistance.
Security and Access Considerations
Omni relies on enterprise SSO via IAM Identity Center. Access control therefore follows the identity provider’s policies rather than AWS console IAM policies. Practitioners should verify that SSO groups map correctly to the intended Omni Spaces to avoid unintended data exposure.
Because no AWS console credentials are required, the attack surface related to console access is reduced. However, the dedicated Omni URL becomes a new entry point that must be protected with the same MFA and session controls enforced by the identity provider.
Telemetry data remains stored in CloudWatch, so existing data‑retention and encryption settings continue to apply. The DevOps Agent operates on the same telemetry, so its suggestions inherit the confidentiality level of the underlying signals.
Related CloudNinjas coverage: AWS.
What This Means For Practitioners
Adopt the following steps to evaluate CloudWatch Omni for your environment:
- Confirm that all services already emit OpenTelemetry data; add an
OTLPexporter for any that do not. - Configure
IAM Identity Centerwith your corporate IdP and map groups to Omni Spaces. - Create a pilot Space for a single team, observe how automatic topology updates affect your deployment pipeline, and measure the reduction in manual dashboard effort.
- Review the investigation history captured by the DevOps Agent to ensure it meets your post‑incident documentation requirements.
- Monitor any cost impact from increased telemetry ingestion and from the AI‑assistant workload.
By aligning observability tooling with existing OpenTelemetry pipelines and centralizing incident context, CloudWatch Omni can streamline day‑to‑day operations while providing AI‑driven guidance. Teams should treat the new SSO‑based access model as a separate security boundary and validate that only authorized groups can view the shared workspace.