How I Put My Personal Website on the Internet Using AWS

Introduction

I used to think putting a website on the internet was basically:

«Write some code → buy a domain → website is online.»

Turns out, there is quite a bit happening in between.

Recently, I started working on my personal website:

The website is meant to be more than just a portfolio. I want it to become a long-term record of what I learn, what I build, the research I read, the projects I work on, and the things I discover throughout my B.Tech journey.

While building it, I wanted to understand something beyond just writing React or Next.js code:

«How does a website actually reach someone's browser?»

That's where AWS came in.

Instead of treating hosting as a magic button that says Deploy, I decided to understand the infrastructure behind it.

This article is my beginner-level explanation of what I learned while putting my website on the internet using AWS.

---

1. First: What Does "Putting a Website Online" Actually Mean?

When I run my website on my laptop, I might see something like:

That's not the internet.

"localhost" basically means:

«"This application is running on my own computer."»

If I shut down my laptop, nobody else can access it.

For a real website, I need infrastructure that can receive requests from visitors and return my website to them.

The basic idea is:

My Code
↓
Hosting Infrastructure
↓
Internet
↓
Visitor's Browser

AWS provides many of the services and infrastructure that can make this possible.

---

2. So What Exactly Is AWS?

AWS stands for Amazon Web Services.

The easiest way I currently understand AWS is:

«AWS is a collection of cloud services that allows developers and organizations to use computing, storage, networking, databases, security and many other capabilities over the internet.»

Instead of buying a physical server, maintaining it, keeping it connected to the internet and dealing with the hardware myself, I can use cloud infrastructure.

For example:

- Amazon S3 → object storage
- Amazon EC2 → virtual servers
- Amazon RDS → managed databases
- Amazon Route 53 → DNS
- Amazon CloudFront → content delivery

One of the first things that clicked for me was this:

«Cloud computing doesn't mean that computers disappeared.»

The computers are still there.

They're running inside enormous data centers. Cloud providers simply make their infrastructure available through services that developers can use over the internet.

---

3. The Architecture Behind My Website

At a high level, the journey looks something like this:

Visitor
↓
shashanksaroj.com
↓
DNS
↓
Hosting / AWS Infrastructure
↓
Website
↓
Visitor's Browser

The important idea for me was understanding the chain:

«Domain → DNS → Hosting → Website → Browser»

Before this, I mostly thought about websites from the perspective of writing code.

Now I'm beginning to understand what happens after the code is written.

---

4. Step One: I Had to Build the Website

Before AWS could host anything, I needed something to host.

My website is built using modern web technologies, including Next.js and React.

During development, I could run it locally with:

npm run dev

At this point, everything was happening on my own machine.

I could edit the code, refresh the browser and immediately see the changes.

But there was one obvious problem:

Nobody else could see it.

So the next question became:

«How do I move this from my computer to infrastructure that can serve it over the internet?»

---

5. Step Two: Understanding Hosting

This was probably the biggest conceptual change for me.

When someone visits my website, their browser sends a request.

Something has to receive that request and return the required website resources.

That infrastructure needs to handle things such as:

1. Receiving requests.
2. Finding the required website resources.
3. Processing or retrieving those resources.
4. Sending the response back to the visitor.

This is where hosting comes in.

In simple terms:

«Hosting means making the resources or application that make up a website available to users over the internet.»

---

6. Step Three: Understanding Storage With Amazon S3

One of the AWS services I learned about was Amazon S3.

S3 stands for Simple Storage Service.

The simplest mental model I have for S3 is:

«A highly scalable cloud storage service where applications can store objects such as files and data.»

Those objects can include:

- Images
- Documents
- Videos
- Backups
- Website assets
- Application data

For a static website, you can think about the files roughly like this:

Website
├── HTML
├── CSS
├── JavaScript
├── Images
└── Other Assets

Instead of those files existing only on my laptop, they can be stored in cloud infrastructure and accessed when needed.

The important realization for me was:

«My laptop doesn't need to remain switched on for a cloud-hosted website to be available.»

---

7. Step Four: Understanding the Domain Name

Now comes the part everyone actually remembers:

shashanksaroj.com

A domain name gives humans a simple way to reach a website.

This is where DNS comes in.

DNS stands for:

«Domain Name System»

I think of DNS as the internet's address book.

When someone enters my domain, DNS helps determine where the request should be directed.

Conceptually:

shashanksaroj.com
↓
DNS
↓
Where should the request go?
↓
Website infrastructure

This is why I don't need to tell someone a complicated technical address just to visit my website.

I can simply give them:

shashanksaroj.com

---

8. Step Five: Connecting the Domain and Hosting

One thing that became very clear to me is that owning a domain and hosting a website are two different things.

The domain is the name:

shashanksaroj.com

The hosting infrastructure is where the website is actually served from.

So conceptually:

Domain
↓
DNS
↓
Hosting Infrastructure
↓
Website

Connecting these pieces is what allows someone to type my domain into a browser and actually reach my website.

---

9. Step Six: HTTPS and Security

I also wanted my website to use HTTPS.

Instead of simply:

http://

the website uses:

https://

HTTPS encrypts communication between the browser and the website.

This becomes especially important for websites that handle things such as:

