I85PREP
⌘ K
AWS Security Specialty study materials
AWS Security Specialty study resources

Fifteen-Minute Attribution on a Two-Billion-Request Bucket

AWS Security Specialty · Put your knowledge to work in context.

All case studies

Fifteen-Minute Attribution on a Two-Billion-Request Bucket

A 60-account organization delivers its CloudTrail organization trail, management events only, to a central log archive bucket. One data-lake bucket in the analytics account takes roughly 2 billion GET and 400 million PUT requests per month. Two unrelated buckets already have S3 server access logging enabled. GuardDuty S3 Protection is on organization-wide. Compliance asks you to answer, within 15 minutes of an alert, "which principal read or deleted object X at 14:03" for any object in the data-lake bucket, and to keep the answer retrievable for 400 days. Finance has rejected a blanket proposal to enable CloudTrail data events on every bucket in the organization, and the team has previously found gaps and multi-hour delays in the server access logs it does have.

1. Which available sources can actually satisfy the 15-minute attribution requirement, and where does each fall short?

Read the worked answer

Rank by fitness for the specific question asked.

CloudTrail data events - the only source that meets the latency and authority requirement. Records carry the principal ARN, session name, source IP, object key and request ID, and are typically queryable in minutes. They are also the only source with the same fidelity as the management-event trail, so correlation is trivial.

S3 server access logs - complementary, not a substitute. Best-effort delivery, often hours late, no delivery guarantee, and known gaps. They do capture some request classes CloudTrail does not, such as certain unauthenticated or signature-mismatched requests, so keep them where they already run - but do not promise a 15-minute SLA on them.

GuardDuty S3 Protection - detection, not attribution. It will tell you a principal behaved anomalously; it will not give you the object-level ledger compliance is asking for.

Management events - wrong event category. DeleteObject, PutObject and GetObject are data events. Management events cover bucket creation, policy changes and deletion of the bucket itself.

So the answer to compliance is: data events, and only data events, on this bucket. The negotiation with Finance is therefore about scope and retention, not about whether to turn it on.

2. Design the CloudTrail configuration and retention so the requirement is met without an open-ended bill. Be specific about selectors, partitioning and lifecycle.

Read the worked answer

Scope the selectors, not the intent. Use advanced event selectors on the organization trail:

  • eventCategory = Data
  • resources.type = AWS::S3::Object
  • resources.ARN starting with the data-lake bucket plus the specific prefixes that hold regulated data, and the vendor-drop prefix separately
  • readOnly split into two selectors so reads and writes can be tuned independently later

At ~2.4 billion requests/month, all-object data events is a five-figure annual line item at list pricing; a prefix-scoped selector covering a small fraction of that volume is a rounding error. Verify current per-event pricing before quoting Finance a number.

Partitioning and retention. CloudTrail writes gzipped JSON with a predictable key layout; register the prefix in the Glue catalog partitioned by account, region and date so Athena scans prune. Lifecycle the archive bucket to an infrequent-access class after 90 days and expire at 400 days plus a margin - the compliance clock is 400 days, so the retention rule is the requirement, not a guess.

Consider CloudTrail Lake only if query latency dominates. It gives SQL over an event data store with configurable retention up to 10 years, but you pay per GB ingested on the full event volume, which is exactly the cost shape Finance rejected.

Write the gap into the design: data events do not cover requests that never authenticated successfully. Keep server access logs on the bucket as the complementary record.

3. Three months later the team discovers that a DeleteObject on a regulated prefix was never alerted on, even though data events were enabled. What are the plausible causes and how do you verify each?

Read the worked answer

Enumerate the failure modes rather than assuming one.

  1. The selector excluded the prefix. The object was written under a key that did not match the ARN prefix filter (for example a different case, or a prefix/ vs prefix mismatch). Verify by querying Athena for any event on that bucket in the window; if the bucket is broadly silent, the selector is too narrow.
  2. DeleteObjects vs DeleteObject. A bulk delete via the multi-object API is a distinct event name. If alerting filtered on eventName = DeleteObject, it will miss bulk deletions entirely.
  3. The trail stopped delivering. Check the trail's LatestDeliveryTime and LatestDeliveryError via the API, and alarm on both. A bucket policy that excludes the trail's account - common after a bucket policy is tightened - silently breaks delivery.
  4. Alerting, not logging, was broken. Confirm the event exists in S3 before touching the detection rule. If it does, the EventBridge pattern or downstream rule is at fault; if the pattern relied on resources.ARN matching, check it against the actual event shape.
  5. Deletion via lifecycle expiration or a bucket-level operation produces no DeleteObject event at all. That is a configuration finding, not a logging gap, and belongs in AWS Config rules.

Verification order: prove the event exists or does not exist in the archive first, then walk backwards to the rule. Debugging the alert before confirming the log exists is how teams spend three days on the wrong layer.