setting-up-cloudwatch-observability
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 — enables running AWS CLI commands directly. All guidance also works with standard AWS CLI access (aws cloudwatch-omni ...).
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. |
| 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. |
| 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. Access Profiles only when async workloads are involved. 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 there is no references/cloudwatch/ today — CloudWatch onboarding (Application Signals) lives in aws-observability.