Bird
Raised Fist0
AWScloud~5 mins

CloudWatch alarms in AWS - Commands & Configuration

Choose your learning style10 modes available
LearnWhyDeepVisualTryChallengeProjectRecallTime
Introduction
CloudWatch alarms watch your cloud resources and tell you when something needs attention. They help you catch problems early by sending alerts based on rules you set.
When you want to know if your server CPU is too high for a long time
When you need to get notified if your website is not responding
When you want to track if your database storage is almost full
When you want to automatically fix problems by triggering actions when an alarm fires
When you want to keep an eye on costs by monitoring resource usage
Config File - cloudwatch-alarm.json
cloudwatch-alarm.json
{
  "AlarmName": "HighCPUUsageAlarm",
  "AlarmDescription": "Alarm when CPU exceeds 80% for 5 minutes",
  "ActionsEnabled": true,
  "AlarmActions": ["arn:aws:sns:us-east-1:123456789012:NotifyMe"],
  "MetricName": "CPUUtilization",
  "Namespace": "AWS/EC2",
  "Statistic": "Average",
  "Dimensions": [
    {
      "Name": "InstanceId",
      "Value": "i-0abcdef1234567890"
    }
  ],
  "Period": 300,
  "EvaluationPeriods": 1,
  "Threshold": 80.0,
  "ComparisonOperator": "GreaterThanThreshold"
}

This JSON file defines a CloudWatch alarm named HighCPUUsageAlarm. It watches the average CPU usage of a specific EC2 instance over 5 minutes (300 seconds). If the CPU goes above 80%, the alarm triggers. It sends a notification to an SNS topic NotifyMe. The Dimensions specify which EC2 instance to watch by its ID.

Commands
This command creates or updates the CloudWatch alarm using the JSON file. It sets the rules and notification actions.
Terminal
aws cloudwatch put-metric-alarm --cli-input-json file://cloudwatch-alarm.json
Expected OutputExpected
No output (command runs silently)
→
--cli-input-json - Specifies the JSON file with alarm configuration
This command checks the details and status of the alarm named HighCPUUsageAlarm to confirm it was created.
Terminal
aws cloudwatch describe-alarms --alarm-names HighCPUUsageAlarm
Expected OutputExpected
{ "MetricAlarms": [ { "AlarmName": "HighCPUUsageAlarm", "AlarmDescription": "Alarm when CPU exceeds 80% for 5 minutes", "ActionsEnabled": true, "OKActions": [], "AlarmActions": [ "arn:aws:sns:us-east-1:123456789012:NotifyMe" ], "InsufficientDataActions": [], "StateValue": "OK", "StateReason": "Threshold Crossed: 1 datapoint [0.0 (27/04/24 10:00:00)] was not greater than the threshold (80.0).", "MetricName": "CPUUtilization", "Namespace": "AWS/EC2", "Statistic": "Average", "Dimensions": [ { "Name": "InstanceId", "Value": "i-0abcdef1234567890" } ], "Period": 300, "EvaluationPeriods": 1, "Threshold": 80.0, "ComparisonOperator": "GreaterThanThreshold" } ] }
→
--alarm-names - Filters output to show only the specified alarm
This command lists all CPU usage metrics for EC2 instances, helping you find the right instance ID to monitor.
Terminal
aws cloudwatch list-metrics --namespace AWS/EC2 --metric-name CPUUtilization
Expected OutputExpected
{ "Metrics": [ { "Namespace": "AWS/EC2", "MetricName": "CPUUtilization", "Dimensions": [ { "Name": "InstanceId", "Value": "i-0abcdef1234567890" } ] } ] }
→
--namespace - Filters metrics by service namespace
→
--metric-name - Filters metrics by metric name
Key Concept

If you remember nothing else from this pattern, remember: CloudWatch alarms watch specific metrics and alert you when those metrics cross thresholds you set.

Common Mistakes
Using the wrong instance ID in the alarm dimensions
The alarm will watch the wrong resource and never trigger for your intended server
Always verify the instance ID by listing metrics or checking your EC2 instances before creating the alarm
Not enabling actions in the alarm configuration
The alarm will detect problems but will not send notifications or trigger actions
Set ActionsEnabled to true and specify AlarmActions like SNS topics to get alerts
Setting the threshold too high or too low without testing
You may get too many false alarms or miss real problems
Start with reasonable thresholds and adjust based on observed metric behavior
Summary
Create a CloudWatch alarm by defining a JSON file with metric, threshold, and actions.
Use the AWS CLI to apply the alarm configuration with put-metric-alarm.
Check alarm status and details with describe-alarms to confirm it works.

Practice

(1/5)
1. What is the primary purpose of an AWS CloudWatch alarm?
easy
A. To store large amounts of log data
B. To monitor a specific metric and notify when it crosses a threshold
C. To create virtual servers in the cloud
D. To manage user permissions and roles

Solution

  1. Step 1: Understand CloudWatch alarm function

    CloudWatch alarms watch metrics like CPU usage or disk space and alert you when values cross set limits.

  2. Step 2: Identify the correct purpose

    Only To monitor a specific metric and notify when it crosses a threshold describes monitoring a metric and notifying on threshold crossing, which is the alarm's job.

  3. Final Answer:

    To monitor a specific metric and notify when it crosses a threshold -> Option B

  4. Quick Check:

    Alarm = Monitor + Notify [OK]
