Set Up CloudWatch Omni: SSO, a Space, First Investigation

Reading about a new observability tool is nice. Breaking something on purpose and watching the tool catch it is better. In this walkthrough you will set up CloudWatch Omni from scratch: connect IAM Identity Center, create a Space for a team, deploy a tiny traced sample app, watch Omni discover it, inject a fault, and let Amazon DevOps Agent run your first investigation.

Omni went GA on September 22. It is a standalone web experience with its own URL and SSO, it works on your existing CloudWatch telemetry with no reconfiguration, and it leaves your existing alarms, dashboards and APIs alone. Background is in the launch post. Console labels on brand-new services shift quickly, so if a button name below differs slightly, trust the screen and the CloudWatch docs.

Prerequisites

• An AWS account in a Region where CloudWatch Omni is available, with admin-level access for setup.
• IAM Identity Center enabled (organization instance preferred), ideally federated to Okta, Entra ID or another SAML 2.0 IdP.
• AWS Config recording in the account and Region. Omni uses it, alongside telemetry, to build topology.
• AWS CLI v2 configured, plus zip and a Bash shell.
• A teammate willing to click an invite link and watch you break things.

Everything below uses us-east-1. Swap in your Region where needed.

Steps to set up CloudWatch Omni

1. Confirm Identity Center and grab your identity store ID. Omni signs people in through Identity Center, so start by making sure you know which instance you are using.

   aws sso-admin list-instances \
     --query 'Instances[0].[InstanceArn,IdentityStoreId]' \
     --output text

   Save the second value (it looks like d-1234567890). You will need it for groups.

2. Create a group for the team. Grant Omni access by group, never by individual. If your IdP syncs groups over SCIM, use an existing one instead and skip ahead.

   STORE_ID=d-1234567890
   
   aws identitystore create-group \
     --identity-store-id "$STORE_ID" \
     --display-name "orders-oncall" \
     --description "Orders team on-call, CloudWatch Omni Space members"

   Note the GroupId in the response.

3. Check that AWS Config is recording. Omni combines telemetry with Config data to draw dependencies. No recorder, thinner map.

   aws configservice describe-configuration-recorder-status \
     --query 'ConfigurationRecordersStatus[].[name,recording,lastStatus]' \
     --output table

   You want True and SUCCESS. If not, turn on recording in the Config console before continuing.

4. Deploy a traced sample app. One Lambda function writing to one DynamoDB table gives Omni a real dependency to discover. The FAULT_RATE variable is our chaos lever.

   cat > app.py <<'EOF'
   import os, random, uuid, boto3
   
   table = boto3.resource("dynamodb").Table("omni-demo-orders")
   
   def handler(event, context):
       rate = float(os.environ.get("FAULT_RATE", "0"))
       if random.random() < rate:
           raise RuntimeError("payment provider timeout (injected)")
       order_id = str(uuid.uuid4())
       table.put_item(Item={"orderId": order_id, "status": "NEW"})
       return {"statusCode": 200, "orderId": order_id}
   EOF
   zip function.zip app.py
   
   aws dynamodb create-table --table-name omni-demo-orders \
     --attribute-definitions AttributeName=orderId,AttributeType=S \
     --key-schema AttributeName=orderId,KeyType=HASH \
     --billing-mode PAY_PER_REQUEST
   
   aws iam create-role --role-name omni-demo-orders-role \
     --assume-role-policy-document '{"Version":"2012-10-17","Statement":[{"Effect":"Allow","Principal":{"Service":"lambda.amazonaws.com"},"Action":"sts:AssumeRole"}]}'
   
   aws iam attach-role-policy --role-name omni-demo-orders-role \
     --policy-arn arn:aws:iam::aws:policy/service-role/AWSLambdaBasicExecutionRole
   aws iam attach-role-policy --role-name omni-demo-orders-role \
     --policy-arn arn:aws:iam::aws:policy/AWSXRayDaemonWriteAccess
   aws iam attach-role-policy --role-name omni-demo-orders-role \
     --policy-arn arn:aws:iam::aws:policy/AmazonDynamoDBFullAccess
   
   ACCOUNT=$(aws sts get-caller-identity --query Account --output text)
   aws lambda create-function --function-name omni-demo-orders \
     --runtime python3.12 --handler app.handler --zip-file fileb://function.zip \
     --role "arn:aws:iam::${ACCOUNT}:role/omni-demo-orders-role" \
     --tracing-config Mode=Active \
     --environment "Variables={FAULT_RATE=0}"

   Active tracing is the important flag: it emits traces that show the Lambda-to-DynamoDB edge. The managed DynamoDB policy is fine for a demo; scope it down anywhere real. If create-function complains the role is not assumable yet, give IAM a moment and rerun it.

