ExamFinch.com My Study

Study guide

1.3 Metric Alarms, Anomaly Detection & Composite Alarms

Practice this exam

AWS Certified CloudOps Engineer – Associate SOA-C03

Track your progress as you read

Finished sections get a check mark.

1 Chapter 1: Monitoring & Observability Infrastructure

1.1 Configuring Workload Observability 1.2 CloudWatch Agent Architecture & Deployment 1.3 Metric Alarms, Anomaly Detection & Composite Alarms

2 Chapter 2: Alarms, Dashboards & Event-Driven Remediation

2.1 CloudWatch Dashboards & Multi-Account Visibility 2.2 Notification Architecture & Alarm Invocation 2.3 Amazon EventBridge Rules, Event Buses & Troubleshooting 2.4 Automated Remediation with Systems Manager & Lambda

3 Chapter 3: Performance Optimization for Compute, Storage & Databases

3.1 EC2 & Compute Performance Optimization 3.2 Amazon EBS Performance Metrics & Volume Tuning 3.3 S3 Performance Strategies & Data Transfer 3.4 Shared Storage (EFS/FSx) & Database Performance

4 Chapter 4: Compute & Database Scalability and Elasticity

4.1 EC2 Auto Scaling Policies & Elasticity 4.2 Auto Scaling Advanced Operations: Warm Pools & Lifecycle Hooks 4.3 Dynamic Scalability Through Caching 4.4 Managed Database Scaling: RDS, Aurora & DynamoDB

5 Chapter 5: High Availability, Fault Tolerance & Load Balancing

5.1 Elastic Load Balancing (ALB/NLB) Configuration & Troubleshooting 5.2 Route 53 Health Checks & DNS Failover 5.3 Multi-AZ Architecture & Fault-Tolerant Deployments

6 Chapter 6: Backup, Data Protection & Disaster Recovery

6.1 Centralized Backup Automation & AWS Backup 6.2 Database Restore Strategies & RTO/RPO Management 6.3 Storage Versioning, Replication & Immutability 6.4 Disaster Recovery Patterns & Multi-Region Resilience

7 Chapter 7: Infrastructure as Code with CloudFormation & AWS CDK

7.1 CloudFormation Foundations & Resource Modeling 7.2 Managing Stacks, Drift Detection & Change Sets 7.3 Infrastructure as Code with AWS CDK 7.4 Identifying & Remediating Deployment Failures

8 Chapter 8: Multi-Account Provisioning, Containers & Third-Party IaC

8.1 Golden Images with EC2 Image Builder & Amazon ECR 8.2 Multi-Account & Multi-Region Resource Sharing 8.3 Deployment Strategies & Container Deployments 8.4 Third-Party Automation with Terraform & Git Workflows

9 Chapter 9: Systems Manager & Event-Driven Operations Automation

9.1 AWS Systems Manager Core Management & Run Command 9.2 Systems Manager Patch Manager & Session Manager 9.3 Event-Driven Operations Automation

10 Chapter 10: Identity, Access Management & Governance

10.1 Advanced IAM Policies, Roles & Policy Conditions 10.2 Auditing Access with CloudTrail Lake & IAM Access Analyzer 10.3 Multi-Account Security: Organizations, SCPs & Identity Center 10.4 Compliance Enforcement with AWS Config & Conformance Packs

11 Chapter 11: Data Security, Encryption & Vulnerability Management

11.1 Data Classification & Amazon S3 Security 11.2 Encryption at Rest with AWS Key Management Service (KMS) 11.3 Encryption in Transit with AWS Certificate Manager (ACM) 11.4 Secrets Management & Centralized Security Findings

12 Chapter 12: VPC Architecture, Endpoints & Network Protection

12.1 VPC Core Architecture, Subnetting & High Availability NAT 12.2 Private Network Connectivity: VPC Endpoints & Peering 12.3 Network Protection & Edge Security Auditing

13 Chapter 13: DNS, Route 53 Routing & Content Delivery

13.1 DNS Architecture & Route 53 Resolver for Hybrid Clouds 13.2 Route 53 Advanced Routing Policies & Query Logging 13.3 Global Content & Service Distribution: CloudFront & Global Accelerator

14 Chapter 14: Network Troubleshooting, Traffic Analysis & Hybrid Connectivity

14.1 VPC Configuration Troubleshooting & Analysis Tools 14.2 Network Traffic Analysis: VPC Flow Logs & Log Analytics 14.3 CloudFront Caching & Hybrid Connectivity Troubleshooting

1.3 Metric Alarms, Anomaly Detection & Composite Alarms

Key Takeaways Explain This Topic AI

CloudWatch metric alarms evaluate M-out-of-N datapoints to prevent false alarm flapping from temporary operational spikes

Missing data treatment settings (missing, ignore, breaching, notBreaching) dictate how absent telemetry affects alarm state transitions

Anomaly detection models metric seasonality using machine learning and evaluates breaches based on standard deviation bands

Composite alarms combine multiple child metric alarms using boolean rule expressions to eliminate alert storms and suppress redundant notifications

EC2 Recover actions automatically migrate instances experiencing StatusCheckFailed_System to healthy physical hosts while retaining original IDs and IP addresses

Last updated: September 2026

CloudWatch Metric Alarm Anatomy & Evaluation Mathematics

Amazon CloudWatch Metric Alarms monitor metric streams or mathematical expressions, transitioning across three states: OK , ALARM , and INSUFFICIENT_DATA . Key alarm configuration elements include:

Namespace : Originating service identifier (e.g., AWS/EC2 or CustomApp/Payment ).

MetricName : Property monitored (e.g., CPUUtilization , mem_used_percent , or 5XXError ).

Dimensions : Key-value pairs identifying the target resource (e.g., InstanceId=i-0123456789abcdef0 ).

Statistic : Mathematical aggregation across the interval ( Average , Sum , Minimum , Maximum , SampleCount , or percentiles like p90 , p95 , p99 ).

Period : Evaluation window duration in seconds (10s, 30s, or multiples of 60s up to 86,400s / 24 hours).

Threshold & Comparison Operator : Target limit and evaluation logic (e.g., GreaterThanOrEqualToThreshold ).

Evaluation Periods and "M out of N" Logic

Alarms evaluate performance using Evaluation Periods ( N N N ) and Datapoints to Alarm ( M M M ):

Standard evaluation ( M = N M = N M = N , e.g., 3 out of 3): Every consecutive period must breach the threshold before triggering.

M out of N evaluation ( M < N M < N M < N , e.g., 3 out of 5): The alarm triggers if at least M M M datapoints breach the threshold across any of the last N N N evaluation periods. Evaluation Window (N = 5 periods)

  • Period: [ t-4 ] [ t-3 ] [ t-2 ] [ t-1 ] [ t ]
  • Status: BREACH OK BREACH BREACH OK
  • Evaluation: 3 out of 5 periods breaching (M=3, N=5) ---> State: ALARM

Using M < N M < N M < N prevents alarm flapping from transient, short-lived spikes while ensuring prompt alerting during intermittent degradation.

Missing Data Treatment

When network partitions or crashes interrupt metric streams, missing data treatment governs state evaluation:

Treatment Setting Alarm Evaluation Behavior Recommended Operational Use Case

missing (Default) Maintains current state; treats absent points as unknown Continuous operational metrics with steady data streams

ignore Skips missing periods and evaluates only existing points Intermittent workloads where gaps should not alter evaluation

breaching Treats missing points as violating threshold Critical heartbeats and health checks where silence indicates total outage

notBreaching Treats missing points as within acceptable threshold Error counts and exception logs where zero data indicates healthy operation

CloudWatch Anomaly Detection Alarms

Static thresholds struggle with workloads subject to cyclic demand. For instance, an e-commerce platform processing 5,000 requests per second at mid-day but only 200 at night produces false alarms with static limits.

