Knowing what the system is doing: metrics, logs, events, and the infrastructure-as-code that provisions them.
Monitoring on AWS is built from a few services that each answer a different question. CloudWatch answers "how is the system behaving?" with time-series metrics, log groups, Logs Insights queries, dashboards, and alarms that fire when a metric crosses a threshold. CloudWatch Events, now part of Amazon EventBridge, answers "what just happened?" by delivering state-change events, such as an EC2 instance stopping or a Glue job failing, and cron-style schedules to targets like Lambda, SNS, or Step Functions. CloudFormation answers "how do we make all of this reproducible?" by declaring alarms, rules, log groups, and dashboards as code alongside the resources they watch.
Start with the CloudWatch page if you are new to the area, since both events and infrastructure templates refer back to its metrics and alarms.
All three pages include runnable examples.
| Goal | Service | Example |
|---|---|---|
| Alert on a threshold | CloudWatch alarm | CPU above 80% for 10 minutes |
| Search application logs | CloudWatch Logs Insights | Count 5xx errors per endpoint |
| React to a discrete event | EventBridge rule | Glue job FAILED triggers a Lambda |
| Run something on a schedule | EventBridge schedule | Nightly snapshot at 02:00 UTC |
| Keep monitoring consistent across accounts | CloudFormation / StackSets | Same alarms in every environment |
In practice they are combined: CloudFormation creates an alarm, the alarm changes state, and that state change is itself an event EventBridge can route. For the wider platform context see the AWS section.