Compliance

Enable S3 access and object-level logging

One capability across S3 server access logs and CloudTrail data events: make every bucket holding sensitive data keep a record of who read, wrote, and deleted which object, so a leak shows up in the audit trail instead of nowhere.

14 min·10 sections·AWS

Last reviewed 16 June 2026

Remediates AWS Security Hub: S3.9 S3.22 S3.23

S3 access logging: the basics

Why your bucket records who configured it but not who used it

S3 logs who configures a bucket by default, but not who uses it. There are two complementary ways to close that object-level gap. S3 server access logging is a per-bucket setting that makes S3 write a plain-text line for every request hitting the bucket (every GET, PUT, DELETE, LIST) into a target bucket you nominate, free of ingestion charges. CloudTrail data events are the newer path: every object-level GetObject, PutObject, and DeleteObject call is captured into a CloudTrail trail with full IAM context, queryable in Athena and routable to EventBridge, billed per event. Both record what server access logging and management-event-only CloudTrail miss: who actually touched the data.

AWS Security Hub turns each into its own control, which is why a single estate can fail several object-logging checks at once. S3.9 fails any bucket with no LoggingEnabled block in its BucketLogging config (server access logging off). S3.22 fails an account with no multi-Region CloudTrail trail logging write data events for S3, and S3.23 fails when no such trail logs read data events. They look like separate problems on the report, but they are one capability: make sure the buckets holding sensitive data keep a durable record of object-level access, so the question "what was actually accessed?" has an answer.

It is flagged because reads and writes are the half of object access that maps directly to data exfiltration and tampering. A leaked credential, an over-broad IAM role, or an over-shared presigned URL usually reads your data and walks out, or overwrites it, rather than touching the bucket's configuration. Without object-level logging, the most security-relevant question after an incident has no answer in your logs, and most breach-notification laws read "we cannot rule it out" as "notify everyone."

In this lesson you will learn how S3 server access logging differs from CloudTrail data events, how to find every bucket and account that is not keeping an object-level access trail, and how to enable both without setting fire to the storage or CloudTrail bill. 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 Capital One bucket was logs nobody read

When the 2019 Capital One breach was disclosed, one detail in the post-mortem was that the attacker's requests had been faithfully captured in S3 server access logs the whole time. The logs existed; nobody was tailing them. The forensics team reconstructed the entire intrusion timeline in 48 hours from those text files alone. The opposite failure is just as common: incident-response firms report year after year that a large share of cloud data-exposure cases involve buckets where object-level data-event logging was never enabled, so investigators can confirm a credential had GetObject on a bucket of customer records but cannot prove which objects were actually downloaded. Under most breach-notification laws, that is the difference between notifying 4,000 affected customers and notifying all 4 million.

Finding buckets with no access trail

Marco is reviewing the morning Security Hub digest at a fintech preparing for its annual SOC 2 review. He sees 47 instances of S3.9 across the production account, plus S3.22 and S3.23 failing at the account level: almost no bucket keeps a server access log, and CloudTrail records no object reads or writes at all.

Rather than bulk-fix everything blind, he confirms the exact check Security Hub runs and picks one bucket to validate the fix before scripting it across the fleet.

Run the audit query Security Hub uses for S3.9. An empty object is the failing case: no LoggingEnabled block means no server access logging.

$ aws s3api get-bucket-logging --bucket fintech-customer-uploads

{

}

# Empty response = no LoggingEnabled config = S3.9 FAIL.

# CloudTrail data events are also off, so S3.22 (write) and S3.23 (read) fail too.

The exact check Security Hub runs. Buckets holding sensitive data come first, since those are the ones whose access you would most need to scope.

How S3 records object-level accessdeep dive

There are two largely independent paths. Server access logs (S3.9) are the legacy mechanism: S3 batches request records server-side and writes plain-text files into a target bucket on a best-effort schedule (usually 1-5 minutes), free of ingestion charges. The control evaluates per bucket and fails when get-bucket-logging returns an empty object. CloudTrail data events (S3.22 for writes, S3.23 for reads) are the newer path: every object-level API call is captured into a CloudTrail trail with full IAM context and JSON schema, billed per event. These controls evaluate at the account level (resource type AWS::::Account) and ask whether the account has a multi-Region trail logging the relevant data events across S3; the multi-Region requirement is the detail people miss, because a single-Region trail does not satisfy them.