CloudWatch Anomaly Detection applies machine learning to analyze up to two weeks of metric history. The model discovers hourly, daily, and weekly seasonality, filtering operational spikes during training.

The model generates an expected metric band with upper and lower bounds. Operators set the anomaly detection threshold as the number of standard deviations ( k k k , typically 1 to 5) the metric may deviate from the band. Alarms trigger when metrics rise above the upper band, fall below the lower band, or exit both boundaries.

Composite Alarms & Alert Storm Suppression

During core infrastructure failures—such as a database outage—hundreds of secondary alarms trigger across dependent application servers and load balancers, causing an alert storm .

Composite Alarms combine multiple metric alarms into a single high-level state using boolean rule expressions ( ALARM , OK , INSUFFICIENT_DATA ): ALARM("HighCPU-WebFleet") AND ALARM("High5xx-ALB") AND NOT ALARM("DatabaseFailoverInProgress")

Alert Suppression Rules

Composite alarms allow operations teams to establish suppression rules (inhibit logic). When a parent infrastructure failure occurs, dependent child alarms are evaluated within the composite rule, preventing downstream paging alerts. Engineers receive a single critical notification targeting the root cause.

Action Limitations : Composite alarms trigger Amazon SNS notifications, AWS Systems Manager OpsCenter OpsItems, and Amazon EventBridge events. However, composite alarms cannot directly execute EC2 actions (Stop, Reboot, Recover) or Auto Scaling policies; those must remain attached to individual metric alarms.

Automated Alarm Actions & EC2 Auto-Recovery

CloudWatch alarms execute automated operational actions:

Auto Scaling Actions : Trigger step or target tracking policies to scale EC2 Auto Scaling groups.

Notification Actions : Publish formatted payloads to Amazon SNS topics, fanning out to email, SMS, or PagerDuty.

EventBridge Event Emission : State transitions emit CloudWatch Alarm State Change events to EventBridge, triggering Lambda functions or Systems Manager runbooks.

Amazon EC2 Instance Actions : Execute Stop, Terminate, Reboot, or Recover.

EC2 Auto-Recovery vs. Reboot

Differentiating EC2 status checks is critical: +-------------------------------------------------------------------------+

  • | StatusCheckFailed_System (Physical Infrastructure / Hypervisor Failure) |
  • | Action: EC2 Recover |
  • | Result: Migrates instance to new physical host in same AZ |
  • | Preserved: Instance ID, Private IP, Elastic IP, Metadata, EBS Volumes |
  • +-------------------------------------------------------------------------+
  • +-------------------------------------------------------------------------+
  • | StatusCheckFailed_Instance (Guest OS / Kernel / Filesystem Failure) |
  • | Action: EC2 Reboot |
  • | Result: Soft reset of the guest operating system |
  • | Use Case: Unresponsive kernel, corrupted systemd service, OOM freeze |
  • +-------------------------------------------------------------------------+

An alarm on StatusCheckFailed_System triggers EC2 Recover , migrating the instance to a new healthy host in the same Availability Zone while preserving its Instance ID, private IP, Elastic IP, and EBS volumes. Conversely, StatusCheckFailed_Instance indicates guest OS kernel panics or filesystem corruption, resolved via EC2 Reboot or manual OS troubleshooting.

Alarm Troubleshooting & Failure Modes

Lingering INSUFFICIENT_DATA : Alarms remain in INSUFFICIENT_DATA when configured dimensions do not match published dimensions exactly. If a metric publishes InstanceId and Environment , an alarm with only InstanceId never receives data.

Period Mismatches : Evaluating a 1-minute alarm on a 5-minute metric stream introduces gaps, leading to unstable evaluations.

Percentile Traps : Percentiles ( p90 , p99 ) require adequate sample sizes. Calculating p99 on endpoints with under 100 requests per period creates erratic spikes or dead-zone evaluations.