Compliance

Enable CloudTrail and API activity logging

One capability across the whole CloudTrail control family: make sure every account keeps a complete, tamper-evident, queryable record of the AWS API calls that change your estate.

14 min·10 sections·AWS

Last reviewed 16 June 2026

Remediates AWS Security Hub: CloudTrail.1 CloudTrail.3 CloudTrail.4 CloudTrail.5 CloudTrail.7

CloudTrail and API activity logging: the basics

What does "audit logging" actually mean across the CloudTrail family?

CloudTrail is the flight recorder for your AWS account. Every console click, SDK call and CLI command resolves to an API action, and a trail writes a durable record of it: who made the call, when, from which source IP, with what parameters, and what the service returned. Without a trail those events scroll past the always-on event history window and are gone, with no way to reconstruct them after the fact.

Security Hub turns the question "is our API activity properly logged?" into a family of separate controls, which is why a single account can fail several CloudTrail checks at once. One control asks whether any trail exists at all; another asks whether at least one trail is multi-Region and captures both read and write management events; another asks whether log file validation is on so the records are tamper-evident; another asks whether the trail is wired into CloudWatch Logs for real-time alerting; another asks whether the trail's own S3 bucket has access logging. They look like five problems on the report, but they are one capability: keep a complete, trustworthy, queryable audit trail of who did what.

The right way to satisfy this whole family is to create one multi-Region trail, configured properly the first time, and apply it across every account. A single trail with management events, log file validation, CloudWatch Logs delivery and a hardened, access-logged S3 bucket clears the entire group at once. Standing up a bare single-Region trail just to clear the easiest check guarantees the stricter ones flag right behind it and you do the work twice.

In this lesson you will learn how CloudTrail records API activity, the difference between the always-on event history and a real trail, and what a complete audit-logging posture looks like: multi-Region coverage, read and write management events, log file validation for tamper-evidence, CloudWatch Logs integration for alerting, and access logging on the trail's own bucket. The Controls this lesson covers section lists every Security Hub control in this capability, each linking to a deep page with the exact check and a copy-and-paste fix.

Fun fact

The audit that asked one question

A SaaS startup pursuing its first SOC 2 and a PCI attestation sailed through most of the technical review. Then the assessor asked for the CloudTrail logs covering the previous twelve months for the account holding cardholder data. The team went to pull them and discovered that account had never had a trail enabled. The console's event history showed the last 90 days, viewing only, with no durable export. There was simply no record for the other nine months. The finding was not "misconfigured logging", it was "no logging", and it pushed the attestation back a full quarter while they stood up trails and waited to accumulate enough history. The trail they eventually turned on cost a few dollars a month.

Finding the gaps in API activity logging

Devon is doing a Security Hub triage pass and sees several CloudTrail findings on a newly onboarded account that a team spun up outside the landing zone. The account already has running workloads, so it has been generating activity with nothing recording it.

Rather than clear the easiest finding first, Devon starts by listing what trails actually exist and how each one is configured, so he can fix the whole capability with one properly built trail instead of chasing each control separately.

List every trail and the configuration the controls care about: multi-Region coverage and log file validation. An empty list, or a single-Region trail, is the failing state.

$ aws cloudtrail describe-trails --query 'trailList[].{Name:Name,MultiRegion:IsMultiRegionTrail,Validation:LogFileValidationEnabled,CWLogs:CloudWatchLogsLogGroupArn}' --output table

-----------------------------------------------------------------

+------------------+-------------+------------+-----------------+

+------------------+-------------+------------+-----------------+

# Single-Region, no validation, no CloudWatch Logs: several CloudTrail controls fail at once.

One under-configured trail trips several controls. Fix it properly once rather than chasing each finding.

How CloudTrail logging actually worksdeep dive

Two things in AWS are easy to confuse. CloudTrail event history is always on, free, single-Region and covers the last 90 days of management events, but it is a viewing feature only and cannot be exported as a durable, validated record. A trail is the thing that delivers events as log files to an S3 bucket, and optionally to CloudWatch Logs, for as long as you keep them. The control family checks for the trail, not the event history, so event history existing does not satisfy any of these controls.

