How to Host a Static Website on Amazon S3

Why Amazon S3 is Ideal for Static Websites?

Think of Amazon S3 as a global, infinitely scalable filing cabinet in the cloud. You upload your website files (HTML, CSS, JavaScript, images) into it, and S3 handles everything else: storing them, serving them to visitors, and scaling automatically if your site gets popular.

This is radically different from a traditional server you might rent (like a virtual machine). With a traditional server, you're responsible for the entire computer—the operating system, web server software (like Apache or Nginx), security patches, and scaling. You pay for that entire machine 24/7, even if no one visits your site.

Common Misconception: S3 only stores data, not host websites

This belief comes from S3's original identity as "Simple Storage Service." People think "storage" means a hard drive you have to manually mount somewhere else to be useful.

Why that belief is inaccurate: S3 has a built-in, dedicated feature called "Static Website Hosting." When you enable it on a bucket, S3 transforms from a simple storage unit into a web server endpoint. It automatically:

1. Assigns your bucket a unique web address (like your-bucket-name.s3-website-region.amazonaws.com).
2. Serves your index.html file as the default page when someone visits the root address.
3. Returns proper HTTP error codes (like 404) for missing files.
4. Delivers your files over HTTPS (with a free Amazon certificate).

So, you're not just storing files; you're instructing S3 to act as a web server specifically for static content. The service that was "just storage" now directly handles the HTTP requests a website needs. This is why it's the simplest, most cost-effective way to host a static site.

How to Host a Static Website on S3

Let's demystify the process with a simple analogy. Imagine your S3 bucket as a single, physical shelf in a vast warehouse. You place your website's files—index.html, about.html, css/style.css—onto this shelf, each with its exact spot.

The "Shelf Address" is your bucket name (e.g., my-awesome-site), and the "File Position" is its key (like css/style.css).

Common Pitfall: The "403 Forbidden" Error

Here is a scenario every beginner encounters. You upload your index.html to the bucket. You copy the URL. You paste it into your browser.

Result: 403 Forbidden or Access Denied.

When you enable "Static Website Hosting", two critical things happen behind the scenes that fix this:

1. A Public Endpoint is created: S3 generates a specific URL designed for web traffic (e.g., http://bucket-name.s3-website-region.amazonaws.com).
2. A Bucket Policy is applied: S3 automatically attaches a rule that says, "Allow everyone ("*") to perform the s3:GetObject action on these files."

Without this second step—the policy change—S3 acts like a strict librarian who refuses to hand over books to strangers. The "Static Website Hosting" switch is the key that unlocks the shelf and invites the public in.

Amazon S3 Static Hosting Tutorial

Welcome to the construction site! Deploying your website to S3 is exactly like building a house. You can't paint the walls before you've laid the foundation, and you can't live there without electricity.

If you skip a step, the house is unusable. Let's walk through the four essential phases of construction, in the exact order you must perform them.

Common Pitfall: The "Missing Room" Syndrome

Here is a very common mistake beginners make. You upload your index.html file, and you think you are done. You open the URL, and it loads... mostly.

Why this is like building a house with only a front door:

If your HTML file contains a link to /about.html or references css/style.css, and those files are not in the bucket, the browser will return a 404 Not Found error for every single link and style sheet.

The Golden Rule: Your S3 bucket must be an exact mirror of your local project folder. If you have a folder structure like images/logo.png on your computer, that exact path must exist in the cloud. S3 does not guess; it only serves what you give it.

AWS S3 Beginner Guide: From Private Locker to Public Website

Let's build the intuition. Imagine Amazon S3 as a massive, secure cloud storage locker. You rent a locker (called a bucket) and place your website files—HTML, images, CSS—inside it.

By default, this locker is locked and private. Only you hold the key. To let visitors view your site, you must explicitly hand out copies of that key by adjusting permissions. S3's "Static Website Hosting" feature is simply the mechanism that transforms your private locker into a public display case with its own web address.

Common Mistake: The "403 Forbidden" Error

When you create an S3 bucket, AWS configures it as private by default. This is a security safeguard—your files are shielded from the public unless you grant access.

A frequent error is assuming that uploading files or enabling "Static Website Hosting" automatically makes them publicly readable. It does not. Without explicit public read permissions, visitors accessing your site's URL will encounter a 403 Forbidden error.

The Fix: Configuring the Bucket Policy

The fix is to attach a bucket policy that allows public s3:GetObject actions. This policy is typically added automatically when you enable static hosting via the AWS console, but if you create or modify the bucket programmatically, you must add it manually.

{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Effect": "Allow",
      "Principal": ""*"",
      "Action": "s3:GetObject",
      "Resource": "arn:aws:s3:::YOUR-BUCKET-NAME/*"
    }
  ]
}