Hint: Alarms watch metrics and alert on changes [OK]
Common Mistakes:
  • Confusing alarms with log storage
  • Thinking alarms create servers
  • Mixing alarms with user management
2. Which of the following is the correct way to specify a CloudWatch alarm threshold for CPU utilization above 80%?
easy
A. "Threshold": "<=80"
B. "Threshold": 80, "ComparisonOperator": "LessThanThreshold"
C. "Threshold": 80, "ComparisonOperator": "LessThanOrEqualToThreshold"
D. "Threshold": 80, "ComparisonOperator": "GreaterThanThreshold"

Solution

  1. Step 1: Understand threshold syntax

    CloudWatch alarms use a numeric Threshold value and a separate ComparisonOperator like GreaterThanThreshold, LessThanThreshold.

  2. Step 2: Choose operator for above 80%

    To alert when CPU is above 80%, use "Threshold": 80, "ComparisonOperator": "GreaterThanThreshold".

  3. Final Answer:

    "Threshold": 80, "ComparisonOperator": "GreaterThanThreshold" -> Option D

  4. Quick Check:

    Above 80% = GreaterThanThreshold(80) [OK]
Hint: Use GreaterThanThreshold for above threshold [OK]
Common Mistakes:
  • Using < instead of > for above threshold
  • Using = which triggers only at exact value
  • Confusing <= with above threshold
3. Given this CloudWatch alarm configuration snippet:
{"MetricName": "CPUUtilization", "Namespace": "AWS/EC2", "Threshold": 70, "ComparisonOperator": "GreaterThanThreshold", "EvaluationPeriods": 3}

What happens if CPU utilization is 75% for 2 consecutive periods and then 65% for the third period?
medium
A. The alarm does not trigger because CPU was not above 70% for all 3 periods
B. The alarm triggers only if CPU is above 70% for 4 periods
C. The alarm triggers immediately when CPU hits 75% the first time
D. The alarm triggers because CPU was above 70% twice

Solution

  1. Step 1: Understand EvaluationPeriods meaning

    The alarm triggers only if the metric breaches the threshold for the specified number of consecutive periods (3 here).

  2. Step 2: Analyze given CPU values

    CPU was above 70% for 2 periods, then dropped below on the 3rd, so the alarm does not trigger.

  3. Final Answer:

    The alarm does not trigger because CPU was not above 70% for all 3 periods -> Option A

  4. Quick Check:

    3 periods breach needed, only 2 met [OK]
Hint: Alarm needs all evaluation periods breached [OK]
Common Mistakes:
  • Thinking alarm triggers after any single breach
  • Ignoring EvaluationPeriods count
  • Assuming alarm triggers immediately
4. You created a CloudWatch alarm but it never enters ALARM state even when the metric crosses the threshold. What is a likely cause?
medium
A. The alarm's EvaluationPeriods is set higher than the number of metric data points
B. The alarm threshold is set too low
C. The alarm is configured to notify but not to monitor metrics
D. The SNS topic ARN configured in alarm actions is invalid

Solution

  1. Step 1: Check EvaluationPeriods vs data points

    If EvaluationPeriods is more than available metric data points, alarm cannot evaluate properly.

  2. Step 2: Confirm impact on alarm state

    Without enough data points, alarm never sees enough breaches to enter ALARM state.

  3. Final Answer:

    The alarm's EvaluationPeriods is set higher than the number of metric data points -> Option A

  4. Quick Check:

    EvaluationPeriods > data points = no alarm [OK]
Hint: Ensure enough data points for EvaluationPeriods [OK]
Common Mistakes:
  • Assuming threshold too low prevents alarm
  • Confusing notification with monitoring
  • Thinking invalid SNS prevents alarm state
5. You want to create a CloudWatch alarm that triggers an auto-scaling action when average CPU utilization exceeds 60% for 5 minutes, but only if this happens during business hours (9 AM to 5 PM). Which approach best achieves this?
hard
A. Create a CloudWatch alarm with threshold 60% and EvaluationPeriods 1, then use EventBridge to trigger scaling only during business hours
B. Set the alarm threshold to 60% and EvaluationPeriods to 5, and configure the alarm to be active only during business hours
C. Create a CloudWatch alarm with threshold 60% and EvaluationPeriods 5, then use a Lambda function triggered by the alarm to check time and trigger scaling
D. Set the alarm threshold to 60% and EvaluationPeriods 5, and configure auto-scaling to ignore alarms outside business hours

Solution

  1. Step 1: Understand alarm and time condition needs

    CloudWatch alarms alone cannot restrict triggering by time; external logic is needed.

  2. Step 2: Evaluate options for time-based control

    Using a Lambda triggered by the alarm to check current time and decide on scaling is flexible and precise.

  3. Step 3: Assess other options

    EventBridge can schedule events but not filter alarm triggers by time; auto-scaling ignores alarms is not a feature.

  4. Final Answer:

    Create a CloudWatch alarm with threshold 60% and EvaluationPeriods 5, then use a Lambda function triggered by the alarm to check time and trigger scaling -> Option C

  5. Quick Check:

    Alarm + Lambda time check = controlled scaling [OK]
Hint: Use Lambda to add time logic after alarm triggers [OK]
Common Mistakes:
  • Expecting alarm to handle time filtering alone
  • Assuming auto-scaling ignores alarms by time
  • Using EventBridge without alarm integration
Recommended

Ready to prove it?

Pass the test and this pattern moves unknown strong while earning +1 Grip toward your certificate.

10 questions~5 mineasy hard