The key trail properties map directly to the controls. IsMultiRegionTrail must be true so global service events such as IAM and STS, emitted only in us-east-1, are captured along with every Region you do not use. The event selector must set ReadWriteType to ALL and IncludeManagementEvents to true so reconnaissance reads, not just writes, are logged. LogFileValidationEnabled produces hourly signed digest files chained with SHA-256 so the logs are tamper-evident. A CloudWatchLogsLogGroupArn streams the same events to CloudWatch Logs within a minute or two, where a metric filter and alarm can page someone on root login or an IAM policy change. And the trail's S3 bucket should itself have server access logging on, so reads and deletes of the audit log are recorded too.

Security Hub evaluates these through AWS Config managed rules on a periodic schedule, so a fix does not flip a finding to PASSED instantly. The control plane change is immediate, but the report catches up on the next evaluation. The strongest posture is an organisation trail created at the AWS Organizations level: it applies to every member account automatically, including accounts that do not exist yet, so the whole family stays green by default rather than per account.

What is the impact of incomplete API activity logging?

The first impact is investigative blindness. When a resource is deleted, a credential is misused or a configuration changes unexpectedly, the first question is always who did this, when and from where. CloudTrail is the answer. A missing trail leaves no record at all; a single-Region trail leaves the Regions you do not watch unrecorded; a write-only trail misses the reconnaissance an attacker performs before they act; and logs with no validation can be quietly rewritten by anyone who reaches the bucket. You cannot investigate what you never recorded, and history cannot be backfilled.

The second impact is detection latency. CloudTrail delivered only to S3 lands in batched files every several minutes, which is fine for forensics but useless for stopping an incident in progress. Wiring the trail into CloudWatch Logs collapses the alerting window to a minute or two and is what makes real-time alarms on root usage, IAM changes and KMS key disables possible. Capital One is the canonical example: every attacker action was logged from minute one, but no alarm fired, and the breach surfaced months later from an external tip.

The third impact is compliance. This family maps to the CIS AWS Foundations Benchmark, NIST 800-53 audit controls (AU-2, AU-3, AU-9, AU-12) and PCI DSS section 10. A passing set of CloudTrail controls across every account is one of the cheapest and most defensible artefacts you can hand an auditor; a failing one is a concrete, citable gap that can hold up an attestation.

The cost to satisfy all of this is small and runs the right way: management events to the first trail are free, so you pay only modest S3 storage and, where used, CloudWatch Logs ingestion. The expensive mistake is over-correcting by enabling per-event data events to "be safe", which are billed per event and can add hundreds or thousands of dollars a month. None of these controls require data events.

How do you build a complete audit trail safely?

Work the capability as one loop rather than chasing individual findings. Build one trail correctly, prove it is actually logging, then make coverage automatic across the organisation so the whole family stays green.

1. Inventory what exists and find the gaps

Run describe-trails across every account and Region. Record whether any trail exists, whether each is multi-Region, whether the event selector is ReadWriteType=ALL with management events, whether log file validation is on, and whether CloudWatch Logs delivery is configured. One under-configured trail is usually the single root cause behind several CloudTrail findings, so treat the trail, not the finding count, as the unit of work.

2. Build one trail that satisfies the whole family

Create a single multi-Region trail capturing read and write management events, with log file validation enabled, delivering to a dedicated, locked-down S3 bucket that has its own server access logging on. Wire it to a CloudWatch Logs group so events are queryable and alarmable within a minute or two. Do NOT enable data events to clear these controls: they are billed per event and none of the controls require them.

3. Prove it is actually recording and alerting

create-trail only defines the trail; start-logging begins delivery. Confirm IsLogging is true, watch the first log file land in S3, verify the event selectors, and add a metric filter and alarm on the high-value events (root login, IAM policy change, CloudTrail config change, KMS key disable). Close the ticket on "logging, validated, alarming", not on "trail created".

4. Make coverage automatic across the organisation

The durable fix is an organisation trail created at the AWS Organizations level, which applies to every member account automatically, including accounts that do not exist yet. Pair it with a Service Control Policy that prevents stopping or deleting logging outside the approved path, and an AWS Config rule to catch any drift. After that, no self-service account can be born without complete logging, and the CloudTrail family stops being a recurring finding.

# Create one multi-Region trail that satisfies the whole CloudTrail family.
aws cloudtrail create-trail \
  --name org-audit-trail \
  --s3-bucket-name my-cloudtrail-logs-bucket \
  --is-multi-region-trail \
  --include-global-service-events \
  --enable-log-file-validation \
  --cloud-watch-logs-log-group-arn arn:aws:logs:us-east-1:111122223333:log-group:/aws/cloudtrail/org:* \
  --cloud-watch-logs-role-arn arn:aws:iam::111122223333:role/CloudTrail_CloudWatchLogs_Role

