S3 basics: buckets, objects, and storage classes

An S3 bucket is a globally-uniquely-named container; an object is a file stored inside it, addressed by a key (its full path-like name within the bucket). That's the entire structural model — no real subdirectories exist underneath, despite the console showing a folder-like browsing experience (a key like photos/2024/vacation.jpg is one flat string; the "folders" are a UI convenience built from splitting on /, not actual nested directory objects, exactly as covered generically in the Cloud Computing domain's storage-types lesson).

Bucket names are globally unique across all of AWS, not just within your account — a name someone else has already taken is unavailable to you, which is why real bucket names are usually suffixed with something distinguishing (a company name, a random string).

S3 buckets are private by default, and since 2018 AWS has layered Block Public Access settings on top that, by default, prevent a bucket from becoming public even if an individual object or bucket policy tries to grant it — a direct response to how common the "someone accidentally made a bucket public" incident used to be. Making a bucket genuinely public (for something like static website hosting) requires deliberately disabling Block Public Access at the bucket level and writing an explicit bucket policy granting read access — two separate steps, on purpose.

Versioning, once enabled on a bucket, keeps every previous version of an object instead of overwriting it — a PUT to an existing key creates a new version rather than replacing the old one, and a DELETE adds a "delete marker" rather than actually destroying the prior versions (which remain recoverable). This is the difference between "I overwrote the wrong file and it's gone forever" and "I overwrote the wrong file and can restore the previous version in seconds."

Versioning isn't free — every version is billed as its own object — which is exactly why it pairs naturally with the lifecycle rules covered next.

Not all data needs to be instantly retrievable at the same cost. S3 offers multiple storage classes trading retrieval speed/cost against storage cost:

A lifecycle rule automates moving objects between classes over time without any manual intervention:

This rule: keep new uploads in Standard for the first 30 days, move to Standard-IA at day 30, move to Glacier at day 90, delete entirely at day 365 — exactly the kind of automated storage-cost management referenced generically in the Cloud Computing domain's cost-optimization lesson.

Two capabilities worth knowing exist, beyond plain storage: