beginnerintermediateadvanced

AWS · S3 Security and Data Lifecycle

S3 Security and Data Lifecycle

Identity vs resource-based access, encryption options, versioning and Object Lock, replication, and least privilege

Bucket policy = resource-basedthe standard way to grant cross-account access directly
SSE-S3 is now the defaultautomatic since Jan 2023 — SSE-KMS needs a second grant
Compliance mode: no override, evernot even root — governance mode is bypassable
Live replication is forward-onlyBatch Replication backfills pre-existing objects

1.Identity-Based vs Resource-Based S3 Access

An identity-based policy is attached to an IAM user/role and says what that identity can do. A bucket policy is attached to the bucket itself (resource-based) and says who can do what to it — including granting access to a completely different AWS account. Both are evaluated together; access requires no explicit deny and at least one explicit allow.

Key features

Identity-based policy: attached to an IAM user/role, portable across resources that policy references
Bucket policy: resource-based, attached to the bucket itself, can grant access to principals in other AWS accounts directly
Bucket policies are the standard way to grant cross-account access without creating a role in the granting account
Access requires no explicit deny anywhere AND at least one explicit allow from either policy type
Bucket policies are limited to 20 KB in size

Identity-based vs bucket (resource-based) policy

Identity-based vs bucket (resource-based) policy
Property	Identity-based	Bucket policy
Attached to	IAM user/role	The bucket itself
Grants cross-account access directly?	No — needs a role to assume	Yes — can name another account's principal
Scope	Whatever resources it references	This bucket and its objects
Size limit	Standard IAM policy limits	20 KB

The badge vs the sign on the door

Identity-based policy

Attached to an IAM user/role
Says what that identity can attempt
Cannot alone grant cross-account access

Bucket policy

Attached to the bucket itself
Can name a principal in another account directly
The standard way to grant cross-account access

Command

json

{ "Effect": "Allow", "Principal": { "AWS": "arn:aws:iam::222233334444:root" }, "Action": "s3:GetObject", "Resource": "arn:aws:s3:::my-bucket/*" }

Identity-based policies are attached to IAM users/roles; bucket policies are attached to the bucket and are the standard way to grant cross-account access directly. Both are evaluated together — access needs no explicit deny and at least one explicit allow.

2.S3 Encryption Options

Since January 2023, S3 automatically encrypts every new object with SSE-S3 by default, at no extra cost. SSE-KMS is an opt-in alternative using a KMS key you can rotate, audit, and control cross-account sharing for — at extra KMS request cost. Client-side encryption encrypts data before it ever reaches S3, so AWS never sees the plaintext at all.

Key features

SSE-S3: automatic default for every new object since January 5, 2023 — no extra cost, S3-managed keys
SSE-KMS: opt-in, uses a KMS key (AWS-managed or customer-managed) — enables auditing via CloudTrail and cross-account sharing (customer-managed key only)
SSE-KMS requires kms:GenerateDataKey to encrypt and kms:Decrypt to read — a second permission layer beyond the S3 policy itself
Client-side encryption: data is encrypted before upload — S3 stores only ciphertext, AWS never has the plaintext or (necessarily) the key
S3 Bucket Keys reduce SSE-KMS request costs to AWS KMS by up to 99% by using a time-limited bucket-level data key

Choosing an S3 encryption option

Choosing an S3 encryption option
Need	Choice
Baseline encryption at rest, no setup	SSE-S3 (automatic default)
Auditable key usage, rotation control	SSE-KMS
Cross-account object sharing with a scoped key	SSE-KMS with a customer-managed key
AWS must never see plaintext at all	Client-side encryption

Who holds the key, and how much control you get

auditable / shareableno setup

AWS manages ityou control it

SSE-S3: automatic default, free
SSE-KMS: auditable, rotatable, cross-account (customer-managed key)
Client-side: AWS never sees plaintext

Command

bash

--server-side-encryption AES256          # SSE-S3
--server-side-encryption aws:kms --ssekms-key-id <key>   # SSE-KMS

SSE-S3 is the automatic default (free, no setup) since Jan 2023. SSE-KMS adds auditability/rotation and requires a separate kms:Decrypt grant beyond the S3 policy — and only a customer-managed key supports cross-account sharing. Client-side encryption keeps AWS from ever seeing plaintext.