5. Generate baseline traffic. Omni and the agent need to see what normal looks like before you break it.

   for i in $(seq 1 150); do
     aws lambda invoke --function-name omni-demo-orders out.json >/dev/null
   done
   cat out.json

6. Enable CloudWatch Omni and connect Identity Center. In the CloudWatch console, open the Omni entry in the navigation and start setup. Choose your Identity Center instance, name the environment, and finish. You get a dedicated Omni URL. These are the values we used:

   Environment name:   acme-observability
   Identity source:    IAM Identity Center (instance from step 1)
   Access granted to:  group orders-oncall
   DevOps Agent:       enabled (default)

   Bookmark the URL. That is what you will hand to people who have never touched the AWS console.

7. Create a Space. Inside Omni, create a Space for the orders team and attach the group. Spaces are how Omni scopes services, alarms and investigations to the people who own them.

   Space name:     orders
   Members:        group orders-oncall
   Services:       omni-demo-orders (Lambda), omni-demo-orders (DynamoDB)

   If the services are not listed yet, give discovery a few minutes and move to the next step.

8. Invite a teammate. Create a user (or use a synced one) and add them to the group. They sign in at the Omni URL with their corporate credentials, no IAM role required.

   USER_ID=$(aws identitystore create-user --identity-store-id "$STORE_ID" \
     --user-name "sam.lee" --display-name "Sam Lee" \
     --name GivenName=Sam,FamilyName=Lee \
     --emails Value=sam.lee@example.com,Type=work,Primary=true \
     --query UserId --output text)
   
   aws identitystore create-group-membership --identity-store-id "$STORE_ID" \
     --group-id "<GroupId from step 2>" \
     --member-id UserId="$USER_ID"

9. Watch auto-discovery. Open the Space’s topology view. You should see the Lambda function with an edge to DynamoDB, built from traces and Config. To confirm the underlying trace data from the CLI:

   aws xray get-service-graph \
     --start-time $(date -d '-30 minutes' +%s) --end-time $(date +%s) \
     --query 'Services[].[Name,Type]' --output table

10. Inject the fault. Flip half the requests to failure and drive traffic again.

    aws lambda update-function-configuration --function-name omni-demo-orders \
      --environment "Variables={FAULT_RATE=0.5}"
    
    aws lambda wait function-updated --function-name omni-demo-orders
    
    for i in $(seq 1 200); do
      aws lambda invoke --function-name omni-demo-orders out.json >/dev/null
    done

11. Run an investigation. In the orders Space, start an investigation on the function’s error spike. DevOps Agent is on by default and begins pulling metrics, logs and topology. Give it a clear prompt:

    Errors on omni-demo-orders jumped in the last 15 minutes.
    What changed, which dependency is involved, and what should we check first?

    A good result points at the injected RuntimeError in the logs, notes DynamoDB is healthy, and ties the start of errors to the configuration update. Have your teammate open the same session so you both see the evidence live.

12. Fix, review history, clean up. Roll back the fault, then open the investigation history to see the timeline, hypotheses and what the agent examined. When you are done, tear down the demo.

    aws lambda update-function-configuration --function-name omni-demo-orders \
      --environment "Variables={FAULT_RATE=0}"
    
    aws lambda delete-function --function-name omni-demo-orders
    aws dynamodb delete-table --table-name omni-demo-orders

    Detach the three policies and delete the role too, so no stray permissions hang around.

Troubleshooting the usual suspects

The Space shows no services. Discovery needs data. Confirm the baseline loop actually ran, that active tracing is on for the function, and that Config is recording in the same Region you enabled Omni in. A service map built from zero traces is, predictably, empty.

Your teammate cannot sign in. Nine times out of ten, the user is not in the group you granted, or the IdP has not pushed the change through SCIM yet. Check membership with aws identitystore list-group-memberships before blaming Omni.

The agent’s answer is vague. That usually means thin evidence, not a dumb agent. Drive more traffic so the error spike is obvious, keep the prompt specific (service name, time window, symptom), and ask follow-up questions in the same session instead of starting over. The agent keeps the context of what it already checked.

Nothing looks different in classic CloudWatch. Correct, and that is the point. Omni reads the same logs, metrics and traces. Your old console views and alarms behave exactly as before, so you can run both while the team gets comfortable.

What you built

You now have CloudWatch Omni running behind corporate SSO, a Space tied to a real on-call group, a service map that drew itself from traces and AWS Config, and one completed AI-assisted investigation with history you can show in a postmortem. None of it touched your existing CloudWatch alarms or dashboards.

Next moves: instrument your real services with OpenTelemetry so discovery has more than one function to chew on, and if you run AI agents, read the agent observability launch post for evaluators and Session Explorer.

At Enkompass (enkompass.net), this is our home turf. We run new AWS services through real client environments the week they ship, so you get the upside without becoming anyone’s 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.