The Complete Guide to AWS CloudTrail: From Audit Log Basics to CloudTrail Lake—Designing “Evidence” by Comparing GCP Cloud Audit Logs and Azure Activity Log

Key takeaways first (read this to grasp the whole picture)

AWS CloudTrail is an audit service that records “who did what and when” in an AWS account as API operations. CloudTrail events include types such as Management events and Data events, and you design how far to record based on your goals.
CloudTrail Lake goes further by ingesting events into an event data store and enabling SQL-based search and analytics. Events are transformed from JSON into columnar ORC, making them easier to query and keep at scale.
Costs can vary greatly—especially with CloudTrail Lake—depending on how you design ingestion volume, retention period, and queries. Pricing pages also spell out retention options (e.g., extending retention to one year / up to seven years, depending on the plan and configuration).

As comparison points:
GCP organizes Cloud Audit Logs into types such as Admin Activity / Data Access / Policy Denied / System Event, which makes the “purpose” of auditing more explicit in the log categories.
Azure’s Activity log (under Azure Monitor) is defined as a platform log that records control-plane (management-plane) events for Azure resources.

Who this article helps (in concrete terms)

First, SREs and operations teams. In incidents, the most painful state is “we know something changed, but we can’t trace who did what.” A well-designed CloudTrail setup improves root-cause analysis speed and makes post-incident prevention more evidence-based.

Next, IT/security and compliance teams. In audits, “we have logs” isn’t enough; you’re often asked to explain what is logged, where it’s stored, tamper-resistance, and retention. CloudTrail’s event types and storage/analysis design points make it easier to translate into internal policy.

And architects planning multi-cloud or future migrations. Since GCP and Azure structure audit evidence differently (GCP by audit-purpose types, Azure first by control-plane evidence), mapping “what corresponds to CloudTrail” helps keep governance designs consistent across clouds.

1. What CloudTrail is: the API-operation record that becomes the “spine” of auditing

Even when you click buttons in the AWS Console, actions are executed as API calls under the hood. CloudTrail records those API operations as events, allowing you to trace them later. The key design principle is not “log everything,” but: decide what you want to be able to prove, collect the minimally sufficient events, retain them for the necessary duration, and keep them searchable in a way that supports real investigations.

The first step is understanding CloudTrail’s event categorization—CloudTrail documentation organizes event types such as management events, data events, and Insights events.

2. Understanding event types: Management events, Data events, and Insights

2-1. Management events

Management events cover configuration changes and administrative actions around AWS resources. This is the core domain auditors often ask about—“who changed the policy,” “when did the configuration change,” etc. A practical approach is to first establish solid change evidence with management events, then expand as needed.

2-2. Data events

Data events cover data-plane operations (e.g., object reads/writes), and they can grow quickly in volume. If you don’t design the scope intentionally, both cost and query burden rise. In practice, data events work best when you narrow the scope—for example, “only critical data areas” or “only audit-relevant operations.”

2-3. CloudTrail Insights events

Insights continuously analyzes management/data events and generates Insights events when activity deviates from a baseline—such as unusual spikes in API call rate or error rate. It’s not only for after-the-fact auditing, but also useful for “early warning” around anomalies (unexpected error surges, unusual time-of-day patterns, etc.).

3. CloudTrail Lake: treat audit logs as “queryable data”

Traditional audit logging often stops at “store it somewhere.” But in real incident response and audits, you inevitably need to quickly retrieve “the log that should exist” from specific angles. CloudTrail Lake is built for that: it centralizes events in an event data store and supports SQL-based querying. It also converts row-based JSON events into columnar Apache ORC, signaling a shift from “logs as files” to “logs as data for investigation.”

3-1. Event data store: an immutable collection for auditing

An event data store is described as an immutable collection of events chosen by criteria (e.g., advanced event selectors). That matters: it’s not designed around “editing history to fit the story.” Its nature aligns with audit needs.

3-2. Pricing and retention: decide a “retention policy” in words first

With CloudTrail Lake, design choices around ingestion, retention, and queries directly affect cost. Documentation and pricing describe retention options and note that event data stores are billable resources with cost shaped by the options selected at creation.

A reliable way to avoid failure is to write a retention policy like:

• Minimum retention required for audit (e.g., X years)
• A “hot window” used frequently for incident investigation (e.g., last 90 days)
• Whether older data is “rarely queried but must remain retrievable”

This makes costs more predictable and makes audit explanations consistent.

4. The core of evidence design: what to record, where to store, and how to query

CloudTrail is not the kind of service where “turn it on and you’re safe.” To produce real assurance, you design these three together:

4-1. What to record: define scope by auditing goals

• If you need proof of change management, center on management events
• If you need traceability for data access, add data events with a carefully limited scope
• If you want faster detection of “unusual activity,” consider Insights

4-2. Where to store: declare the “system of record”

In audit contexts, “which store is the authoritative source” matters. Whether you use CloudTrail Lake as the searchable hub or keep another canonical archive, clearly define: “this is the system of record” and “this is how long it is preserved.” That reduces confusion during incidents.

4-3. How to query: design Lake so it can answer your questions