Replace YOUR-BUCKET-NAME with your actual bucket name. Without this policy, S3 blocks all public requests—even if static hosting is enabled—because the bucket remains locked. The default privacy is intentional; your job is to deliberately open the door for your website's visitors.

Configure S3 Bucket for Website

Let's use a powerful analogy to understand configuration. Think of your S3 bucket as a physical mailbox at a public post office. You want anyone to be able to walk up, open the little door, and retrieve a letter (your index.html file).

To make this work, you must do two specific things:

If you only put up the sign but leave the mailbox locked, people will see your sign, try to open it, find it locked, and walk away frustrated—that's your 403 Forbidden error. The configuration isn't complete until both the sign and the unlocked state are in place.

Required Settings for Website Hosting

To transform your bucket into a functional website, you must explicitly configure these three settings. Missing any one of them will result in an error.

1. Enable Static Website Hosting:
   In the bucket's Properties tab, find the "Static website hosting" block and enable it. This creates the public website endpoint (e.g., http://your-bucket.s3-website-region.amazonaws.com) and tells S3 to act as a web server for this bucket.
2. Specify Index and Error Documents:
   Within that same setting, you must enter the exact key names of your files:
   • Index document: Typically index.html. This is the default file served when someone visits your bucket's root URL.
   • Error document (optional but recommended): e.g., 404.html. This custom page is served when a requested file doesn't exist.
3. Apply a Public Read Bucket Policy:
   This is the critical "unlock" step. The bucket must have a policy that grants the s3:GetObject permission to the public ("Principal": "*"). When you enable static hosting through the AWS Management Console, AWS often suggests and can apply a basic policy for you. If you skip this or remove it, your site will return 403 Forbidden.

Pitfall: Incorrect Bucket Policy Leads to 403 Errors

Even with static hosting enabled, a misconfigured bucket policy will lock your site down. The most common errors are:

How to Correct the Policy

If you encounter a 403 error, follow these steps to verify your policy:

1. Go to your bucket's Permissions tab.
2. Under Bucket policy, click Edit.
3. Ensure your policy JSON matches this exact structure, replacing YOUR-BUCKET-NAME:

{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Effect": "Allow",
      "Principal": ""*"",
      "Action": "s3:GetObject",
      "Resource": "arn:aws:s3:::YOUR-BUCKET-NAME/*"
    }
  ]
}

1. Click Save changes.

Why this works: This policy is the formal "key" you give to the world. It states: "Anyone (Principal: "*") is allowed to perform the s3:GetObject action (download files) on any object (Resource: .../*) inside this specific bucket." S3's static website endpoint checks this policy on every request for a file. If the policy allows the GetObject action for the public, S3 serves the file. If the policy is absent or denies access, S3 returns 403.

Test your fix: After saving the policy, wait 10-20 seconds (for AWS propagation), then access your bucket's website endpoint URL. You should now see your index.html page. If you still see 403, double-check the bucket name in the Resource ARN matches your bucket exactly (case-sensitive) and that the /* is present.

Cloud Static Site Deployment

Think of deployment as the final act of turning your private cloud shelf into a public display case. You've already uploaded all your website files—the shelf is stocked. But until you enable static website hosting and set the index document, that shelf remains locked in a private warehouse. No one can access it.

Deployment is the moment you instruct S3: "Serve these files to anyone who asks for them, and start with index.html when they visit the root address."