The destination plumbing for server access logging has a chicken-and-egg trap: the target bucket needs its own logging configuration or Security Hub flags it too, so the standard pattern is a central log-archive bucket that logs to itself with a separate prefix. The target bucket also needs a policy granting s3:PutObject to the logging.s3.amazonaws.com service principal (with an aws:SourceAccount condition to prevent confused-deputy abuse), which for newer accounts with ACLs disabled is the only mechanism that works. Use SSE-S3 rather than SSE-KMS on the target bucket, because KMS requires the logging principal to hold kms:GenerateDataKey on the key and gets messy across accounts.

For data events, you scope with advanced event selectors so the cost tracks the risk: log read and write data events for a sensitive prefix only, and leave high-traffic public buckets out where logging would be pure cost with no audit value. The same selector can cover read and write, so in practice you configure both S3.22 and S3.23 at once. Server access logs are best-effort and idiosyncratically formatted but cover the audit case cheaply; CloudTrail data events are the right complement when you need guaranteed, structured, IAM-attributed capture or real-time alerting. Most teams use server access logs broadly and data events scoped to the buckets that hold regulated data.

What is the impact of running buckets without access logging?

The direct impact is forensic blindness. S3 buckets are the long-term resting place for the most sensitive data in most organisations: backups, exports, customer uploads, training data. The bucket policy controls who can access objects; access and data-event logging are the only things that record who did. Without them, breach disclosure has to assume worst-case, because there is no way to scope down to what an attacker actually read or deleted. The cost difference between "we know it was these 14 objects" and "we must notify every customer in the bucket" can be millions of dollars in disclosure, legal, and customer-credit costs.

The regulatory impact is just as direct. SOC 2, ISO 27001, HIPAA, and PCI DSS requirement 10 all require logging of access to systems holding sensitive data, and "S3 buckets without access logging" is the textbook audit finding. For organisations with continuous-compliance attestations, an open S3.9, S3.22, or S3.23 finding is itself a control failure regardless of whether anything was breached, and it gets cited the next year if it is not fixed.

The operational impact is that incident-response time blows up. Without logs, an investigation that should take an afternoon ("did this leaked key touch our PII bucket, and what did it do?") becomes a multi-week effort of inference from billing data, CloudFront logs, and customer-side artefacts. Every additional hour of investigation has both direct labour cost and reputational cost as the breach window stays open.

How do you enable S3 access logging safely?

Work the capability as one loop rather than chasing individual findings. The order matters: stand up the destination before sources write to it, scope data events before you turn them on, and set retention before logs pile up.

1. Inventory which buckets and accounts keep an access trail

Sweep every bucket with get-bucket-logging to find the S3.9 failures, and check each account's CloudTrail trails for S3 read and write data-event selectors to find the S3.22 and S3.23 gaps. Rank buckets by data sensitivity (customer PII, payment records, and regulated exports first; build artefacts and public assets last), because that ranking decides both where logging is mandatory and where data events would be pure cost.

2. Stand up a central log-archive bucket first

Create one log-archive bucket per account (or one in a dedicated logging account), pointing its own logging at itself with a separate prefix so it does not fail S3.9 too. Use SSE-S3 for encryption, enforce TLS, and block public access. Grant s3:PutObject to logging.s3.amazonaws.com with an aws:SourceAccount condition so the logging service can write to it; for ACL-disabled accounts this bucket-policy grant is the only mechanism that works.

3. Enable server access logging broadly and data events scoped

Bulk-enable server access logging across source buckets with put-bucket-logging and a per-source prefix; the call is idempotent and S3.9 is change-triggered, so it can pass within minutes. For S3.22 and S3.23, add an advanced event selector to a multi-Region trail that logs read and write data events, scoped to sensitive prefixes only so the per-event CloudTrail cost tracks the risk rather than the whole estate's traffic.

4. Cap retention and prevent recurrence

Lifecycle the log-archive bucket aggressively (Standard for 30 days, then Glacier tiers, expiring at the compliance horizon: 12 months for SOC 2 and PCI, 6 years for HIPAA) and set retention on any CloudWatch destinations, because server access logs accumulate fast on busy buckets. Then make logging a provisioning default backed by a Config rule, so every new bucket holding sensitive data is born compliant rather than remediated after the fact.

# Enable server access logging on a flagged bucket, pointing at a central archive bucket.
aws s3api put-bucket-logging \
  --bucket fintech-customer-uploads \
  --bucket-logging-status '{"LoggingEnabled":{"TargetBucket":"fintech-s3-access-logs","TargetPrefix":"customer-uploads/"}}'

