1e:T4ad,Lifecycle rules automate moving / deleting objects based on age, prefix, or tag. ```xml logs/ Enabled 30 STANDARD_IA 90 GLACIER 365 ``` **What you can do:** - **Transition** between storage classes on age. - **Expire** (delete) objects after N days. - **Expire non-current versions** when versioning is on. - **Clean up incomplete multipart uploads** after N days (crucial for cost hygiene). - Filter by **prefix** and **tags**. **Use cases:** - Log retention — Standard → IA → Glacier → delete. - Compliance — keep for 7 years, then delete. - Cleanup of temp / staging prefixes. - Garbage collection of orphaned multipart uploads (these cost real money and don't show in normal bucket size). **Don't forget** the "Abort Incomplete Multipart Upload after 7 days" rule — it's the single most commonly forgotten cost leak.1f:T495,**Versioning**, when enabled on a bucket, keeps every version of every object. Writes don't overwrite; they create a new version. Deletes create a **delete marker** (instead of removing). **States:** - **Unversioned** (default) - **Versioning-Enabled** - **Versioning-Suspended** — new writes don't create versions, but existing versions remain **How to use:** - Recover accidentally deleted / overwritten files. - Protect against ransomware (combine with MFA Delete). - Compliance requirements ("retain all writes"). **Costs:** - Each version is billed separately. - Run **lifecycle rules on non-current versions** — e.g. delete non-current after 30 days. **MFA Delete:** require MFA to permanently delete versions or change the versioning state. Strong protection; slightly more friction for admins. **Object Lock** (separate feature) — WORM: lock objects against deletion/overwrite for a retention period. Compliance for SEC 17a-4, FINRA, etc. **Gotchas:** - Turning versioning on is irreversible (you can suspend, not disable). - Delete markers count as objects (and cost a tiny amount). - Cross-region replication requires versioning enabled on both sides.20:T546,**S3 always encrypts objects at rest** since 2023. Options differ on **who owns the key** and **who is audited**. | Mode | Who holds the key | Auditing | |------------------|----------------------|--------------------| | **SSE-S3** | AWS-managed (AES-256) | Minimal | | **SSE-KMS** | You own a KMS key | Fine-grained (CloudTrail logs every decryption) | | **SSE-KMS with DSSE** | Dual-layer encryption | Same + extra defense in depth | | **SSE-C** | You supply the key on every request | Highest control but operationally painful | **In transit:** use HTTPS. Bucket policies can enforce with `aws:SecureTransport`. **Client-side encryption:** encrypt before upload (own key). S3 just stores bytes. Higher friction; use when regulatory constraints forbid cloud KMS. **Bucket Keys** (with SSE-KMS) — reduce KMS API calls by ~99% by using a bucket-level intermediate key. Enable unless you specifically need per-object KMS logs. **Default encryption** — set on the bucket so that any object uploaded without an encryption header is encrypted with the default scheme. **Which to pick:** - Default: **SSE-S3** is fine for most data. - Compliance / multi-tenant: **SSE-KMS** with a dedicated CMK per tenant. - Regulated (health/financial) with key control: **SSE-C** or **client-side**.21:T56d,

S3

What is S3?

S3 consistency model

Pre-signed URLs

Static website hosting

S3 storage classes

Lifecycle rules

Versioning

S3 encryption options

Bucket policies, IAM, and ACLs

Multipart upload

S3 events and notifications

S3 replication

S3 security best practices

Object Lock

S3 Access Points

Glacier retrieval tiers

S3 performance and parallelism

S3 Select and Object Lambda

Cross-account access

S3 cost components and traps