Step by step S3 static site setup with bucket policy CDN and HTTPS

Ready to make your static site boring and dependable instead of a rental car that catches fire on the freeway? This guide walks through hosting a static website on Amazon S3 from bucket creation through optional CDN and HTTPS. No wizardry, just a few clicks and some polite policy statements.

Create the S3 bucket

Pick a globally unique, DNS friendly bucket name and choose a region near your users. If you plan to use a custom domain later, avoid special characters and keep it simple. Regions matter for latency and billing, so choose wisely and then forget about it until you need to migrate.

Enable website hosting and set index and error pages

In the S3 console open Properties and turn on website hosting. Set an index document, typically index.html, and an optional error document such as error.html for nicer 404 pages. The site endpoint shown in the console is useful for early tests before you add CloudFront.

Upload files and manage permissions

Use the console or the AWS CLI to upload your files. You can set object ACLs to public read or you can let a bucket policy do the job. Public means public, so double check there are no secrets in the assets folder unless you enjoy surprises.

CLI quick tip

For a simple upload with the AWS CLI use a command like

aws s3 sync build/ s3://your-bucket-name

This keeps file timestamps and reduces churn. Use versioned filenames in your build to avoid cache headaches.

Make the site readable by browsers

Add a bucket policy granting anonymous users permission to read objects under the bucket prefix. In plain English grant s3 get object so browsers can fetch assets without credentials. If you want to be fancier, use CloudFront with origin access control so the bucket does not have to be public.

Add CloudFront and a custom domain for HTTPS

CloudFront gives you HTTPS and a global edge cache which means faster loads and fewer angry emails. Create a distribution that points to your S3 website or the S3 origin. If you use CloudFront with a custom domain request a certificate from AWS Certificate Manager in the us-east-1 region, since CloudFront expects certificates from that region.

DNS and certificates

Point a CNAME or an alias record from your domain provider to the CloudFront distribution. Validate the ACM certificate via DNS to avoid the email therapy process.

Test the site and maintain deployments

Hit the S3 website endpoint or the CloudFront domain and check the browser network tab for missing assets or 403s. Automate deployment with a build script that outputs versioned filenames so new releases do not collide with cached files. When you do need to clear edge caches use an invalidation in CloudFront or bump the file names.

Checklist before you hit launch

• Bucket name is DNS friendly and in the right region
• Website hosting enabled with index and error documents set
• Files uploaded and either public or covered by a bucket policy
• Optional CloudFront distribution created and linked to a custom domain
• ACM certificate requested in us east 1 and DNS validated
• Cache strategy in place, either invalidation or versioned filenames

Final tips and gotchas

If a file returns a 403 check object permissions and the bucket policy. If assets seem stale then you are battling cache behavior. Use meaningful cache control headers on static assets and invalidate only when necessary to save money. And remember to avoid storing secrets in the static host, because public means public and that really is permanent.

There you go. You now have a boring and reliable static website on AWS S3, optionally bolstered by CloudFront and HTTPS. Go enjoy the silence while your site serves index.html with minimal drama.