Steps to Make the Site Live

After you have uploaded every file from your website project to the S3 bucket, follow these precise steps to activate the site.

S3 now assigns your bucket a unique website endpoint (e.g., http://your-bucket.s3-website-us-east-1.amazonaws.com). Visiting that URL will serve your index.html file.

Common Misconception: Uploading files instantly makes the site live

Uploading files to an S3 bucket does not publish a website. By default, an S3 bucket is private. All objects inside it are inaccessible to the public internet.

The "Static website hosting" setting is the separate switch that:

Without enabling this setting, your bucket has no public URL, and S3 will not act as a web server. The files exist but are locked away. Therefore, deployment is not file transfer—it is configuration. You must explicitly enable static website hosting and specify the index document to make your uploaded files publicly reachable.

Advanced Settings: Custom Domains, SSL, and CloudFront

Your S3 bucket's default website endpoint (e.g., your-bucket.s3-website-us-east-1.amazonaws.com) is like a temporary P.O. box. It works, but it's impersonal and hard to remember. To build a professional brand, you need a permanent street address—your custom domain (e.g., www.yourbrand.com).

However, there's a catch: S3 static website endpoints do not support HTTPS directly for custom domains. Modern browsers require that security lock (SSL/TLS) to show the "Secure" padlock icon.

Common Pitfall: Forgetting to Update DNS Records

This is the most common reason for "downtime" during deployment. After creating your CloudFront distribution and getting your SSL certificate, you might think you are done.

But wait! If you don't update your DNS records, your domain (e.g., www.yourdomain.com) still points to your old host—or nowhere at all.

How to avoid downtime:

1. Wait for Deployment: Ensure your CloudFront distribution status is "Deployed" (not "In Progress") before changing DNS.
2. Update DNS Immediately: In your domain registrar (like GoDaddy, Namecheap, or Route 53), create a CNAME record for www pointing to your CloudFront domain.
3. Use Low TTL: If possible, lower your DNS TTL (Time To Live) to 300 seconds 24 hours before the switch. This makes the change propagate faster.

# This tells the world where to find your site
www.yourdomain.com.  300  IN  CNAME  d1234abcd.cloudfront.net.

Pro Tip: Root domains (like yourdomain.com without 'www') cannot use CNAME records. Instead, use an ALIAS or ANAME record (if supported by your registrar) or a redirect service. But for www, CNAME is the standard and correct choice.

Setting Up Bucket Policy for Public Access

Let's use a powerful analogy to understand this. Think of your S3 bucket as a private warehouse. By default, the warehouse is locked tight.

Even if you enable "Static Website Hosting" (which puts up a sign saying "Public Library"), the Security Guard (S3) still needs explicit written orders. Without a policy, the guard follows the default rule: "No one enters."

The Bucket Policy is that written order. It tells the guard: "Allow any visitor to enter and read any document, but do not let them rearrange or remove anything."

The Policy in Plain English

You don't need to be a JSON expert to understand a bucket policy. It simply answers three questions:

Common Pitfall: The "Open Writable" Bucket

A very common mistake beginners make is using a wildcard action like "s3:*" just to "fix" a 403 error quickly.

The Golden Rule: Your website bucket should be a read-only display case, not a public dropbox. The safest policy grants s3:GetObject permission only.

{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Effect": "Allow",
      "Principal": ""*"",
      "Action": ""s3:GetObject"",
      "Resource": "arn:aws:s3:::YOUR-BUCKET-NAME/*"
    }
  ]
}

Replace YOUR-BUCKET-NAME with your actual bucket name. This policy is the "key" you give to the world to let them see your site, but nothing else.

Frequently Asked Questions (FAQ)

Welcome to the troubleshooting workshop! Even the best architects hit a snag now and then. Here are the most common questions I hear from students, answered with the "why" and the "how."

{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Effect": "Allow",
      "Principal": ""*"",
      "Action": "s3:GetObject",
      "Resource": "arn:aws:s3:::YOUR-BUCKET-NAME/*"
    }
  ]
}