/setting-up-cloudwatch-observability

name: setting-up-cloudwatch-observability
description: >-
  Sets up CloudWatch Application Observability (also called Omni) for the first time. Covers creating an Omni
  Space or Domain; configuring and listing Omni access grants (who has access and at what level) and access
  profiles bounding what async alerts, integrations, or agents can do; instrumenting an application or AI
  agent with the ADOT SDK so traces reach CloudWatch Omni (Python/Node/Java/.NET on EC2/ECS/EKS/Lambda) —
  CloudWatch Omni only; for Application Signals (auto-instrumentation, monitored service, ServiceEvents,
  reporting telemetry) use aws-observability — including no-image-rebuild and .NET CoreCLR profiler env vars;
  ingesting Azure telemetry via the CloudWatch agent on an Azure VM or AKS cluster; connecting Slack to a
  Space (and whether GitHub can be connected); and registering a custom MCP tool server over HTTP or stdio and
  choosing its auth (API key, bearer, or OAuth2). For using a Space already set up — querying, dashboards,
  Omni alerts, or defining Omni resources as code — use aws-observability.
version: 2

Setting Up CloudWatch Application Observability

> **Scope:** First-time setup of a CloudWatch Application Observability Space — from creation through first traces flowing. For using a Space that is already set up (queries, dashboards, alerts, evaluations), route to **aws-observability**.

**Works best with** the [AWS MCP server](https://docs.aws.amazon.com/aws-mcp/) — enables running AWS CLI commands directly. All guidance also works with standard AWS CLI access (`aws cloudwatchomni ...`).

Concepts

| Term | What it is | |---|---| | **Domain** | The identity boundary. Carries the authorization provider (IAM or Identity Center) and owns the endpoint URL customers reach Omni through. One per account, or one shared across an AWS Organization. | | **Space** | A workspace holding telemetry, in exactly one account and one Region. Created under a Domain. At most one per account per Region. Region rule: under an IAM-only Domain a Space may sit in a Region other than the Domain's; under an Identity Center Domain the Space must be in the Domain's own Region — Identity Center plus Spaces in several Regions needs the org-scoped Domain. | | **Access grant** | Attaches a principal — person, group, IAM identity, or async workload — to one Space at a permission level. The only way anyone reaches data *through* a Space — it does not restrict the source CloudWatch log groups, which stay readable under their own IAM. | | **Access Profile** | A named boundary for async workloads (alerts, integrations, agents) that act without a person in the loop. It is only a named container: `create-access-profile` takes a Space, a name, and a description and nothing else — no permission, action, or scope input. It does something only once two separate sets of grants exist (what the profile may do; which workloads may assume it) and a workload names it. | | **Dataset** | What queries run against. Telemetry arrives through the CloudWatch OTLP endpoints, or by forwarding what is already in CloudWatch log groups. |

Setup order from nothing: **Domain → Space → grants → telemetry in → instrumentation.** "Telemetry in" (a collector exporting to CloudWatch's OTLP endpoints, plus dataset forwarding for what is already in CloudWatch) is its own step, separate from instrumenting the workloads. Access Profiles are **conditional**, not a step in the sequence — only when async workloads (alerts, integrations, agents) are involved. Whenever you give this sequence, also say that instrumentation or forwarding started before a Space exists appears to succeed while delivering telemetry nowhere the customer can see — a customer who checks Omni first reads a working, empty Space as a failure. For the concept relationships and the full arc, see `references/cloudwatch-omni/app-basics.md`.

This is a **routing skill**. Classify the user's setup request and delegate to the correct reference. References live under `references/cloudwatch-omni/` (CloudWatch Omni); this skill has no CloudWatch setup content, so it has no `references/cloudwatch/` folder — CloudWatch onboarding (Application Signals) lives in **aws-observability**.

| User intent | Reference | |---|---| | Understand **what Omni is**, its concepts, or **where to start** | `references/cloudwatch-omni/app-basics.md` | | **Instrument an AI agent** (ADOT, OpenInference, framework detection, trace verification), or **deploy an agent to production** and get traces flowing to CloudWatch — env vars per platform (AgentCore, Lambda, or other platforms such as ECS/EC2/EKS), routing spans to a custom trace log group, IAM permissions needed, ADOT version requirements | `references/cloudwatch-omni/omni-agents-instrumentation/omni-agents-instrumentation.md` (§ Production deployment for the deploy case) | | **Per-framework OpenInference guide** (LangChain, LangGraph, Strands, CrewAI, OpenAI Agents, Vercel AI) once the agent framework is known | `references/cloudwatch-omni/omni-agents-instrumentation/openinference-framework-guide.md`, then the matching `references/cloudwatch-omni/omni-agents-instrumentation/instrument-<framework>.md` | | **Instrument an application** (ADOT SDK on EC2/ECS/EKS/Lambda — Python, Node.js, Java, .NET) | `references/cloudwatch-omni/instrumentation/instrumentation.md` | | Emit a **custom application or agent metric** so it is queryable in Omni (why OTLP and not `PutMetricData`/EMF) | `references/cloudwatch-omni/instrumentation/instrumentation.md` (§ Custom metrics) | | Create an **account-scoped Space or Domain** | `references/cloudwatch-omni/spaces-and-domains.md` | | Whether a Space can be in a **different Region from its Domain** | `references/cloudwatch-omni/spaces-and-domains.md` (Prerequisites → Region rules) | | The **AgentCore evaluation role** that `create-space` asks for — what it is, whether to create one | `references/cloudwatch-omni/spaces-and-domains.md`