# Log object-level read and write data events, scoped to the sensitive prefix only,
# on a multi-Region trail (which is what S3.22 and S3.23 require).
aws cloudtrail put-event-selectors \
  --trail-name acme-management-trail \
  --advanced-event-selectors '[{"Name":"Log read+write data events for customer-records","FieldSelectors":[{"Field":"eventCategory","Equals":["Data"]},{"Field":"resources.type","Equals":["AWS::S3::Object"]},{"Field":"resources.ARN","StartsWith":["arn:aws:s3:::acme-customer-records/"]}]}]'

Quick quiz

Question 1 of 5

Security Hub shows S3.9 failing on many buckets and S3.22 and S3.23 failing at the account level. What is the most efficient way to think about them?

Keep learning

Go deeper on how S3 records object-level access and the trade-offs between server access logs and CloudTrail data events.

You can now treat S3 access logging as one capability rather than a scatter of findings: inventory which buckets and accounts keep an object-level trail, stand up a central log-archive bucket without tripping the same finding on itself, enable server access logging broadly and CloudTrail data events scoped to sensitive prefixes, and lifecycle the logs so storage stays bounded. The Controls this lesson covers section below links every control in this group to its deep page and fix.

Back to the library

S3 access logging: the cost and risk view

A near-zero server-log cost and a scopeable data-event cost that bound breach disclosure

These controls split into two cost shapes. Server access logging (S3.9) is almost free: you pay only for storage of the log files, a few cents per GB-month, reduced further by tiering to Glacier, with no per-request or ingestion charge. CloudTrail data events (S3.22 and S3.23) are billed per event recorded (roughly $0.10 per 100,000 events), so a high-traffic bucket can be a meaningful number if you log everything indiscriminately. The lever that keeps the bill proportionate is scoping data events to the buckets and prefixes that actually hold sensitive data.

Frame each failing control by the data behind it. A bucket of customer PII or payment records carries a far higher expected loss if its access cannot be reconstructed than a public static-asset bucket, yet both show up as a single red finding. The savings from leaving logging off the sensitive buckets are negligible; the downside is unbounded breach-disclosure cost.

The financial exposure of an unlogged bucket is the opposite order of magnitude to the logging spend. A breach affecting a bucket with no access trail forces worst-case disclosure: notifying every customer whose data could have been accessed rather than only those who were, because there is no way to narrow the scope. Regulatory fines and customer-credit costs scale with the breadth of that disclosure. The right finance posture is to enable server access logging everywhere sensitive data lives, scope data events to where the risk is, and set retention from the compliance obligation rather than storage convenience.

This lesson is for the finance partner who sees object-logging findings on the security report and a new CloudTrail data-events line appear on the bill, and wants to know what they buy and how to keep them bounded. It covers why server access logging is near-free, why data events are billed per event and must be scoped, how retention drives storage cost, and how to frame the asymmetry between logging spend and breach-disclosure exposure.

Fun fact

The Capital One bucket was logs nobody read

How a finance partner frames the object-logging findings

Priya is the finance and governance partner at the fintech, sitting in on the SOC 2 readiness review. The Security Hub export shows 47 S3.9 failures plus S3.22 and S3.23 failing at the account level, and the first question in the room is what turning logging on will add to the bill. The honest answer splits in two: server access logging is almost free, a few cents per GB-month for the log files and nothing per request, so that side of the work is a rounding error. CloudTrail data events are the line to watch, because they bill roughly $0.10 per 100,000 events and a busy bucket can run those numbers up fast if you log everything indiscriminately.

So Priya does not approve blanket data-event logging across all 47 buckets. She asks the team to rank the buckets by what they hold: customer uploads, payment exports and regulated records first, build artefacts and public static assets last. Server access logging she signs off everywhere sensitive data lives, since it costs almost nothing. Data events she scopes to the handful of buckets holding regulated data, so the per-event CloudTrail charge tracks the risk rather than the traffic. Her output for the finance pack is simple: server logging on across the sensitive estate for cents, data events scoped to the regulated buckets, and the central log-archive bucket funded as a named compliance line so a later cost sweep does not quietly cut it.

Why object logging belongs on the risk register

The financial exposure of an unlogged bucket has two components. The first is breach-scope cost: without an access trail, the legal obligation is to notify every customer whose data lived in the bucket, regardless of what was actually touched. The gap between notifying the affected accounts and notifying the entire bucket is the difference between an internal incident and a headline event, with corresponding differences in legal fees, regulatory fines, and customer-credit costs.