Because CloudTrail Lake uses SQL, you can structure answers to questions like:
“Who did what API, on which service, when, and in which region?”
Design the event data store selection criteria based on the questions you must be able to answer under pressure.

5. Practical templates: “operational patterns” teams can share

These aren’t code snippets—these are patterns you can use directly in team discussions.

Template A: prioritize change management (“who changed what?”)

• Goal: trace configuration, permissions, and network changes
• Design: record primarily management events
• Ops: weekly summary of high-risk actions (IAM/keys/network) and reconcile with change records
• Benefit: stronger, evidence-based explanations for incidents and audits

Template B: capture data events only for critical data zones

• Goal: trace access (read/write) to critical data
• Design: accept that data events grow fast; limit the scope to critical areas
• Ops: define thresholds for “expected vs abnormal” usage; optionally support with Insights
• Benefit: meet audit needs while controlling cost

Template C: prepare an “incident question set” in CloudTrail Lake

• Goal: make investigations fast when incidents happen
• Design: build event data stores to match the questions you need to answer
• Ops: template your frequent questions:
  • “What change operations were performed on this resource during this period?”
  • “What actions did this user/role execute?”
  • “Which APIs saw a sudden error spike?” (with Insights support)
• Benefit: faster initial response and less person-dependence

6. Comparing with GCP and Azure: same “audit logs,” but different organization models

6-1. GCP: Cloud Audit Logs uses four types to separate audit purposes

GCP’s Cloud Audit Logs includes log names such as Admin Activity / Data Access / Policy Denied / System Event. That means the log classification is explicitly aligned to the “purpose of auditing.”

The closest mapping to AWS CloudTrail’s management/data events is:

• CloudTrail Management events ↔ GCP Admin Activity
• CloudTrail Data events ↔ GCP Data Access

GCP’s explicit Policy Denied and System Event categories also make it easier to have conversations like “audit denied access attempts” or “audit service-side system events.”

6-2. Azure: Activity log is centered on control-plane evidence

Azure Monitor’s Activity log is described as a platform log for control-plane (management-plane) events—such as when resources are modified or deployment errors occur.

As a result, Azure evidence design often starts with:

• “Lock down and retain Activity log for management operations,” then
• add data-plane auditing via service-specific logs and diagnostic settings

If you translate AWS thinking as “CloudTrail management events are mandatory; data events are selectively designed,” the cross-cloud governance conversation becomes much smoother.

7. Common pitfalls: CloudTrail gets painful if you try to “fix it later”

Here are typical mistakes and how to avoid them:

1. Logs exist, but the needed operations aren’t captured
   If you don’t explicitly map “audit questions” to event types (management/data/Insights), you’ll eventually face “we didn’t log that.” Start by defining the questions, then back-calculate required events.

2. You capture too much, making it expensive and unreadable
   Data events grow rapidly. CloudTrail Lake costs tie directly to ingestion and retention. Define retention policy before expanding scope.

3. No one is responsible for looking at the logs
   Audit vs operations vs security monitoring require different viewing frequency and dashboards. Logs that are never reviewed weekly are effectively “not there.” Assign owners and cadence, and create lightweight routines (weekly summaries) so the system stays alive.

Conclusion: CloudTrail isn’t just an “audit log”—it’s infrastructure for operations and trust

AWS CloudTrail records AWS API operations as events so you can trace “who did what and when.” It includes management events, data events, and Insights events—each designed based on your purpose.
With CloudTrail Lake, you can centralize events into event data stores and query them with SQL. Converting JSON to ORC is a deliberate step toward making logs “investigable data.”
Because Lake cost and retention are design-dependent, deciding retention policy first is the safest path.

GCP organizes auditing explicitly into four audit-purpose types, while Azure’s Activity log centers on control-plane evidence. If you map these to CloudTrail’s concepts, you can keep a consistent auditing “core” across clouds.

A practical next step: start by securing change management evidence with management events, then add data events only for critical areas. Move carefully—but design intentionally. With CloudTrail, that intentional design becomes trust.

Reference links (official / primary sources)

• CloudTrail events (Management / Data / Insights)

  • https://docs.aws.amazon.com/ja_jp/awscloudtrail/latest/userguide/cloudtrail-events.html

• CloudTrail Insights (detecting unusual API call/error rates)

  • https://docs.aws.amazon.com/awscloudtrail/latest/userguide/logging-insights-events-with-cloudtrail.html

• CloudTrail Lake overview

  • https://docs.aws.amazon.com/awscloudtrail/latest/userguide/cloudtrail-lake.html

• CloudTrail Lake event data stores (query, pricing/retention basics)

  • https://docs.aws.amazon.com/awscloudtrail/latest/userguide/query-event-data-store.html

• AWS CloudTrail pricing (JP)

  • https://aws.amazon.com/jp/cloudtrail/pricing/

• GCP Cloud Audit Logs overview

  • https://docs.cloud.google.com/logging/docs/audit

• Azure Monitor Activity log (EN)

  • https://learn.microsoft.com/en-us/azure/azure-monitor/platform/activity-log

• Azure Monitor Activity log (JA)

  • https://learn.microsoft.com/ja-jp/azure/azure-monitor/platform/activity-log