Made a Static Website on S3... and Then Locked It Down with Bucket Policies

Today was kinda exciting — and a bit chaotic, not gonna lie.

The idea was simple:
Host a static website on S3.
But then I thought — wait, what if I don’t want everyone poking around my bucket?

So Day 15 turned into a two-part mission:

Put a website live on S3 without a single server
Control access using proper bucket policies

🌍 Hosting My First Static Website (No EC2 Involved!)

I started with a super basic index.html — literally this:

<!DOCTYPE html>
<html>
  <head>
    <title>My First S3 Website</title>
  </head>
  <body>
    <h1>Hello from S3!</h1>
    <p>Day 15 and I’m on the web 🚀</p>
  </body>
</html>

Then in S3:

Created a new bucket (named it something like my-website-demo-day15)
Disabled “Block Public Access” (S3 warns you here — deep breath)
Uploaded my index.html
Enabled Static Website Hosting from the Properties tab
- Set index.html as the index document
Copied the website endpoint and pasted it into my browser…

🎉 It worked. My page was live.

But Wait — It’s Public. Like, Too Public.

That’s when it hit me: Anyone could upload anything to this bucket if permissions weren’t right. So I started messing with bucket policies.

This is where things got tricky.

My First S3 Bucket Policy – Allow Read-Only Access

I crafted a simple policy (and broke it 3 times before getting it right):

{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Sid": "PublicReadGetObject",
      "Effect": "Allow",
      "Principal": "*",
      "Action": "s3:GetObject",
      "Resource": "arn:aws:s3:::my-website-demo-day15/*"
    }
  ]
}

It basically says:

“Anyone can read files from this bucket, but only read. No uploads, no deletes.”

After saving the policy, I refreshed the browser — still working ✅
Then I tried uploading from the CLI without credentials — Access Denied ✅

Success. I had a public site, but on my terms.

What I Learned Today

Hosting a site on S3 feels magical. No backend. No server headaches.
S3 static hosting is beginner-friendly — perfect for simple projects or testing HTML.
Bucket Policies are super powerful… but also a bit intimidating at first.
- One wrong line, and either nobody gets access, or everyone does everything.
You don’t need EC2 for everything. This was a reminder that serverless options are real — and useful.

Bonus Tip: Clean Bucket Naming

S3 bucket names are globally unique, so I’ve started prefixing mine with dates or usernames to avoid conflicts like:

my-website-demo-day15
2025-05-static-blog-bucket

⏭️ Next Up?

I might:

Try setting up custom error pages for broken routes (like 404.html)
Connect the static site to Route 53 with a custom domain
OR experiment with signed URLs to give time-limited access to files

Wrapping Up

Today I saw both sides of S3 — the easy wow (hosting a website), and the deep control (permissions via bucket policy).
It felt like stepping out of just “learning AWS” and into actually using it.

Day 15 — done.

Day 15: AWS - S3