AWS S3 – Client and Server Side Encryption

AWS S3 client-side and server-side encryption gives you five distinct ways to protect data in Amazon Simple Storage Service, each with a different balance of key ownership, operational complexity, audit depth, and cost. The right choice depends on who you need to lock out: just external attackers, or AWS itself. This guide covers every S3 encryption option, when to use each one, how to enforce them with bucket policies, what shows up in CloudTrail, and how to decide between native key management, BYOK, and HYOK.

Quick Answer: Which AWS S3 Encryption Option Should You Use?

For most workloads: use SSE-KMS with a customer-managed KMS key. You get AES-256 encryption at rest, a complete CloudTrail audit trail of every encrypt and decrypt event tied to an IAM identity, independent key disable capability, and automatic annual key rotation. For highest key sovereignty (where AWS must never hold your key): use client-side encryption with your own master key. For simplest setup with no key management overhead and no audit trail requirement: SSE-S3 (which is now the S3 default since January 2023). For supplying your own key per-request without using KMS: SSE-C.

Key Takeaways

• S3 encrypts by default since January 2023: All new objects in any S3 bucket are automatically encrypted with SSE-S3 (AES-256) even without explicit configuration. Existing objects are not retroactively encrypted.
• Five encryption options exist, split across two categories: Server-side (SSE-S3, SSE-KMS, SSE-C) means S3 handles the encryption operation after receiving the data. Client-side means you encrypt before uploading, so S3 never sees plaintext.
• SSE-KMS is the recommended default for regulated workloads: It provides a per-operation audit trail in CloudTrail, supports customer-managed keys with BYOK, and allows you to disable or delete a key to immediately prevent decryption without deleting objects.
• BYOK and HYOK serve different sovereignty requirements: BYOK (importing your own key material into AWS KMS) keeps the key in AWS during use but gives you provenance. HYOK (client-side encryption with your own master key) means AWS never touches the key at any point.
• Encryption in transit requires a separate bucket policy: S3 default encryption only covers data at rest. Deny aws:SecureTransport=false in your bucket policy to enforce TLS for all requests.

What Is AWS S3 Encryption and Why Does It Matter?

Amazon S3 (Simple Storage Service) is AWS’s object storage service. It stores data as objects inside containers called buckets. Each object can be up to 5 TB. S3 is widely used for backups, data lakes, application assets, log archives, and regulated data sets including healthcare (HIPAA), financial (PCI DSS), and government (FedRAMP) workloads.

Encryption in S3 addresses two separate threat models. Encryption at rest protects objects stored on disk from being read if the underlying storage media is accessed without authorization. Encryption in transit protects objects while they travel between clients and the S3 service. Both are required for most compliance frameworks, and both require separate configurations in S3.

S3 uses AES-256 with Galois Counter Mode (AES-256-GCM) for all symmetric encryption operations. GCM provides authenticated encryption: it appends a unique authentication tag to every encrypted object, verifying both that the data has not been tampered with and that the correct key was used for decryption. This protects against both passive eavesdropping and active modification of stored ciphertext.

Encryption in Transit: Enforcing TLS for All S3 Requests

S3 supports HTTPS (TLS) for all API requests. TLS encrypts the connection between the client and the S3 endpoint, protecting object data and request metadata in transit. However, S3 does not enforce HTTPS by default; an S3 bucket without a policy will accept both HTTP and HTTPS requests.

To enforce TLS for all requests to a bucket, apply a bucket policy that denies any request where the aws:SecureTransport condition key is false. The policy below denies all GetObject requests that do not use HTTPS:

{
  "Id": "EnforceSSLOnly",
  "Version": "2012-10-17",
  "Statement": [
    {
      "Sid": "DenyNonSSLRequests",
      "Action": "s3:*",
      "Effect": "Deny",
      "Resource": [
        "arn:aws:s3:::your-bucket-name",
        "arn:aws:s3:::your-bucket-name/*"
      ],
      "Condition": {
        "Bool": {
          "aws:SecureTransport": "false"
        }
      },
      "Principal": "*"
    }
  ]
}

