How to Create CloudWatch Alarms in AWS (Console + CLI Examples)

Simple explanation

Before creating an alarm, it helps to understand the difference between three related CloudWatch concepts:

• A metric is a time-series measurement. CPU usage at 2:00 PM, 2:05 PM, 2:10 PM. It is just data. CloudWatch collects hundreds of metrics automatically from AWS services with no setup required.
• A dashboard visualizes those metrics in charts. CloudWatch Dashboards are useful for understanding trends, but someone still has to look at them.
• An alarm watches a metric and does something when the value crosses a line you draw. No one has to be watching. The alarm fires on its own.

How CloudWatch alarms work

When you create an alarm, you define a chain of components that determine when and how it fires:

• Metric — which specific measurement to watch (for example, CPUUtilization for a specific EC2 instance)
• Statistic — how to aggregate data points within each period: Average, Sum, Minimum, Maximum, SampleCount, or a percentile like p99
• Period — the time window for each data point, in seconds (60 = 1 minute, 300 = 5 minutes)
• Threshold — the numeric value and comparison operator (greater than 80%, less than 10 GB, and so on)
• Evaluation periods — how many consecutive data points must breach the threshold before the alarm fires; higher values reduce false positives from brief spikes
• Datapoints to alarm (M of N) — a flexible variant: M out of the last N periods must breach the threshold. Setting 3 out of 5 fires the alarm if 3 of the last 5 data points were over the threshold, even if they weren’t all consecutive.
• Missing data treatment — what to do when no data arrives for a period (covered below)
• Actions — what happens when the alarm transitions to a new state

The three alarm states

Actions fire on state transitions, not while an alarm stays in a state. To be notified when an incident starts and again when it resolves, configure actions for both the ALARM state and the OK state.

Missing data treatment

When no metric data arrives during a period, CloudWatch needs to know how to handle the gap. The four options are:

• notBreaching — treat the missing period as within threshold. Good for sparse metrics like Lambda invocations that genuinely have quiet periods.
• breaching — treat the missing period as a threshold violation. Use this when absence of data is itself a problem, such as an EC2 health check that should always be reporting.
• ignore — keep the current alarm state unchanged during the gap.
• missing — the alarm transitions to INSUFFICIENT_DATA.

When to use CloudWatch alarms

Almost every production AWS workload needs alarms. These are the most common scenarios and what each alarm is protecting against:

• EC2 high CPU or status checks — sustained CPU above 80% may indicate a runaway process or an undersized instance. A failing status check means the instance or underlying hardware is unhealthy and needs immediate attention.
• Lambda errors or throttles — any errors in a function that should be error-free, or throttles showing you’ve hit the concurrency limit and requests are being dropped. See Monitoring Lambda in AWS for function-level alerting strategies.
• RDS low storage or connection pressure — storage exhaustion stops a database instance with no warning. Connection pressure approaching max_connections causes client errors as new connections are rejected.
• ALB 5xx spikes — a spike in 5xx responses from a load balancer means backend instances are returning errors. Alarm separately on ALB-level 5xx and target-level 5xx to distinguish load balancer issues from application issues.
• SQS queue backlog — if the age of the oldest message climbs, your consumer is falling behind. This usually means a consumer is failing silently or scaling hasn’t kicked in.
• Log-based patterns — you can create log-based metrics from CloudWatch Logs and alarm on them, which is useful for custom application errors that don’t map to a standard AWS metric.

Choose the right alarm type

How to create a CloudWatch alarm in the AWS Console

The following steps create a metric alarm. If you’re new to CloudWatch, the CloudWatch overview explains how alarms fit into the broader service.

1. Open CloudWatch. In the AWS Console, search for CloudWatch in the top search bar and open the service. Confirm you’re in the correct region. Alarms are region-scoped and don’t cross regions.

2. Navigate to Alarms. In the left sidebar, under Alarms, click All alarms. Then click Create alarm.

3. Select a metric. Click Select metric. You’ll see namespaces for every AWS service that reports to CloudWatch. Browse to the service you want (for example, EC2 > Per-Instance Metrics) or use the search box to find a specific metric. Select the metric row and click Select metric.

4. Configure the metric and conditions. You’re now on the “Specify metric and conditions” screen.

   • Under Metric: choose your statistic (Average is appropriate for most continuous metrics; Sum is better for error counts and event-based metrics) and your period (5 minutes is a sensible default; 1 minute gives faster detection at higher cost).
   • Under Conditions: choose Static threshold type (or Anomaly detection if you want a learned band). Set the comparison operator and enter the threshold value.

5. Set evaluation logic. Expand Additional configuration:

   • Set Datapoints to alarm. For example, “2 out of 3” means two of the last three periods must breach the threshold before the alarm fires. This avoids false positives from brief spikes.
   • Set Missing data treatment. For most metrics, Treat missing data as missing (transitions to INSUFFICIENT_DATA) is a safe default. Choose Treat missing data as bad if absence of the metric is itself an alert condition.

   Click Next.

