S3 security

Memory hook: Encryption protects stored bytes, policies authorize callers, and browser rules do neither job for you.

Must remember

Match encryption to the key-control requirement

SSE-S3: S3 manages encryption keys. New S3 objects receive server-side encryption by default; that baseline does not mean every bucket satisfies a requirement for a particular customer-managed key.
SSE-KMS: KMS adds key-policy control and key-use auditing. A caller may need both S3 authorization and KMS authorization; an allowed object read can still fail when key access is missing.
S3 Bucket Keys reduce eligible SSE-KMS calls and cost. They do not replace the KMS key policy or make unauthorized callers trusted.
DSSE-KMS: two layers of server-side encryption for requirements explicitly calling for dual-layer protection. S3 Bucket Keys are not supported with DSSE-KMS. DSSE-KMS guidance
SSE-C: S3 performs encryption but the customer supplies the key over HTTPS for relevant operations; S3 does not retain that key. Losing it can make the object unrecoverable.
Current SSE-C caveat: since April 2026, new general-purpose buckets—and existing buckets in accounts without SSE-C objects—block new SSE-C writes by default. It requires deliberate enablement; these labs do not enable it. Client-side encryption is different: the client encrypts before uploading. SSE-C behavior

Separate defaults, enforcement and exposure

Default encryption supplies a storage behavior. A bucket-policy deny can enforce a required encryption header/key; design conditions carefully because a missing header and an explicitly incorrect header are different requests.
TLS enforcement uses a deny for insecure transport, commonly aws:SecureTransport = false. Encryption at rest does not protect HTTP traffic.
Block Public Access is another independent safeguard. Identity policies, resource policies, explicit denies and applicable account controls still participate in authorization.
CORS lets a browser expose responses across specified origins/methods. It is not an S3 permission and is not relevant to every non-browser client.
Pre-signed URLs temporarily use the signer's permission. Access can end when the URL expires, the signing credentials expire, or authorization is revoked; the requested URL lifetime is not a guaranteed lifetime.
Server access logs provide best-effort request records in a logging bucket. They are not a synchronous authorization gate or a complete substitute for selected CloudTrail data events. S3 security guidance

Retention and application-specific access

Object Lock protects object versions, not merely a filename. Governance permits specifically authorized bypass; compliance cannot be shortened or bypassed during retention, including by root.
A legal hold has no automatic expiry and remains until released by an authorized principal. It is independent of a version's timed retention. Either can prevent deletion.
MFA Delete adds MFA requirements to selected versioning/permanent-deletion operations and requires root-controlled setup. It is different from Object Lock and is not configured here.
Glacier Vault Lock fixes a retention policy for the separate legacy Glacier vault model. Do not confuse it with S3 Glacier storage classes or S3 Object Lock. Object Lock concepts
Access Points provide separate endpoints and policies over shared bucket data; they do not create independent object copies or bypass the bucket's security controls.
Object Lambda historically transformed S3 reads through Lambda. Since November 7, 2025 it is limited to existing users and selected partner solutions. Recognize the course pattern, but use supported application/edge transformation designs for new customers. Availability notice

Choose under exam pressure

Requirement in the question	Best direction
Control and audit use of a customer-managed key	SSE-KMS plus correct key/S3 policies
Explicit dual-layer encryption requirement	DSSE-KMS
Data must arrive at AWS already encrypted	Client-side encryption
Temporary download of one private object	Pre-signed URL
Authorized browser request blocked cross-origin	Inspect CORS
Non-bypassable retention of a version	Object Lock compliance
Separate application policies over one bucket	Access Points

Traps

Making CORS permissive cannot fix missing IAM or KMS permissions.
Changing a bucket's default encryption does not retroactively re-encrypt all existing versions.
force_destroy is not stronger than an AWS retention lock.
A URL is a temporary bearer capability: anyone receiving it can use its allowed access while it remains valid.

Active recall

1. S3 allows GetObject, but an SSE-KMS download fails. What second boundary should you inspect?

Inspect KMS key policy and decrypt permissions, including cross-account requirements. S3 authorization and KMS authorization are separate; weakening CORS cannot fix either.

2. A browser cannot read a private object after its origin was added to CORS. What was missing?

CORS does not authenticate the request. Supply valid authorization, such as an authorized short-lived pre-signed URL, while preserving private bucket access.

3. A seven-day pre-signed URL was signed with credentials expiring sooner. How long is it usable?

No longer than those credentials remain valid, and possibly less if authorization is revoked. The URL's requested expiration cannot extend credential lifetime.

4. A regulated version must resist deletion even by administrators until a date. Governance or compliance?

Compliance matches that requirement. Governance has an authorized bypass path. A legal hold instead expresses an indefinite hold until authorized release.

5. Two applications need different policies over the same objects. Should each receive a duplicate bucket?

Not necessarily. Access Points can present separate policy boundaries over shared bucket data. Duplicate buckets introduce replication, consistency and storage concerns that the requirement may not need.

Terraform anchor: Model encryption, CORS, bucket policy and public-access blocking separately; successful validation does not prove end-to-end authorization.