Apply this policy to every S3 bucket that contains sensitive data. Note that the Resource block needs to cover both the bucket ARN and the object ARN (with /*) to deny both bucket-level and object-level API calls made over HTTP.

Server-Side Encryption (SSE): Three Options Explained

Server-side encryption means S3 receives your data over HTTPS, then encrypts it before writing it to disk. S3 stores the ciphertext. When you request the object, S3 decrypts it (using the appropriate key) before sending it back to you over HTTPS. The encryption and decryption happen inside the S3 service boundary. Your application does not need to handle cryptographic operations.

SSE-S3: S3-Managed Keys (The Default Since January 2023)

SSE-S3 (Server-Side Encryption with Amazon S3-Managed Keys) is the default encryption method for all new S3 objects as of January 2023. AWS generates a unique AES-256-GCM data encryption key for each object. That data key is then encrypted with a regularly-rotated master key that AWS manages entirely. You have no visibility into or control over either key.

SSE-S3 is appropriate for workloads where encryption at rest is required but there is no requirement for a customer audit trail of key usage or independent key control. It adds zero operational overhead and zero cost beyond standard S3 storage. The trade-off: you cannot disable, rotate, or audit access to the encryption key. There is no CloudTrail record of individual object decryptions. You cannot revoke the ability to decrypt an object without deleting the object itself.

SSE-KMS: KMS-Managed Keys with Audit Trail and Customer Control

SSE-KMS uses AWS Key Management Service (KMS) to manage the encryption keys that protect your S3 objects. When you upload an object with SSE-KMS, S3 calls KMS to generate a data encryption key (DEK). KMS returns two versions: a plaintext DEK (used to encrypt the object) and an encrypted DEK (stored alongside the encrypted object in S3). S3 discards the plaintext DEK immediately after encrypting the object. When you download the object, S3 sends the encrypted DEK to KMS, which decrypts it and returns the plaintext DEK so S3 can decrypt the object and return it to you.

Every GenerateDataKey and Decrypt call to KMS generates a CloudTrail log entry that includes the KMS key ARN, the requesting IAM principal, the S3 bucket and object key, and a timestamp. This gives you a complete, identity-linked audit trail of every encrypt and decrypt event on every S3 object protected by SSE-KMS.

SSE-KMS supports two key types, which have significantly different security and control properties:

AWS-managed KMS key (aws/s3): AWS creates this key automatically the first time you enable SSE-KMS on a bucket without specifying a CMK. AWS manages the key entirely, including rotation (every three years for aws/s3 keys). You can view the key in KMS but cannot change its policy, disable it, or delete it. You get CloudTrail logging but no independent control over the key.

Customer-managed KMS key (CMK): You create this key in KMS before enabling SSE-KMS. You define the key policy, control who can use the key for S3 encryption and decryption, enable automatic annual rotation, and can disable or delete the key at any time. Disabling the CMK immediately prevents S3 from decrypting any objects encrypted with that key, without deleting those objects. This is the recommended option for regulated workloads.

SSE-C: Customer-Provided Encryption Keys

SSE-C (Server-Side Encryption with Customer-Provided Keys) requires you to include a 256-bit AES encryption key in the HTTP request header for every PutObject (upload) and GetObject (download). S3 uses your provided key to perform the AES-256 encryption or decryption operation, then immediately discards the key from memory. S3 stores only a randomly salted HMAC (Hash-Based Message Authentication Code) fingerprint of the key to validate future requests.

The consequence: if you lose the key, you permanently lose access to every object encrypted with it. There is no key recovery mechanism. SSE-C must use HTTPS; S3 rejects SSE-C requests made over HTTP.

SSE-C is appropriate when you need S3 to perform encryption operations but you cannot or will not put your key into AWS KMS. You accept full responsibility for key management, rotation, storage, and distribution to every system that needs to access the objects. SSE-C generates no KMS CloudTrail events because it does not use KMS.

Client-Side Encryption: Encrypting Before Upload

Client-side encryption means your application or client encrypts the data before it leaves your environment. What S3 receives and stores is already ciphertext; S3 never has access to the plaintext. This is the only S3 encryption model where AWS cannot access your data under any operational circumstance, including legal compulsion directed at AWS.

The AWS SDK for Java (and other languages) provides an S3 encryption client that implements client-side encryption. There are two key management options:

Client-side with AWS KMS CMK: Your application calls KMS to generate a plaintext data key and an encrypted data key. Your application encrypts the object with the plaintext data key, discards the plaintext key, and uploads the ciphertext along with the encrypted data key as object metadata. To download and decrypt, your application retrieves the encrypted data key from the object metadata, calls KMS to decrypt it, uses the returned plaintext data key to decrypt the object, and discards the plaintext key. AWS KMS is involved in key wrapping, so there is a CloudTrail record of key operations, but AWS never has access to the plaintext object data.

Client-side with a self-managed master key: Your application uses its own master key (stored in your HSM, key management system, or application keystore) to wrap and unwrap the data encryption key. AWS is not involved in any key operation. This is the HYOK (Hold Your Own Key) model: the encryption key is entirely outside AWS. Even if AWS were compelled to provide access to your S3 bucket, the stored ciphertext is useless without the master key that never entered AWS.

Native Key Control vs. BYOK vs. HYOK: Which Model Fits Your Requirements?

The most consequential encryption decision for any S3 workload is not which AES mode to use — it is who controls the keys. The three key control models available for S3 have very different security properties, operational requirements, and compliance implications.

Dimension	Native (SSE-S3 or AWS-managed KMS key)	BYOK (Customer-managed KMS key with imported key material)	HYOK (Client-side encryption with self-managed master key)
Who generates the encryption key	AWS	Customer (imported into KMS)	Customer (never enters AWS)
AWS access to plaintext key	Yes	Yes, during active KMS operations	No
CloudTrail audit trail per object	SSE-S3: No. AWS-managed KMS: Yes	Yes (GenerateDataKey + Decrypt events)	KMS variant: Yes (key wrap/unwrap). Self-managed: No
Independent key disable/revoke	SSE-S3: No. AWS-managed KMS: No	Yes (disable or delete CMK immediately)	Yes (revoke at your key management system)
Automatic key rotation	SSE-S3: Yes (AWS-managed). AWS-managed KMS: Every 3 years	Yes (annual for CMK) or manual for imported material	Fully customer-managed
Operational complexity	Low	Medium	High
KMS API cost per S3 operation	SSE-S3: None. AWS-managed KMS: $0.03/10k calls	$0.03/10k calls	KMS variant: $0.03/10k calls. Self-managed: None
Best for	General workloads; simplicity priority	Regulated sectors; HIPAA, PCI DSS, FedRAMP	Zero-trust storage; air-gapped; classified data

IAM Model: Least-Privilege Access for S3 Encryption

Encryption alone does not prevent unauthorized access. Proper IAM configuration determines who can read (and therefore decrypt) S3 objects. A well-designed IAM model for SSE-KMS S3 workloads separates encryption key management from data access using three layers of control.

S3 bucket policy: Controls which IAM principals can perform S3 API calls (GetObject, PutObject, ListBucket, DeleteObject) on the bucket and its objects. For SSE-KMS enforcement, add a Deny condition requiring the s3:x-amz-server-side-encryption header to be aws:kms on all PutObject requests, ensuring no unencrypted objects can be uploaded.

KMS key policy: Controls which IAM principals can use the CMK for kms:GenerateDataKey (needed to encrypt objects) and kms:Decrypt (needed to decrypt objects). S3 service calls KMS on behalf of the requesting IAM principal; the principal must have both S3 and KMS permissions for the operation to succeed. Separate the key administrator role (who can manage key policy, rotate, disable) from the key user role (who can encrypt/decrypt via S3).

IAM identity policy: The calling principal’s IAM policy must allow both the S3 action and the KMS action. For a read-only role that should access S3 objects but never upload new ones, grant s3:GetObject and kms:Decrypt only. For a write role, add s3:PutObject and kms:GenerateDataKey. Never grant kms:CreateKey, kms:DeleteKey, or kms:DisableKey to application roles.

Service Control Policies (SCPs): If your AWS accounts are in an AWS Organization, SCPs provide a guardrail layer above IAM policies. Use an SCP to deny any S3 PutObject that does not include an encryption header, preventing any principal in the organization from accidentally storing unencrypted S3 objects regardless of individual account IAM configurations.

Key Rotation for S3 Encryption

Key rotation for S3 SSE-KMS works through KMS key rotation, not through re-encrypting every S3 object. When automatic annual rotation is enabled on a customer-managed CMK, KMS generates new cryptographic material and marks it as the active version. All new S3 PutObject operations use the new key material. Existing objects remain encrypted with the key material version that was active when they were uploaded; KMS retains all previous versions and uses the correct one when decrypting those older objects.

This means you never need to re-upload or re-encrypt your S3 objects to implement key rotation. The CMK ARN and key ID remain the same; the rotation is transparent to S3 and to your applications. The rotation event is logged in CloudTrail under the RotateKey event type.

For BYOK keys with imported key material, automatic rotation is not available through KMS. You must generate new key material externally, import it into the same CMK, set it as the primary key material, and manage the transition timeline yourself. For SSE-C, you are fully responsible for rotation: you must supply new keys in your requests and re-encrypt existing objects if you want to change the key protecting them.

CloudTrail Logging for S3 Encryption Events

CloudTrail logging is the audit backbone for SSE-KMS encryption compliance. Every KMS API call made by S3 on behalf of a requesting principal generates a CloudTrail record that includes the KMS key ARN, the IAM principal (user, role, or service), the source IP address, the S3 bucket name and object key, and a timestamp.

The two events to monitor are GenerateDataKey (generated when an object is uploaded with SSE-KMS) and Decrypt (generated when an object is downloaded and decrypted). Alerting on these events enables several security use cases: detecting unexpected principals decrypting sensitive objects, identifying unusually high decryption volumes that might indicate data exfiltration, auditing compliance with data access policies, and building evidence packages for regulatory audits.

Configure CloudTrail to deliver S3 data events in addition to management events, as S3 object-level activity (GetObject, PutObject, DeleteObject) is not captured in management event logs by default. Route CloudTrail logs to a separate, write-protected S3 bucket in a dedicated security account to prevent tampering.

Cost Considerations for S3 Encryption

SSE-S3 adds no cost to S3 storage or requests. SSE-KMS adds KMS API call costs: AWS KMS charges $0.03 per 10,000 API calls (GenerateDataKey for uploads, Decrypt for downloads). For a workload uploading and downloading 1 million objects per month, the KMS API cost is approximately $6 per month per CMK per region. Customer-managed KMS keys also cost $1 per key per month.

At high request volumes (tens of millions of S3 operations per month), KMS API costs become meaningful. S3 mitigates this through a bucket-level key feature: when you enable the S3 Bucket Key option on an SSE-KMS bucket, S3 generates a short-lived bucket-level data key from your CMK and uses it to generate individual object DEKs locally, reducing KMS API calls by up to 99%. The Bucket Key approach dramatically reduces cost for high-throughput S3 workloads while preserving the same encryption properties.

SSE-C has no AWS cost for key management, but you bear the full operational cost of storing, distributing, rotating, and protecting the key outside AWS. Client-side encryption with a self-managed master key similarly has no AWS key management cost but requires your own infrastructure for key lifecycle management.

Enforcing S3 Encryption with Bucket Policies

Encryption configuration on a bucket sets the default behavior for new objects, but it does not prevent a caller from explicitly uploading an unencrypted object unless you add a Deny policy. To guarantee that all objects are encrypted and that only your chosen method is used, combine two Deny statements in the bucket policy.

To enforce SSE-KMS with a specific CMK:

{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Sid": "DenyNonKMSEncryption",
      "Effect": "Deny",
      "Principal": "*",
      "Action": "s3:PutObject",
      "Resource": "arn:aws:s3:::your-bucket-name/*",
      "Condition": {
        "StringNotEquals": {
          "s3:x-amz-server-side-encryption": "aws:kms"
        }
      }
    },
    {
      "Sid": "DenyWrongKMSKey",
      "Effect": "Deny",
      "Principal": "*",
      "Action": "s3:PutObject",
      "Resource": "arn:aws:s3:::your-bucket-name/*",
      "Condition": {
        "StringNotEquals": {
          "s3:x-amz-server-side-encryption-aws-kms-key-id": "arn:aws:kms:us-east-1:123456789012:key/your-key-id"
        }
      }
    }
  ]
}

The first statement denies any upload not using SSE-KMS. The second statement further constrains uploads to only use your specific CMK ARN, preventing someone from accidentally using the default aws/s3 key or a different CMK on your regulated data bucket.

Complete Comparison of All S3 Encryption Options

The table below summarizes all S3 encryption options across the dimensions that matter for a security and compliance decision:

Option	Encryption at Rest	Encryption in Transit	Key managed by	CloudTrail per object	Independent key control	AWS sees plaintext
SSE-S3	Yes (AES-256-GCM)	No (separate policy)	AWS	No	No	Yes
SSE-KMS (AWS-managed key)	Yes (AES-256-GCM)	No (separate policy)	AWS	Yes	No	Yes
SSE-KMS (Customer-managed CMK)	Yes (AES-256-GCM)	No (separate policy)	Customer (in KMS)	Yes	Yes	Yes
SSE-C	Yes (AES-256-GCM)	No (separate policy)	Customer (outside AWS)	No	Yes	Yes (during op)
Client-side + KMS CMK	Yes (AES-256-GCM)	No (separate policy)	Customer (key wrap in KMS)	Yes (key wrap only)	Yes	No
Client-side + self-managed key	Yes (AES-256-GCM)	No (separate policy)	Customer (entirely outside AWS)	No	Yes	No
aws:SecureTransport policy	No	Yes (TLS)	AWS (TLS certificate)	No	No	N/A

Multi-Cloud and Hybrid Encryption Architecture for S3

Organizations using S3 alongside Azure Blob Storage, Google Cloud Storage, or on-premises object storage face a key management consistency challenge: each cloud platform has its own native key management service, and managing separate key inventories, rotation policies, and audit trails across providers multiplies operational complexity and compliance effort.

Three patterns address multi-cloud S3 encryption consistently:

• Cloud-native per-cloud with unified CLM: Use SSE-KMS for S3, Azure-managed keys for Blob, and Cloud KMS for GCS, but deploy a certificate and key lifecycle management platform that aggregates the key inventory, monitors rotation compliance, and provides a unified audit trail across all cloud providers. This preserves native performance while providing governance visibility.
• Centralized BYOK into each cloud: Generate all key material from a single external key management system. Import derived keys into AWS KMS (for SSE-KMS BYOK), Azure Key Vault (for Azure BYOK), and GCP Cloud KMS (for GCP BYOK). All clouds use keys that trace back to the same authoritative source. Key rotation and lifecycle policy are managed centrally.
• Client-side encryption with a shared master key: Encrypt all data client-side before upload, using the same master key regardless of which cloud the data lands in. The cloud provider is entirely excluded from the key hierarchy. This is the strongest multi-cloud sovereignty model but requires your application to handle all cryptographic operations and your external key management system to be highly available for every read and write operation.

For organizations managing encryption keys across S3 and other cloud and on-premises sources, Encryption Consulting’s CBOM Secure provides automated discovery and inventory of cryptographic assets including KMS keys, S3 bucket encryption configurations, and certificate inventory in CycloneDX format for compliance reporting. Our cloud data protection advisory services design the right key control architecture for your specific multi-cloud compliance requirements.

How Encryption Consulting Can Help

Encryption Consulting is an applied cryptography firm with ISO/IEC 27001:2022 and SOC 2 certifications. We help organizations design, implement, and audit S3 encryption configurations that satisfy HIPAA, PCI DSS, FedRAMP, NIST 800-53, and other compliance frameworks.

• Cloud Data Protection Advisory: We assess your current S3 encryption configuration, identify gaps (unencrypted buckets, missing bucket policies, SSE-S3 where SSE-KMS is required, missing CloudTrail data events), and design the target architecture including key control model, IAM model, bucket policy enforcement, and rotation schedule. See our advisory services.
• HSM as a Service: For BYOK and client-side encryption scenarios where your key material must be generated in a FIPS-validated HSM outside AWS, Encryption Consulting’s HSM as a Service provides dedicated FIPS 140-2 Level 3 HSM infrastructure for key generation, with integration into AWS KMS key import workflows.
• CBOM Secure: AWS environments with many S3 buckets often have inconsistent encryption configurations. Encryption Consulting’s CBOM Secure discovers and inventories all S3 bucket encryption settings, KMS key configurations, and access policies across your AWS accounts, generating a Cryptographic Bill of Materials in CycloneDX format that identifies gaps and supports audit evidence packages.
• PKI as a Service: For organizations that need private PKI certificates for S3 client authentication (mutual TLS to S3 Access Points or S3 via VPC endpoints), Encryption Consulting’s PKI as a Service provides managed private CA with ACME-automated certificate lifecycle management.
• PQC Readiness: NIST finalized post-quantum cryptography standards FIPS 203 (ML-KEM), FIPS 204 (ML-DSA), and FIPS 205 (SLH-DSA) in August 2024. NIST IR 8547 points toward deprecating RSA and ECC around 2030. While AES-256-GCM used by S3 is considered quantum-resistant, the key management infrastructure (KMS key wrapping, TLS connections to S3 endpoints) will need to transition to post-quantum algorithms. Encryption Consulting’s PQC Readiness service maps your full S3 cryptographic posture against the migration timeline.

To discuss your S3 encryption architecture, contact Encryption Consulting.

Conclusion

AWS S3 now encrypts all new objects by default, which removes the risk of accidentally storing unencrypted data. But default encryption with SSE-S3 provides no audit trail, no independent key control, and no ability to revoke access to data without deleting it. For any regulated workload, SSE-KMS with a customer-managed CMK is the minimum appropriate configuration: it adds a per-object audit trail, lets you disable the key to instantly revoke S3 decryption capability, and supports BYOK if you need customer-generated key material.

Client-side encryption is the right choice when the threat model requires that AWS never have access to plaintext, including under legal compulsion. It adds application complexity but provides the strongest data sovereignty position available in any cloud environment.

The key control decision, the IAM design, the bucket policy enforcement, and the CloudTrail configuration all matter as much as the encryption method itself. Encryption without the surrounding controls is compliance theater: you can say the data is encrypted, but you cannot say who decrypted it, when, or whether they were authorized to do so.

Frequently Asked Questions

What is the difference between SSE-S3, SSE-KMS, and SSE-C in Amazon S3?

SSE-S3 has AWS generate, manage, and rotate all encryption keys automatically with no customer visibility or control. SSE-KMS uses AWS KMS and provides a CloudTrail audit trail of every encrypt and decrypt operation, with a choice between AWS-managed or customer-managed keys. SSE-C requires you to supply a 256-bit AES key in every request header; S3 uses it and immediately discards it, storing only an HMAC fingerprint. The key difference is audit depth and control: SSE-S3 provides neither; SSE-KMS provides both; SSE-C provides control without a KMS audit trail.

What is client-side encryption in Amazon S3 and when should I use it?

Client-side encryption means you encrypt data before uploading to S3, so S3 stores only ciphertext and AWS never handles plaintext. Use it when regulatory requirements mandate encryption before data leaves your environment, when your threat model includes AWS as a potential access point (HYOK model), or when you need zero-trust storage where no cloud provider can access your data. The trade-off is full application responsibility for key management, rotation, and distribution to all systems that need object access.

Does AWS S3 encrypt data by default?

Yes. As of January 2023, Amazon S3 automatically applies SSE-S3 (AES-256-GCM) to all new objects in any S3 bucket, even without explicit configuration. Existing objects already stored in a bucket are not retroactively encrypted. You can change the default to SSE-KMS at the bucket level to enable a CloudTrail audit trail and customer key control.

What is BYOK for Amazon S3 and how does it work?

BYOK (Bring Your Own Key) for S3 means you generate key material in your own HSM or key management system, import it into AWS KMS as a customer-managed key with imported key material, and configure SSE-KMS on your S3 bucket to use that CMK. AWS KMS uses your imported material to generate the data encryption keys that protect your objects. You retain the source key material and can delete it from KMS to immediately prevent further decryption without AWS support involvement.

How do I enforce encryption on all S3 objects using a bucket policy?

Add a Deny statement in your S3 bucket policy targeting s3:PutObject requests where the s3:x-amz-server-side-encryption header is not set to aws:kms (for SSE-KMS) or AES256 (for SSE-S3). Add a second Deny statement using the aws:SecureTransport condition set to false to block any HTTP (non-TLS) request. These two conditions together prevent both unencrypted uploads and unencrypted connections to the bucket.

How does AWS S3 encryption appear in CloudTrail audit logs?

SSE-KMS generates a GenerateDataKey CloudTrail event on every PutObject and a Decrypt event on every GetObject. Each event includes the KMS key ARN, the requesting IAM principal, the S3 bucket and object key, source IP, and a timestamp. SSE-S3 and SSE-C do not generate KMS events. Enable S3 data events in CloudTrail separately from management events, as S3 object-level API calls are not captured in management event logs by default.