Versioning
Versioning keeps every version of an object in a bucket, so overwrites and deletes are recoverable — a delete adds a "delete marker" rather than removing data. It protects against accidental loss and, combined with MFA Delete, against malicious deletion. Versioning increases storage (you keep old versions), so pair it with lifecycle rules to expire non-current versions.
- Keeps prior versions; delete adds a delete marker
- Protects against accidental/malicious overwrite and delete
- Pair with lifecycle to expire old versions and control cost
Source: AWS docs — S3 User Guide
Lifecycle rules
Lifecycle rules automate moving objects to cheaper storage classes (transition) or deleting them (expiration) after a defined age. This is the primary cost lever for large buckets: keep recent data hot, transition older data to IA/Glacier, and expire what you no longer need — including old object versions when versioning is on.
- Transition to cheaper classes and/or expire objects by age
- The main S3 cost-optimization tool at scale
- Can target non-current versions when versioning is enabled
Source: AWS docs — S3 User Guide
Encryption
S3 encrypts objects at rest by default. You can use S3-managed keys (SSE-S3), AWS KMS keys (SSE-KMS) for auditable, controllable keys, or dual-layer/customer-provided variants for stricter needs. Encryption in transit uses HTTPS/TLS; you can enforce it with a bucket policy that denies non-TLS requests. For interviews, the key trade-off is SSE-KMS (fine-grained control + CloudTrail audit) vs SSE-S3 (simplest).
- At rest: SSE-S3, SSE-KMS, and customer-provided options
- In transit: TLS, enforceable via bucket policy
- SSE-KMS adds key control + audit at some request overhead
Source: AWS docs — S3 User Guide
Bucket policies, IAM and Block Public Access
Access to S3 is governed by IAM identity policies (what a principal can do), bucket policies (resource policies on the bucket, including cross-account and conditions like TLS-only or specific VPC endpoints), and — as a safety net — S3 Block Public Access, which prevents accidental public exposure. Least privilege plus Block Public Access on by default is the secure baseline.
- IAM policies (identity) + bucket policies (resource) combine
- Block Public Access prevents accidental public buckets
- Use conditions (TLS, VPC endpoint, account) for tighter control
Exam tip: Block Public Access is a safety net that overrides permissive ACLs/policies. The secure baseline is: private bucket + Block Public Access on + least-privilege access via IAM/bucket policy + presigned URLs or CloudFront OAC for sharing.
Source: AWS docs — S3 User Guide
Presigned URLs
A presigned URL grants time-limited access to a single object using the signer’s credentials, so clients can upload or download directly to/from S3 without the bucket being public and without proxying bytes through your servers. This is the standard pattern for user uploads/downloads: your backend signs a URL, the client transfers directly to S3.
- Time-limited, per-object access with the signer’s permissions
- Lets clients upload/download directly, keeping buckets private
- Offloads byte transfer from your servers
Source: AWS docs — S3 User Guide
Multipart upload
Multipart upload splits a large object into parts uploaded in parallel and reassembled by S3, improving throughput and resilience (a failed part is retried without restarting the whole upload). It is recommended for large files and required beyond a maximum single-PUT size. Combine with lifecycle rules to clean up incomplete multipart uploads.
- Parallel part uploads → higher throughput and retryable
- Recommended/required for large objects
- Add a lifecycle rule to abort incomplete uploads
Source: AWS docs — S3 User Guide
Durability vs availability
Durability is the probability your data is NOT lost — S3 is designed for extremely high durability by storing redundant copies across multiple facilities in a Region. Availability is the probability you can ACCESS it at a given moment (subject to the storage class's SLA). These are different axes: One Zone-IA keeps the same durability design within a SINGLE AZ, so it's cheaper but loses the data if that AZ is destroyed — lower effective durability against an AZ loss. Match the class to how catastrophic data loss would be.
- Durability = won't lose data (redundant copies across a Region)
- Availability = can reach it now (per storage-class SLA)
- One Zone-IA trades AZ-loss protection for lower cost
Exam tip: One Zone-IA is cheaper but stored in a single AZ; don't use it for data that must survive that AZ failing.
Source: AWS docs — S3 User Guide
Comparison: S3 vs EBS vs EFS (and versioning vs replication)
S3 vs EBS vs EFS: S3 is OBJECT storage accessed over HTTPS by key — massively scalable, durable, for files/backups/data lakes/static assets (not a filesystem). EBS is BLOCK storage for a SINGLE EC2 instance (a virtual disk / boot volume / database volume). EFS is a shared FILE system (NFS) mountable by MANY instances at once across AZs. Versioning vs replication: versioning keeps historical copies of an object in the SAME bucket (recover overwrites/deletes); replication copies objects to ANOTHER bucket/Region (DR, lower-latency regional reads) — they solve recovery vs geographic redundancy.
- S3 = object (HTTP/key); EBS = block for one instance; EFS = shared file for many instances
- Choose by access model: object store vs single-instance disk vs shared filesystem
- Versioning = history in the same bucket; Replication = copies to another bucket/Region
Source: AWS docs — S3 User Guide