Article dates: Originally published on 16 May 2026. This correction was checked against primary documentation on 27 October 2026; this is not a new publication date.
Schematic illustration only: KMS participates in the relevant encryption options, not every S3 upload. This is not a precise key-flow diagram. The unrelated AI authentication illustration in the original has been omitted.
Introduction: Why S3 Security Matters
Amazon S3 (Simple Storage Service) stores objects such as application backups, media assets, healthcare records, and financial data. Incorrect access permissions can expose information even when it is encrypted at rest. Understanding S3's security model, including encryption, authentication, and authorization, is essential for cloud architects and developers working on AWS. (AWS S3 and IAM)
This post covers encryption at rest and in transit, authentication and access controls (IAM, bucket policies, presigned URLs, and VPC endpoints), and practices for securing S3 general purpose buckets. Other S3 bucket types have different capabilities. All C# and policy examples are illustrative and untested, not production-ready configurations. C# fragments require compatible packages, dependencies, AWS credentials, permissions, and a configured Region. The examples can change data, access, or costs if adapted and run. Review and test any intended deployment in an authorized environment first.
Amazon S3: Security Architecture Overview
- SSE-S3 (Amazon S3 managed keys)
- SSE-KMS (AWS Key Management Service)
- SSE-C (Customer provided keys)
- DSSE-KMS (Dual-layer SSE with KMS)
- Client-side encryption (CSE)
- IAM policies (identity-based)
- Bucket policies (resource-based)
- Presigned URLs; signed cookies through CloudFront (AWS CloudFront signed cookies)
- VPC endpoint policies
- Block Public Access settings
Encryption at Rest: All Options Explained
SSE-S3: Server-Side Encryption with Amazon S3 Managed Keys
Since January 2023, new S3 object uploads are encrypted by default with SSE-S3 unless another supported encryption option is selected. S3 uses AES-256 and manages and protects the data keys. This baseline does not require application-managed keys or an additional SSE-S3 encryption charge. It does not establish that historical objects were re-encrypted or that their access permissions are correct. (AWS SSE-S3 and default encryption)
When to use SSE-S3: Baseline encryption when separate KMS key control and key-operation auditing are not required.
SSE-KMS: Server-Side Encryption with AWS KMS Keys
SSE-KMS adds key-management controls through AWS Key Management Service (KMS), including:
- Separate access control for KMS keys alongside S3 object permissions (AWS SSE-KMS guidance)
- Key-material rotation options that depend on the key type and configuration (AWS KMS key rotation)
- CloudTrail records for supported KMS operations; S3 Bucket Keys change KMS request frequency and audit granularity (AWS S3 Bucket Keys)
- Cross-account sharing of SSE-KMS objects requires a customer-managed KMS key and appropriate S3 and KMS permissions. The KMS key must be in the same Region as the bucket; a multi-Region key is not automatic cross-Region sharing (AWS SSE-KMS guidance)
- Key protection using the documented KMS modules and key-store configuration. Check current FIPS validation for the relevant module; KMS and AWS CloudHSM are not interchangeable services (AWS FIPS validation)
SSE-KMS: AWS SDK for .NET Example
using Amazon.S3;
using Amazon.S3.Model;
var s3Client = new AmazonS3Client();
// Illustrative, untested upload; use authorized test resources and configuration.
var putRequest = new PutObjectRequest
{
BucketName = "my-secure-bucket",
Key = "sensitive-data.json",
ContentBody = "{ \"secret\": \"data\" }",
ServerSideEncryptionMethod = ServerSideEncryptionMethod.AWSKMS,
ServerSideEncryptionKeyManagementServiceKeyId = "arn:aws:kms:us-east-1:123456789012:key/my-key-id"
};
var response = await s3Client.PutObjectAsync(putRequest);
Console.WriteLine($"SSE-KMS key: {response.ServerSideEncryptionKeyManagementServiceKeyId}");
// Enforcing encryption in a bucket policy requires a complete Statement
// and review of the bucket default. A partial Condition is not a ready policy.
SSE-C: Server-Side Encryption with Customer-Provided Keys
With SSE-C, you supply the key with relevant requests, and S3 encrypts or decrypts the object without retaining the key itself. You are responsible for durable key management. Since April 2026, SSE-C is disabled by default for new writes in all new general purpose buckets and in existing buckets belonging to accounts with no SSE-C-encrypted objects. This is not a ban on reading existing SSE-C objects. Deliberate use requires checking the bucket configuration; this example does not change it. (AWS SSE-C guidance) Important implications:
- Supply the key for relevant reads and writes, and maintain the mapping between keys and objects or object versions. Do not store it beside the data in a way that defeats separation.
- If the key is lost with no recoverable copy, the encrypted object is unrecoverable.
- AWS requires HTTPS for SSE-C requests.
- S3 retains a randomly salted HMAC to validate later key submissions, not the key itself; the HMAC cannot recover the key (AWS SSE-C details)
// SSE-C instructional safeguard only; this is not an upload implementation.
// Before any upload, integrate secure retrieval of a durably stored 32-byte key,
// recoverable backups, and the object/version-to-key mapping.
// Verify recovery before allowing writes. Never create a throwaway upload key.
using System;
throw new InvalidOperationException(
"Implement durable SSE-C key retrieval and verified recovery before uploading.");
// Only after key management is implemented, the relevant request properties are:
// ServerSideEncryptionCustomerMethod = ServerSideEncryptionCustomerMethod.AES256
// ServerSideEncryptionCustomerProvidedKey = Convert.ToBase64String(keyBytes)
// This fragment neither enables SSE-C on a bucket nor uploads an object.
DSSE-KMS: Dual-Layer Server-Side Encryption
DSSE-KMS applies two independent AES-256 layers. The first uses a data key generated by KMS; the second uses a separate key managed by S3. It can support a requirement for multilayer encryption, but does not by itself certify compliance. Allow for extra processing and charges, and note that S3 Bucket Keys are not supported. Do not assume a fixed latency or an exact twofold KMS-call or price multiplier. (AWS DSSE-KMS guidance)
Client-Side Encryption (CSE)
With client-side encryption, data is encrypted before it is sent to S3, which receives encrypted object content. In practice, the trust boundary also depends on where the application runs, key management, KMS permissions, and visible metadata; this is not a blanket guarantee that AWS can never be involved in access to plaintext. AWS provides the AWS Encryption SDK and the S3 Encryption Client, which is not deprecated as an entire product. Select a supported version. The following uses the documented .NET V4 interface, not a tested integration. Its strict commitment policy will not decrypt older non-key-committing ciphertext; review migration requirements. (AWS client-side encryption; AWS .NET V4 encryption client; AWS Encryption SDK overview)
using System.Collections.Generic;
using Amazon.S3.Model;
using Amazon.Extensions.S3.Encryption;
using Amazon.Extensions.S3.Encryption.Primitives;
// Documented V4 interface; illustrative and untested.
// Requires a compatible package, credentials, permissions, and configured Region.
// Replace the key and bucket only in an authorized test environment.
var context = new Dictionary<string, string>();
var materials = new EncryptionMaterialsV4(
"1234abcd-12ab-34cd-56ef-1234567890ab", KmsType.KmsContext, context);
var config = new AmazonS3CryptoConfigurationV4(
SecurityProfile.V4,
CommitmentPolicy.RequireEncryptRequireDecrypt,
ContentEncryptionAlgorithm.AesGcmWithCommitment);
using var client = new AmazonS3EncryptionClientV4(config, materials);
await client.PutObjectAsync(new PutObjectRequest {
BucketName = "my-bucket",
Key = "encrypted-file.bin",
FilePath = "/tmp/file.bin"
});
| Feature | SSE-S3 | SSE-KMS | DSSE-KMS | SSE-C | CSE |
|---|---|---|---|---|---|
| Key Management | Amazon S3 | AWS KMS | KMS and S3, in two layers | Customer | Customer-selected design |
| Key-operation Audit | No customer KMS log | CloudTrail | CloudTrail | Depends on key management | Depends on library and keys |
| Key-material Rotation | Service-managed | Depends on key type/configuration | Depends on key type/configuration | Customer responsibility | Customer or KMS responsibility |
| Plaintext object content at S3 during processing? | Yes, in authorized processing | Yes, in authorized processing | Yes, in authorized processing | Yes, in authorized processing | Object content arrives encrypted |
| Performance Impact | Built-in baseline encryption | Workload and KMS-call dependent | Additional two-layer processing | Workload and key-management dependent | Client/library dependent |
| Additional Cost | No additional SSE-S3 charge | KMS and configuration dependent | DSSE-KMS and KMS pricing | Customer key-management operations | Compute, keys and storage as configured |
Comparison sources: (AWS SSE-S3 and default encryption; AWS SSE-KMS guidance; AWS DSSE-KMS guidance; AWS SSE-C guidance; AWS .NET V4 encryption client) These are qualitative distinctions, not benchmark measurements or a price quote.
Encryption in Transit
Use HTTPS to connect to S3. HTTPS connections to S3 API endpoints use TLS 1.2 or later; TLS 1.0 is no longer supported. This does not force every request to use HTTPS: S3 can still accept HTTP, and S3 website endpoints do not support HTTPS. (AWS encryption in transit; AWS S3 website endpoints) The policy below denies insecure transport for principals that are not AWS services. The service-principal exclusion avoids breaking service calls when network context is redacted. It does not grant access. Review authorized service paths and test before applying a policy. (AWS S3 policy examples)
{
"Version": "2012-10-17",
"Statement": [
{
"Sid": "DenyHTTP",
"Effect": "Deny",
"Principal": "*",
"Action": "s3:*",
"Resource": [
"arn:aws:s3:::my-bucket",
"arn:aws:s3:::my-bucket/*"
],
"Condition": {
"Bool": {
"aws:SecureTransport": "false",
"aws:PrincipalIsAWSService": "false"
}
}
}
]
}
Authentication and Access Control
IAM Policies: Identity-Based Access
IAM (Identity and Access Management) policies are attached to users, groups, and roles. They define allowed or denied actions, resources, and conditions. Effective access also depends on resource policies, permission boundaries, organization policies, and explicit denies. (AWS S3 and IAM) This example separates object reads from listing requests scoped to reports/. These Allow statements do not cancel broader grants from another policy. (AWS S3 policy examples)
{
"Version": "2012-10-17",
"Statement": [
{
"Effect": "Allow",
"Action": "s3:GetObject",
"Resource": "arn:aws:s3:::my-bucket/reports/*"
},
{
"Effect": "Allow",
"Action": "s3:ListBucket",
"Resource": "arn:aws:s3:::my-bucket",
"Condition": {
"StringLike": {
"s3:prefix": [
"reports/",
"reports/*"
]
}
}
}
]
}
Bucket Policies: Resource-Based Access
Bucket policies are attached to a bucket rather than an identity. They can define permissions for principals in the account, other accounts, and AWS services, subject to all applicable access rules. They support cross-account access and requirements such as encryption and HTTPS. Avoid unnecessary public access; a correctly configured CloudFront distribution can serve a private S3 bucket origin. (AWS S3 and IAM; AWS private S3 origins)
Access Control Lists (ACLs): Legacy Feature
S3 ACLs are an older bucket/object access-control mechanism. AWS generally recommends disabling them with Bucket owner enforced and using IAM and bucket policies. Check compatibility with older tools before changing ownership controls; cross-account access does not by itself require ACLs. (AWS S3 Object Ownership)
Presigned URLs: Time-Limited Access
Presigned URLs grant temporary access to an operation on an S3 object using the permissions of the signer, without giving the recipient separate AWS credentials. They are bearer tokens: anyone who has the URL may be able to use it, so protect it accordingly. Common uses include downloads and direct browser uploads. The URL can expire earlier than requested if the signing credentials expire or are revoked. (AWS presigned URL guidance)
using Amazon.S3;
using Amazon.S3.Model;
// Independent, illustrative example; configure authorized credentials and Region.
using var s3Client = new AmazonS3Client();
// Download URL: up to 1 hour, subject to credential validity.
var request = new GetPreSignedUrlRequest
{
BucketName = "my-bucket",
Key = "confidential-report.pdf",
Verb = HttpVerb.GET,
Expires = DateTime.UtcNow.AddHours(1)
};
string presignedUrl = s3Client.GetPreSignedURL(request);
// Generate presigned URL for upload
var uploadRequest = new GetPreSignedUrlRequest
{
BucketName = "my-bucket",
Key = "uploads/user-file.jpg",
Verb = HttpVerb.PUT,
Expires = DateTime.UtcNow.AddMinutes(15),
ContentType = "image/jpeg"
};
string uploadUrl = s3Client.GetPreSignedURL(uploadRequest);
AWS SDK for .NET presigned URL reference. This fragment has not been compiled or executed.
Block Public Access: The Safety Net
S3 Block Public Access (BPA) applies at the access-point, bucket, account, and AWS Organizations levels, as configured. S3 uses the most restrictive applicable combination; organization policy can enforce account settings. The four settings are:
- BlockPublicAcls: Reject requests that apply public bucket or object ACLs.
- IgnorePublicAcls: Ignore public access granted by ACLs.
- BlockPublicPolicy: Reject public bucket or access-point policies under S3's public-policy evaluation rules.
- RestrictPublicBuckets: For a public bucket or access-point policy, restrict access to AWS service principals and authorized users in the owner's account; this blocks cross-account access, including otherwise specific grants.
Enable the appropriate BPA controls at the applicable levels. Disabling a bucket setting cannot override an account-level block. Before permitting public access, review every applicable layer and the alternative of CloudFront with a private bucket. (AWS Block Public Access guidance; AWS private S3 origins)
VPC Endpoint Policies
An S3 gateway VPC endpoint lets appropriately configured VPC resources reach S3 without traversing the public internet. An endpoint policy adds access control but does not replace IAM or bucket policies. A bucket-policy condition using aws:SourceVpce can restrict requests to a named endpoint. The Deny below covers the bucket and its objects and grants no access by itself. It can also block console access and authorized service workflows; review these paths and plan recovery before applying it. (AWS VPC endpoint bucket policies)
{
"Version": "2012-10-17",
"Statement": [
{
"Sid": "DenyOutsideNamedVPCEndpoint",
"Effect": "Deny",
"Principal": "*",
"Action": "s3:*",
"Resource": [
"arn:aws:s3:::my-bucket",
"arn:aws:s3:::my-bucket/*"
],
"Condition": {
"StringNotEquals": {
"aws:SourceVpce": "vpce-0123456789abcdef0"
}
}
}
]
}
Object Lock and Data Immutability
Amazon S3 Object Lock provides WORM (Write Once, Read Many) protection for object versions in versioning-enabled buckets. It protects the specified version; it does not prevent new versions or delete markers. It may support record-retention requirements, but does not by itself establish compliance with SEC, CFTC, HIPAA, or other applicable law, including Israeli law. The two retention modes are:
- Compliance mode: A protected version cannot be deleted by any user, including root, or have its retention period shortened before expiry. Select retention only after reviewing requirements, cost, and legal implications.
- Governance mode: Bypassing retention requires
s3:BypassGovernanceRetentionand the explicit bypass request mechanism. It supports controlled overrides, not protection against deletion by those with that authority.
Legal Hold is separate from a retention period and protects an object version without a fixed end date until explicitly removed. Users with the appropriate permission can remove it. (AWS Object Lock guidance) Object Lock does not preserve encryption keys or protect against loss of access to them; a retained encrypted version can still become unreadable. (AWS Object Lock and encryption keys)
Security Monitoring and Auditing
AWS CloudTrail for S3
CloudTrail Event history shows supported management events by default. Persistent retention and object operations such as GetObject, PutObject, and DeleteObject need an appropriately configured trail or event data store, including data-event selection. Data events can generate substantial volume and additional cost, so choose coverage according to sensitivity and audit needs. (AWS S3 CloudTrail events; AWS CloudTrail Event history)
Amazon Macie
Amazon Macie helps discover sensitive data in supported S3 objects, using managed and custom identifiers, and generates supported policy-risk findings. Coverage depends on the data format, permissions, and discovery configuration. Do not assume that every sensitive value or configuration issue, such as missing access logging, will be detected. (AWS Macie overview; AWS Macie supported storage and formats) Macie cannot decrypt SSE-C or client-side-encrypted objects to inspect their plaintext. For SSE-KMS or DSSE-KMS with a customer-managed key, Macie needs permission to use that key. (AWS Macie encryption support)
S3 Security Checklist
Production S3 Security Best Practices
Encryption
- Consider SSE-KMS for sensitive buckets needing separate key controls
- Choose DSSE-KMS for a defined multilayer-encryption requirement
- Enforce the required encryption type while accounting for bucket defaults
- Enforce HTTPS and review required AWS service exceptions
- Configure key-material rotation according to KMS key type
Access Control
- Enable Block Public Access at the applicable levels
- Prefer Bucket owner enforced without ACLs after compatibility review
- Use VPC endpoints according to internal access needs
- Apply least-privilege IAM policies
- Use the shortest practical presigned URL lifetime
Versioning and Recovery
- Enable versioning according to recovery needs and storage budget
- Evaluate MFA Delete for critical data and its operational limitations
- Configure Object Lock against verified retention requirements
- Plan replication and disaster recovery, and verify restoration
Monitoring
- Enable CloudTrail data events for sensitive buckets
- Configure S3 server access logging where needed
- Consider Macie after reviewing cost and detection coverage
- Alert on relevant findings and public-access configuration changes
Additional checklist references: (AWS S3 Versioning; AWS MFA Delete; AWS server access logging)
Conclusion
S3 provides layered protection for data at rest and in transit. SSE-KMS fits workloads needing separate key control and auditing; client-side encryption changes the trust boundary but requires key management and recovery planning. Block Public Access, least-privilege policies, and appropriate endpoints are important access controls. Combine encryption, permissions, versioning, Object Lock where required, and monitoring tailored to the workload. Review costs and operational consequences before enabling services. This article explains options; it does not change any account configuration.