Study guide
9.1 CloudWatch Metrics, Dimensions, Metric Math & High Resolution
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
9.1 CloudWatch Metrics, Dimensions, Metric Math & High Resolution
Key Takeaways Explain This Topic AI
A CloudWatch metric is uniquely identified by a three-part coordinate: Namespace, MetricName, and a specific combination of Dimensions (up to 30 key-value pairs); CloudWatch treats different dimension combinations as entirely independent metrics without automatic aggregation.
Standard metric resolution stores data at 1-minute intervals, whereas High-Resolution metrics support 1-second, 5-second, 10-second, and 30-second granularities via PutMetricData with StorageResolution=1, decaying through four distinct retention tiers.
High-resolution CloudWatch alarms evaluate sub-minute periods (10-second or 30-second windows) to trigger automated Auto Scaling actions or incident remediation within seconds of acute performance regressions.
CloudWatch Metric Math enables on-the-fly mathematical and statistical transformations without publishing additional custom metrics, supporting functions such as RATE (per-second change), SEARCH (dynamic multi-resource discovery), and FILL (sparse data handling).
CloudWatch Metric Streams provide continuous, push-based delivery of near-real-time metrics to Amazon Kinesis Data Firehose (HTTP endpoints, Amazon S3, Datadog, Splunk), bypassing the throttling, latency, and cost limitations of legacy GetMetricData polling.
Last updated: September 2026
CloudWatch Metrics Architecture: Namespaces, Metric Names, and Dimensions
Amazon CloudWatch is the foundational monitoring and observability service for AWS workloads. To design scalable telemetry architectures, DevOps engineers must understand how CloudWatch structures, identifies, and isolates metric data.
Metric Identity Coordinates
A CloudWatch metric is not merely a name; it is uniquely identified by an exact three-part tuple:
Namespace : A container for CloudWatch metrics. Namespaces isolate metrics from different applications or services. AWS service namespaces follow the strict convention AWS/<service> (such as AWS/EC2 , AWS/ECS , AWS/RDS , AWS/ApplicationELB ). Custom namespaces cannot begin with AWS/ and typically reflect organizational domains (e.g., CustomApp/Payments , Enterprise/Billing ).
Metric Name : The specific performance attribute being monitored (e.g., CPUUtilization , TargetResponseTime , OrderProcessingLatency ).
Dimensions : A collection of name-value pairs (up to 30 dimensions per metric) that serve as categorical metadata identifying the specific entity or context (e.g., InstanceId=i-0123456789abcdef0 , AutoScalingGroupName=prod-frontend-asg , Environment=Production ). Unique Metric Identity = { Namespace, MetricName, [ Dimension_1, Dimension_2, ... Dimension_N ] }
The Dimension Aggregation Trap
Important
DOP-C02 Core Principle : CloudWatch treats every unique combination of dimensions as a completely independent, distinct metric! CloudWatch does not automatically aggregate or roll up data across dimensions.
For example, consider an application running on three EC2 instances that publishes a custom metric named FailedLogins in the CustomApp/Security namespace:
{ MetricName: "FailedLogins", Dimensions: [ { Name: "InstanceId", Value: "i-111" }, { Name: "Environment", Value: "Prod" } ] }
{ MetricName: "FailedLogins", Dimensions: [ { Name: "InstanceId", Value: "i-222" }, { Name: "Environment", Value: "Prod" } ] }
{ MetricName: "FailedLogins", Dimensions: [ { Name: "InstanceId", Value: "i-333" }, { Name: "Environment", Value: "Prod" } ] }
If you attempt to retrieve or alarm on FailedLogins using only the single dimension Environment=Prod , CloudWatch will return no data points . The metric with dimension [Environment] does not exist unless your code explicitly published a separate data point with only that dimension, or you use CloudWatch Metric Math SEARCH to aggregate across instances dynamically.
Standard vs. High-Resolution Metrics and Storage Retention
CloudWatch classifies metrics into two storage resolution classes:
- Feature Standard Resolution High-Resolution
- Data Point Granularity 1 minute (60 seconds) 1 second, 5 seconds, 10 seconds, or 30 seconds
- Publishing Method Default PutMetricData PutMetricData with StorageResolution=1
- AWS Service Metrics Standard for most AWS services Selected services (e.g., Step Functions execution metrics)
CloudWatch Alarm Period 1 minute, 5 minutes, 15 minutes, etc. 10 seconds or 30 seconds (High-Resolution Alarms)
- Cost Profile Standard custom metric pricing Standard custom metric price + PutMetricData API call volume
- Metric Retention Lifecycles and Resolution Aging
CloudWatch automatically rolls up and aggregates historical data points as they age through predefined retention tiers. You cannot alter these retention windows:
1-second data points : Retained for 3 hours . Highly ephemeral; ideal for real-time triage during automated deployments.
1-minute data points : Retained for 15 days . Used for operational day-to-day troubleshooting and standard dashboards.
5-minute data points : Retained for 63 days . Used for medium-term capacity planning and trend analysis.
1-hour data points : Retained for 455 days (15 months) . Used for long-term historical retrospectives and seasonal workload comparisons.
When high-resolution data ages past 3 hours, CloudWatch aggregates the 1-second data points into 1-minute aggregates, and they remain accessible under the 15-day retention tier.
- Publishing High-Resolution Metrics via CLI
- To publish high-resolution metrics, specify --storage-resolution 1 : aws cloudwatch put-metric-data \
- -namespace "CustomApp/Payments" \
- -metric-data '[
- {
- "MetricName": "TransactionLatency",
- "Dimensions": [
- {"Name": "Region", "Value": "us-east-1"},
- {"Name": "Tier", "Value": "API"}
- ],
- "Value": 42.5,
- "Unit": "Milliseconds",
- "StorageResolution": 1
- }
- ]'
- High-Resolution Alarms
Standard CloudWatch alarms evaluate metrics at periods of 60 seconds or greater. High-resolution alarms evaluate metrics at intervals of 10 seconds or 30 seconds :
When configuring an alarm on a high-resolution metric, setting the Period to 10 or 30 seconds creates a high-resolution alarm.
If the metric has a storage resolution of 1 second, CloudWatch aggregates the data points into the 10-second or 30-second period using the specified statistic (e.g., p99 , Average , Sum ).
High-resolution alarms evaluate every 10 seconds, allowing automated remediation (such as Auto Scaling group step scaling or Lambda rollback invocations) to trigger within 10–30 seconds of an outage rather than waiting several minutes.
CloudWatch Metric Math & Dynamic Analytics
Metric Math enables DevOps engineers to execute arithmetic expressions and statistical queries across multiple metrics without writing custom code or publishing synthetic metrics.
Core Built-In Functions
RATE(metric) : Calculates the per-second rate of change between successive data points. Essential for cumulative counters (e.g., converting a monotonic counter like TotalRequests into RequestsPerSecond ).
SEARCH('SearchExpression', 'Statistic', Period) : Dynamically queries and discovers metrics matching a schema. Particularly powerful in Auto Scaling groups where instance IDs change continuously.
FILL(metric, value | LINEAR | REPEAT) : Replaces missing or null data points with a static value, linear interpolation, or the previous value. This prevents alarm state thrashing during temporary low-traffic periods.
DIFF(metric) : Returns the absolute difference between consecutive metric data points.
SUM(metrics) , AVG(metrics) , MIN(metrics) , MAX(metrics) : Aggregates across arrays of metrics returned by expressions or search queries.
Example: Dynamic 5xx Error Rate Calculation
In modern microservices, alerting on raw 5xx count causes false alarms during peak traffic and missed alerts during low traffic. The robust indicator is the 5xx Error Rate Percentage . Metric Math calculates this dynamically across an Application Load Balancer: {
- "MetricDataQueries": [
- {
- "Id": "m5xx",
- "MetricStat": {
- "Metric": {
- "Namespace": "AWS/ApplicationELB",
- "MetricName": "HTTPCode_Target_5XX_Count",
- "Dimensions": [
- {"Name": "LoadBalancer", "Value": "app/prod-alb/1234567890abcdef"}
- ]
- },
- "Period": 60,
- "Stat": "Sum"
- },
- "ReturnData": false
- },
- {
- "Id": "mTotal",
- "MetricStat": {
- "Metric": {
- "Namespace": "AWS/ApplicationELB",
- "MetricName": "RequestCount",
- "Dimensions": [
- {"Name": "LoadBalancer", "Value": "app/prod-alb/1234567890abcdef"}
- ]
- },
- "Period": 60,
- "Stat": "Sum"
- },
- "ReturnData": false
- },
- {
- "Id": "eErrorRate",
- "Expression": "(FILL(m5xx, 0) / FILL(mTotal, 1)) * 100",
- "Label": "5XX Error Rate (%)",
- "ReturnData": true
- }
- ]
- }
Note : Wrapping m5xx in FILL(m5xx, 0) ensures that minutes with zero errors evaluate to 0 instead of null , while FILL(mTotal, 1) prevents division-by-zero errors when traffic drops to zero.
Dynamic Resource Discovery with SEARCH
To compute the aggregate CPU utilization across all instances currently belonging to an Auto Scaling group without hardcoding instance IDs: AVG(SEARCH('{AWS/EC2, AutoScalingGroupName} MetricName="CPUUtilization" AutoScalingGroupName="prod-payment-asg"', 'Average', 60))
SEARCH queries CloudWatch catalog metadata at runtime, finding every instance currently tagged with that Auto Scaling group dimension and aggregating their CPU utilization into a single composite metric.
Real-Time Metric Streams vs. Batch API Polling
Historically, external observability platforms (such as Datadog, Dynatrace, New Relic, or Splunk) and enterprise data lakes collected CloudWatch metrics via periodic API polling using GetMetricData or ListMetrics .
Limitations of API Polling
API Throttling & Rate Limits : GetMetricData has strict transactions-per-second (TPS) quotas. In multi-account enterprise environments with tens of thousands of resources, polling triggers ThrottlingException errors.
Data Latency : Polling is batched (typically every 5 to 15 minutes), delaying incident detection.
Escalating Costs : Every GetMetricData API call is billed per metric queried, creating massive cost overhead at scale.
Architecture of CloudWatch Metric Streams
CloudWatch Metric Streams replace polling with a continuous, push-based delivery model:
Streaming Mechanism : CloudWatch automatically captures metrics as they are published and streams them directly to an Amazon Kinesis Data Firehose delivery stream with sub-3-minute latency.
Output Formats : Supports OpenTelemetry 0.7 (standard protobuf/JSON representation) and JSON formatted payloads.
Delivery Destinations : Kinesis Data Firehose delivers the metric stream directly to:
- Amazon S3 (for analytical data lake storage via Athena/Glue)
- Third-party HTTP partner destinations (Datadog, New Relic, Splunk, Dynatrace, Sumo Logic)
- Custom HTTP endpoints (private SIEM or analytics platforms)
Granular Filtering : Metric streams can be configured with include filters or exclude filters by namespace (e.g., stream AWS/EC2 , AWS/ECS , and CustomApp/* while excluding noisy namespaces like AWS/Logs ).
DOP-C02 Exam Watchouts & Troubleshooting
Scenario / Symptom Root Cause Solution
Metric exists in console under InstanceId , but querying by AutoScalingGroupName returns No Data CloudWatch does not roll up metrics across dimension subsets automatically Publish metric data points with the AutoScalingGroupName dimension explicitly, or query using Metric Math SEARCH
High-resolution metric historical data older than 3 hours cannot be found at 1-second resolution CloudWatch automatically aggregates 1-second data points into 1-minute data points after 3 hours Query the metric using 60-second period; export real-time 1-second data via Metric Streams or Kinesis if long-term raw resolution is mandated
Composite alarm flutters between ALARM and INSUFFICIENT_DATA during low-traffic hours Metric expressions result in null when underlying metrics emit no data points Use FILL(m1, 0) or FILL(m1, REPEAT) within the Metric Math expression to substitute missing data points with predictable values
Metric Stream delivery to third-party endpoint fails silently IAM role used by CloudWatch Metric Streams lacks permissions to put records into Kinesis Data Firehose, or Firehose delivery stream is throttled Ensure IAM trust policy trusts streams.metrics.cloudwatch.amazonaws.com and grants firehose:PutRecord and firehose:PutRecordBatch