AWS CloudTrail Log Analyzer Guide: Summarize Cloud Activity

Cloud services record an enormous amount of activity. Every API call, every resource change, and every failed permission check can produce a log entry, and a busy cloud account produces far more entries than any person can read line by line. The practical question is rarely "what happened in this log" in full, but "what happened most, what failed, and who did it". A summary that answers those three questions turns an unreadable log into a starting point for investigation.

The AWS CloudTrail Log Analyzer tool summarizes pasted log JSON by event, error, and user. You paste CloudTrail log JSON, and it counts events, errors, and activity per user, giving you the shape of the log at a glance. It analyzes text you paste; it does not connect to your AWS account, fetch live logs, change any resource, or prove that an action was authorised. A summary is a map of the pasted data, and like any map, it is only as complete as the data it was drawn from. If the pasted sample covers one hour, the summary describes one hour, not the whole day, and conclusions must be scoped accordingly.

CloudTrail entries have a structure worth understanding before reading any summary. Each entry names an event, such as an instance launch or a policy change, the user or role that performed it, the time it happened, the source address it came from, and whether it succeeded or produced an error. Grouping by event name shows which actions dominate the log. Grouping by error shows which actions failed, and whether the failures cluster on one action, which suggests a permission problem, or spread across many, which suggests a wider outage or a misconfigured tool. Grouping by user shows whose activity dominates, and whether a normally quiet account suddenly became the busiest one, which is often the most interesting signal in the whole summary.

A worked example you can follow

Take a sample log of 200 entries from one morning. Grouping by event gives: 120 RunInstances calls, 50 DescribeInstances calls, 20 PutObject calls, and 10 other events. Checking the total: 120 plus 50 plus 20 plus 10 equals 200, which accounts for every entry. Grouping by outcome gives: 180 successes and 20 errors, since 200 minus 180 equals 20, an error rate of 20 divided by 200, which equals 0.10, or 10 percent. Grouping the 20 errors by event shows all 20 are PutObject calls, which means every PutObject call in the sample failed, since 20 errors out of 20 PutObject calls equals a 100 percent failure rate for that action, while every other action succeeded. That concentration points the investigation at object storage permissions for the calling user, not at a general outage.

Now group the same sample by user. Suppose user alice accounts for 150 entries, user ben for 40, and a service role for 10, and 150 plus 40 plus 10 equals 200, accounting for the log again. If alice normally produces about 20 entries a morning, then 150 is more than seven times her usual volume, since 150 divided by 20 equals 7.5, and that change, combined with the PutObject failures, suggests her morning's work included a script or tool repeatedly retrying a failing storage action. The next step is not to blame alice, but to ask what she was running, whether it was expected, and whether its retries explain both the volume and the errors. A third sample shows the quiet version of the same logic: a log of 50 entries, all successes, spread evenly across 5 users at 10 each, since 50 divided by 5 equals 10, with no event dominating. That summary describes a normal morning, and the value of the analyzer there is negative evidence: nothing stands out, so no investigation is needed.

When you paste logs for analysis, handle them as sensitive data. CloudTrail entries can contain account identifiers, resource names, addresses, and sometimes values that should not be shared widely. Paste only the sample the analysis needs, redact secrets, access keys, and tokens before pasting, and do not share the summary more widely than the investigation requires. Never paste credentials into any analyzer, and treat any log line containing a secret as a line to redact first, without exception.

Common mistakes to avoid

The first mistake is generalising from a partial sample, such as one hour, to a whole day or a whole account. The second mistake is reading a high event count as a problem on its own; a busy action can be entirely normal, and it is the combination of volume, errors, and user change that signals trouble. The third mistake is ignoring errors because the overall error rate looks low; a 10 percent overall rate can hide a 100 percent failure rate for one critical action. The fourth mistake is pasting unredacted logs containing secrets, which creates a new security problem while investigating an old one.

The JSON Studio tool helps you inspect and validate JSON structure before pasting it for analysis, and the Word Counter tool gives a rough sense of a pasted sample's size. For background on keeping web-facing configuration safe, see HTTP Security Headers Guide.

Checking the result before you act on it

Before acting on a log summary, confirm the sample's time window, confirm the totals add up across groupings, spot-check a few entries behind any surprising count, and check whether a busy or failing user was running something expected. Only then choose a response: a permission fix for a concentrated failure, a conversation with a user whose volume changed sharply, or a wider investigation when errors spread across actions. A summary that is scoped, cross-checked, and tied to real entries is the difference between chasing noise and finding the one pattern that explains the morning.