The second is audit cost. A single object-logging finding can delay a certification; multiple findings in the same category generate remediation plans and follow-up audits. The engineer-hours and auditor-hours to manage that cycle typically cost more than enabling logging across the account would have.

Against both, the cost of enabling logging is small and controllable. Server access logging is cents per GB-month; data events are billed per event but scopeable to the buckets that hold regulated data. The finance role is to make the asymmetry visible, set retention from the strictest applicable framework, fund the central log-archive bucket as a named compliance line so cost-optimisation sweeps do not cut it, and require that any unlogged sensitive bucket carries an explicit, finance-visible risk acceptance rather than a silently suppressed finding.

What finance can do about the object-logging gap

Finance cannot write the bucket policy or the event selector, but it can set the framing that keeps a near-free control from being deprioritised and a per-event one from running away. Three levers.

1. Separate the near-free server logs from the metered data events

Make the two cost shapes explicit so nobody treats the capability as one undifferentiated spend. Server access logging is cents per GB-month of storage with no ingestion charge, so it can go on everywhere sensitive data lives without a budget conversation. CloudTrail data events bill per event, so a single high-traffic bucket logged in full can be a meaningful line. Approve server logging broadly and require that data events are scoped to sensitive prefixes before they go on.

2. Risk-weight the buckets by the data they hold, not the finding count

The raw count of failing buckets is misleading because a public static-asset bucket and a customer-PII bucket both show up as one red finding. The number that matters for finance is which failing buckets hold regulated or customer data, because those are the ones whose missing access trail forces worst-case breach disclosure. Put the PII, payment and regulated-export buckets at the top, and treat a public asset bucket that logging would only make expensive as the lowest priority or an explicit exclusion.

3. Fund the central log-archive bucket and require recorded exceptions

Fund the central log-archive bucket as a named compliance line with retention set by the strictest framework, 12 months for SOC 2 and PCI, 6 years for HIPAA, so a cost-optimisation sweep does not cut the one bucket the auditors will ask about. Then require that any sensitive bucket left unlogged carries an explicit, finance-visible risk acceptance rather than a silently suppressed finding, because the distinction between we accepted this risk and we never looked is what makes the posture defensible after an incident.

Quick quiz

Question 1 of 5

How do the two object-logging mechanisms differ in cost shape?

Keep learning

Go deeper on how S3 records object-level access and the trade-offs between server access logs and CloudTrail data events.

You have finished the finance view of S3 object logging. You know server access logging is near-free storage while CloudTrail data events bill per event and must be scoped to sensitive prefixes, that the exposure is unbounded breach-disclosure cost rather than a line on the bill, and that the central log-archive bucket deserves a named compliance line so a cost sweep does not cut it. Next time the object-logging findings appear, you will separate the near-free logs from the metered ones, risk-weight by the data each bucket holds, and require an explicit exception for anything sensitive left unlogged.

Back to the library

S3 access logging: the headline

If data leaves, can you prove what was taken?

Every S3 bucket either records who touches the objects in it or it does not. By default AWS records who changes a bucket's configuration but not who reads, writes, or deletes the data inside. This capability flags the buckets and accounts where that object-level trail is off. Without it, a leaked credential or over-shared URL becomes a worst-case disclosure event: you cannot tell regulators or customers which objects were accessed, so you have to assume all of them were.

The leadership question is not the command; it is whether object-level logging is on by policy for the data that matters, with retention set by legal obligation and any exception carrying an explicit sign-off. The defensible end state is that sensitive buckets log access by default, so the answer to "who read that file?" is a query rather than a months-long investigation.

The cost of enabling logging is small and scopeable; the cost of not having it during an incident is not. This is less a technical configuration than a basic hygiene expectation for data that matters.

A short read for the leader who needs to know what object-level logging proves, why making it a default is a governance decision rather than a budget one, and what a defensible end state looks like: sensitive buckets logged by policy with retention tied to the compliance horizon.

Fun fact

The Capital One bucket was logs nobody read

What it looks like when object logging is policy, not afterthought

After a customer security questionnaire stalled on a single line, can you tell us which objects a compromised credential accessed, the executive team stopped treating the S3 logging findings as a backlog of red items. The honest answer at the time was no: by default the account recorded who changed a bucket's configuration but not who read, wrote or deleted the data inside. That gap is not a technical curiosity, it is the difference between telling regulators we know it was these 14 objects and telling every customer in the bucket that their data may have been taken.

