☁️Week 6: I Deployed My First Static Website on AWS S3 — Here’s What I Learned

Week 6 of my DevOps learning journey officially moved into AWS Cloud.

Until now, I had worked with Linux, Git, and DevOps life cycle fundamentals. But this week, I deployed a static website using Amazon S3 — and it changed how I look at cloud infrastructure.

At first glance, hosting a static site sounds simple.

Upload files. Enable hosting. Done.

But once I started, I realized there’s much more happening under the hood.

🚀 Step 1 — Preparing the Website

I began by cloning a portfolio template from GitHub and verifying the file structure locally.

Before touching AWS, I made sure:

• index.html was present
• CSS and JS folders were structured properly
• Assets were correctly linked

That small validation step saved potential debugging later.

Lesson: Deployment issues often start with incorrect file structure.

🪣 Step 2 — Creating an S3 Bucket (Naming Matters)

When creating the bucket, I learned something important:

• S3 bucket names are globally unique across all AWS accounts.

My first attempt failed because the name was already taken.

So I followed a structured format:

pravin-portfolio-venkatesh-ap-south-1

I selected the Mumbai region (ap-south-1) to keep latency low.

Lesson: Even naming conventions matter in cloud architecture.

📂 Step 3 — Uploading Files (The Root-Level Trap)

Uploading files was straightforward — but there’s a common mistake here.

You must upload the contents of the folder, not the folder itself.

If index.html is inside another directory, S3 static hosting will fail.

I ensured:

• index.html is at root level
• CSS and asset folders are properly visible

Lesson: Most “S3 website not working” issues happen because of incorrect object structure.

🌐 Step 4 — Enabling Static Website Hosting

Under bucket properties, I enabled:

• Index document → index.html
• Error document → error.html

After saving, AWS generated a website endpoint URL.

Here’s something interesting:

• The S3 Object URL is different from the S3 Website Endpoint.
• The website endpoint is what actually serves your site publicly.
• That distinction clarified how S3 behaves internally.

🔐 Step 5 — Public Access & Bucket Policy

When I first opened the website endpoint…

• “Access Denied.”

Even if files are uploaded correctly, S3 will not serve them unless:

• Block Public Access settings allow it
• Bucket policy grants s3:GetObject permission

After configuring a proper public read bucket policy, the website finally loaded.

That moment felt different.

Because now I understood how access control works — not just how to upload files.

✅ Step 6 — Verification (The Most Underrated Step)

Many people stop after configuration, but I didn’t.

I verified:

• Homepage loads
• CSS styling works
• Images render correctly
• No permission errors

Deployment isn’t complete until validation is done.

🔁 Step 7 — Making a Small Update

To simulate a real workflow, I edited the homepage tagline and re-uploaded index.html.

At first, the change didn’t appear.

The reason?

Browser caching.

After performing a hard refresh, the updated content showed correctly.

Even small changes require proper redeployment and validation.

What This Assignment Really Taught Me

This wasn’t just about hosting a static website.

It helped me understand:

• Cloud storage fundamentals
• Public vs private access models
• Permission debugging
• Object hierarchy importance
• Endpoint differences
• Deployment validation mindset

For learning purposes, I used:

• Public S3 Bucket + HTTP Website Endpoint

But in real production systems:

• S3 is kept private
• CloudFront sits in front
• HTTPS is enforced
• Origin Access Control is used

That’s where I’m heading next.

💡 Final Thoughts

• Cloud isn’t about clicking buttons.
• It’s about understanding how systems connect.
• One small misconfiguration — and nothing works.

But when everything aligns — structure, permissions, endpoint — it works beautifully.

This was my first AWS S3 deployment, and it definitely won’t be the last.

P.S. This post is part of the DevOps Micro Internship (DMI) Cohort-2 by Pravin Mishra. You can start your DevOps journey by joining this Discord community ( https://discord.pravinmishra.com/ ).