Enabling CloudTrail is a checkbox. Monitoring CloudTrail is where security work actually starts.
Most AWS accounts have CloudTrail enabled. Few teams treat it as a first-class detection signal until after something painful happens—usually a leaked key, a public S3 change, or IAM drift nobody can explain.
This guide is for practitioners who need operational clarity, not another CSPM dashboard tour.
What CloudTrail is (and is not)
CloudTrail is a management-plane audit log. It records API activity across your account: who called what, from where, with which identity, and whether it succeeded.
It is not:
- A packet capture tool (use VPC Flow Logs for network metadata).
- A workload runtime monitor (use GuardDuty, EDR, or runtime security where applicable).
- A replacement for application logs (your app still needs structured logging).
If you only watch CloudTrail, you will miss application-layer attacks. If you ignore CloudTrail, you will miss account takeover paths that start with IAM and end in data exfiltration.
Events that should never be “just noise”
| Signal family | Why it matters |
|---|---|
ConsoleLogin / AssumeRole failures | Credential stuffing, session hijack attempts, misconfigured automation |
CreateAccessKey / CreateLoginProfile | Persistence on human or break-glass identities |
PutBucketPolicy / PutBucketPublicAccessBlock | Accidental or malicious data exposure |
AuthorizeSecurityGroupIngress 0.0.0.0/0 | Classic lateral exposure pattern |
GetSecretValue spikes from unusual principals | Secret harvesting |
You do not need a rule for every API. You need high-signal rules with context—principal history, geo, time-of-day, and whether the action matches a change window.
Query patterns that survive audits
Whether you use CloudTrail Lake, Athena, or a SIEM, keep three saved queries warm:
- New principals assuming powerful roles —
AssumeRoleintoOrganizationAccountAccessRole,AdministratorAccess, or custom admin profiles. - Root usage — Any
Rootidentity outside break-glass runbooks. - S3 public exposure —
PutBucketAcl,PutBucketPolicy, and public access block changes correlated with object uploads.
Store these as named queries so incident responders are not inventing SQL during an outage.
Alerting without alert fatigue
The failure mode is obvious: alert on every PutBucketPolicy and train everyone to mute the channel.
Better approach:
- Baseline normal change paths (CI roles, Terraform runners, backup jobs).
- Throttle by principal + action + outcome, not globally.
- Enrich with account tags (prod vs. sandbox) before the alert hits a human.
For a step-by-step ingestion path into a managed pipeline, see our guide on setting up CloudTrail to S3.
Final thought
CloudTrail monitoring is not “advanced AWS security.” It is the minimum credible story for any team that stores customer data in S3 and uses IAM for access control. If you want help turning CloudTrail into actionable detections—not another unread stream—talk to us.