Choose the S3 object events your investigation will need

Write the investigation questions first

Suppose a team needs to explain who read or replaced objects under a sensitive S3 prefix. A list of enabled logging services does not yet answer that question. The collection decision needs the object operations, bucket and prefix that matter, plus the period for which investigators expect to retrieve the resulting records.

AWS documents S3 object-level activity as CloudTrail data events, which are not logged by default and are not available in the standard CloudTrail Event history view. A reviewer who searches that view and finds no object read has not established that the read did not happen. The relevant collection path must first exist. ^[1]

Turn the investigation question into a short contract. Name the bucket owner, the object prefix, relevant read and write operations, collection destination and retention owner. Decide whether activity outside that prefix matters to a separate question. The purpose is to make a deliberate scope choice, not to imply that a narrow object selector supplies complete evidence for the account.

Choose the event category deliberately

CloudTrail advanced selectors can filter data events by fields including eventCategory, resources.type, resource ARN and event properties such as readOnly or eventName. AWS documents AWS::S3::Object as the resource type for ordinary S3 object data events. A category selection and a resource selection describe different parts of the matching decision. ^[2]

For this article's hypothetical case, the intended selection is object data events for GetObject and PutObject inside one reviewed prefix of a general-purpose bucket. The accessible matrix uses that limited scope. It is not a recommendation to exclude other operations from every production trail, and it is not an executable configuration for all S3 resource types.

Write down why the named operations answer the question and which questions they leave open. If deletion, tagging or another operation matters to the investigation, include that requirement before choosing the selector. An apparently clean set of records can be incomplete simply because the collection contract was narrower than the investigator's later question.

Translate scope into selectors

Resource scope deserves a literal comparison. AWS's selector guidance supports ARN prefix matching with StartsWith; that is different from assuming an asterisk is interpreted as a wildcard inside an arbitrary string. For a bucket boundary, include the slash after the bucket name, then the intended object prefix. Confirm the expected ARN form for the resource type. ^[2]

Consider a placeholder boundary such as arn:aws:s3:::REVIEWED-BUCKET/reports/. The hypothetical reports/ scope and a similarly named prefix elsewhere should be different test cases. Keep the example clearly separate from the reader's actual bucket identifiers and policy. The string shown here is a review aid, not a configuration that has been deployed.

The matrix records expected selector results, not observed events. Pair it with a configuration review that checks spelling, resource type, event names and whether read-only filtering unintentionally excludes one of the chosen operations. A resource prefix that looks plausible in prose still needs to match the exact configuration stored in CloudTrail.

Source. Primary documentation ^{[1] [2] [3] [4] [5]}. Accessed August 28, 2026.

Method. Expected matches for a hypothetical GetObject and PutObject selection inside one reviewed S3 object prefix, derived from AWS selector documentation. The matrix does not report observed events or delivery results.

Accessible table and figure data

Figure 1 accessible table

Hypothetical request	Selected by example	Reason
GetObject in reviewed prefix	Yes	Named read event and resource prefix
PutObject in reviewed prefix	Yes	Named write event and resource prefix
DeleteObject outside reviewed prefix	No	Outside the chosen resource scope
GetObject in a similarly named bucket	No	Exact bucket prefix includes the slash boundary
Bucket policy change	Separate management selector	Not an object-data request

Figure 1 accessible table

Hypothetical request	Selected by example	Reason
GetObject in reviewed prefix	Yes	Named read event and resource prefix
PutObject in reviewed prefix	Yes	Named write event and resource prefix
DeleteObject outside reviewed prefix	No	Outside the chosen resource scope
GetObject in a similarly named bucket	No	Exact bucket prefix includes the slash boundary
Bucket policy change	Separate management selector	Not an object-data request

Download imageDownload table CSV

Treat selector replacement as a production change

The PutEventSelectors API changes the trail's event-selector configuration. AWS documents replacement behavior and the distinction between basic and advanced selectors. Moving to advanced selectors is not safely understood as appending a new object filter to every existing selection. Preserve all intended event coverage explicitly in the replacement configuration. ^[3]

Before the change, export a reviewable copy of the current selector configuration and identify its owner. Compare the proposed replacement against it, including the management-event selection. A request to add evidence for object reads should not unintentionally remove the management operations needed to explain who changed the bucket or the trail itself.

Define a rollback configuration and an approved change window. The rollback should restore the known prior selection, not a hand-reconstructed approximation made during an incident. After applying an authorized change, read the configuration back and compare it with the approved version. Configuration acceptance and event receipt should be recorded as separate steps.

Validate records rather than a green toggle

CloudTrail event records provide fields such as event time, event source, event name, identity and resource context, with availability depending on the event. AWS's record reference is the appropriate basis for deciding which fields a parser or investigation query may rely on. Do not assume that every record contains every optional field. ^[4]

An authorized validation exercise should generate a harmless in-scope read and write against test objects, then retrieve their expected records through the intended evidence path. Include an out-of-scope request to test the selector boundary. Use a distinct test marker where practical and record the action, target, time and the record actually found, without publishing sensitive identifiers.

If a record is absent, investigate matching, delivery, query filters and access permissions separately. An empty search result does not identify which stage failed. Preserve the negative result and the configuration snapshot so the next reviewer can reproduce the question instead of receiving only a final statement that “logging works.”

Publish the blind spots and retention decision

AWS compares CloudTrail with S3 server access logging and documents differences in the information and operations they record. They are distinct evidence sources rather than interchangeable names for the same dataset. Choose any complementary source because it answers a specific remaining question, and document how its records will be retained and interpreted. ^[5]

Keep collection scope, expected delivery and retention in separate fields. A selector can be correct while a downstream destination is inaccessible to investigators or retains records for too short a period. Name the person who owns each stage and set a retrieval check that uses the investigator's authorized access rather than only the logging administrator's view.

For a shared logging arrangement, distinguish the bucket owner from the trail owner and the investigator. Record who can approve a selector change and who can authorize a retrieval test. This avoids a handoff in which each team confirms its own configuration while nobody verifies the complete question.

The review is ready for approval when the owner can explain both a selected and an excluded request, show that the intended configuration was preserved and point to a receipt from the authorized validation exercise. The excluded case is particularly useful: it proves that the team understands the boundary it chose and can recognize when a future investigation requires that boundary to change.