Leadership set the end state rather than the implementation: sensitive buckets log object-level access by policy, retention is set by the strictest applicable framework rather than by storage convenience, and any unlogged sensitive bucket carries an explicit, signed-off exception. Because the cost of enabling logging is small and scopeable while the cost of not having it during an incident is unbounded, this was never a budget decision. It was a decision about whether the company could give a narrow, defensible answer to who read that file, or would be forced into worst-case disclosure every time.

Why this is a board-level risk

Running buckets without access logging means the organisation cannot answer the one question regulators, lawyers, and boards always ask after an incident: what data was actually accessed? Without that answer, the only defensible position is worst-case, accepting the full reputational and financial weight of an unscoped breach. Object-level logging is the mechanism that makes a narrow, defensible answer possible.

The cost of remediation is negligible relative to either the breach-scope or the audit exposure. This is one of the rare controls where the right answer is simply to enable it everywhere sensitive data lives, with data events scoped to where the risk is. The leadership question is not which buckets justify it but whether there is a policy that ensures it is on by default, with retention set by legal obligation and exceptions reviewed and approved.

The leadership move on S3 object logging

The executive handle is not to approve logging bucket by bucket, it is to require that sensitive buckets log object-level access by default and that retention and exceptions are deliberate, recorded decisions.

1. Set a default: sensitive buckets log access on creation

Make it policy that any bucket holding regulated or customer data is provisioned with server access logging on and data events scoped to it, enforced in the provisioning baseline and an AWS Config rule rather than remembered per bucket. The right end state is that the Security Hub findings can only appear for a known list being remediated, never for a sensitive bucket created last Friday with no policy attached.

2. Tie retention to legal obligation, not storage convenience

Set the log-archive retention from the strictest applicable framework and have it confirmed by legal, not chosen by whoever wanted the storage bill lower. Logs that expire before the compliance horizon are worse than none, because they imply a control that was not actually there when it mattered. Ask which framework sets the retention and confirm the lifecycle policy matches it.

3. Treat any unlogged sensitive bucket as a recorded exception

A sensitive bucket left without an object-level trail should carry a documented, governance-visible reason with an explicit sign-off, not a quietly suppressed finding. The distinction between we reviewed this and accepted the risk and we never looked is exactly what makes the answer to which objects were accessed defensible in front of a regulator or a customer. Ask for the exception list, not just the pass rate.

Quick quiz

Question 1 of 5

What is the one question object-level logging exists to let the business answer after an incident?

Keep learning

Go deeper on how S3 records object-level access and the trade-offs between server access logs and CloudTrail data events.

Two takeaways: a bucket with no object-level trail forces worst-case disclosure because you cannot prove which objects were touched, and the fix is cheap and scopeable while the absence is unbounded. The leadership outcome is sensitive buckets logged by policy on creation, retention set by legal obligation, and every exception on the record with a sign-off. The question to ask is not what logging costs, it is whether we can answer who read that file with a query rather than a worst-case assumption.

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.

S3

Part of the learning path See what's happening

Enable S3 access and object-level logging

S3 access logging: the basics

The Capital One bucket was logs nobody read

Finding buckets with no access trail

How S3 records object-level accessdeep dive

What is the impact of running buckets without access logging?

How do you enable S3 access logging safely?

1. Inventory which buckets and accounts keep an access trail

2. Stand up a central log-archive bucket first

3. Enable server access logging broadly and data events scoped

4. Cap retention and prevent recurrence

Quick quiz

Keep learning

S3 access logging: the cost and risk view

The Capital One bucket was logs nobody read

How a finance partner frames the object-logging findings

Why object logging belongs on the risk register

What finance can do about the object-logging gap

1. Separate the near-free server logs from the metered data events

2. Risk-weight the buckets by the data they hold, not the finding count

3. Fund the central log-archive bucket and require recorded exceptions

Quick quiz

Keep learning

S3 access logging: the headline

The Capital One bucket was logs nobody read

What it looks like when object logging is policy, not afterthought

Why this is a board-level risk

The leadership move on S3 object logging

1. Set a default: sensitive buckets log access on creation

2. Tie retention to legal obligation, not storage convenience

3. Treat any unlogged sensitive bucket as a recorded exception

Quick quiz

Keep learning

Controls this lesson covers

S3

Related compliance lessons