Introduction and Context

The Problem

Your team needs to deploy a marketing site, documentation portal, or single-page application. The site is entirely client-rendered — no server-side logic, no dynamic data generation at request time. The infrastructure team wants the lowest possible operational overhead: no EC2 instances to patch, no load balancers to manage, no autoscaling groups to configure.

S3 static website hosting solves this class of problem. S3 becomes an HTTP origin, serving your HTML, CSS, JavaScript, and assets directly to end users. Combined with CloudFront (out of scope for this lab), it forms the backbone of serious production static delivery pipelines.

The measurable outcome of this lab: a publicly accessible URL that serves your static site, returns a custom 404 page on missing routes, and is locked down to read-only public access via a properly scoped bucket policy.

What You Are Building

You will create an S3 bucket configured as a static website host. The bucket will serve an index.html entry point and a custom error.html page. Access will be granted through a bucket policy — not through object-level ACLs — which is the correct production pattern. You will verify the endpoint responds correctly, validate error routing, and then tear down all resources cleanly.

In this section, I confirmed:

0 of 3 completed

I understand the use case: static, client-rendered content with no server logicI understand the measurable end result: a live S3 website endpoint serving HTMLI have an AWS account and sufficient IAM permissions to create and configure S3 buckets