Exercise: Create a CloudWatch Alarm for an AWS Resource
By the end of this lesson, you'll be able to:
- Walk through designing a CloudWatch alarm for a realistic AWS resource
- Apply this module's "thresholds reflect the workload" principle to a concrete scenario
- Apply this module's Cost & Cleanup discipline to monitoring resources specifically
Prerequisites: "Backup Concepts and Security Best Practices"
Before you begin: two valid paths, as in every earlier module
As with earlier hands-on activities in this course, you can design this directly in a real AWS account or work through it entirely on paper. If you do create real resources, review your current Free Tier eligibility and current CloudWatch pricing first — alarms, custom metrics, and log storage each have their own independent cost story, and none should be assumed automatically free.
The scenario: a fictional Course API needs an alarm
A fictional Course API (similar in shape to earlier modules' projects) is running behind a load balancer. The team wants to be notified automatically if the application starts failing meaningfully, rather than waiting for a user to report it.
Designing the alarm, step by step
- Choose a meaningful metric — for this scenario, the application's error rate (or error count over a time window) is a strong fit, since it directly reflects whether requests are succeeding, following Lesson 1's metric concept.
- Choose a threshold that reflects this specific workload — not a number copied from an unrelated example (Lesson 2's warning) — based on what this application's error rate normally looks like under healthy conditions.
- Decide what the alarm should trigger — a notification to whoever is on call, following Lesson 2's "an alarm signals, it doesn't fix" principle; the actual investigation and fix still require a human (or an automated response system) to act.
- Decide what "investigate" looks like when it fires — check CloudWatch Logs for the specific errors occurring (Lesson 1), check whether a recent deployment coincides with the spike, and — if an unexpected AWS configuration change is suspected rather than an application bug — check CloudTrail (Lesson 3 and Lesson 7's incident-thinking sequence).
Cost & Cleanup
If any part of this was built in a real account, work through this checklist before considering the exercise finished:
- Delete the CloudWatch alarm created for this exercise, once you're done experimenting.
- Delete any test metric filters created against CloudWatch Logs, if you created one.
- Delete temporary CloudWatch dashboards, if one was created solely for this exercise.
- Delete any temporary SNS notification topic created to receive the alarm's notifications.
- Delete any temporary log groups created specifically for this exercise, if you don't need to keep the logs.
- Confirm nothing training-related remains by checking the CloudWatch dashboard directly — the same "verify, don't assume" discipline every earlier module's hands-on activity applied to its own resources.
Exercise
For the fictional Course API's alarm: (1) which metric would you choose, and why does it directly reflect whether the application is working? (2) how would you decide on a meaningful threshold, rather than copying one from an unrelated example? (3) when the alarm fires, walk through what you'd check first, second, and third, referencing this module's earlier lessons. (4) list the cleanup steps for the alarm and any related resources you created.
Show hint
Revisit Lesson 1 for the metric choice, Lesson 2 for the threshold reasoning, and Lesson 7's Detect-Investigate-Contain/Correct-Learn sequence for the investigation order.
Exercise: Create a CloudWatch Alarm for an AWS Resource Quiz
My Notes
Log in to keep private notes on this lesson.
Questions about this lesson
No questions yet — be the first to ask.
Log in to ask a question about this lesson.
Summary
This closing exercise applies the module's CloudWatch concepts to one concrete, scoped task: designing an alarm for a fictional AWS resource, choosing a meaningful metric and threshold, deciding what happens when it fires, and working through the Cost & Cleanup discipline for any monitoring resources created along the way.