Amazon Simple Storage Service, commonly known as S3, is one of the most widely used cloud storage services in the world, storing trillions of objects for millions of customers across virtually every industry. As organizations store increasingly sensitive data in S3, including personal information, financial records, healthcare data, and intellectual property, the security of that data has become a paramount concern. Server-side encryption is the primary mechanism Amazon provides for protecting data at rest in S3, ensuring that objects stored in buckets are encrypted before being written to disk and decrypted automatically when retrieved by authorized users and applications.
Server-side encryption in Amazon S3 means that AWS handles the encryption and decryption process on your behalf, removing the burden of managing cryptographic operations from your application code. When you upload an object with server-side encryption enabled, S3 encrypts the data using the specified encryption method before storing it on the underlying storage infrastructure. When you or your application retrieves that object, S3 automatically decrypts it before returning it, provided the requester has the necessary permissions. This transparent encryption model protects data from unauthorized access at the storage layer without requiring application-level changes, making it one of the most practical and widely adopted approaches to cloud data security.
Why Encryption Matters for S3
Since January 5, 2023, Amazon S3 has automatically encrypted all new object uploads with S3-managed keys (SSE-S3) unless another supported method is selected. That baseline protects data at rest but does not correct a public bucket or an overly permissive IAM policy: authorized S3 API reads are transparently decrypted. Sensitive data still needs least-privilege IAM and bucket policies, S3 Block Public Access, appropriate monitoring, and separate KMS key permissions when required.
Encryption at rest may contribute to requirements under applicable privacy, payment or regulated-industry frameworks, but it does not itself make a workload HIPAA-, PCI DSS-, GDPR- or FedRAMP-compliant. The organization must evaluate the actual controls required for its data and jurisdiction, including confidentiality, access permissions, auditability, retention, key governance and incident procedures. S3 encryption evidence can support an assessment, but the relevant compliance result depends on the wider system and documented responsibilities—not the presence of one encryption setting.
Current Amazon S3 Encryption Options
Amazon S3 offers four principal server-side encryption choices for suitable workloads. SSE-S3 uses S3-managed keys and is the standard baseline for new uploads. SSE-KMS uses AWS KMS keys for stronger key-use controls. DSSE-KMS adds a second, independently applied layer of KMS-backed server-side encryption for workloads that require dual layers. SSE-C accepts keys supplied by the customer with each request, but it is disabled by default for new general purpose buckets from April 2026 and must be explicitly enabled where justified.
Choose encryption based on data sensitivity, key custody, permissions, audit needs, operational complexity, and cost. SSE-S3 is automatically applied to new uploads without an extra encryption charge. SSE-KMS adds KMS controls and request costs; DSSE-KMS provides two encryption layers when specifically required. SSE-C makes the customer responsible for supplying and safeguarding a key on each relevant request, and AWS recommends keeping it disabled unless a documented legacy need exists.
SSE-S3 Managed Keys Explained
SSE-S3 is the baseline form of Amazon S3 encryption for newly uploaded objects and needs no explicit opt-in. S3 uses AES-256 and service-managed encryption keys to protect data at rest, transparently decrypting an object for an authorized API requester. This protects stored object bytes, but the application still needs correct identity, public-access and transport controls. A customer who needs direct authority over key access and cryptographic audit events should evaluate a suitable AWS KMS-backed method instead of assuming SSE-S3 supplies independent customer-managed keys.
The encrypted data key is stored alongside the encrypted object, and S3 uses the root key to decrypt the data key whenever authorized access to the object is requested. This envelope encryption approach means that even if an attacker obtained the stored encrypted data key, they could not use it without access to the S3-managed root key.
An upload can explicitly specify SSE-S3 using the x-amz-server-side-encryption: AES256 header, but the header is not required to obtain baseline encryption on a new S3 object. Since January 5, 2023, S3 automatically encrypts new uploads with SSE-S3 where no other supported method is selected. Do not impose a bucket policy denying every request without an explicit encryption header merely to prevent plaintext storage: it can reject applications that would otherwise inherit the bucket default. Use tested policy conditions when a particular KMS key or encryption mode is actually required.
Amazon S3 has applied baseline SSE-S3 encryption to new object uploads since January 5, 2023—not November 2023. The setting applies to both previously existing and newly created buckets, while older objects that were unencrypted before the change are not retroactively encrypted simply by the new default. Review object inventory and migration plans separately from the setting for future uploads. S3 Bucket Keys, SSE-KMS and DSSE-KMS solve different key-control or cost problems and should not be described as prerequisites for baseline protection.
SSE-KMS Key Management Service
SSE-KMS generates AWS KMS key-use events that can appear in CloudTrail, including cryptographic API calls made on behalf of S3 operations. These events do not provide a complete log of which S3 objects were read or written; S3 Bucket Keys may also reduce how often KMS receives requests. For object-level auditing, configure the relevant S3 CloudTrail data events, which are not captured by default. KMS events and S3 object data events answer related but different security questions.
Second, SSE-KMS allows customers to define granular key policies that control which IAM principals, AWS services, and accounts can use each KMS key for encryption and decryption operations. This access control capability means that even if an IAM principal has permission to read objects from an S3 bucket, they cannot decrypt SSE-KMS encrypted objects unless they also have explicit permission to use the KMS key.
This separation of access control between the S3 bucket policy and the KMS key policy provides defense in depth that is difficult to achieve with SSE-S3 alone. Organizations can create dedicated KMS keys for different sensitivity levels of data, different application environments, or different business units, allowing fine-grained control over who can access which data even when multiple parties share the same S3 bucket.
AWS Managed Versus Customer Managed
AWS managed KMS keys for S3 use the aws/s3 alias and are controlled by AWS; their key policy is not editable like a customer managed KMS key policy. They can supply KMS-backed encryption in supported same-account situations but do not provide every cross-account key-sharing or governance capability. Customer managed KMS keys allow organizations to define key policies and approved access more precisely. Select the key type with attention to service integration, account boundaries, charges and monitoring instead of assuming an AWS managed key grants complete customer key-policy control.
Customer managed keys are KMS keys that you create and manage in your own AWS account, giving you complete control over key policies, rotation schedules, key aliases, and the ability to disable or delete the key. Creating a customer managed key allows you to define precisely which IAM principals and AWS services can use the key, set custom rotation policies, import your own key material if compliance requirements mandate that your organization generates its own cryptographic key material, and enable cross-account access for scenarios where multiple AWS accounts need to share access to encrypted data.
Customer managed KMS keys provide policy control, key lifecycle management and options for appropriate cross-account integrations, but they can add monthly key and API charges and operational complexity. No single compliance framework universally requires every sensitive S3 object to use a customer managed key. First map the specific control or contractual requirement to the supported KMS feature, then document permissions, key availability, rotation and restoration. A stronger key policy is only useful if legitimate applications and disaster recovery can still access the encrypted records.
SSE-C Customer Provided Keys
With SSE-C, the customer supplies an AES-256 key when uploading or reading an encrypted object. Amazon S3 performs encryption and decryption without retaining that key for subsequent requests, so the customer must safeguard it and provide it again. From April 2026 AWS disabled SSE-C by default for new general purpose buckets and existing buckets in accounts with no SSE-C encrypted objects. It can be deliberately enabled in eligible environments, but AWS recommends retaining the block unless there is a specific requirement.
The operational implications of SSE-C are significant and must be carefully considered before selecting this option. Because S3 does not store the provided keys, the customer is entirely responsible for key storage, key distribution to all systems that need to upload or retrieve encrypted objects, key rotation procedures, and key backup and recovery. If the encryption key for an object is lost, the object becomes permanently inaccessible because there is no mechanism for recovering or resetting the key through AWS.
All SSE-C requests must be made over HTTPS because the encryption key is transmitted in the request headers, and any attempt to use SSE-C over an unencrypted HTTP connection is rejected by S3. Organizations considering SSE-C should have a mature key management infrastructure already in place and a clear operational plan for managing the key lifecycle reliably over time.
Bucket Default Encryption Settings
Every Amazon S3 bucket has default encryption enabled. Beginning January 5, 2023, S3 applies SSE-S3 to new objects when no other supported encryption type is requested. Basic at-rest encryption no longer depends on applications explicitly setting a PUT request header. Configure SSE-KMS or DSSE-KMS as a bucket default when your workload requires those additional key controls, and test that applications, permissions, and monitoring work with the selected setting.
Configuring default encryption through the S3 console involves navigating to the bucket’s Properties tab, finding the Default Encryption section, and selecting the desired encryption type along with the specific KMS key if SSE-KMS is chosen. The same configuration is available through the AWS CLI using the put-bucket-encryption command and through AWS CloudFormation using the BucketEncryption property in an S3 bucket resource definition. Infrastructure as code approaches to bucket default encryption configuration are strongly preferred in production environments because they ensure that encryption settings are consistently applied across all buckets created through automated provisioning processes and that any changes to encryption configuration are tracked in source control.
Enforcing Encryption Through Bucket Policies
Bucket policies can enforce requirements stricter than S3’s automatic SSE-S3 baseline, such as rejecting explicitly unauthorized encryption settings or requiring an approved KMS key. However, a blanket deny for uploads lacking an encryption header may reject requests that would otherwise inherit the bucket’s encryption default. That is not necessary simply to prevent plaintext uploads under today’s S3 baseline. Test any explicit-header policy alongside inherited bucket defaults before rollout.
A bucket requiring SSE-KMS with a particular KMS key can combine default encryption, policy conditions, IAM permissions, and the KMS key policy. A rule requiring an explicit aws:kms header deliberately rejects an upload without that header, even if the bucket default would otherwise encrypt the object. Choose and document that behavior rather than assuming it is universally required. Verify permitted key identifiers and cross-account or service roles against current AWS guidance.
Encryption Key Rotation Best Practices
Key rotation is the practice of periodically replacing encryption keys with new ones to limit the amount of data encrypted under any single key and reduce the risk associated with a key being compromised. AWS KMS supports automatic key rotation for customer managed keys, which when enabled generates new cryptographic key material annually while preserving the key identifier and all associated key policies. Importantly, AWS KMS does not re-encrypt existing objects when a key is rotated. Instead, it retains all previous versions of the key material and uses the appropriate version to decrypt objects encrypted under older key material while using the current key material for all new encryption operations.
For SSE-S3, key rotation is handled entirely by AWS without any customer action required, as S3 regularly rotates the service-managed root keys used to protect data encryption keys. For SSE-KMS with AWS managed keys, rotation is also automatic and handled by AWS on an annual basis. For SSE-KMS with customer managed keys, automatic rotation must be explicitly enabled through the KMS console, CLI, or API, and the rotation schedule can be customized to meet compliance requirements that mandate rotation more frequently than the default annual cycle.
For SSE-C, customers are entirely responsible for implementing their own key rotation procedures, including re-encrypting existing objects under new keys if the compliance requirement demands that data encrypted under rotated keys be migrated to the new key rather than simply using the old key for ongoing decryption.
Cross Region Replication and Encryption
Amazon S3 Cross-Region Replication is a feature that automatically copies objects from a source bucket in one AWS region to a destination bucket in a different region, commonly used for disaster recovery, geographic data distribution, and compliance requirements mandating data copies in specific regions. When replicating encrypted objects, the encryption behavior of replicated objects in the destination bucket depends on the encryption configuration of both the source object and the replication rule. Understanding how encryption interacts with replication is important for maintaining consistent security posture across replicated data.
For a source object already encrypted with SSE-S3, S3 Replication preserves the source encryption type for the replica; the destination bucket’s default SSE-KMS configuration does not automatically convert that SSE-S3 replica to SSE-KMS. SSE-KMS and DSSE-KMS objects require the relevant replication rule configuration and permissions. The replication role must be authorized to read the encrypted source and use the destination KMS key, with additional cross-account policy considerations where applicable.
If the destination bucket uses a different KMS key than the source bucket, both keys must grant the replication IAM role the necessary permissions. Cross-account replication of SSE-KMS encrypted objects is particularly complex and requires careful attention to key policies on both the source and destination KMS keys to ensure the replication service can perform the necessary decrypt and re-encrypt operations across account boundaries.
Monitoring Encryption Compliance Status
Encryption monitoring should answer two different questions: whether new objects inherit the intended bucket encryption default, and whether historical objects actually have the required encryption and key configuration. S3 automatically encrypts new uploads, so a rule testing merely whether default encryption is enabled cannot prove a bucket meets an additional SSE-KMS or approved-key requirement. Use suitable AWS Config controls, S3 Inventory, access records and targeted object checks; consult current managed-rule behavior because generic default-encryption checks may be satisfied even when stronger policy is not.
Amazon Macie can discover sensitive data in supported S3 objects and generate findings; it is not an automatic mechanism that makes a bucket compliant or changes unsafe permissions by itself. AWS Security Hub may aggregate relevant findings, while CloudTrail S3 data events—when separately enabled—help audit object access. AWS KMS key-use events show cryptographic operations but cannot be treated as a complete list of S3 object reads. Connect these different evidence sources and verify the controls actually required for the dataset.
Performance Considerations with Encryption
A common concern among organizations evaluating S3 server-side encryption is whether encryption adds meaningful latency to S3 operations. For SSE-S3, the performance impact is negligible because the encryption and decryption operations are performed by S3’s internal infrastructure with no additional network round trips required. Objects encrypted with SSE-S3 are stored and retrieved with essentially the same performance characteristics as unencrypted objects, making SSE-S3 appropriate even for latency-sensitive workloads that require consistent low-latency access to stored data.
SSE-KMS can introduce KMS request charges and service quotas in addition to S3 pricing. S3 Bucket Keys can substantially reduce the KMS requests generated by suitable SSE-KMS workloads, with implications for the granularity of CloudTrail key-use events and the encryption context used by policies. S3 Bucket Keys are not supported for DSSE-KMS. Model actual request patterns and test key controls before assuming every object access incurs a fixed KMS cost or latency.
Cost Implications of Encryption Options
SSE-S3 is automatically applied to all new objects in Amazon S3, starting January 5, 2023, without a separate encryption charge. SSE-KMS may add AWS KMS key and API request charges, which can be reduced for some workloads with S3 Bucket Keys. DSSE-KMS adds another KMS-backed encryption layer for specific requirements, while SSE-C imposes considerable key-handling responsibility. Evaluate the full security and cost model instead of treating default encryption as an optional add-on.
SSE-KMS can incur charges for KMS key use and request volume, but do not assume that every single S3 GET always maps to exactly one billable KMS Decrypt call. S3 Bucket Keys can lower the number of KMS requests for supported SSE-KMS workloads, changing the key-use events available in CloudTrail. Costs also depend on key type, Region, service quotas and usage pattern. Model observed workloads and current AWS pricing rather than citing an undated universal request allowance or one-to-one API billing formula.
For workloads that perform millions of S3 operations per month, KMS API costs can accumulate to meaningful amounts that should be factored into total cost of ownership calculations. Customer managed keys also incur a monthly fee per key, which is relevant for organizations that create large numbers of dedicated keys for different data classifications or application environments.
Migrating Existing Objects to Encryption
Changing a bucket’s default encryption applies to future writes, not automatically to historical objects. Objects stored without server-side encryption before the January 2023 SSE-S3 baseline remain a separate remediation task: use a supported copy or Batch Operations copy to write encrypted replacements. The newer UpdateObjectEncryption API cannot act on unencrypted source objects, so inventory the actual encryption state before choosing a migration method.
Copying an object with the required encryption settings remains an option for previously unencrypted objects, but copy operations can create new object versions or change creation-related timestamps and affect retention planning. Check S3 lifecycle policies and versioning before a bulk migration. For objects already using SSE-S3 in a general purpose bucket, UpdateObjectEncryption can change eligible objects to SSE-KMS without copying object data, preserving their existing metadata and timestamps. It is not a substitute for copying unencrypted objects.
S3 Batch Operations supports large-scale copy jobs for historical unencrypted objects and an Update object encryption operation for eligible SSE-S3-to-SSE-KMS transitions. The update option can preserve object metadata and avoid moving data, but it does not support unencrypted sources, SSE-C or DSSE-KMS objects, and it is restricted by Object Lock conditions. An encryption update also does not itself trigger new live replication events. Validate a representative object set, KMS permissions, versioning and completion reports before running a bucket-wide job.
Encryption in Multi Account Environments
Multi-account S3 encryption governance involves AWS Organizations guardrails, bucket encryption defaults, IAM and key policies, audit logging, and periodic configuration checks. Since January 2023 S3 encrypts new uploads with SSE-S3 automatically. A service control policy or bucket rule requiring an explicit encryption header can therefore block otherwise automatically encrypted uploads; that behavior is not necessary to prevent plaintext storage. Use supported conditions to enforce an actual KMS-key or encryption-type requirement and test the complete request path.
Cross-account access to SSE-KMS encrypted objects requires careful key policy configuration to grant the necessary decrypt permissions to IAM principals in other accounts. The KMS key policy in the owning account must explicitly grant the external account or specific IAM roles within it permission to use the key for decrypt operations.
Additionally, the IAM policies in the accessing account must grant the relevant principals permission to perform the KMS decrypt action on the specific key. Both conditions must be satisfied for cross-account decryption to succeed, which can create troubleshooting challenges when access fails. Documenting key sharing relationships and maintaining consistent naming conventions for keys shared across accounts significantly reduces the operational complexity of managing cross-account encrypted data access in large multi-account environments.
Conclusion
S3 automatically encrypts new objects using SSE-S3, with SSE-KMS, DSSE-KMS, and selectively enabled SSE-C available for different key-control needs. Encryption at rest does not replace object permissions, public-access protection, or appropriately configured S3 data-event logging. Align key custody, encryption method, application compatibility, costs, and operational monitoring with the workload, and check current AWS documentation before applying policy examples.
For a new S3 security assessment, first verify the automatic SSE-S3 baseline that AWS has applied since January 5, 2023; there is no need to enable it anew across all buckets. Then ask whether the business requires an approved AWS KMS key, dual-layer DSSE-KMS, defined cross-account key access or an auditable cryptographic control. These decisions should be based on data classification and actual regulatory or contractual obligations, not a mistaken impression that an unconfigured bucket stores new uploads in plaintext.
If policy requires SSE-KMS or DSSE-KMS, configure the supported bucket default and verify permissions, key policy, cost, and application compatibility. A requirement to send an explicit encryption header is a separate decision and can reject uploads that would have inherited a valid default. Use a carefully scoped test of approved and denied requests before enforcing a more restrictive condition. Where historical unencrypted objects exist, plan a controlled S3 Batch Operations copy or other supported re-encryption procedure; changing a bucket default does not retroactively transform prior objects.
The long-term encryption governance program should include regular auditing of bucket encryption configurations using AWS Config rules and Security Hub findings, monitoring of KMS key usage through CloudTrail and KMS key metrics, periodic review of key policies to ensure access remains appropriately restricted as organizational structures and application architectures evolve, and a defined process for rotating customer managed keys on a schedule that satisfies compliance requirements.
S3 server-side encryption is a continuing part of storage governance rather than a one-time compliance certificate. Maintain key permissions and recovery procedures, inspect access and encryption evidence, and test workloads after policy or KMS changes. These measures can reduce risk but cannot guarantee protection against every exposure or satisfy every regulation automatically. The strongest outcome is a documented, testable encryption and authorization plan that matches the data’s classification and the organization’s actual legal and operational requirements.