S3 & Static Website Hosting

The plain-language idea

S3 (Simple Storage Service) is object storage: it holds objects (files, of any size or type) inside buckets, each object addressed by a key — a string like images/avatar.png. That's the whole model. There's no real directory tree underneath it, no file permissions in the Unix sense, no partial writes — just buckets, keys, and the bytes behind each key.

Two things sit on top of that simple model and matter in practice:

• Storage classes — the same object can live at different price/retrieval tradeoffs: a "frequent access" class for data read constantly, an "infrequent access" class that's cheaper to store but costs more per retrieval (right for backups, old logs), and an "archival" tier that's cheapest to store but slowest and most expensive to retrieve (right for data you almost never touch but must keep). None of this changes what an object is — only what it costs to store and to read it back.
• Versioning and lifecycle policies — versioning keeps every version of an object instead of overwriting it in place; "deleting" a versioned object adds a delete marker rather than erasing anything, so the previous version is still recoverable. Lifecycle policies are rules that act automatically over time — transition an object to a cheaper storage class after N days, or expire (actually delete) it after N days.

See it in a real thing: a bucket that can serve a whole site by itself

A bucket with static website hosting enabled gets its own website endpoint, a document configured as the index document (served for /), and one configured as the error document (served for anything not found). Point a browser at that endpoint and the bucket serves HTML, CSS, and JS directly — no server, no Lambda, nothing running at all.

This is genuinely different from the setup this track's CDN lesson describes, where S3 is the origin behind CloudFront. Static website hosting mode is what S3 can do entirely on its own: serve files over plain HTTP, from one region, to whichever bucket policy makes the objects public. It has no HTTPS of its own, no custom domain without extra DNS work, and no caching at the edge — which is exactly why real production sites still put CloudFront in front of a bucket even though the bucket is technically capable of serving the site by itself.

What people usually miss

Watch out

• S3 has no real folders. The console shows something that looks like a folder tree, but it's a display convenience layered over keys containing / characters — images/2024/avatar.png is one flat key, not a file three directories deep. There's no operation that "moves a folder" the way a filesystem has one; renaming a prefix means copying every object under it to new keys and deleting the old ones.
• Lifecycle rules act on elapsed time, not on access frequency. A rule that transitions objects to a cheaper class "after 30 days" fires on age since upload, regardless of whether that object gets read constantly or never — a separate, access-pattern-aware storage class exists specifically for data whose access pattern isn't known upfront, but a plain lifecycle rule doesn't watch access at all.
• Versioning doesn't make storage free. Every version an object has ever had is still a full, separately billed copy — "deleting" a versioned object without a lifecycle rule cleaning up old versions is a common, quiet way a bucket's storage bill creeps up with nothing visibly deleted.
• Enabling website hosting mode isn't a prerequisite for using a bucket as a CloudFront origin. These are two independent features that happen to sound related — CloudFront can read from a private bucket via Origin Access Control without website hosting mode ever being turned on, and that's the more secure of the two setups, not a lesser one.

Why this matters in interviews

"Would you serve this static site straight from an S3 website endpoint, or put CloudFront in front of it?" tests whether a candidate knows S3 alone can technically host a site, but also knows precisely what it's missing (HTTPS, a custom domain, edge caching) — and that the secure production answer is a private bucket behind CloudFront, not a public bucket serving directly.