6. Configure actions. Under Notification, select the alarm state that triggers the action (In alarm). Choose an existing SNS topic or create a new one. To also receive a recovery notification, click Add notification, choose the OK state, and select the same topic. You can also add EC2 actions (reboot, stop, recover), Auto Scaling policies, or Lambda invocations from this screen. Click Next.

7. Name the alarm. Give the alarm a descriptive name that includes the service, metric, and environment. For example: EC2-HighCPU-prod-web-01. A clear name makes it obvious what’s wrong when the alarm fires at 2 AM. Add an optional description. Click Next.

8. Review and create. Check the alarm configuration on the preview screen. Click Create alarm. The alarm will start in INSUFFICIENT_DATA state until the first evaluation period completes.

How to create a CloudWatch alarm with the AWS CLI

The CLI is ideal for scripting alarm creation, managing alarms across many resources at once, or wiring alarm setup into infrastructure automation. All examples use put-metric-alarm.

EC2 high CPU alarm

This fires if average CPU utilization stays above 80% for two consecutive 5-minute periods. Ten minutes of sustained high CPU is a more reliable signal than a single spike, and two evaluation periods prevents false positives from brief bursts.

aws cloudwatch put-metric-alarm \
  --alarm-name "EC2-HighCPU-prod-web-01" \
  --alarm-description "CPU utilization above 80% for 10 minutes" \
  --namespace AWS/EC2 \
  --metric-name CPUUtilization \
  --dimensions Name=InstanceId,Value=i-0abc123def456789 \
  --statistic Average \
  --period 300 \
  --evaluation-periods 2 \
  --threshold 80 \
  --comparison-operator GreaterThanThreshold \
  --treat-missing-data breaching \
  --alarm-actions arn:aws:sns:us-east-1:123456789012:production-alerts \
  --ok-actions arn:aws:sns:us-east-1:123456789012:production-alerts

The —ok-actions flag points to the same SNS topic so you’re notified when CPU recovers, not just when it spikes. Setting —treat-missing-data breaching means if the instance stops reporting (for example, because it was terminated unexpectedly), the alarm fires rather than going silent.

Lambda error rate alarm using metric math

Lambda’s raw Errors metric counts errors, but the rate matters more when invocation volume varies. This example uses metric math to compute errors divided by invocations and fires when the error rate exceeds 5%. See Monitoring Lambda in AWS for more Lambda-specific alerting patterns.

aws cloudwatch put-metric-alarm \
  --alarm-name "Lambda-HighErrorRate-process-orders" \
  --alarm-description "Lambda error rate above 5%" \
  --metrics '[
    {
      "Id": "errors",
      "MetricStat": {
        "Metric": {
          "Namespace": "AWS/Lambda",
          "MetricName": "Errors",
          "Dimensions": [{"Name": "FunctionName", "Value": "process-orders"}]
        },
        "Period": 300,
        "Stat": "Sum"
      },
      "ReturnData": false
    },
    {
      "Id": "invocations",
      "MetricStat": {
        "Metric": {
          "Namespace": "AWS/Lambda",
          "MetricName": "Invocations",
          "Dimensions": [{"Name": "FunctionName", "Value": "process-orders"}]
        },
        "Period": 300,
        "Stat": "Sum"
      },
      "ReturnData": false
    },
    {
      "Id": "error_rate",
      "Expression": "errors / invocations * 100",
      "Label": "Error Rate",
      "ReturnData": true
    }
  ]' \
  --threshold 5 \
  --comparison-operator GreaterThanThreshold \
  --evaluation-periods 1 \
  --alarm-actions arn:aws:sns:us-east-1:123456789012:production-alerts

RDS low free storage alarm

RDS reports FreeStorageSpace in bytes, not gigabytes. 10 GB = 10,737,418,240 bytes. Always check a metric’s unit before setting a threshold. Getting it wrong silently creates an alarm that never fires.

aws cloudwatch put-metric-alarm \
  --alarm-name "RDS-LowFreeStorage-prod-postgres" \
  --alarm-description "RDS free storage below 10 GB" \
  --namespace AWS/RDS \
  --metric-name FreeStorageSpace \
  --dimensions Name=DBInstanceIdentifier,Value=prod-postgres \
  --statistic Average \
  --period 300 \
  --evaluation-periods 3 \
  --threshold 10737418240 \
  --comparison-operator LessThanThreshold \
  --alarm-actions arn:aws:sns:us-east-1:123456789012:production-alerts

Testing alarms before relying on them

Use set-alarm-state to force an alarm into any state without affecting real metrics. This verifies that your SNS notification path works end to end before an actual incident.

# Force the alarm into ALARM state to test the SNS notification
aws cloudwatch set-alarm-state \
  --alarm-name "EC2-HighCPU-prod-web-01" \
  --state-value ALARM \
  --state-reason "Testing alarm notification path"

# Reset it back to OK when done
aws cloudwatch set-alarm-state \
  --alarm-name "EC2-HighCPU-prod-web-01" \
  --state-value OK \
  --state-reason "Test complete"

