If you want cheap durable hosting that does not meltdown under traffic spikes and mostly just serves files, welcome to S3 static website hosting. This guide walks through bucket creation, public access tuning, index and error document setup, MIME types and Cache Control, and the optional CloudFront layer for HTTPS and global speed. Read it like a recipe for a reliable site and not like a legal contract.

Why use S3 for static websites

Short version: it is inexpensive, reliable, and scales without begging developers to babysit servers. It is perfect for single page apps, docs, marketing sites, and tiny front ends that deserve to be fast.

• AWS S3 handles storage and delivery with high durability.
• Static hosting avoids server runtimes which means fewer moving parts.
• Combine with CloudFront for HTTPS, edge caching, and lower latency.

Create your bucket and pick a region

Create an S3 bucket with a globally unique name that either matches your domain or a friendly project name. Pick a region close to your audience to shave off latency. Yes it matters, and yes it is worth a thought.

Make the objects readable but not chaos

Static assets need to be public if you are serving them directly from the S3 website endpoint. If you use CloudFront you can and should restrict direct public access and let CloudFront fetch objects securely. Adjust block public access settings intentionally. Public access is fine for assets but do not leave other bucket settings wild.

Example minimal bucket policy

{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Sid": "PublicReadGetObject",
      "Effect": "Allow",
      "Principal": "*",
      "Action": "s3:GetObject",
      "Resource": "arn:aws:s3:::your-bucket-name/*"
    }
  ]
}

Replace your-bucket-name. This policy grants public read only to objects, not to bucket configuration or lists. Keep it narrow and intentional.

Enable static website hosting and set index and error documents

In the S3 console enable static website hosting and set an index document such as index.html and an optional error document. S3 will give you a website endpoint that serves pages over HTTP. If you want HTTPS for a custom domain, add CloudFront below.

Upload files and set correct MIME types and cache headers

Upload your HTML CSS JS and images. Make sure each object has a Content-Type metadata set so browsers render things correctly. If you upload from a build pipeline most tools set MIME types automatically, but double check for odd file extensions.

Cache Control and cache busting

Use Cache-Control headers to control browser and CDN caching. Typical patterns work well and keep users happy.

• Long lived static assets like hashed JS and CSS: Cache-Control: public max-age=31536000 immutable
• HTML pages you might change: Cache-Control: public max-age=60 must-revalidate or no-cache depending on your needs
• When updating assets use versioned filenames so clients do not keep an ancient copy forever.

Add CloudFront for HTTPS performance and global caching

CloudFront gives you HTTPS, edge caching, and global reach. Request an ACM certificate in us-east-1 if you are using a custom domain with CloudFront. For origins you can either point CloudFront at the S3 website endpoint or use the S3 REST endpoint with origin access control. If you want to lock the bucket down do not keep it public. Use an Origin Access Identity or the newer Origin Access Control to restrict direct access and have CloudFront fetch objects securely.

In DNS point your domain to the CloudFront distribution. Route 53 users can create an alias record. Other DNS providers will use an A or CNAME depending on the provider rules. Remember that the S3 website endpoint will not serve HTTPS for your custom domain so CloudFront is the path if you need SSL.

Test and troubleshoot like a detective

Test the S3 website URL and the CloudFront domain. Look in the browser console for 404s wrong MIME types or missing assets. Use curl -I to inspect headers and Cache-Control values. If assets are served but not updated check caching and invalidation. Invalidating CloudFront caches or bumping versioned file names fixes most grief.

Quick checklist before you go live

• Bucket name chosen and region set
• Public access adjusted and bucket policy applied only to objects
• Static website hosting enabled with index and error documents
• Uploaded files have correct Content-Type and Cache-Control headers
• CloudFront configured for HTTPS with restricted origin if needed
• DNS points to CloudFront and ACM certificate is attached for the custom domain

There you go. Cheap durable hosting that scales, with a few knobs to tweak. Use long cache times for hashed files, keep HTML fresher, and put CloudFront in front if you need HTTPS and speed around the globe. Now go deploy and enjoy the satisfying feeling of a site that actually loads fast.