- Login credentials
- Forms
- Personal information
- Payments
- Authentication
- APIs

Even though my website is primarily a personal site, I think HTTPS should be considered a basic requirement for a modern website.

---

10. Step Seven: Understanding CDNs

Another concept I came across while learning about AWS was the Content Delivery Network, or CDN.

A CDN is designed to help deliver content efficiently to users in different geographic locations.

The basic idea is:

Website
↓
CDN
↙ ↓ ↘
User User User

Instead of every request necessarily having to travel back to the same origin infrastructure, cached content can be served from locations closer to users.

This can reduce latency and improve the loading experience.

AWS provides this capability through Amazon CloudFront.

---

11. What Actually Happens When Someone Opens My Website?

This was the part I found the most interesting.

Let's say someone types my domain into their browser.

A simplified version of the process looks like this:

Step 1 — The browser receives the domain

shashanksaroj.com

Step 2 — DNS resolution happens

The browser needs to determine where the domain should point.

shashanksaroj.com
↓
DNS

Step 3 — The request reaches the website infrastructure

The request is directed toward the infrastructure responsible for serving my website.

Step 4 — The required resources are returned

Depending on the website and architecture, the browser may receive HTML, JavaScript, CSS, images and other resources.

Step 5 — The browser renders the website

The browser processes those resources and turns them into the page I see on the screen.

So the simplified journey is:

Browser
↓
Domain
↓
DNS
↓
Hosting Infrastructure
↓
Website Resources
↓
Browser
↓
Web Page

And all of that happens extremely quickly.

---

12. The Part That Changed How I Think About Websites

Before learning this, I mostly thought about websites from the perspective of:

«"What code do I write?"»

Now I'm starting to think about:

«"What happens to this code after I write it?"»

There are multiple layers involved:

Frontend
↓
Application
↓
Hosting
↓
Storage
↓
Networking
↓
DNS
↓
Security
↓
Internet

A website isn't just a collection of HTML, CSS and JavaScript.

It's a system.

---

13. Why I Didn't Want to Just Click "Deploy"

Modern platforms can make deployment incredibly easy.

That's great.

But as a CSE student, I don't want to only know:

«"Click this button and the website goes live."»

I want to understand what that button is actually doing.

When something breaks later, I want to be able to ask:

- Why isn't my domain resolving?
- Why is HTTPS failing?
- Why is an asset returning a 404?
- Why can't my application access a resource?
- Why is the website slow?
- Where is my data actually stored?
- How much is this infrastructure costing?

Understanding the underlying concepts makes debugging much easier.

---

14. What I Learned From Putting One Website Online

Building one personal website introduced me to several concepts that I previously knew mostly as terminology.

☁️ Cloud Computing

Using computing infrastructure and services over the internet instead of managing all the physical infrastructure myself.

🌐 DNS

The system that helps connect human-readable domain names with destinations on the internet.

💾 Cloud Storage

Storing application resources and data in cloud infrastructure.

🖥️ Compute

Running applications and workloads on remote computing infrastructure.

🔐 Security

Controlling access and protecting communication between users and applications.

🚀 Content Delivery

Using distributed infrastructure to deliver content efficiently to users.

---

15. The Funny Part: My Website Is Tiny 😂

There is an important reality check.

shashanksaroj.com is not Netflix.

I don't have millions of users.

I don't need hundreds of servers.

I don't have massive amounts of traffic.

But that's exactly why I think this was such a useful project.

A small personal website gives me a safe environment to learn concepts that become extremely important at larger scales.

I can experiment without having to operate some enormous production system.

---

16. What I Want to Build Next

This website is only the beginning.

I want it to become a living record of my B.Tech journey.

Over the next few years, I want to publish:

- TILs — Today I Learned
- Research notes
- AI/ML experiments
- Neuro-AI research
- Projects
- Technical articles
- Experiments
- Books and papers I've read
- Things I broke and fixed

And as the website grows, I want the infrastructure behind it to grow with my understanding.

That means gradually learning:

Linux
↓
Networking
↓
AWS
↓
Docker
↓
CI/CD
↓
Databases
↓
Monitoring
↓
Scalable Architecture

---

17. What I Would Tell Another Beginner

If you're also a first-year CSE student, don't wait until you "know cloud computing" before touching AWS.

You probably won't understand everything at first.

I didn't.

Start with something small.

Build a website.

Deploy it.

Break it.

Fix it.

Read the documentation.

Break it again.

Then gradually understand why each component exists.

That's when cloud computing starts becoming real.

---

18. Final Takeaway

The most important thing I learned from putting shashanksaroj.com online wasn't a particular AWS service.

It was understanding the journey from:

Code on my laptop
↓
Website/Application
↓
Cloud Infrastructure
↓
Networking
↓
DNS
↓
Internet
↓
Someone else's Browser

A while ago, I would have simply said:

«"My website is hosted on the cloud."»

Now I can start asking better questions:

Where is it hosted?

How does the request reach it?

Where are the files stored?

How is the domain connected?

How is HTTPS handled?

How would this architecture change if 1,000 people visited it?

What happens if 1 million people visit it?

I think that's the real beginning of learning cloud engineering.

And for me, it started with something very simple:

«I wanted my name on the internet.»

shashanksaroj.com