For a long time, I kept watching tutorials on cloud and DevOps.

I understood bits and pieces — S3, CloudFront, DNS — but nothing really clicked.

So I decided to stop watching and actually build something.

This project started as a simple goal: "I just want to put a website on the internet using AWS."

What I didn’t expect was how much this one project would teach me about how the internet actually works behind the scenes.

By the end, I had my own live website:

👉 https://kamleshcloud.com

And more importantly, I finally understood what happens when someone opens a website.

What is a static website?

Before starting this project, I always thought a website needs a server running in the background.

But that’s not always true.

A static website is simply a collection of files like:

• index.html

• style.css

• script.js

That’s it.

These files are already written and stored somewhere. When a user opens the website, the browser just downloads these files and displays the page.

There is no backend logic or database involved in this setup.

That was one of the first things that surprised me.

It made me realise that for many use cases like portfolios, landing pages, or simple blogs, you don’t actually need a full server setup.

You just need a place to store your files and a way to deliver them to users.

Final Architecture

Once everything was set up, my website followed this flow:

User → Route 53 → WAF → CloudFront → S3

At first, this looked very confusing to me.

But when I broke it down step by step, it started making sense:

• S3 is where my website files are stored

• CloudFront is responsible for delivering those files

• Route 53 connects my domain name to the website

• WAF acts like a security layer in front

• ACM helps enable HTTPS

Instead of thinking of these as separate services, I started seeing them as parts of one system working together to serve a simple website.

Step-by-Step: What I Actually Did

1. Built the website locally

I started by creating a simple website on my local machine using VS Code.

At this stage, the website only worked on my laptop.

This made me realise something very basic but important:

A website is just a collection of files until it is hosted somewhere on the internet.

Until those files are uploaded to a platform like AWS, no one else can access them.

That was my starting point.

2. Uploaded the files to S3

The next step was to move my website from my laptop to the cloud.

For this, I used Amazon S3.

I created a bucket and uploaded my website files:

• index.html

• style.css

• script.js

At this point, my files were finally stored in AWS.

But something interesting happened.

Even though the files were there, the website still wasn’t properly “live” yet.

That’s when I realised:

Uploading files is not the same as hosting a website.

You still need to tell AWS how to serve those files as a website.

3. Enabled static website hosting

This step is where things started to come together.

Inside S3, I enabled static website hosting and set:

👉 index.html as the default page

At first, I didn’t fully understand why this was needed.

But then it made sense.

When someone opens a website, they don’t type something like:

/index.html

They just open the main domain.

So AWS needs to know:

“What file should I show by default?”

That file is called the index document.

Once I enabled this, my website started working through the S3 endpoint.

This was the first time I saw my website actually live on the internet.

4. Added CloudFront (this confused me at first)

After getting the S3 version working, the next step was to add CloudFront.

This part was confusing in the beginning.

I kept thinking:

“If S3 is already hosting my website, why do I need CloudFront?”

But later, I understood it in a simple way:

• S3 = storage

• CloudFront = delivery

Instead of users directly accessing S3, they now access CloudFront.

So the flow becomes:

User → CloudFront → S3

CloudFront acts as the front layer that handles requests and delivers the website.

This is how most real-world setups work.

That’s when I started understanding that cloud architecture is about separating responsibilities.

5. Understanding the root object

This was one of the terms that confused me a lot at first.

In CloudFront, there is something called the default root object.

I set it to:

index.html

But what does that actually mean?

It simply means:

“When someone opens the root of the website, which file should be shown?”

Since users don’t type:

/index.html

we need to tell CloudFront what to load by default.

That’s exactly what the root object does.

Once I understood this, it stopped feeling like a complex term.

6. Bought a custom domain

After CloudFront was working, I wanted to make the website feel more real.

So I bought my own domain:

kamleshcloud.com

using Route 53.

This was a big step for me.

Instead of using a long AWS-generated URL, I now had something that actually looked like a real website.

I also realised that this domain is not just for this project.

I can use it in the future for:

• my portfolio

• my blog

• and even potential business ideas

That made this project feel much more meaningful.

7. Setting up HTTPS (this tested my patience)

After setting up the domain, the next step was to make the website secure using HTTPS.

For that, I used AWS Certificate Manager (ACM).

I requested a certificate for my domain, and at first everything looked fine.

But then the status stayed stuck at:

👉 “Pending validation”

This was frustrating because I wasn’t sure what was missing.

After digging a bit, I understood that AWS needed proof that I actually owned the domain.

This is done using DNS validation.

Once I created the required records in Route 53, the certificate finally changed to:

👉 “Issued”

That moment felt really satisfying because now my website was secure and could be accessed using HTTPS.

8. Connecting the domain (this is where it finally worked)

Even after setting up the certificate, my domain still didn’t work at first.

When I tried opening it, I got:

👉 DNS_PROBE_FINISHED_NXDOMAIN

At that point, I realised something was still missing.

The domain was not properly connected to CloudFront yet.

To fix this, I created an alias record in Route 53 and pointed it to my CloudFront distribution.

After doing that, I had to wait a few minutes for DNS to propagate.

And then…

🔥 The website finally went LIVE

👉 https://kamleshcloud.com

That was honestly one of the best moments of this project.

9. Adding WAF (security layer)

The final step was adding a basic security layer using AWS WAF.

You can think of WAF like a security guard in front of your website.

Before any request reaches CloudFront, WAF checks it first.

So now the flow becomes:

User → Route 53 → WAF → CloudFront → S3

Even though this is a basic setup, it made the architecture feel more complete and closer to real-world systems.

What I Learned

This project taught me much more than I expected.

Some of the biggest lessons were:

• A website is just a collection of files

• S3 stores the files, CloudFront delivers them

• DNS is what connects everything

• HTTPS requires validation, not just a button click

• Cloud architecture is really about request flow

Most importantly, I realised that things only start making sense when you actually build something.

Problems I Faced

This project was not smooth, and that’s what made it valuable.

Some of the issues I ran into:

• Certificate stuck on “Pending validation”

• Domain not working (NXDOMAIN error)

• Confusion around CloudFront concepts

• Understanding root object and behavior

But solving these problems is what made everything click.

Final Result

Here is my live website:

👉 https://kamleshcloud.com

And the GitHub repository:

👉 https://github.com/KamleshDevopsAndCloud

Final Thought

If you are starting your cloud journey, my advice is simple:

Don’t wait until you feel ready.

Just build something.

Break things. Fix them. Try again.

That’s when everything starts making sense.