Study guide
10.2 CloudWatch Dashboards, Composite Alarms & Anomaly Detection
AWS Certified DevOps Engineer – Professional Exam
Track your progress as you read
Finished sections get a check mark.
1 Chapter 1: CI/CD Pipeline Architecture & Source Integration
1.1 Multi-Stage & Multi-Account CodePipeline Design 1.2 CodeBuild Projects, Build Environments & Pipeline Secrets 1.3 Source Control Workflows, Webhooks & Branching Models
2 Chapter 2: Automated Testing, Test Gates & Quality Verification
2.1 Automated Unit, Integration & Acceptance Testing in Pipelines 2.2 Load Testing, Performance Benchmarking & Synthetic Canaries 2.3 Security Scanning, SAST/DAST & Approval Gates
3 Chapter 3: Artifact Management & Multi-Platform Deployment Strategies
3.1 Artifact Lifecycle Management with CodeArtifact, ECR & S3 3.2 Automated Image Baking with EC2 Image Builder 3.3 In-Place, Rolling & Immutable Deployments on EC2 3.4 Blue/Green & Canary Deployments for ECS, EKS & Lambda
4 Chapter 4: CloudFormation, CDK & Reusable IaC Components
4.1 Advanced CloudFormation: Nested Stacks, Change Sets & Custom Resources 4.2 Cross-Account & Multi-Region StackSets & Drift Detection 4.3 Modern IaC: AWS CDK, SAM & Service Catalog Governance
5 Chapter 5: Multi-Account Architecture, Organizations & Control Tower
5.1 AWS Organizations Hierarchy, OUs & Account Provisioning 5.2 Service Control Policies (SCPs) & Multi-Account Guardrails 5.3 AWS Control Tower, Account Factory & Landing Zone Automation
6 Chapter 6: Systems Manager & Large-Scale Fleet Configuration
6.1 SSM Agent, Hybrid Activation & Session Manager 6.2 Systems Manager Run Command, State Manager & Associations 6.3 Patch Manager, Parameter Store vs Secrets Manager & AppConfig
7 Chapter 7: High Availability & Multi-Region Resiliency
7.1 Designing Resilient Multi-AZ & Multi-Region Architectures 7.2 Route 53 Traffic Flow, Health Checks & DNS Failover 7.3 Data Replication: Aurora Global DB, DynamoDB Global Tables & S3 CRR
8 Chapter 8: Scalability, Auto Scaling & Disaster Recovery Automation
8.1 EC2 Auto Scaling Policies, Lifecycle Hooks & Warm Pools 8.2 Container & Serverless Scalability: ECS Capacity Providers, EKS & API Gateway 8.3 Disaster Recovery Strategies: RTO, RPO & Architecture Tiers 8.4 Automated Backup & Recovery with AWS Backup & Elastic Disaster Recovery
9 Chapter 9: CloudWatch Metrics, Agent Collection & Log Aggregation
9.1 CloudWatch Metrics, Dimensions, Metric Math & High Resolution 9.2 Unified CloudWatch Agent & Custom Metric Collection 9.3 Centralized Log Aggregation, Retention & Cross-Account Subscriptions
10 Chapter 10: Log Analysis, Dashboards & Distributed Tracing with X-Ray
10.1 CloudWatch Logs Insights, Filter Syntax & Query Optimization 10.2 CloudWatch Dashboards, Composite Alarms & Anomaly Detection 10.3 Distributed Tracing with AWS X-Ray & Service Maps
11 Chapter 11: Automated Observability & Event-Driven Monitoring
11.1 Application & Infrastructure Health Checks with Route 53 & ALB 11.2 Centralized Observability with Amazon OpenSearch & Athena 11.3 Synthetic Monitoring with CloudWatch Synthetics Canaries
12 Chapter 12: Event-Driven Incident Detection & Notification Pipelines
12.1 AWS Health, CloudTrail Events & Operational Notification 12.2 EventBridge Event Routing, Patterns & Multi-Account Buses 12.3 Asynchronous Event Processing: SNS, SQS Queues & Dead-Letter Handling
13 Chapter 13: Automated Remediation & Deployment Troubleshooting
13.1 AWS Config Managed Rules & Automated Remediation with SSM 13.2 Event-Driven Infrastructure Self-Healing with Lambda & Step Functions 13.3 Troubleshooting CI/CD Pipeline & Deployment Failures 13.4 Root Cause Analysis for Auto Scaling & Container Failures
14 Chapter 14: Identity, Access Management & Secrets at Scale
14.1 IAM Policy Evaluation Logic, NotAction & Explicit Denies 14.2 IAM Permissions Boundaries & Delegated Administration 14.3 IAM Identity Center, Cross-Account Roles & STS Session Policies 14.4 Automated Secrets Management & Secret Rotation with Secrets Manager
15 Chapter 15: Security Automation, Data Protection & Compliance Auditing
15.1 Network Security Automation: Security Groups, NACLs, Network Firewall & WAF 15.2 Cryptographic Controls & Key Management with AWS KMS & ACM 15.3 Automated Threat Detection: GuardDuty, Inspector & Security Hub 15.4 Continuous Compliance Auditing & Log Integrity with CloudTrail & Config
10.2 CloudWatch Dashboards, Composite Alarms & Anomaly Detection
Key Takeaways Explain This Topic AI
CloudWatch OAM provides cross-account observability within one Region. Deploy a sink and same-Region links in every required Region, then use cross-Region dashboard widgets to compose the regional views in a central monitoring account.
Widgets support diverse operational views including metric time-series (line and stacked area), single numerical statistics, bar charts, dynamic CloudWatch Logs Insights query tables, and real-time alarm status grids.
CloudWatch Anomaly Detection applies machine learning algorithms over historical metric trends to generate dynamic upper and lower prediction bands, eliminating static threshold maintenance for workloads with cyclic or diurnal traffic patterns.
Composite Alarms combine multiple metric and anomaly detection alarms using Boolean expressions (AND, OR, NOT), drastically reducing alert fatigue and suppressing redundant downstream notifications during widespread outages.
Alarm suppression rules prevent composite alarms from triggering secondary alerts during scheduled maintenance windows, deployment rollouts, or when a root-cause suppressor alarm is already in an ALARM state.
Last updated: September 2026
CloudWatch Dashboards: Cross-Account & Cross-Region Architecture
Modern enterprise cloud architectures span hundreds of AWS accounts and multiple geographic Regions. Operating isolated dashboards within each individual account creates visibility silos and slows incident response. Amazon CloudWatch provides centralized, unified operational dashboards capable of rendering telemetry across accounts and Regions on a single pane of glass.
Cross-Account Observability via CloudWatch Observability Access Manager (OAM)
AWS CloudWatch Observability Access Manager (OAM) establishes secure, native cross-account telemetry sharing without requiring complex custom IAM role assumption scripts or third-party forwarding agents. [ Source Account A (111111111111) ] ──┐
- │ (Telemetry Link)
- [ Source Account B (222222222222) ] ──┼──> [ Central Monitoring Account (999999999999) ]
- │ - Unified Dashboards
- [ Source Account C (333333333333) ] ──┘ - Cross-Account Alarms / Metrics
Monitoring Account Configuration : In every Region that must be observed, a designated centralized operations account creates one OAM Sink using the regional CreateSink API. A sink resource policy ( PutSinkPolicy ) defines which source accounts are authorized to attach to the sink. The policy can authorize individual account IDs or an entire organization via aws:PrincipalOrgID : {
- "Version": "2012-10-17",
- "Statement": [
- {
- "Effect": "Allow",
- "Principal": "*",
- "Action": ["oam:CreateLink", "oam:UpdateLink"],
- "Resource": "*",
- "Condition": {
- "StringEquals": {
- "aws:PrincipalOrgID": "o-enterpriseorg123"
- }
- }
- }
- ]
- }
Source Account Configuration : Each workload account establishes an OAM Link using CreateLink , referencing a sink in the same Region. The link specifies which telemetry types to share, such as AWS::CloudWatch::Metric , AWS::Logs::LogGroup , and AWS::XRay::Trace . Repeat the link in every Region whose telemetry must be shared.
Cross-Region Dashboard Composition : OAM itself is a within-Region cross-account feature. After configuring regional sink/link pairs, dashboard widgets can specify their target region ; a single dashboard can then display an EC2 metric from us-east-1 , an Aurora metric from eu-west-1 , and a DynamoDB metric from ap-southeast-1 side-by-side. Alarms and composite alarms remain Region-scoped.
Dashboard Sharing Mechanisms
To share dashboards with stakeholders outside the primary AWS management console, CloudWatch provides three sharing architectures:
AWS IAM Identity Center (Successor to AWS SSO) : Provides enterprise users authenticated access to specific dashboards using corporate Active Directory or Okta credentials without provisioning IAM users in the AWS account.
Amazon Cognito User Pools : Authenticates external clients or contractors via username/password or third-party SAML/OpenID Connect identity providers.
Public Dashboard Sharing with Passphrase : Generates a publicly accessible HTTPS URL protected by a shared secret passphrase. Sensitive metric dimensions should be audited prior to enabling public sharing.
Dashboard Widget Types & Visualizations
CloudWatch Dashboards are defined as declarative JSON objects containing an array of widget definitions positioned on a 24-column responsive grid layout. {
- "widgets": [
- {
- "type": "metric",
- "x": 0, "y": 0, "width": 12, "height": 6,
- "properties": {
- "metrics": [
- [ "AWS/ApplicationELB", "TargetResponseTime", "LoadBalancer", "app/prod-alb/123", { "stat": "p99" } ]
- ],
- "period": 60,
- "region": "us-east-1",
- "title": "Production ALB p99 Latency"
- }
- }
- ]
- }
- Supported Widget Types
Line & Stacked Area Widgets : Display continuous time-series metrics. Stacked area widgets illustrate resource composition (e.g., memory utilization across multiple ECS task containers).
Single Value (Number) Widgets : Render the most recent aggregate scalar value with color-coded threshold formatting (e.g., displaying current active EC2 node count or daily error count).
Bar Charts : Display comparative categorical data across instances, Auto Scaling groups, or microservices.
Logs Insights Query Widgets : Embed live CloudWatch Logs Insights queries directly into the dashboard. The widget automatically executes the query and renders the resulting tabular or time-binned bar chart, refreshing on dashboard reload.
Alarm Status Widgets : Display the real-time operational status ( OK , ALARM , INSUFFICIENT_DATA ) of selected alarms in a compact grid, allowing operations engineers to instantly assess fleet health.
Text / Markdown Widgets : Embed static runbooks, operational standard operating procedures (SOPs), architecture diagrams, and emergency on-call contact links alongside live telemetry.
- Static Threshold Alarms vs. Machine Learning Anomaly Detection
- Limitations of Static Thresholds
In high-volume consumer-facing applications, traffic fluctuates dramatically following cyclic patterns (e.g., diurnal weekday peaks and late-night lulls). Configuring a static threshold alarm on a metric such as RequestCount or CPUUtilization introduces severe operational drawbacks:
A static threshold set for peak hours will fail to detect critical outages occurring during low-traffic off-peak hours (false negatives).
A static threshold set to detect off-peak anomalies will trigger false alarms during standard afternoon traffic spikes (false positives).
CloudWatch Anomaly Detection Architecture
CloudWatch Anomaly Detection applies supervised machine learning algorithms to historical metric data. The model continuously analyzes up to two weeks of metric history to identify:
Hourly, daily, and weekly seasonality.
Gradual macroeconomic and operational trends.
Random noise versus systematic shifts. Expected Value Band = Model Prediction ± (Band Width × Standard Deviation) Metric Value
^ Upper Threshold Band
│ . - ~ ~ ~ - .
- │ / \ [Breach: ALARM]
- │ / ~~~~~~~~~~~~~ \ * * *
- │ / / Actual \ \ / \
- │ │ │ Metric │ │ │ │
- │ \ \ / / \ /
- │ \ ~~~~~~~~~~~~~ / - ~ ~ -
- │ \ / Lower Threshold Band
- │ ` - ~ ~ ~ - '
- └──────────────────────────────────────────────> Time
- Configuring Anomaly Detection Alarms
Band Width (Standard Deviation Multiplier) : Controls the width of the prediction band. A lower number (e.g., 1 ) creates a narrow band, increasing alarm sensitivity. A higher number (e.g., 3 ) creates a wide band, alerting only on extreme, unprecedented deviations.
Evaluation Functions :
GreaterThanUpperThreshold : Triggers when the metric exceeds the expected ceiling (e.g., detecting unexpected latency or error spikes).
LessThanLowerThreshold : Triggers when the metric drops below the expected floor (e.g., detecting an upstream network partition dropping transaction volume).
OutsideBand : Triggers when the metric breaches either the upper or lower boundary.
Model Customization & Excluded Periods : During abnormal operational events (such as load tests, catastrophic regional outages, or Black Friday sales), DevOps engineers can configure Excluded Time Periods . This instructs the algorithm to ignore data points within those windows so the anomaly detection model is not skewed.
- Composite Alarms: Architecture & Boolean Logic
- The Alert Fatigue & Alarm Storm Problem
When a fundamental infrastructure dependency fails—such as an Amazon RDS database storage volume filling up—it triggers a cascade of individual metric alarms: database storage low, database CPU high, backend container connection pool timeout, Application Load Balancer HTTP 504 count high, and frontend API latency critical. On-call engineers receive dozens of simultaneous pager notifications for a single underlying incident, causing alert fatigue.
Composite Alarm Rule Mechanics
A Composite Alarm evaluates the states of other alarms using Boolean logic ( AND , OR , NOT ). A composite alarm does not monitor raw metrics directly; it monitors underlying child alarms (which can be standard metric alarms or anomaly detection alarms). Composite Alarm Rule Syntax:
- ALARM("alarm_name") | OK("alarm_name") | INSUFFICIENT_DATA("alarm_name")
- Logical Operators: AND, OR, NOT
- Production Example: Microservice Outage with Maintenance Suppression ALARM("alb-target-5xx-high")
- AND ALARM("ecs-container-cpu-critical")
- AND NOT ALARM("scheduled-maintenance-active")
This alarm transitions to ALARM only if both the ALB 5xx errors and container CPU are breached simultaneously, but suppresses all notification actions if the operations team has put the environment into scheduled-maintenance-active mode.
Alarm Suppression Rules
CloudWatch Composite Alarms support built-in Suppression Rules . An alarm can designate a Suppressor Alarm :
When the suppressor alarm is in the ALARM state, the composite alarm is prevented from executing any notification or remediation actions, even if its own Boolean rule evaluates to ALARM .
WaitPeriod : The duration (in seconds) that the composite alarm waits before evaluating its alarm state after the suppressor alarm transitions. This accommodates propagation delays during deployment rollouts.
ExtensionPeriod : The duration (in seconds) that the suppression state remains active after the suppressor alarm transitions back to OK . This prevents alarm thrashing while systems stabilize following maintenance or recovery.
Automated Operational Remediation Actions
CloudWatch Alarms (both metric and composite) support multi-target automated remediation workflows when transitioning between states ( ALARM , OK , INSUFFICIENT_DATA ):
Target Action Integration Mechanism DevOps Use Case
Amazon SNS Publishes JSON notification to an SNS topic Fans out alerts to PagerDuty, email, Slack webhooks, and AWS Lambda remediation scripts
EC2 Auto Scaling Executes Step Scaling or Simple Scaling policies Dynamically adds or terminates EC2 instances in response to acute traffic surges
EC2 Instance Recovery Triggers recover action on StatusCheckFailed_System Automatically migrates an EC2 instance to new physical hardware upon underlying host degradation while retaining instance ID, private IP, elastic IP, and EBS attachments
EC2 Power Actions reboot , stop , or terminate Reboots unresponsive application nodes or shuts down rogue instances
AWS Systems Manager Creates an SSM OpsCenter OpsItem or, for existing customers, an Incident Manager incident Tracks operational work; Incident Manager has not accepted new customers since November 7, 2025
Important
Action Constraint : Composite alarms can execute Amazon SNS notifications, create Systems Manager OpsItems, and, in accounts that already use the service, create SSM Incident Manager incidents. However, composite alarms cannot directly trigger EC2 Auto Scaling policies or EC2 instance recovery/reboot actions ; those actions must be triggered by underlying single-metric alarms.
DOP-C02 Exam Watchouts & Troubleshooting
Issue / Scenario Root Cause Resolution Protocol
Composite alarm fails to execute actions when child alarm triggers The rule expression syntax uses invalid casing or incorrect operator keywords Ensure alarm names in expressions match exactly: ALARM("name") ; operators must be uppercase ( AND , OR , NOT )
Cross-account dashboard shows Access Denied on metric widgets OAM Sink policy in the monitoring account does not include the source account or Organization ID Update PutSinkPolicy on the central OAM sink to allow oam:CreateLink from the source account's AWS Organization ID
Anomaly detection alarm triggers false alarms following a marketing campaign The ML model was trained on historical baseline data that did not anticipate the traffic surge Configure an Excluded Time Period covering the campaign window; allow 14 days of normalized traffic to re-train the model
Composite alarm attempts to trigger EC2 Auto Scaling action but fails configuration Composite alarms do not support Auto Scaling actions as direct targets Configure the Auto Scaling scaling policy on the specific underlying metric alarm; use the composite alarm for SNS/SSM alerting
Anomaly detection band fails to generate for a newly created custom metric The metric does not have sufficient data points to generate an ML statistical baseline CloudWatch requires a minimum of 3 days (ideally 14 days) of continuous metric data to establish accurate seasonality models