Static Website Hosting on S3

S3 can serve static files directly over HTTP as a website: HTML, CSS, JavaScript, images — content that doesn't change based on server-side logic. Two conventions make this work: an index document (the file served for a directory-style request, typically something like index.html) and an error document (the file served when a requested object doesn't exist).

Say this plainly, because it's a common beginner confusion: S3 static website hosting is not the same as running PHP, Laravel, Node, a Java server, or a database backend. There's no server-side execution happening inside S3 at all — it serves whatever static files you uploaded, exactly as uploaded, nothing more. A genuinely dynamic application still needs compute somewhere (EC2 from Module 3, or the serverless options later in this course) — but a static frontend hosted on S3 can absolutely call APIs hosted elsewhere, which is exactly the architecture this course's own capstone project builds toward.

A website has to be publicly reachable to do its job — so static website hosting is one of the rare, legitimate cases where enabling public access on a bucket is the correct call, made deliberately and narrowly (Lesson 2's Block Public Access discussion applies directly here: you're making an intentional, understood exception, not skipping the decision).

This is exactly why the distinction matters: static website content (meant for anyone to see) and private application or customer data (meant for restricted, specific access) have fundamentally different access requirements. Never house both in the same publicly-accessible bucket — a website bucket should contain only the public content it's meant to serve, with private data kept in an entirely separate, private bucket.

Serving a website directly from an S3 bucket works, but it has real trade-offs worth knowing about even at this level: no built-in HTTPS on the bucket's own default endpoint, no fine-grained caching control at the edge, and no easy way to serve the same content efficiently to users spread across the world. Amazon CloudFront — a content delivery layer this course introduces properly later — commonly sits in front of an S3 website bucket in production to address exactly those gaps. This lesson only names that relationship; building it is the capstone's job, not this module's.