3.Versioning, Object Lock, and Lifecycle Transitions

Versioning keeps every past copy of an object under distinct version IDs. Object Lock (which requires versioning) adds WORM protection on top — governance mode can be bypassed with a special permission, compliance mode cannot be overridden by anyone, including the root user, until the retention period expires. Lifecycle rules automate storage-class transitions and expiration over time.

Key features

Object Lock requires S3 Versioning to be enabled on the bucket first
Governance mode: bypassable with s3:BypassGovernanceRetention permission — for testing retention policies or emergency overrides
Compliance mode: cannot be overridden or shortened by anyone, including the root account, until the retention period expires
A legal hold has no expiration — it protects until explicitly removed, independent of any retention period
A simple (non-versioned) DELETE on a locked object inserts a delete marker rather than actually deleting the protected version
Lifecycle rules transition objects between storage classes or expire them based on age/prefix, working with versioning to also manage old versions

Governance mode vs compliance mode

Governance mode

Protects against deletion/overwrite by most users
Bypassable with s3:BypassGovernanceRetention
Good for testing a retention policy before compliance mode

Compliance mode

Cannot be overridden by anyone, including root
Retention period cannot be shortened once set
Only way to delete early: delete the entire AWS account

Signature

Governance (bypassable) vs compliance (no override, ever) mode

Object Lock requires versioning. Governance mode is bypassable with a special permission (good for testing); compliance mode has no override for anyone, including root, until the retention period expires — choose deliberately, since compliance mode cannot be walked back.

Live replication (Cross-Region or Same-Region) automatically copies new/updated objects going forward — it does not retroactively copy objects that existed before replication was configured. S3 Batch Replication handles that on-demand for existing objects. Replication can also change object ownership on copy, which is how cross-account sharing stays clean.

Key features

Live replication (CRR/SRR) replicates new and updated objects going forward only — not pre-existing objects
S3 Batch Replication handles existing objects, previously-failed replications, or replicating already-replicated objects to new destinations
Cross-Region Replication (CRR): different Regions — compliance, latency, operational efficiency use cases
Same-Region Replication (SRR): same Region — log aggregation, prod/test account sync, data sovereignty
The "owner override" option changes replica ownership to the destination bucket's account, useful for restricting access to the replica independent of the source owner
S3 Replication Time Control (S3 RTC) is an SLA-backed option replicating 99.99% of new objects within 15 minutes

Command

text

Live replication (CRR/SRR): new + updated objects only, going forward
S3 Batch Replication: on-demand, for existing/failed/already-replicated objects

Live replication (CRR/SRR) only copies new/updated objects going forward — use S3 Batch Replication for pre-existing objects. CRR crosses Regions (compliance, latency); SRR stays in-Region (log aggregation, data sovereignty). Owner override cleanly separates replica ownership for cross-account sharing.

5.Least Privilege and Avoiding Public Buckets

Default to the narrowest S3 access that satisfies the requirement — scope bucket policies to specific principals and actions, keep Block Public Access enabled, and treat a public bucket as a deliberate, reviewed exception rather than a convenience default.

Key features

Scope bucket policy Principal and Action as narrowly as the actual use case requires — avoid wildcard Principals except for genuinely public content
Prefer S3 Access Points or presigned URLs over broad bucket policies when only specific paths or specific short-lived access is needed
A public bucket should be a reviewed, deliberate architectural decision (e.g. static website assets), not a default reached for convenience
IAM Access Analyzer for S3 can surface bucket policies that grant broader access than intended

Command

text

Default: private, narrowest policy that satisfies the requirement.
Public: only as a deliberate, reviewed exception — e.g. static asset bucket behind CloudFront.

Default to the narrowest S3 access that satisfies the requirement — scoped bucket policies, presigned URLs, or access points over wildcard Principals. A public bucket should be a deliberate, reviewed exception, and even then usually sits behind CloudFront rather than being directly public.

Spotted a mistake on this page? Tell us.

Read Sheet

1.Identity-Based vs Resource-Based S3 Access

2.S3 Encryption Options

3.Versioning, Object Lock, and Lifecycle Transitions

4.Replication and Cross-Account Sharing

5.Least Privilege and Avoiding Public Buckets