# List all alarms currently in ALARM state
aws cloudwatch describe-alarms \
  --state-value ALARM \
  --query 'MetricAlarms[*].{Name:AlarmName,Metric:MetricName,State:StateValue}' \
  --output table

# Delete an alarm
aws cloudwatch delete-alarms \
  --alarm-names "EC2-HighCPU-prod-web-01"

Setting up notifications with SNS

CloudWatch alarms deliver notifications through Amazon SNS (Simple Notification Service). SNS acts as a pub/sub fanout layer: you create a topic, subscribe one or more endpoints to it, and then point alarms at the topic ARN. When an alarm fires, SNS delivers the notification to every active subscription on the topic.

# Create an SNS topic for alarm notifications
aws sns create-topic --name production-alerts \
  --query 'TopicArn' --output text
# Returns: arn:aws:sns:us-east-1:123456789012:production-alerts

# Subscribe an email address to the topic
aws sns subscribe \
  --topic-arn arn:aws:sns:us-east-1:123456789012:production-alerts \
  --protocol email \
  --notification-endpoint your-email@example.com
# You will receive a confirmation email — click the link to activate

# Subscribe a webhook (for Slack, PagerDuty, or OpsGenie)
aws sns subscribe \
  --topic-arn arn:aws:sns:us-east-1:123456789012:production-alerts \
  --protocol https \
  --notification-endpoint https://hooks.example.com/your/webhook/url

Email subscriptions work well for low-urgency or informational alarms. For production incidents that need immediate human response, connect SNS to a tool like PagerDuty, OpsGenie, or a dedicated Slack channel via HTTPS subscription. The SNS messaging model page covers topic configuration and subscription filtering in more detail.

Composite alarms: reducing alert noise

A composite alarm combines the states of multiple metric alarms using Boolean expressions (AND, OR, NOT). The most common use case: don’t page anyone when a single metric spikes in isolation. Require two or more related signals to be in ALARM simultaneously before notifying.

# Component alarm 1: Lambda errors above threshold
aws cloudwatch put-metric-alarm \
  --alarm-name "Lambda-HighErrors" \
  --namespace AWS/Lambda \
  --metric-name Errors \
  --dimensions Name=FunctionName,Value=process-orders \
  --statistic Sum \
  --period 300 \
  --threshold 5 \
  --comparison-operator GreaterThanThreshold \
  --evaluation-periods 1

# Component alarm 2: Lambda p99 duration above threshold
aws cloudwatch put-metric-alarm \
  --alarm-name "Lambda-HighDuration" \
  --namespace AWS/Lambda \
  --metric-name Duration \
  --dimensions Name=FunctionName,Value=process-orders \
  --statistic p99 \
  --period 300 \
  --threshold 8000 \
  --comparison-operator GreaterThanThreshold \
  --evaluation-periods 1

# Composite alarm: fires only when BOTH component alarms are in ALARM state
aws cloudwatch put-composite-alarm \
  --alarm-name "Lambda-DegradedService" \
  --alarm-rule "ALARM(\"Lambda-HighErrors\") AND ALARM(\"Lambda-HighDuration\")" \
  --alarm-description "Both high errors and high duration — service is degraded" \
  --alarm-actions arn:aws:sns:us-east-1:123456789012:production-alerts

Composite alarms can also suppress child alarms during a known outage or maintenance window. When you set the parent alarm to ALARM state manually, it can be configured to prevent its children from firing separately, which avoids an alert storm when you already know something is wrong. This pattern is covered in the incident response with monitoring guide.

Choosing thresholds without creating noisy alerts

The most common complaint about CloudWatch alarms is that they’re either too noisy or miss real incidents. Both problems usually trace back to thresholds set without looking at actual baseline behavior.

Start with observed behavior

Before setting a threshold, look at your metric’s history in CloudWatch Dashboards. Find the normal range — not just the average, but also peak behavior during traffic spikes and deployments. Set your threshold where you would genuinely want to be paged, not at a round number that happens to be above average.

Period length affects both speed and noise

A 1-minute period detects problems faster than a 5-minute period, but it also makes alarms more sensitive to brief spikes. A metric that naturally jitters between 75% and 85% CPU will generate constant false positives with a 1-minute period and an 80% threshold. The same alarm with a 5-minute average period fires only during a sustained problem, which is usually what you actually want.

Use evaluation periods to absorb transient spikes

A single evaluation period with a tight threshold is appropriate only when you need zero tolerance. StatusCheckFailed > 0 is a good example: any failure is immediately serious and should fire without delay. For metrics that naturally vary, use 2 or 3 consecutive evaluation periods to require sustained bad behavior before the alarm fires.

When patterns vary, use anomaly detection

If your application traffic varies significantly by time of day or day of week, a fixed threshold will either be too tight during peak hours or too loose during quiet ones. Anomaly detection alarms learn the expected range from historical patterns and fire when the metric deviates beyond a configurable band, with no manual threshold tuning required.

Combine signals to reduce single-metric noise

If CPU alone fires multiple times per week without a real incident behind it, combine it with another metric. A composite alarm requiring both high CPU and elevated 5xx errors is almost always pointing at a real problem. CPU alone rarely is.