Your AWS Account Has a Security Camera. Is It Recording?
When something goes wrong in AWS, the first question is always "who did this?" CloudTrail answers it, but only if you set it up before the incident. Here's how it works and what to turn on today.
Imagine you walk into your office on Monday morning and find a window open and a laptop missing. Your first question is simple: "Where's the security camera footage?"
Now imagine the same thing in your AWS account. A new IAM user appeared overnight. An EC2 instance is running in a region you've never used. A storage bucket is gone.
You need the same footage. In AWS, that footage is called AWS CloudTrail, and the scary part is this: if it wasn't set up properly before the incident, the footage may not exist.
What CloudTrail Actually Is
CloudTrail records API activity in your AWS account. Every time someone or something does anything in AWS, whether clicking in the console, running the CLI, or code calling an SDK, an API call happens. CloudTrail writes down that call.
Each record answers four questions:
- Who made the call? (a user, a role, or an AWS service)
- What did they do? (create a user, delete a bucket, launch a server)
- When did it happen?
- Where did it come from? (source IP address, region, and tool)
That's the entire investigation toolkit in four words: who, what, when, where.
What One Event Looks Like
Here's a simplified CloudTrail event, trimmed to the important fields. (The IP address is a placeholder from the documentation range.)
1
2
3
4
5
6
7
8
9
10
11
{
"eventTime": "2026-10-06T02:14:09Z",
"eventSource": "iam.amazonaws.com",
"eventName": "CreateAccessKey",
"awsRegion": "us-east-1",
"sourceIPAddress": "203.0.113.25",
"userIdentity": {
"type": "IAMUser",
"userName": "dev-intern"
}
}Read it like a detective: at 2:14 AM, the user
dev-intern created a new access key from an IP address you may not recognize. Was that the intern, or someone who stole the intern's credentials? That question is exactly why this log matters.
Infographic showing a CloudTrail event log with four callouts explaining who made the API call, what action was taken, when it happened, and where it originated.
Good News and Bad News
The good news: CloudTrail is turned on by default for every AWS account. Open the CloudTrail console, click Event history, and you can already search your recent activity.
The bad news: that default view has two big limits.
- It only goes back 90 days. After that, the records disappear.
- It only shows management events. These are actions on your AWS resources, such as creating users, changing permissions, or launching servers.
What it does not show by default are data events: the activity inside your resources, such as someone downloading files from an S3 bucket or invoking a Lambda function. Those must be turned on separately, and they can add cost, so enable them thoughtfully for sensitive resources.
The Fix: Create a Trail
A trail is a CloudTrail setting that delivers a permanent copy of your events to an S3 bucket that you control. Think of it as moving from "the camera shows the last 90 days" to "every recording is saved to a vault."
When you create a trail, these settings matter most:
- Apply to all regions. Attackers love launching resources in regions you never check.
- Log file validation: enabled. This lets you prove the logs weren't tampered with.
- Store logs in a separate, locked-down S3 bucket. Ideally, very few people can delete from it.
For beginners, the easiest path is the console: CloudTrail → Trails → Create trail. It sets up the bucket permissions for you. If you prefer the CLI, the shape of it looks like this:
1
2
3
4
5
6
7
aws cloudtrail create-trail \
--name security-trail \
--s3-bucket-name my-cloudtrail-logs-bucket \
--is-multi-region-trail \
--enable-log-file-validation
aws cloudtrail start-logging --name security-trailNote that the bucket needs a policy allowing CloudTrail to write to it, which is one more reason the console wizard is friendlier the first time.
Event history is the 90-day preview. A trail is the permanent recording.
Searching the Footage
You don't have to read raw logs line by line. In the console, Event history lets you filter by event name, user name, resource, or time range.
From the CLI, you can ask pointed questions. For example, "Who has been creating access keys?"
1
2
3
aws cloudtrail lookup-events \
--lookup-attributes AttributeKey=EventName,AttributeValue=CreateAccessKey \
--max-results 5For larger investigations, you can query trail logs stored in S3 with Amazon Athena, or use CloudTrail Lake, which is built for running SQL-style queries over your events.
Six Events Worth Watching
You can't stare at logs all day. The smarter move is to know which events are the "alarm bells" and get alerted when they happen. Start with these:
1. ConsoleLogin without MFA, or from an unusual place. A root login should be especially rare. Treat any root activity as worth a look.
2. CreateUser and CreateAccessKey. Attackers who get in often create new identities so they can come back later.
3. AttachUserPolicy, PutUserPolicy, and AttachRolePolicy. These change permissions. A sudden jump to broad admin access is a classic escalation move.
4. StopLogging and DeleteTrail. A smart attacker tries to turn off the camera first. If someone disables logging, treat it as an emergency.
5. RunInstances in unfamiliar regions. Surprise servers, especially in regions you don't use, often mean crypto mining.
6. Changes to S3 bucket policies or public access settings. These can quietly expose data to the world.
To get alerts, you can send trail events to CloudWatch Logs, create metric filters for these event names, and attach alarms that notify you through Amazon SNS. Amazon GuardDuty can also watch CloudTrail activity for suspicious behavior and raise findings for you.
Six CloudTrail events that deserve an alert before they become an incident.
Your 10-Minute CloudTrail Checklist
If you only do one thing after reading this article, do this:
- Open CloudTrail → Event history and look around. See what your account has been doing.
- Create a multi-region trail that delivers logs to S3.
- Turn on log file validation so your logs can be verified later.
- Protect the log bucket. Restrict who can delete or change it, and consider versioning.
- Set up at least one alert, ideally for
StopLoggingor root account sign-ins. - Practice one search. Find who created the last IAM user in your account. When a real incident happens, you'll be glad you've done it before.
The Bigger Takeaway
Security tools that prevent problems get all the attention: firewalls, MFA, least privilege. But no prevention is perfect, and when something slips through, the first question is always the same: what happened, and who did it?
CloudTrail is how you answer. It doesn't stop the break-in, but it tells you which door was used, what was touched, and what to fix.
The best time to turn on the camera is before you need it. Check that it's recording. Save the footage. Set the alarms.
This article is part of my ongoing learning journey in cybersecurity and AWS cloud security.
Enjoyed reading this content? Let the author know!
Your likes, comments, shares, and saves help creators reach more builders.
Loading recommendations
Loading article