AWS Cloud Architect & Developer · AWS Cloud Architecture
CloudWatch and CloudTrail
Monitoring metrics and logs with CloudWatch and auditing API activity with CloudTrail.
Six concepts. CloudWatch and CloudTrail share a name prefix and both emit events — but the SAA question is almost always which kind of question each one answers, and the trap is treating them as interchangeable because both are 'logging'.
- AWS Cloud Architect & Developer
- Easy level
- 6 concepts
- 5 practice questions
1CloudWatch vs CloudTrail
Amazon CloudWatch is operational monitoring: it collects numeric time-series metrics (CPU, latency, custom application counts), centralizes logs, and drives alarms, dashboards and Auto Scaling from those signals. AWS CloudTrail is governance auditing: it records API calls and account activity — who invoked what, when, and from which source IP — for security review and compliance.
The exam trap is treating them as interchangeable because both are 'logging'. CloudWatch answers whether the system is healthy or performing within limits. CloudTrail answers who made a configuration change. Event history in the console covers the last 90 days free; a trail delivered to S3 keeps events indefinitely for long-term audit.
Figure. CloudWatch answers 'is it healthy?'; CloudTrail answers 'who called which API?'.
Which service answers the question?
- Performance or audit?Read the stem: is it asking about a metric threshold, log pattern or resource health — or about tracing an API action to a principal?
- Operational signalMetrics, logs, alarms, dashboards and Auto Scaling triggers are CloudWatch territory.
- Account auditWho deleted a security group rule, who launched an instance, or which IAM user changed a bucket policy — that is CloudTrail.
| Question you are asked | Service | What it records |
|---|---|---|
| Is CPU too high? Did ERROR lines spike? | Amazon CloudWatch | Metrics, log groups, alarms and dashboards |
| Who changed this security group overnight? | AWS CloudTrail | API call events with user, time and source IP |
| Alert me when latency exceeds 200 ms for five minutes | Amazon CloudWatch | Metric alarm, often paired with SNS for notification |
A security group ingress rule was modified at 3 a.m. and you must identify the IAM principal responsible. Which service do you open first?
- Amazon CloudWatch Logs, filtering the VPC flow log group
- AWS CloudTrail Event history, filtered by AuthorizeSecurityGroupIngress
- Amazon CloudWatch, on the StatusCheckFailed_System metric
CloudTrail records API calls with the caller identity; AuthorizeSecurityGroupIngress is the event you filter for. CloudWatch Logs might hold application text but not the IAM audit record for the API call itself, and a status-check alarm tells you an instance is unhealthy, not who edited a security group.
2CloudWatch metrics
CloudWatch Metrics stores numeric time-series data — CPUUtilization, network throughput, queue depth, or a custom count your app publishes — and every metric is a namespace, name and dimension set sampled over time. AWS services emit many metrics automatically; you can also PutMetricData for application-specific signals.
Granularity matters on the exam. Standard metrics arrive at one-minute resolution; high-resolution custom metrics can go down to one second. EC2 ships with basic monitoring every five minutes at no charge; detailed monitoring samples every one minute and is billed. The recurring trap: memory and disk usage are not default EC2 metrics — the console shows CPU and network, not RAM, until you add the CloudWatch Agent on the instance.
Figure. Metric resolution and custom namespaces are billed choices — detailed monitoring is not free magic.
How a metric lands in CloudWatch
- Source emitsAn AWS service or your application publishes a numeric sample with a timestamp.
- Namespace and dimensionsThe sample is stored under a namespace like AWS/EC2 with dimensions such as InstanceId so you can filter one resource.
- Downstream useDashboards graph the series; alarms and Auto Scaling policies read the same stream.
| Mode | Sample interval | Cost | Typical exam cue |
|---|---|---|---|
| Basic monitoring | 5 minutes | Free | Default on launch; enough for coarse capacity checks |
| Detailed monitoring | 1 minute | Charged per instance | Stem asks for finer CPU visibility or faster alarm reaction |
| High-resolution custom | 1 second | Charged per metric | Your app publishes a custom metric with sub-minute spikes |
An ops team wants one-minute CPU samples on every EC2 instance to drive tighter alarms. What must they enable?
- Detailed monitoring on each instance
- The CloudWatch Agent for CPU metrics
- A CloudTrail trail delivered to S3
Detailed monitoring moves EC2 CPUUtilization to one-minute granularity. Basic monitoring stays at five minutes. The agent is for memory, disk and custom metrics — not for unlocking one-minute CPU, which detailed monitoring already provides.
3CloudWatch alarms
A CloudWatch alarm watches one metric (or a metric-math expression) and enters ALARM when the value breaches a threshold for a configured number of evaluation periods. That state change is what triggers actions — not the single spike that might have caused it.
Alarm actions are the exam's second half. Publish to SNS to email or page someone; invoke an Auto Scaling policy to add capacity; stop, reboot or recover an EC2 instance. When the underlying host fails — StatusCheckFailed_System — a recover action asks AWS to move the instance to healthy hardware, a pattern the stem often hides behind 'automatically restore a failed instance'. Guest-OS or application failure is StatusCheckFailed_Instance: reboot or replace the instance; recover does not fix software inside the guest.
Figure. The alarm sits between the metric stream and every automated response. One sustained breach can both notify humans through SNS and add capacity through Auto Scaling — the exam often tests which action fits the stem, not whether alarms exist at all.
From metric breach to action
- Define thresholdPick the metric, comparison operator and threshold — for example Average CPUUtilization greater than 80.
- Set evaluation periodsRequire the breach for N consecutive periods so one noisy minute does not page the team.
- Wire actionsOn ALARM, notify through SNS, scale through Auto Scaling, or recover/reboot/stop the instance.
An instance passes application health checks but fails the hypervisor system status check. You want AWS to attempt automatic recovery without manual intervention. What do you configure?
- A CloudWatch alarm on StatusCheckFailed_System with a recover action
- A CloudWatch alarm on StatusCheckFailed_Instance with an SNS notification only
- CloudTrail Event history filtered on StopInstances
StatusCheckFailed_System means the underlying hardware or network path is impaired; the recover action migrates the instance to healthy capacity. StatusCheckFailed_Instance is a guest-OS or app issue where recover is not the fix, and CloudTrail tells you who stopped an instance — it does not heal one.
4Logs, Insights and metric filters
CloudWatch Logs centralizes text from applications, Lambda, VPC flow logs and more into log groups and streams. Logs Insights runs a query language over those events when you need to search or aggregate after the fact — 'count ERROR lines in the last hour by host' — without exporting data first.
When a log pattern must drive an alarm, a metric filter on the log group turns matching lines into a custom metric — for example increment a count each time a line contains ERROR. Pair that metric with an alarm and SNS exactly as you would for CPU. Metric filters count only events that arrive after the filter is created; they do not backfill historical log data, which is a pro-tip trap on timing questions.
Figure. Text becomes numbers at the metric filter — that is the bridge the exam tests. Everything to the right of it is ordinary CloudWatch alarm wiring you already know from CPU monitoring.
Alerting on a log pattern
- Ingest logsShip application output to a CloudWatch Logs log group.
- Filter to metricCreate a metric filter matching the pattern — ERROR, 5xx, login failures — to publish a numeric count.
- Alarm and notifyAlarm on that custom metric — for example greater than 10 in five minutes — and publish to SNS.
You need an email when an application logs more than ten ERROR lines within five minutes. What is the correct building block sequence?
- CloudTrail trail → S3 event → SNS
- Log group → metric filter on ERROR → alarm → SNS
- Logs Insights saved query → IAM policy → SNS
The filter turns matching log lines into a metric; the alarm watches that metric over time; SNS delivers the notification. CloudTrail audits API calls, not application log text, and Insights queries do not by themselves emit alarm-ready metrics.
5CloudTrail audit trail
CloudTrail captures management events — API calls that change resources — and data events when you enable them for services like S3 object-level activity. Each record carries userIdentity, eventName, sourceIPAddress and eventTime, which is exactly the evidence a security review needs.
Retention splits the exam answers. CloudTrail Event history in the console is free and covers roughly the last 90 days. For durable, tamper-resistant storage, create a trail that delivers JSON files to an S3 bucket — optionally with CloudWatch Logs integration and SNS on delivery failures. Organization trails in the management account give every linked account a single audit stream into one locked bucket.
CloudTrail records API activity for audit. Retention and Lake versus Trails are a small options table — who can read which events — not a network diagram. Picture an append-only event log keyed by account and Region if you need a mental model.
Tracing an unexpected API change
- Filter the eventIn Event history, filter by event name — AuthorizeSecurityGroupIngress — or by the affected resource ID.
- Read identity fieldsInspect userIdentity for the IAM user or role, plus sourceIPAddress and eventTime.
- Go beyond 90 daysQuery the trail's S3 bucket, often through Athena, when the change is older than Event history retains.
| Store | Retention | Exam cue |
|---|---|---|
| Event history (console) | About 90 days, free | Recent change, quick lookup |
| Trail to S3 | Indefinite while you keep the bucket | Compliance archive, incident from months ago |
| Organization trail | Same S3 durability, all accounts | Central audit for many linked accounts |
A bucket policy was altered fourteen months ago and regulators need proof of the caller. Where do you look first?
- CloudTrail Event history in the console
- The organization CloudTrail trail's S3 bucket, queried with Athena
- CloudWatch Logs Insights on the S3 access log group
Event history only retains on the order of 90 days, so a fourteen-month-old change is already gone from the console view. A trail's S3 delivery keeps events for as long as you retain the bucket; Athena makes multi-month searches practical.
6CloudWatch Agent and custom metrics
The CloudWatch Agent is a lightweight process you install on EC2 instances and on-premises servers. It collects memory, disk and swap utilization — metrics the hypervisor never exposes as defaults — and can also tail log files into CloudWatch Logs from the same agent configuration.
Custom metrics through PutMetricData or the agent let you alarm on business signals: queue depth, failed checkout count, license usage. CloudWatch Logs retention is separately configurable from one day to ten years or never expire, which is a cost question distinct from metric storage.
Hypervisor defaults expose CPU and network; memory, disk and swap need the in-guest CloudWatch Agent (or custom PutMetricData). The default-versus-agent table is the teaching artefact — there is no topology beyond install-then-alarm.
When the stem mentions RAM or disk
- Check defaultsCPU and network appear out of the box; memory and disk do not.
- Install the agentDeploy the CloudWatch Agent with an IAM role that allows cloudwatch:PutMetricData and logs:PutLogEvents.
- Alarm on the new metricCreate the usual alarm once mem_used_percent or disk_used_percent is flowing.
| Signal | Default metric? | How to get it |
|---|---|---|
| CPU utilization | Yes — basic or detailed | Enable detailed monitoring for one-minute CPU |
| Memory utilization | No | Install CloudWatch Agent |
| Disk space used | No | Install CloudWatch Agent |
Dashboards must show memory utilization for a fleet of Linux EC2 instances. What is the minimum additional setup?
- Enable detailed monitoring on each instance
- Install and configure the CloudWatch Agent on each instance
- Turn on a CloudTrail organization trail
Memory is measured inside the guest OS; EC2 does not publish it by default. Detailed monitoring only increases CPU sampling frequency. CloudTrail records API activity and does not emit memory metrics.
Notes
- CloudWatch Metrics: Collects numeric time-series metrics (CPU, network, custom app metrics) that drive alarms, dashboards, and Auto Scaling decisions.
- CloudWatch Alarms: Trigger actions (SNS notification, Auto Scaling, EC2 stop/reboot) when a metric breaches a threshold for a set number of evaluation periods.
- CloudWatch Logs: Centralizes application and system logs; Logs Insights queries them and metric filters convert log patterns into metrics.
- CloudTrail: Records API calls and account activity for governance, compliance, and security auditing - who did what, when, and from where.
- CloudWatch vs CloudTrail: CloudWatch answers 'is it performing/healthy?' (metrics/logs); CloudTrail answers 'who made this change?' (API audit trail).
Formulas
- CloudWatch metric resolution: standard metrics at 1-minute granularity; high-resolution custom metrics down to 1 second.
- EC2 default metrics: basic monitoring every 5 minutes free; detailed monitoring every 1 minute (charged).
- CloudTrail retention: Event history shows the last 90 days free; a trail to S3 stores events indefinitely.
- CloudWatch Logs retention: configurable from 1 day to 10 years (or never expire).
- Memory/disk metrics: not collected by default; require the CloudWatch Agent on the instance.
Exam traps & shortcuts
- 'Who deleted/changed this resource?' => CloudTrail. 'Is CPU/latency too high?' => CloudWatch metrics/alarms.
- EC2 memory and disk usage are not default metrics - the correct answer is to install the CloudWatch Agent.
- To auto-recover a failing instance, use a CloudWatch alarm on the StatusCheckFailed_System metric with a recover action.
- For a searchable pattern in logs turning into an alert, use a metric filter on CloudWatch Logs plus an alarm.
Reference tables
Pin the what versus who split before every scenario question.
| Stem language | Reach for |
|---|---|
| CPU high, latency spike, custom app count | CloudWatch metrics and alarms |
| Search log text or count ERROR lines | CloudWatch Logs; metric filter if an alarm is needed |
| Who deleted/changed this resource? | CloudTrail Event history or S3 trail |
| Memory or disk usage on EC2 | CloudWatch Agent |
| Auto scale when load stays high | CloudWatch alarm → Auto Scaling policy |
| Recover hardware-level instance failure | Alarm on StatusCheckFailed_System → recover action |
| Fact | Value |
|---|---|
| Standard CloudWatch metric resolution | 1 minute |
| High-resolution custom metrics | Down to 1 second |
| EC2 basic monitoring interval | 5 minutes, free |
| EC2 detailed monitoring interval | 1 minute, charged |
| CloudTrail Event history window | About 90 days, free |
| CloudWatch Logs retention | 1 day to 10 years, or never expire |
Recap
Read this before a timed SAA block — the traps are all classification.
- What vs who
- CloudWatch watches performance and health; CloudTrail records who called which API.
- Metrics
- Basic EC2 CPU every five minutes free; detailed every one minute; high-res custom to one second. Memory and disk are never defaults.
- Alarms
- Threshold plus evaluation periods trigger SNS, Auto Scaling or EC2 recover on StatusCheckFailed_System.
- Logs to alerts
- Metric filter turns log patterns into metrics; filters do not backfill history.
- Audit retention
- Event history ~90 days; trail to S3 for long-term compliance.
- Agent
- Install the CloudWatch Agent when the stem names RAM, disk or custom log files.
Practise CloudWatch and CloudTrail
Reading is free and needs no account. Practice, mocks and progress live in the app.
- 5 exam-style questions on this topic, with explanations
- A 6-question practice set that ends the chapter
- Timed mocks scored with the real marking scheme
- Readiness tracked per topic, kept on your device