3.2.2.6. Building CloudWatch Dashboards & QuickSight Visualizations

3.2.2.6. Dashboards, Alarms & Visualization

Dashboards provide situational awareness; alarms trigger automated responses. Together they form the monitoring control plane.

CloudWatch Dashboards:

• Combine metrics from multiple AWS accounts and regions in a single view
• Widgets: line charts, stacked areas, numbers, gauges, text, log insights queries
• Auto-refresh intervals: 10 seconds to 15 minutes
• Share via public URL (for NOC screens) or embed in internal tools

Alarm architecture:

Loading diagram...

Alarm actions:

• SNS notification: Email, SMS, Lambda, HTTP endpoint
• Auto Scaling: Trigger scale-out or scale-in
• EC2 action: Reboot, stop, terminate, recover an instance
• Systems Manager: Run an Automation runbook

Composite alarms combine multiple alarms with AND/OR logic. Example: trigger only when both CPU > 80% AND error rate > 5% — reducing false positives from either metric alone.

# Composite alarm: only fires when both conditions are true
aws cloudwatch put-composite-alarm \
  --alarm-name "HighCPU-AND-HighErrors" \
  --alarm-rule 'ALARM("HighCPU") AND ALARM("HighErrorRate")'

Exam Trap: CloudWatch alarms evaluate based on the period and evaluation periods settings. An alarm with period=300s and evaluation-periods=3 requires the metric to breach the threshold for 15 consecutive minutes before firing. The datapoints-to-alarm setting lets you trigger after M of N periods breach (e.g., 2 of 3) for more sensitive detection. Getting these settings wrong is the most common cause of "alarm didn't fire" or "alarm fires too often."