# Capture read AND write management events (not data events, which are billed per event).
aws cloudtrail put-event-selectors --trail-name org-audit-trail \
  --event-selectors ReadWriteType=All,IncludeManagementEvents=true

# Defining the trail does not record anything: start it, then verify it is logging.
aws cloudtrail start-logging --name org-audit-trail
aws cloudtrail get-trail-status --name org-audit-trail --query IsLogging --output text

# For org-wide coverage, recreate with --is-organization-trail from the management
# or delegated-admin account so every member account inherits it automatically.

Quick quiz

Question 1 of 5

Security Hub shows several CloudTrail findings on one account: no multi-Region trail, no log file validation, no CloudWatch Logs delivery. What is the most efficient way to fix them?

Keep learning

Go deeper on how trails, event types and validation work across the CloudTrail control family.

You can now treat audit logging as one capability rather than a scatter of findings: build one multi-Region trail with read and write management events, log file validation and CloudWatch Logs delivery, prove it is actually logging and alerting, and promote it to an organisation trail so every account inherits it by default. The Controls this lesson covers section below links every control in this group to its deep page and fix.

Back to the library

CloudTrail logging: the cost and risk view

A near-free prerequisite that almost every other assurance depends on

CloudTrail is AWS's built-in record of who did what in your cloud account: every login, configuration change, resource creation and deletion, captured with a timestamp, the identity responsible and the source of the request. This family of controls checks that the record exists, is complete across every Region, can be proven unaltered, and is wired up for alerting. The dollar cost of all of it is small and predictable: management events delivered to the first trail are free, so you pay only modest S3 storage and, where you use it, CloudWatch Logs ingestion.

The cost of getting it wrong is the opposite of small. A failing audit-logging control maps directly to PCI DSS logging requirements and to NIST 800-53 audit controls. If the business has told a customer, a regulator or an auditor that it maintains audit logs of account activity, a gap here makes that claim false for the affected account, and the price shows up as a delayed attestation, a contractual breach or a remediation deadline imposed by an assessor.

There is one cost trap worth naming. Management events are free, but CloudTrail data events (S3 object reads, Lambda invocations) are billed per event and can add hundreds or thousands of dollars a month on busy accounts. None of these controls require data events, so enabling them "to be thorough" is a cost error, not extra safety.

This lesson is for the finance partner who sees a cluster of CloudTrail findings on the security report and wants to know what the right response is and what it costs. It covers why these controls are nearly free to satisfy, why they map to PCI DSS and NIST obligations the business may already carry, the data-events cost trap to avoid, and how to turn the findings into a single org-wide fix rather than a recurring per-account chore.

Fun fact

The audit that asked one question

How a finance partner frames the CloudTrail findings

Devon brings the CloudTrail findings to his finance partner because a newly onboarded account, spun up outside the landing zone, has lit up several controls at once and he wants the spend sized before he turns anything on. The partner's first point is reassuring on cost: management events delivered to the first trail are free, so the whole family is satisfied for single-digit to low-double-digit dollars a month per account, just modest S3 storage and, where used, CloudWatch Logs ingestion. There is no budget argument for leaving it open, which makes this finding unusual; the question is never can we afford the fix, it is why is it not fixed already.

The partner reframes the exposure as compliance and incident cost rather than a line item. A failing audit-logging control maps directly to PCI DSS section 10 and to the NIST 800-53 audit family, and if the business has told a customer, a regulator or an auditor that it keeps audit logs of account activity, a gap here makes that claim false for the affected account, with the price showing up as a delayed attestation, a contractual breach or an assessor's remediation deadline. The partner also flags one cost trap to police: management events are free, but data events, S3 object reads and Lambda invocations, are billed per event and can add hundreds or thousands of dollars a month. None of these controls require data events, so after any remediation push the finance ask is to glance at the CloudTrail line; a sudden jump usually means someone enabled data events to be thorough, which is a cost error to claw back, not extra safety.

Why audit logging belongs on the risk register

The cost model here is asymmetric. Satisfying the whole CloudTrail family costs single-digit to low-double-digit dollars a month per account, because the management events it requires are delivered free to the first trail. There is no meaningful budget argument for leaving it open, which makes it unusual: the question is never can we afford to fix it, it is why is it not fixed already.

