Recommended resources
The freely available resources this lesson will direct you to.
Welcome back. In the last lesson, you used CloudFormation’s Events tab to follow a stack update and deletion. That view is useful for understanding a deployment, but it does not answer every question you might ask afterward. Who requested a change? What did a resource’s configuration look like before the change? Is the application healthy now?
This lesson separates three services that answer those different questions: CloudTrail for API activity and audit, AWS Config for resource configuration history and compliance, and CloudWatch for operational monitoring. Choosing between them is a recurring SAA-C03 skill, and the distinction is useful when troubleshooting your own AWS environments.
Start with the question you need answered
Suppose a security group unexpectedly allows SSH from anywhere. An investigation has three parts. You want to identify the API request that changed access, compare the security group’s configuration before and after, and determine whether the affected application is experiencing problems. No single service is the best primary source for all three.
| Primary question | Start with | Evidence you expect |
|---|---|---|
| Who made a request, when, and through which API? | CloudTrail | An event with an action, time, principal, and request details |
| What was this supported resource’s configuration, and how did it change? | AWS Config | Recorded configuration states and a resource timeline |
| How is the workload behaving? Should someone be alerted? | CloudWatch | Metrics, application or service logs, dashboards, and alarms |
CloudTrail records AWS account activity, particularly API calls. Its Event history lets you inspect the most recent 90 days of management events in a Region without first creating a trail. For longer-term delivery to storage, you configure a trail. A useful exam distinction is that management events concern actions such as creating or changing a resource; high-volume data events, such as S3 object-level operations, require explicit selection and can add cost. Do not assume an S3 PutObject request will appear just because you can see bucket-management events.
CloudWatch has a different center of gravity: measurements and operational signals. The following video makes the CloudWatch–CloudTrail distinction visually. Watch the selected portions rather than treating its console layout or every example metric as a configuration instruction.
AWS Cloudwatch vs Cloudtrail - Whats the Difference?
“AWS Cloudwatch vs Cloudtrail – Whats the Difference?” from Be A Better Dev contrasts workload monitoring with account auditing.
Watch CloudWatch monitoring for logs, metrics, and alarms. Then skip to CloudTrail auditing for recorded actions and the distinction between management and data events. One qualification to keep in mind: the video's memory-utilization example is not a default EC2 metric; collecting OS memory metrics requires additional setup, such as the CloudWatch agent.
The fact that both products can involve “logs” is not enough to choose between them. CloudTrail events are the audit evidence for AWS API activity. CloudWatch Logs is a place to collect and query logs, commonly from applications and AWS services. You can deliver CloudTrail events to CloudWatch Logs for analysis or alerting, but doing so does not turn CloudWatch into the source of those audit records.
Use AWS Config to reconstruct resource state
CloudTrail can show that an AuthorizeSecurityGroupIngress request occurred. That does not make it a convenient inventory of what every recorded security group looked like at each point in time. AWS Config addresses that state question: when recording is enabled for a supported resource type, it records configuration information and presents a configuration timeline. It can also evaluate resources against Config rules—for example, whether a security group permits unrestricted SSH—and show compliance status over time.
Watch the Config demonstration as an investigation, not as a lab to copy. Enabling recording across an account and adding rules can incur charges, even when you are only experimenting.
“AWS Config Tutorial” from Stephane Maarek shows the difference between discovering resources, recording their configurations, and evaluating them against a rule.
Watch recording setup for the purpose and cost warning, without following the setup steps. At resource timeline, notice that seeing a resource’s configuration is distinct from having a compliance result. Watch restricted SSH for what a Config rule evaluates, then configuration changes to see the before-and-after view alongside related CloudTrail activity.
Two boundaries matter. First, configuration recording and rule evaluation are separate capabilities: a timeline can exist without a compliance rule, while a compliance result requires a rule. Second, Config is not a retroactive record of everything that happened before you enabled the relevant recording. Its history depends on what resource types you chose to record and what Config supports.
AWS describes how Config and CloudTrail complement one another in its service-integration documentation:
AWS Service Integrations with AWS Config - AWS Config
Read AWS’s short “AWS CloudTrail” subsection to connect an API event with a configuration change.
Under “AWS Service Integrations with AWS Config,” find the subsection “AWS CloudTrail,” immediately after “AWS Control Tower.” Read the integration explanation, stopping before “AWS Security Hub CSPM.” Focus on which service supplies request details and which supplies the changed configuration.
In the security-group example, you would use the Config timeline to establish what changed, then a related CloudTrail event to investigate which principal made the request. An assumed role or AWS service may appear as the acting principal; interpreting who ultimately initiated an action can require examining its context rather than relying on a username alone.
Use CloudWatch to observe the effect
After finding the security-group change, you may still need to know whether users are seeing errors or whether instances are overloaded. That is CloudWatch’s domain. Many AWS services publish metrics, which you can graph on dashboards and evaluate with alarms. CloudWatch Logs stores logs in log groups and streams; Logs Insights helps you query them. For EC2, basic service metrics do not include guest-OS memory or disk usage by default. The CloudWatch agent can collect those OS-level measurements and logs when you configure it.
Read the following AWS documentation selectively; the goal is to distinguish the types of operational evidence, not to set up every CloudWatch feature today.
What is Amazon CloudWatch? - Amazon CloudWatch
Read AWS’s overview of metrics, alarms, logs, and the CloudWatch agent. These are the CloudWatch capabilities most useful for distinguishing operational monitoring from auditing and configuration history.
In “Operational visibility with metrics, alarms, and dashboards,” start with the opening metrics paragraph at “Metrics collect and track key performance data” and continue through the alarm paragraph ending with automated actions; metrics through alarms anchors that span. In “Collect, store, and query logs,” read from the opening description of CloudWatch Logs through the metric-filter explanation, ending at logs and queries. Finally, in “Use the CloudWatch agent to gather metrics, logs, and traces from Amazon EC2 fleets,” read the opening paragraph from the agent’s system-metric capabilities through its alarm use, anchored by agent capabilities.
An alarm is only as useful as the signal it evaluates. A CPU alarm could indicate high utilization, but it would not, by itself, tell you that an SSH rule was opened. Likewise, finding the API request in CloudTrail does not tell you whether customers experienced errors. In a real investigation, you combine the evidence rather than expecting one console to explain the entire incident.
Apply the distinction without adding lab costs
You can make this concrete using the CloudFormation lab you just completed, with read-only checks. In the same Region where you ran the stack, open CloudTrail → Event history and look for management events associated with creating, updating, or deleting the stack. Check an event’s time, event name, and principal. Event delivery may take a little time; if the event is not visible, also check that you selected the correct Region and time range.
Then consider two questions that Event history alone would not settle:
- To reconstruct the bucket’s recorded tag values over time, you would need appropriate AWS Config recording for that resource. Do not enable Config merely for this check; it can generate charges.
- To track an application’s errors, latency, or resource utilization after a deployment, you would choose suitable CloudWatch logs, metrics, and possibly alarms. Your deleted empty-bucket lab had no application-health signal to monitor.
These checks reinforce a practical selection rule for exam scenarios: identify the requested evidence before selecting a service. “Audit who called an API,” “show how a resource was configured,” and “alert on unhealthy behavior” are different requirements even when they describe the same incident.
Key takeaways
CloudTrail records activity; AWS Config records supported resource configurations and can evaluate compliance; CloudWatch monitors operational behavior. CloudTrail and Config can be correlated to explain a change, while CloudWatch helps reveal its effect on a workload. Check what was actually enabled or recorded before assuming historical evidence exists, and account for the cost of optional recording, logs, and alarms.
Next, you will distinguish GuardDuty, Security Hub, Inspector, and Macie—services that use different kinds of security evidence to detect threats, assess vulnerabilities, find sensitive data, or bring findings together.