Amazon S3 CloudTrail events
Important
Amazon S3 now applies server-side encryption with Amazon S3 managed keys (SSE-S3) as the base level of encryption for every bucket in Amazon S3. Starting January 5, 2023, all new object uploads to Amazon S3 are automatically encrypted at no additional cost and with no impact on performance. The automatic encryption status for S3 bucket default encryption configuration and for new object uploads is available in AWS CloudTrail logs, S3 Inventory, S3 Storage Lens, the Amazon S3 console, and as an additional Amazon S3 API response header in the AWS Command Line Interface and AWS SDKs. For more information, see Default encryption FAQ.
This section provides information about the events that S3 logs to CloudTrail.
Amazon S3 data events in CloudTrail
Data events provide information about the resource operations performed on or in a resource (for example, reading or writing to an Amazon S3 object). These are also known as data plane operations. Data events are often high-volume activities. By default, CloudTrail doesn’t log data events. The CloudTrail Event history doesn't record data events.
Additional charges apply for data events. For more information about CloudTrail pricing, see
AWS CloudTrail Pricing
You can log data events for the Amazon S3 resource types by using the CloudTrail console, AWS CLI, or CloudTrail API operations. For more information about how to log data events, see Logging data events with the AWS Management Console and Logging data events with the AWS Command Line Interface in the AWS CloudTrail User Guide.
The following table lists the Amazon S3 resource types for which you can log data events.
The Data event type (console) column shows the value to
choose from the Data event type list on the CloudTrail console. The resources.type value column shows the resources.type
value, which you would specify when configuring advanced event selectors using the AWS CLI or
CloudTrail APIs. The Data APIs logged to CloudTrail column shows the API
calls logged to CloudTrail for the resource type.
| Data event type (console) | resources.type value | Data APIs logged to CloudTrail |
|---|---|---|
| S3 |
AWS::S3::Object
|
|
| S3 Access Point |
AWS::S3::Access Point
|
|
| S3 Object Lambda |
AWS::S3ObjectLambda::AccessPoint
|
|
| S3 Outposts |
AWS::S3Outposts::Object
|
You can configure advanced event selectors to filter on the eventName,
readOnly, and resources.ARN fields to log only those events that
are important to you. For more information about these fields, see AdvancedFieldSelector in the
AWS CloudTrail API Reference.
Amazon S3 management events in CloudTrail
Amazon S3 logs all control plane operations as management events. For more information about S3 API operations, see the Amazon S3 API Reference.
How CloudTrail captures requests made to Amazon S3
By default, CloudTrail logs S3 bucket-level API calls that were made in the last 90
days, but not log requests made to objects. Bucket-level calls include events
such as CreateBucket, DeleteBucket,
PutBucketLifecycle, PutBucketPolicy, and so on.
You can see bucket-level events on the CloudTrail console. However, you can't view
data events (Amazon S3 object-level calls) there—you must parse or query CloudTrail
logs for them.
Amazon S3 account-level actions tracked by CloudTrail logging
CloudTrail logs account-level actions. Amazon S3 records are written together with other AWS service records in a log file. CloudTrail determines when to create and write to a new file based on a time period and file size.
The tables in this section list the Amazon S3 account-level actions that are supported for logging by CloudTrail.
Amazon S3 account-level API actions tracked by CloudTrail logging appear as the following event names. The CloudTrail event names differ from the API action name. For example, DeletePublicAccessBlock is DeleteAccountPublicAccessBlock.
Amazon S3 bucket-level actions that are tracked by CloudTrail logging
By default, CloudTrail logs bucket-level actions for general purpose buckets. Amazon S3 records are written together with other AWS service records in a log file. CloudTrail determines when to create and write to a new file based on a time period and file size.
This section lists the Amazon S3 bucket-level actions that are supported for logging by CloudTrail.
Amazon S3 bucket-level API actions tracked by CloudTrail logging appear as the following
event names. In some cases, the CloudTrail event name differs from the API action
name. For example, PutBucketLifecycleConfiguration is
PutBucketLifecycle.
In addition to these API operations, you can also use the OPTIONS object object-level action. This action is treated like a bucket-level action in CloudTrail logging because the action checks the CORS configuration of a bucket.
S3 Express One Zone bucket-level (Regional API endpoint) actions tracked by CloudTrail logging
By default, CloudTrail logs bucket-level actions for directory buckets as
management events. The eventsource for CloudTrail management events for S3 Express One Zone is
s3express.amazonaws.com.
Note
For S3 Express One Zone, CloudTrail logging of Zonal endpoint (object-level, or data plane) API operations (for example,
PutObject or GetObject) is not supported.
These following Regional endpoint API operations are logged to CloudTrail.
For more information, see Security best practices for S3 Express One Zone.
Amazon S3 object-level actions in cross-account scenarios
The following are special use cases involving the object-level API calls in cross-account scenarios and how CloudTrail logs are reported. CloudTrail delivers logs to the requester (the account that made the API call), except in some access denied cases where log entries are redacted or omitted. When setting up cross-account access, consider the examples in this section.
Note
The examples assume that CloudTrail logs are appropriately configured.
Example 1: CloudTrail delivers logs to the bucket owner
CloudTrail delivers logs to the bucket owner even if the bucket owner does not have permissions for the same object API operation. Consider the following cross-account scenario:
-
Account A owns the bucket.
-
Account B (the requester) tries to access an object in that bucket.
-
Account C owns the object. Account C might or might not be the same account as Account A.
Note
CloudTrail always delivers object-level API logs to the requester (Account B). In addition, CloudTrail also delivers the same logs to the bucket owner (Account A) even when the bucket owner does not own the object (Account C) or have permissions for those same API operations on that object.
Example 2: CloudTrail does not proliferate email addresses that are used in setting object ACLs
Consider the following cross-account scenario:
-
Account A owns the bucket.
-
Account B (the requester) sends a request to set an object ACL grant by using an email address. For more information about ACLs, see Access control list (ACL) overview.
The requester gets the logs along with the email information. However, the bucket owner—if they are eligible to receive logs, as in example 1—gets the CloudTrail log reporting the event. However, the bucket owner doesn't get the ACL configuration information, specifically the grantee email address and the grant. The only information that the log tells the bucket owner is that an ACL API call was made by Account B.
