Advanced 15 min read

AWS CloudTrail: Auditing Account Activity

By the end of this lesson, you'll be able to:

Explain what AWS CloudTrail records and why it exists
Distinguish CloudTrail's account-activity auditing from CloudWatch's operational monitoring
Trace a fictional AWS API action through to a recorded CloudTrail event

Prerequisites: "CloudWatch Alarms"

A different question: not "is it healthy," but "who changed this"

Everything covered so far in this module — metrics, logs, alarms — answers questions about application health. AWS CloudTrail exists to answer a genuinely different question: who or what performed a given action against an AWS resource, and when. CloudTrail records AWS API and account activity — actions taken through the Console, the CLI, or by AWS services themselves acting on your behalf.

CloudWatch versus CloudTrail: this distinction matters

Side-by-side diagram showing CloudWatch collecting metrics and logs from an application or service for operational monitoring, answering whether the application is healthy, compared with CloudTrail recording AWS API actions by a user, role, or service, answering who or what changed a resource. — The two can complement each other, but they are not the same service answering the same question.

It's worth stating this plainly, because the two get confused constantly: CloudTrail is not just another CloudWatch log, and CloudWatch and CloudTrail do not do the same thing. CloudWatch is built around application and service operational health; CloudTrail is built around auditing AWS account activity — and CloudTrail does not record every possible application-level event either; that's still application/service logging's job (Lesson 1).

Tracing an action through CloudTrail

Diagram showing a fictional IAM role calling a fictional ModifySecurityGroup AWS API action, processed by the AWS API, with CloudTrail recording the resulting event for later audit or investigation. — This is a fictional example action, used purely to teach the auditability concept — not a real resource or a real security incident.

A concrete, fictional example: an administrator's IAM role calls a fictional ModifySecurityGroup action, changing a Security Group's rules. CloudTrail records that this specific identity made that specific request at that specific time — information that becomes essential later if a team needs to understand why a Security Group's configuration changed, or who made an unexpected change to any AWS resource.

Exercise

A team notices a Security Group's rules changed unexpectedly overnight, and no application error or health alarm fired at the time. Using this lesson's distinction, explain which service — CloudWatch or CloudTrail — is the right place to look to find out which identity made that change, and why CloudWatch alone wouldn't answer that specific question.

Show hint

CloudWatch would tell you if the application's health changed; this question is about who changed an AWS resource's configuration.

AWS CloudTrail: Auditing Account Activity Quiz

1. A Security Group changed unexpectedly, and you need to determine which AWS identity made the API call. Which service is the best fit?

AWS CloudTrail Amazon CloudWatch metrics Amazon CloudWatch dashboards alone None of these record this information

2. CloudWatch and CloudTrail serve exactly the same purpose.

True False

3. AWS ______ records AWS API and account activity for auditing.

Show hint

It's the service this entire lesson introduces, answering "who or what changed this resource?"

My Notes

Questions about this lesson

No questions yet — be the first to ask.

Summary

AWS CloudTrail records AWS API and account activity — who or what made a request, what action occurred, and when — answering a fundamentally different question from CloudWatch's operational health monitoring: CloudWatch asks whether the application is healthy, while CloudTrail asks who or what changed a given AWS resource.

❬ Previous Next ❭