The exposure lives on the compliance and incident-cost side. A failing logging control maps to specific PCI DSS and NIST audit-logging requirements the business may have committed to through a contract, a regulator or a SOC 2 / PCI attestation. The cost of leaving it open is a delayed or qualified attestation, a contractual breach, or an incident that has to be scoped on worst-case assumptions because no record exists. Each of those is materially larger than the trail.

There is also a watch-out on the bill: after any logging remediation push, glance at the CloudTrail line. A sudden jump usually means someone enabled per-event data events unnecessarily. That is a quick conversation that can claw back real money without weakening any of these controls.

What finance can do about the CloudTrail logging gap

Finance cannot create a trail, but it can frame audit logging as a near-free prerequisite, prevent the one data-events cost trap, and connect the gap to obligations the business already carries. Three levers.

1. Fund logging as a near-free prerequisite, not a cost to weigh

The whole family costs single-digit to low-double-digit dollars a month per account because management events are delivered free to the first trail; you pay only modest S3 storage and any CloudWatch Logs ingestion. Treat it as a planned, trivial line, because there is no meaningful budget argument for leaving it open. The cost that matters is the compliance and incident exposure behind the gap, not the storage bill, so the finance posture is to approve the spend on sight and ask why a near-free control is still open.

2. Police the data-events cost trap after any remediation push

Management events are free; data events, S3 object reads and Lambda invocations, are billed per event and can add hundreds or thousands of dollars a month on a busy account. None of these controls require data events, so enabling them to be thorough is a cost error, not extra safety. Make it a standing check: after any logging remediation, glance at the CloudTrail line, and if it jumps, have the quick conversation to turn data events off, which can claw back real money without weakening any control.

3. Tie each failing control to a named obligation and a deadline

A failing audit-logging control maps to specific PCI DSS and NIST audit-logging requirements the business may have committed to through a contract, a regulator or a SOC 2 / PCI attestation. The cost of leaving it open is a delayed or qualified attestation, a contractual breach, or an incident scoped on worst-case assumptions because no record exists, each materially larger than the trail. Treat any open finding as an owned item with a deadline tied to the relevant attestation window, not a backlog candidate.

Quick quiz

Question 1 of 5

What does it cost to satisfy the whole CloudTrail control family on an account?

Keep learning

Go deeper on how trails, event types and validation work across the CloudTrail control family.

You have finished the finance view of CloudTrail logging. You know the whole family is satisfied for single-digit to low-double-digit dollars a month per account because management events are free to the first trail, that the one real cost trap is enabling per-event data events that none of the controls require, and that the exposure is compliance and incident cost, PCI DSS section 10 and the NIST 800-53 audit family, not a big bill. Next time the cluster appears, you will fund the trail on sight, police the CloudTrail line after the push, and tie each open finding to the attestation window it threatens.

Back to the library

CloudTrail logging: the headline

Whether we can answer 'who did what' across the whole estate

Audit logging is the category that determines whether, after something goes wrong, the honest answer is "here is exactly what happened" or "we have no idea." CloudTrail is the record, and the report shows the gaps as a scatter of separate findings across the CloudTrail control family.

The leadership question is not "are we compliant today?" It is "if there is an incident or an audit tomorrow, can we prove what happened in every account?" The defensible end state is one organisation-wide trail applied automatically to every account, with logging that nobody can quietly turn off outside the approved path.

This is not a cost decision. The fix is essentially engineering time plus a few dollars a month. It is a governance decision about whether a complete audit record is guaranteed by design or left to everyone remembering to turn it on.

A short read for the leader who needs to know what audit logging proves, why a gap is a governance issue rather than a budget one, and what a defensible end state looks like: one organisation-wide trail every account inherits, with logging that can't be silently disabled.

Fun fact

The audit that asked one question

What it looks like when an audit trail is guaranteed by design

The CloudTrail findings reached the executive review after an assessor asked a SaaS startup for twelve months of logs on the account holding cardholder data and the team discovered that account had never had a trail enabled. The console's event history showed the last 90 days, viewing only, with no durable export, so there was simply no record for the other nine months. The finding was not misconfigured logging, it was no logging, and it pushed the attestation back a full quarter while the team stood up trails and waited to accumulate history. The trail they eventually turned on cost a few dollars a month.

