AWS CloudTrail Logs: What They Record and How to Monitor Them

Last verified on Nov 8, 2026.

CloudTrail is the audit record of your AWS account. Every API call and console sign-in becomes a JSON event that says who acted, from where and against which service. When someone asks what changed before an outage, or whether a credential was misused, this is where the answer lives.

What a CloudTrail record contains

The fields you will query most often are documented in the CloudTrail record contents reference:

• eventTime is the UTC time the request completed.
• eventSource is the service the request went to, such as signin.amazonaws.com.
• eventName is the API action requested.
• userIdentity describes the IAM identity that made the call, including its type.
• sourceIPAddress and userAgent say where and through what the call came from.
• errorCode and errorMessage appear when the request failed, including authorization failures.
• requestParameters and responseElements carry the call inputs and, for actions that make changes, the result.
• awsRegion and recipientAccountId place the event.

Events also carry eventCategory and readOnly, which let you separate write calls from reads.

What to look for

Start with questions, not dashboards:

• Has the root user been used? Look for userIdentity.type equal to Root.
• Are console sign-ins failing? Look for eventName equal to ConsoleLogin with responseElements.ConsoleLogin equal to Failure, grouped by sourceIPAddress.
• Did anyone sign in without MFA? The sign-in event carries additionalEventData.MFAUsed.
• Is one identity collecting errorCode values like AccessDenied at a rate it never did before?
• Which eventName values with readOnly false ran in the last hour, and who ran them?

One caution from the AWS docs: the Region recorded on a sign-in event varies. Root sign-ins are recorded in us-east-1, us-east-2 or us-west-2, and IAM user sign-ins through the global endpoint can land in several Regions. Do not filter sign-in searches to one awsRegion.

Make the results readable

Raw trails are noisy because AWS services call each other constantly. Three habits cut that down:

• Group by userIdentity.arn so you see people and roles, not individual calls.
• Separate readOnly true from false. Writes are the smaller set and the more consequential one.
• Compare a window to the previous one. A role that made a handful of AccessDenied calls yesterday and several hundred today is worth a look even if each call is harmless.

Example: a root console login without MFA

This is an abbreviated example based on the AWS documentation for root sign-in events. The account ID and address are placeholders.

{
  "eventVersion": "1.08",
  "userIdentity": {
    "type": "Root",
    "arn": "arn:aws:iam::111122223333:root",
    "accountId": "111122223333"
  },
  "eventTime": "2023-07-12T13:35:31Z",
  "eventSource": "signin.amazonaws.com",
  "eventName": "ConsoleLogin",
  "awsRegion": "us-east-1",
  "sourceIPAddress": "192.0.2.0",
  "responseElements": { "ConsoleLogin": "Success" },
  "additionalEventData": { "MFAUsed": "No" },
  "recipientAccountId": "111122223333",
  "eventCategory": "Management"
}

Read it top down. userIdentity.type is Root, so this was the account owner credential and not an IAM user. MFAUsed is No. sourceIPAddress is where the sign-in came from. If that address is not your office, a VPN or a known admin, you have a question to answer today.

A failed attempt has the same shape with ConsoleLogin set to Failure and an errorMessage.

How Sazabi reads CloudTrail

Per the Sazabi docs, Sazabi reads CloudTrail through the trail's CloudWatch Logs delivery. You connect your AWS account, pick the trail's log group, and Sazabi sets up a CloudWatch subscription filter on it. It uses the same cross-account IAM role as the CloudWatch log source.

Each event keeps CloudTrail's own JSON, so eventName, eventSource, userIdentity, sourceIPAddress, errorCode, recipientAccountId, awsRegion, eventTime, eventCategory and readOnly stay searchable.

Three things from the docs matter before you start:

• The trail needs CloudWatch Logs delivery turned on. An organization trail delivers every member account's events to one log group.
• The log group must be in the same AWS region as your Sazabi project.
• Reading trails straight from S3 is not available yet.

If you would rather keep every AWS credential on your side, run your own OpenTelemetry Collector against the log group. See OpenTelemetry.

Use it with the other AWS sources

CloudTrail tells you what an identity did. VPC Flow Logs tells you what its network was doing, and GuardDuty flags findings about the same account. The full list is on the AWS integration page. Sazabi pricing is on the pricing page.