The lesson leadership drew was not about that one account. It was that audit logging is the substrate every other security capability is built on, GuardDuty, anomaly alerting and forensic timelines all consume CloudTrail, so an account with incomplete logging is missing the data several other controls depend on. The executive framing settled on the durable, structural fix: one organisation-wide trail applied automatically to every account, including accounts that do not exist yet, protected so nobody can quietly turn it off outside the approved path. The question leadership keeps asking is not are we compliant today, it is, if there is an incident or an audit tomorrow, can we prove what happened in every account, and is that guaranteed by design rather than left to everyone remembering to switch it on.

Why this is a board-level risk

Audit logging is the substrate every other security capability is built on. GuardDuty, anomaly alerting and forensic timelines all consume CloudTrail. An account with incomplete logging is not just missing one control, it is missing the data several other controls depend on, which makes every other misconfiguration more dangerous because you also cannot see how or when it was introduced.

The cost of getting this wrong is large and well documented, while the cost of fixing it is essentially engineering time plus a few dollars a month. This is the rare class of control where the risk of inaction is severe and the cost of action is small, which is exactly the trade leadership should be quickest to approve, and the durable fix is structural: one org-wide trail that no team can opt out of.

The leadership move on CloudTrail logging

The executive handle is not to approve each trail, it is to require that a complete audit record is guaranteed by design across every account and cannot be quietly turned off. Three moves.

1. Make complete logging a structural default, not a per-account chore

Require one organisation trail created at the AWS Organizations level so every member account inherits multi-Region, validated, CloudWatch-integrated logging automatically, including accounts that do not exist yet. The right outcome is that no self-service account can be born without complete logging, so the CloudTrail family stops being a recurring finding and stays green by default rather than depending on someone remembering to turn it on.

2. Make logging tamper-evident and impossible to silently disable

Insist that the trail has log file validation on so records are demonstrably unaltered, and that a Service Control Policy prevents stopping or deleting logging outside the approved path, with an AWS Config rule to catch drift. The point leadership should hold to is that the audit record exists, can be proven complete, and cannot be quietly switched off, because a record an insider can rewrite is no better than no record at all in an investigation.

3. Approve the trade quickly: severe downside, small cost

This is the rare class of control where the risk of inaction is severe, no answer to who did what after an incident or audit, while the cost of action is essentially engineering time plus a few dollars a month. The leadership move is to approve it fast and ask one standing question at review: if there is an incident or an audit tomorrow, can we prove what happened in every account, and is that guaranteed structurally rather than left to memory.

Quick quiz

Question 1 of 5

Why is audit logging described as the substrate every other security capability depends on?

Keep learning

Go deeper on how trails, event types and validation work across the CloudTrail control family.

Two takeaways: audit logging is the substrate every other security capability depends on, so an account with incomplete logging makes every other misconfiguration more dangerous, and because the downside is severe while the cost is a few dollars a month, this is the trade to approve quickest. The leadership outcome is one organisation-wide trail every account inherits, validated and protected by a Service Control Policy so it cannot be silently disabled. The question to keep asking is whether you can prove what happened in every account tomorrow, by design.

Back to the library

Controls this lesson covers

One capability, many AWS Security Hub controls. This lesson is the shared playbook; each control below keeps its own deep page with the exact check, severity and a copy-and-paste fix.

CloudTrail

Part of the learning path See what's happening

Enable CloudTrail and API activity logging

CloudTrail and API activity logging: the basics

The audit that asked one question

Finding the gaps in API activity logging

How CloudTrail logging actually worksdeep dive

What is the impact of incomplete API activity logging?

How do you build a complete audit trail safely?

1. Inventory what exists and find the gaps

2. Build one trail that satisfies the whole family

3. Prove it is actually recording and alerting

4. Make coverage automatic across the organisation

Quick quiz

Keep learning

CloudTrail logging: the cost and risk view

The audit that asked one question

How a finance partner frames the CloudTrail findings

Why audit logging belongs on the risk register

What finance can do about the CloudTrail logging gap

1. Fund logging as a near-free prerequisite, not a cost to weigh

2. Police the data-events cost trap after any remediation push

3. Tie each failing control to a named obligation and a deadline

Quick quiz

Keep learning

CloudTrail logging: the headline

The audit that asked one question

What it looks like when an audit trail is guaranteed by design

Why this is a board-level risk

The leadership move on CloudTrail logging

1. Make complete logging a structural default, not a per-account chore

2. Make logging tamper-evident and impossible to silently disable

3. Approve the trade quickly: severe downside, small cost

Quick quiz

Keep learning

Controls this lesson covers

CloudTrail

Related compliance lessons