DEV Community: Anupa Supul

Why Doesn't My Website Crash When Thousands of People Visit? Understanding Amazon EC2

Anupa Supul — Fri, 31 Jul 2026 10:16:11 +0000

When I first started learning AWS, I assumed that if a website became popular, the solution was simple.

Buy a bigger server.

More CPU.

More RAM.

More storage.

Problem solved.

But then I started thinking about websites like Netflix, Amazon, and Instagram.

Millions of people visit them every day.

Sometimes millions of users are online at exactly the same time.

Surely they don't keep buying one giant server every time traffic increases.

So how do they handle sudden spikes in visitors without crashing?

That question introduced me to Amazon EC2 Auto Scaling.

The Problem

Imagine I build my own portfolio website.

Normally, around 100 people visit it each day.

Everything works perfectly.

Then one day, someone with a huge social media following shares my website.

Within minutes...

10,000 people try to open it.

What happens?

If I only have one EC2 instance, that single server now has to handle every request.

Soon it becomes overloaded.

Pages load slowly.

Some users get errors.

Eventually...

The website crashes.

flowchart LR

Users --> EC2

style EC2 fill:#ff9999

Clearly, one server isn't enough.

My First Thought

My first solution was:

Just buy a bigger server.

For example:

Upgrade from

2 GB RAM

16 GB RAM

This is called Vertical Scaling.

flowchart LR

SmallEC2["Small EC2"]

-->LargeEC2["Bigger EC2"]

This works...

But only up to a point.

Eventually, even the biggest server has limits.

AWS Had a Better Idea

Instead of buying one huge server...

Why not create more servers whenever they're needed?

That's exactly what Auto Scaling does.

Instead of this:

flowchart LR

Users --> OneServer

AWS can do this:

flowchart LR

Users

-->ELB

ELB-->EC21

ELB-->EC22

ELB-->EC23

ELB-->EC24

Now the workload is shared across multiple EC2 instances.

Each server handles only part of the traffic.

What Is Amazon EC2 Auto Scaling?

Amazon EC2 Auto Scaling automatically launches or removes EC2 instances depending on your application's traffic.

Simply put:

More visitors ➜ More servers
Fewer visitors ➜ Fewer servers

No manual work required.

Scale Out

Suppose your website suddenly becomes popular.

Traffic increases.

Auto Scaling detects the increase.

It automatically launches additional EC2 instances.

flowchart LR

Traffic

-->AutoScaling

AutoScaling

-->EC21

AutoScaling

-->EC22

AutoScaling

-->EC23

AutoScaling

-->EC24

This process is called Scale Out.

Scale In

Now imagine it's midnight.

Most users leave.

You no longer need four servers.

Keeping them running would waste money.

Auto Scaling automatically terminates the extra EC2 instances.

flowchart LR

TrafficDrops

-->AutoScaling

AutoScaling

-->EC21

This is called Scale In.

You only pay for what you actually use.

Auto Scaling Group

Auto Scaling doesn't create random servers.

Instead, it manages them inside something called an Auto Scaling Group (ASG).

An ASG follows rules that you define.

For example:

Minimum Instances → 2
Desired Instances → 3
Maximum Instances → 10

If traffic increases, AWS can grow from:

3 → 4 → 5 → 6 → ... → 10

If traffic decreases, it can shrink back down.

Everything happens automatically.

Auto Scaling + Elastic Load Balancer

One thing finally clicked for me.

Auto Scaling creates servers.

But...

How do users know which server to use?

That's where the Elastic Load Balancer (ELB) comes in.

flowchart LR

Users

-->ELB

ELB-->EC21

ELB-->EC22

ELB-->EC23

ELB-->EC24

The Load Balancer distributes traffic.

Auto Scaling creates or removes servers.

Together, they make applications highly available.

Real-World Examples

Auto Scaling is useful almost everywhere.

Imagine:

Black Friday shopping
Concert ticket sales
Online gaming events
Netflix releasing a new season
Viral social media applications

Traffic suddenly increases.

Instead of crashing...

AWS automatically adds more servers.

Once traffic drops, it removes the extra servers.

Why This Saves Money

Without Auto Scaling, you might keep ten servers running all day.

Even when only one server is needed.

That's expensive.

With Auto Scaling:

Busy hours:

8 Servers

Quiet hours:

2 Servers

AWS adjusts automatically.

You only pay for the servers you actually need.

Benefits of Auto Scaling

Handles sudden traffic spikes

Improves application availability

Prevents server overload

Automatically adds or removes EC2 instances

Reduces infrastructure costs

Works seamlessly with Elastic Load Balancers

What Changed My Perspective

Before learning Auto Scaling, I thought handling more users meant buying a more powerful server.

Now I understand that's only one approach.

Sometimes the better solution isn't:

A bigger server.

It's:

More servers working together.

That small mindset shift completely changed how I think about scalable applications.

Final Thoughts

When I first heard the term Amazon EC2 Auto Scaling, I imagined it was just another AWS feature.

Now I realize it's one of the key reasons modern cloud applications stay online during sudden traffic spikes.

Instead of guessing how many servers you'll need...

AWS watches your traffic for you.

When demand increases, it automatically adds more servers.

When demand decreases, it removes the extras.

That's one of the biggest advantages of cloud computing.

You don't have to build for your busiest day.

AWS scales with you.

Key Takeaways

Auto Scaling automatically launches and removes EC2 instances.
Scale Out adds more servers during high traffic.
Scale In removes servers when traffic decreases.
Auto Scaling Groups manage EC2 instances using rules.
Elastic Load Balancer distributes traffic across all instances.
Together, ELB and Auto Scaling build highly available applications.

*Thanks for reading! *

How Does AWS Know Which Website I'm Trying to Visit? Understanding Amazon Route 53

Anupa Supul — Fri, 31 Jul 2026 09:57:57 +0000

When I first started learning web development, opening a website felt almost magical.

I would type something like:

www.amazon.com

Press Enter.

A few seconds later, the website appeared.

I never stopped to think about what actually happened.

How did my computer know where Amazon's servers were?

How did it find the correct server among millions connected to the internet?

And why don't we type an IP address like:

54.239.28.85

instead of simply typing:

amazon.com

Those questions eventually led me to one of the first networking services in AWS:

Amazon Route 53

The Question That Made Me Curious

Imagine I build my own MERN application.

I deploy it on an EC2 instance.

AWS gives me a public IP address like:

18.142.120.54

Technically, people can visit my application using that IP.

But let's be honest...

Nobody wants to remember numbers like that.

It's much easier to visit:

myportfolio.com

myapp.com

That made me wonder:

How does my computer know that "myapp.com" actually means "18.142.120.54"?

The Phone Contact Analogy

This example made everything click for me.

Imagine your best friend has this phone number.

+94 71 123 4567

Do you memorize the number?

Probably not.

Instead, you save it as:

John

Now whenever you want to call him, you simply tap:

John

Your phone automatically finds the correct phone number.

You don't need to remember it.

The internet works almost the same way.

Instead of remembering:

18.142.120.54

we simply remember:

mywebsite.com

Something translates that easy-to-read name into the server's IP address.

That "something" is called DNS (Domain Name System).

What Is Amazon Route 53?

Amazon Route 53 is AWS's managed DNS service.

Its job is simple:

Convert human-friendly domain names into IP addresses that computers understand.

Instead of this:

18.142.120.54

We simply type:

mywebsite.com

Route 53 performs the translation and sends us to the correct server.

What Actually Happens?

Let's say I open:

www.myportfolio.com

Here's what happens behind the scenes.

flowchart LR

A[User Types myportfolio.com]

-->B[Browser]

-->C[Amazon Route53 DNS Lookup]

-->D[Returns IP Address]

-->E[EC2 Server]

-->F[Website Loads]

The entire process usually takes only milliseconds.

A Real AWS Example

Suppose I host my MERN application on an EC2 instance in Singapore.

Its public IP address is:

18.xxx.xxx.xxx

Without Route 53, users would have to visit:

18.xxx.xxx.xxx

With Route 53:

flowchart LR

A[myportfolio.com]

-->B[Amazon Route53]

-->C[18.xxx.xxx.xxx]

-->D[EC2 Instance]

Much easier.

Why Is It Called Route 53?

One thing that caught my attention was the number 53.

It's actually named after Port 53, the standard network port used for DNS communication.

A small detail, but one I found interesting.

Route 53 Does More Than DNS

Initially, I thought Route 53 only converted domain names into IP addresses.

But it can also:

Route traffic globally
Perform Health Checks
Fail over to healthy resources
Route traffic intelligently
Improve application availability

Where Route 53 Fits in AWS

As I learned more AWS services, I realized Route 53 is usually the very first AWS service involved when someone opens a website.

flowchart LR

User

-->Route53

-->CloudFront

-->LoadBalancer

-->EC2

-->Database

Every service has its own responsibility.

Route 53 simply helps users find the right destination.

Why Route 53 Matters

Without DNS:

Users must remember IP addresses.

With Route 53:

Easy-to-remember domain names

Highly available DNS

Faster routing

Health monitoring

Traffic routing policies

Works with almost every AWS service

What Changed My Perspective

Before learning AWS, I thought typing a website name directly connected me to the server.

Now I understand there's an important translation happening first.

Someone has to convert:

mywebsite.com

into

18.xxx.xxx.xxx

That's exactly what DNS does.

And in AWS, that job belongs to Amazon Route 53.

Final Thoughts

When I first heard the name Route 53, I had no idea what it actually did.

Now I think of it much more simply.

It's like the contact list on my phone.

I don't remember phone numbers.

I remember names.

Similarly, my browser doesn't magically know where a website lives.

Route 53 translates a human-friendly domain name into the server's actual address.

Sometimes the most important AWS services are the ones quietly working behind the scenes.

And Route 53 is definitely one of them.

Key Takeaways

Route 53 is AWS's managed DNS service.
It converts domain names into IP addresses.
It makes websites easier to access.
It supports health checks and intelligent routing.
It's usually the first AWS service involved when visiting a website.

*Thanks for reading! *

Why Is Netflix So Fast Everywhere? Understanding Amazon CloudFront

Anupa Supul — Wed, 22 Jul 2026 10:27:13 +0000

When I first started learning AWS, I thought website speed mostly depended on one thing:

A powerful server.

More CPU.

More memory.

Better hardware.

Problem solved.

Or at least that's what I thought.

Then a question hit me.

Netflix loads quickly.

YouTube loads quickly.

Amazon loads quickly.

But their servers aren't sitting in my room.

In fact, many of them are located thousands of kilometers away.

So why doesn't every click feel slow?

That question eventually led me to Amazon CloudFront.

The Thought That Started It

Imagine I host a website on AWS in Singapore.

Now imagine someone opens that website from Sri Lanka.

Every image.

Every CSS file.

Every JavaScript file.

Every request.

Has to travel all the way to Singapore and back.

flowchart LR
    USER[User in Sri Lanka]
    SERVER[AWS Server in Singapore]

    USER --> SERVER

That doesn't sound very efficient.

And it gets even worse when thousands or millions of users are involved.

So I started wondering:

How do global companies deliver content so quickly to people all around the world?

The Concept That Finally Clicked

The simplest way I understand CloudFront is this:

Imagine there is only one library in an entire country.

Every student has to travel there to borrow a book.

It works.

But it's slow.

Now imagine small branches of that library are opened across different cities.

Students can get popular books from a nearby branch instead of traveling to the main library.

That's basically what CloudFront does.

Instead of forcing every user to communicate with the original server, AWS places copies of content closer to users.

What Is Amazon CloudFront?

Amazon CloudFront is AWS's Content Delivery Network (CDN).

Its job is simple:

Deliver content from the location closest to the user whenever possible.

Rather than always requesting files from the original server, CloudFront stores frequently requested content in locations around the world called Edge Locations.

When a user requests that content again, it can be delivered from a nearby Edge Location instead of the original AWS Region.

A Simple Example

Suppose I host a portfolio website.

The website contains:

Images
CSS files
JavaScript files

Without CloudFront:

flowchart LR
    USER[User]
    SERVER[Singapore Server]

    USER --> SERVER

Every request makes the full journey.

With CloudFront:

flowchart LR
    USER[User]

    EDGE[CloudFront Edge Location]

    SERVER[Singapore Server]

    USER --> EDGE
    EDGE --> SERVER

If the content is already cached, CloudFront delivers it immediately.

Fewer long-distance trips.

Faster loading times.

Better experience.

What Are Edge Locations?

While learning AWS Global Infrastructure, I came across three important concepts:

Regions
Availability Zones
Edge Locations

CloudFront uses Edge Locations to serve content closer to users.

Think of them as small delivery centers spread around the world.

flowchart TD
    USER[User]

    EDGE[Nearest Edge Location]

    ORIGIN[Origin Server]

    USER --> EDGE
    EDGE --> ORIGIN

When content is already available at the Edge Location, users get it much faster.

Why This Matters

Before learning CloudFront, I thought performance was mainly about the server.

Now I realize distance is part of the equation too.

Even a powerful server can't overcome physics.

Data still needs to travel.

CloudFront helps reduce that distance from the user's perspective.

And when you're serving users across different countries, that makes a huge difference.

CloudFront + S3

One of the most common AWS architectures combines CloudFront with Amazon S3.

flowchart LR
    USER[Users]

    CF[CloudFront]

    S3[Amazon S3 Bucket]

    USER --> CF
    CF --> S3

This setup is commonly used for:

Static websites
Images
Downloads
Documentation
Portfolio sites

CloudFront + Modern Web Applications

CloudFront can also work with dynamic applications.

flowchart LR
    USER[Users]

    CF[CloudFront]

    ELB[Load Balancer]

    EC2[EC2 Instances]

    USER --> CF
    CF --> ELB
    ELB --> EC2

Seeing architectures like this helped me realize that AWS services aren't isolated tools.

They work together to solve larger problems.

Why Is Netflix So Fast?

This was the original question that made me curious.

Streaming platforms serve enormous amounts of content every second.

Imagine if every user had to fetch videos directly from a single server.

The experience would be terrible.

Instead, content is distributed closer to users.

Popular files are cached.

Travel distance is reduced.

Latency drops.

The result is a much smoother experience.

While Netflix has a far more complex infrastructure than this simplified example, the underlying idea is very similar:

Bring content closer to users.

Benefits of Amazon CloudFront

After learning about CloudFront, these are the biggest benefits that stood out to me:

✅ Faster content delivery

✅ Lower latency

✅ Better user experience

✅ Reduced load on origin servers

✅ Global content distribution

✅ Improved scalability

What Changed My Perspective

Before learning AWS, I thought website performance was mostly about powerful servers.

Then I learned about:

Load Balancers
Auto Scaling
CloudFront

And I realized something.

Sometimes the fastest solution isn't a bigger server.

It's bringing content closer to the user.

That simple idea is what made CloudFront click for me.

Final Thoughts

When I first heard about Amazon CloudFront, it sounded like just another AWS service.

Now I see it differently.

It's AWS's answer to a simple problem:

How do you make a website feel fast for users all around the world?

Not by making people travel farther.

By bringing content closer to them.

And honestly, that's not something I ever thought about when I first started learning web development.

ops

How AWS Security Groups Finally Made Sense to Me

Anupa Supul — Wed, 22 Jul 2026 10:11:43 +0000

🔐 How AWS Security Groups Finally Made Sense to Me

The AWS feature that taught me security isn't just about passwords and encryption.

When I launched my first EC2 instance, AWS asked me to configure something called a Security Group.

At the time, I didn't think much about it.

I simply opened the ports AWS recommended, launched the server, and moved on.

The application worked.

The website loaded.

Everything seemed fine.

But as I continued learning AWS, I kept seeing Security Groups appear everywhere.

EC2 instances had them.

Databases had them.

Load Balancers used them.

That's when I started wondering:

What exactly are Security Groups, and why are they so important?

The Mistake Most Beginners Make

When I first heard the word security, I immediately thought about:

Passwords
Encryption
Authentication
Antivirus software

Security Groups are different.

They answer a much simpler question:

Who is allowed to communicate with my AWS resources?

And surprisingly, that single question is incredibly important.

A Real Scenario: Hosting a Website

Imagine I deploy a MERN application on an EC2 instance.

Users need to access the website through their browsers.

For that to happen, the server must allow:

HTTP (Port 80)
HTTPS (Port 443)

flowchart TD
    U[User]
    SG[Security Group]
    EC2[EC2 Instance]

    U --> SG
    SG --> EC2

Without those ports being open, nobody can access the application.

Even if the server is running perfectly, it remains unreachable.

This was my first realization:

Security Groups don't make resources public.

They decide whether traffic is allowed to reach them.

So What Is a Security Group?

The simplest explanation I found is:

A Security Group acts as a virtual firewall for AWS resources.

It controls two types of traffic:

Inbound Rules

Traffic coming into a resource.

Examples:

Users visiting a website
Developers connecting through SSH
Applications calling APIs

Outbound Rules

Traffic leaving a resource.

Examples:

Calling external APIs
Downloading updates
Connecting to databases

Every request is checked against these rules.

If a rule allows it, traffic passes.

If not, AWS blocks it automatically.

The SSH Example

This is where Security Groups became very practical for me.

Suppose I want to connect to my EC2 instance using SSH.

SSH uses:

Port 22

flowchart TD
    DEV[Developer]
    SSH[SSH Port 22]
    SG[Security Group]
    EC2[EC2 Instance]

    DEV --> SSH
    SSH --> SG
    SG --> EC2

A common beginner mistake is allowing:

0.0.0.0/0

Which means:

Anyone on the internet can attempt to connect.

It works.

But it's not ideal.

A safer approach is allowing only your own public IP address.

That way, only you can access the server.

The Database Scenario That Made Everything Click

This was the example that finally made Security Groups click for me.

Imagine a simple application architecture:

flowchart TD
    USER[Users]

    FE[Frontend]

    API[Backend API]

    DB[(Database)]

    USER --> FE
    FE --> API
    API --> DB

Now ask yourself:

Should internet users connect directly to the database?

Definitely not.

The database should only accept requests from the backend server.

Instead of this:

flowchart TD
    INTERNET[Internet Users]
    DB[(Database)]

    INTERNET -. Blocked ❌ .-> DB

We want this:

flowchart TD
    FE[Frontend]
    API[Backend API]
    DB[(Database)]

    FE --> API
    API --> DB

Security Groups make this possible by controlling exactly who can communicate with what.

Why Security Groups Are Stateful

One AWS concept that surprised me was that Security Groups are stateful.

Imagine a user sends a request to an EC2 instance.

flowchart LR
    USER[User]

    SG[Security Group]

    EC2[EC2 Instance]

    USER --> SG
    SG --> EC2

    EC2 --> USER

If the inbound request is allowed, the response is automatically allowed back.

You don't need to create a separate return rule.

AWS handles that automatically.

This makes Security Groups much easier to manage.

A Real-World AWS Architecture

A simple production setup might look like this:

flowchart TD
    USER[Users]

    SG1[Web Security Group]

    EC2[Backend Server]

    SG2[Database Security Group]

    DB[(Database)]

    USER --> SG1
    SG1 --> EC2

    EC2 --> SG2
    SG2 --> DB

In this setup:

Users can access the backend server.
The backend server can access the database.
Users cannot access the database directly.

This is one of the most common security patterns you'll see in AWS architectures.

Security Is Not Just About Applications

Before learning AWS, I thought security mostly happened inside the application.

Things like:

User authentication
Password hashing
JWT tokens
Role-based access control

Those are still important.

But AWS taught me something else:

Security also exists at the infrastructure level.

Even a perfectly written application can become vulnerable if network access isn't configured properly.

Security Groups provide one of the first layers of defense.

What Changed My Perspective

The first time I configured a Security Group, it felt like just another setup step before launching an instance.

Now I see it differently.

Every rule is answering a simple question:

Who should be allowed to communicate with this resource?

The more I learn AWS, the more I realize that cloud security isn't about blocking everything.

It's about allowing only what is necessary.

And Security Groups are one of the simplest and most effective tools AWS provides for doing exactly that.

Final Thoughts

Security Groups looked complicated when I first encountered them.

Today, I think of them much more simply.

They're the gatekeepers of AWS resources.

They decide:

Who can enter
What traffic is allowed
What traffic should be blocked

And understanding that concept helped me appreciate why Security Groups appear in almost every AWS architecture diagram.

Sometimes the most important AWS services aren't the most exciting ones.

They're the ones quietly protecting everything behind the scenes.

Why Doesn't Everyone Connect to the Same Server? Understanding AWS Elastic Load Balancer (ELB)

Anupa Supul — Mon, 20 Jul 2026 05:51:01 +0000

While learning AWS, I noticed something interesting.

In almost every AWS architecture diagram, there was a service sitting in front of multiple servers.

It looked something like this:

Users
   │
   ▼
Load Balancer
   │
 ┌─┴─┐
 ▼   ▼
EC2 EC2

At first, I didn't understand why it was there.

I kept thinking:

"Why can't users just connect directly to the server?"

After all, if the server is running my application, shouldn't users talk to it directly?

The more I learned, the more I realized that this simple service solves a huge problem.

And that's how I discovered AWS Elastic Load Balancer (ELB).

The Question That Made Me Curious

Imagine I build a website.

On a normal day, maybe 100 people visit it.

One server is enough.

Everything works smoothly.

Now imagine my website suddenly goes viral.

Thousands of people start visiting at the same time.

What happens?

Every request goes to the same server.

Eventually, that server becomes overwhelmed.

Pages become slow
Users start waiting
Requests fail
Visitors leave

That's when I realized:

The problem isn't just having servers.

It's deciding how traffic should be shared between them.

The Coffee Shop Analogy

This was the example that made everything click for me.

Imagine a coffee shop with only one cashier.

500 Customers
      │
      ▼
  1 Cashier

The line becomes huge.

Customers wait.

Some leave before getting served.

Now imagine adding three more cashiers.

500 Customers
      │
      ▼
 ┌─────────┐
 │ Manager │
 └─────────┘
  │  │  │  │
  ▼  ▼  ▼  ▼
 C1 C2 C3 C4

The manager directs customers to whichever cashier is available.

Nobody has to choose a cashier manually.

The workload gets distributed automatically.

That manager is basically what a Load Balancer does.

So... What Is an Elastic Load Balancer?

The simplest way I understand it is:

An Elastic Load Balancer automatically distributes incoming traffic across multiple servers.

Instead of sending every user to one server, AWS spreads the requests across several servers.

Benefits include:

Improved performance
Higher availability
Better fault tolerance
Handling traffic spikes

Without a Load Balancer

10,000 Users
      │
      ▼
     EC2

One server has to handle everything.

If it fails, the application becomes unavailable.

With a Load Balancer

10,000 Users
       │
       ▼
 Load Balancer
   │    │    │
   ▼    ▼    ▼
 EC2  EC2  EC2

Traffic gets shared.

Each server handles a smaller amount of work.

The application stays responsive.

What Happens If a Server Fails?

Without a Load Balancer:

Users
  │
  ▼
Failed Server ❌

Website unavailable.

With a Load Balancer:

Users
  │
  ▼
Load Balancer
 │     │     │
 ▼     ▼     ▼
❌    EC2   EC2

Traffic automatically moves to healthy servers.

Most users never notice anything happened.

How ELB Works With Auto Scaling

Internet Users
       │
       ▼
 Load Balancer
       │
 ┌─────┼─────┐
 ▼     ▼     ▼
EC2   EC2   EC2
       │
       ▼
 Auto Scaling

Auto Scaling decides how many servers exist.
ELB decides where traffic goes.

Together, they keep applications scalable and highly available.

Final Thoughts

When I first saw Elastic Load Balancer in AWS diagrams, it looked like just another service with a complicated name.

Now I see it much more simply.

"If thousands of users arrive at the same time, who decides where each request should go?"

That's exactly the problem ELB solves.

And for me, it was another reminder that cloud computing isn't just about servers.

It's about designing systems that continue working even when demand grows.

Understanding Amazon Route 53: How the Internet Finds Your Website

Anupa Supul — Fri, 10 Jul 2026 11:00:15 +0000

When I first started learning web development, I never really thought about what happened after typing a website address into my browser.

For example, if I typed:

www.amazon.com

www.google.com

the website would simply open.

It felt almost like magic.

But one day, while learning AWS, I stopped and asked myself:

"How does my computer know where this website actually is?"

After all, computers don't understand names like google.com or amazon.com.

They understand IP addresses.

So who translates a website name into an IP address?

That's when I discovered Amazon Route 53 and, more importantly, learned about DNS (Domain Name System).

Before Learning DNS...

To be honest, I assumed typing a website name was enough.

I thought my browser somehow knew where every website lived.

But that's not how the internet works.

Every website has an IP address, something like this:

54.239.28.85

Imagine having to remember IP addresses for every website you visit.

Instead of typing:

google.com

you would have to type:

142.250.190.78

That would be nearly impossible.

Thankfully, DNS exists.

What Is DNS?

The simplest way I understand DNS is this:

DNS is like the internet's phonebook.

Instead of remembering someone's phone number, you save their name in your contacts.

When you tap their name, your phone finds the correct number automatically.

DNS works the same way.

Instead of remembering an IP address, we simply type a domain name.

DNS finds the correct IP address for us.

That simple analogy made everything click.

So... What Is Amazon Route 53?

Once I understood DNS, Route 53 became much easier to understand.

The easiest way I remember it is:

Amazon Route 53 is AWS's DNS service.

Its main job is to help users reach the correct website.

When someone types:

mywebsite.com

Route 53 helps translate that name into the IP address of the server hosting the website.

Without DNS, our browsers wouldn't know where to send the request.

A Simple Example

Imagine I've deployed my MERN application on an EC2 instance.

The server has an IP address like this:

13.229.xxx.xxx

Technically, visitors could use that IP address to access my website.

But let's be honest...

Which is easier to remember?

13.229.xxx.xxx

myportfolio.com

The answer is obvious.

Route 53 connects the domain name with the server's IP address.

The Journey of a Website Request

This was one of my favorite things to learn because it finally showed me what happens behind the scenes.

When I type a website into my browser:

www.mywebsite.com

the process looks something like this:

You
│
▼
Browser
│
▼
DNS (Route 53)
│
▼
Find Server IP Address
│
▼
AWS Server (EC2)
│
▼
Website Loads

The whole process happens in just a few milliseconds.

As users, we hardly even notice it.

Why Is It Called Route 53?

This was a question I was curious about.

It turns out the number 53 comes from Port 53, the standard network port used by DNS.

Once I learned that, the name suddenly made much more sense.

More Than Just Finding Websites

As I kept learning, I realized Route 53 can do much more than simply translate domain names.

It can also:

Route users to different servers.
Improve availability.
Support disaster recovery.
Help direct users to the nearest AWS Region.

I haven't explored all of these features yet, but it's exciting to know there's much more to learn.

How Route 53 Fits Into Everything I've Learned

One thing I really like about AWS is how each service connects with another.

Route 53 doesn't replace EC2.

It doesn't replace CloudFront.

Instead, it works together with them.

A simple setup might look like this:

         User
           │
           ▼
  Route 53 (DNS)
           │
           ▼
    CloudFront
           │
           ▼
    Load Balancer
           │
           ▼
         EC2
           │
           ▼
       Database

Seeing the bigger picture made me realize that AWS isn't just a collection of individual services.

They're all designed to work together.

What Changed My Perspective

Before learning AWS, I thought opening a website was as simple as typing its name into the browser.

Now I understand there's an entire system working behind the scenes before the website even starts loading.

A simple service like DNS makes the internet much easier to use.

Without it, we'd all be trying to remember long IP addresses instead of simple website names.

It's one of those things we use every single day but rarely stop to think about.

Final Thoughts

When I first heard the name Amazon Route 53, I honestly had no idea what it did.

Now I think of it much more simply.

It's the service that helps the internet answer one basic question:

"Where should this request go?"

Without DNS, finding websites would be far more complicated.

Learning Route 53 helped me appreciate that even the simplest action—typing a website name—depends on an incredible amount of technology working quietly in the background.

And that's another reason why I'm enjoying this AWS learning journey.

Every topic makes me look at the internet a little differently.

Why Doesn't AWS Want Me Using the Root Account? Understanding IAM

Anupa Supul — Fri, 10 Jul 2026 10:51:37 +0000

The day I created my AWS account, I was excited to start exploring cloud computing.

I logged in, looked around the AWS Management Console, and couldn't wait to launch my first EC2 instance.

But before I did anything, I noticed something interesting.

AWS kept reminding me:

"Don't use your root account for everyday tasks."

At first, I didn't understand why.

I remember thinking,

"It's my account. Why shouldn't I use it?"

If the root account has the highest level of access, wouldn't it make sense to use it all the time?

The more I learned, the more I realized AWS wasn't trying to make things difficult.

It was actually trying to protect me.

That curiosity introduced me to one of the most important AWS services: IAM (Identity and Access Management).

My First Thought

Coming from web development, I was used to creating one account and using it for everything.

So when AWS suggested creating another user instead of using the root account, it felt unnecessary.

I thought,

"I'll be the only one using this account anyway."

But then I imagined something.

What if someone somehow got access to my root account?

They wouldn't just have access to one EC2 instance.

They could:

Delete every resource
Remove databases
Change billing settings
Create new users
Close the AWS account

Suddenly, AWS's warning started making a lot more sense.

So... What Is the Root Account?

The root account is the account you create when you first sign up for AWS.

It's like the master key to everything inside your AWS account.

With it, you can:

Access every AWS service
Change account settings
Manage billing
Create or delete users
Delete almost every resource

Because it has unlimited permissions, AWS recommends using it only when absolutely necessary.

For everyday work, there's a better option.

That's where IAM comes in.

What Is IAM?

The simplest way I understand IAM is this:

IAM helps you decide who can access your AWS account and what they're allowed to do.

Instead of everyone using the powerful root account, you create separate IAM users with only the permissions they need.

That immediately reminded me of something we use in everyday life.

The Analogy That Helped Me

Imagine you own a company.

You probably wouldn't hand your master office key to every employee.

Instead:

The manager gets access to most areas.
The accountant can access financial records.
The receptionist can access only the front desk.
Visitors can enter only the waiting area.

Everyone has different responsibilities.

Everyone gets different levels of access.

IAM works exactly the same way.

Instead of giving every user full control, AWS lets you decide exactly what each person can do.

The Four IAM Concepts That Finally Clicked for Me

When I first saw IAM documentation, I came across four terms over and over again:

Users
Groups
Roles
Policies

At first, they all sounded similar.

But once I understood their purpose, they became much easier to remember.

👤 IAM Users

An IAM User represents a person or an application that needs access to AWS.

For example:

Me
Another developer
A CI/CD pipeline

Instead of sharing one account, everyone gets their own login.

That makes AWS much safer and easier to manage.

👥 IAM Groups

Imagine I have five developers working on the same project.

Giving each person the same permissions one by one would be repetitive.

Instead, I can create a group called:

Developers

Then simply add users to that group.

Anyone who joins automatically receives the same permissions.

That felt like a much smarter approach.

📜 IAM Policies

Policies are simply permission rules.

They answer questions like:

Can this user launch an EC2 instance?
Can they upload files to S3?
Can they delete databases?

Without a policy, an IAM user can't do very much.

Policies define what is allowed and what isn't.

🎭 IAM Roles

Roles confused me the most at first.

Then I learned they're a little different from users.

Instead of representing a person, a role is usually assumed temporarily by an AWS service or an application.

For example:

An EC2 instance might need permission to upload files to S3.

Instead of storing secret access keys on the server, AWS lets the EC2 instance assume an IAM Role.

That role gives it only the permissions it needs.

Once I understood that, roles made much more sense.

The Principle That Stuck With Me

While learning IAM, I came across an idea called the Principle of Least Privilege.

It simply means:

Only give the permissions that are actually needed. Nothing more.

If someone only needs to read files from S3...

Don't give them permission to delete S3 buckets.

If someone only needs to view CloudWatch logs...

Don't give them administrator access.

It's a simple idea, but it makes a huge difference when it comes to security.

How I Plan to Use IAM

Now that I understand IAM better, here's how I plan to use my AWS account:

Keep the root account safe.
Enable Multi-Factor Authentication (MFA).
Create an IAM user for everyday work.
Give only the permissions I actually need.
Use roles whenever AWS services need to communicate securely.

It feels like a much safer way to work.

What Changed My Perspective

Before learning AWS, I thought security started after deploying an application.

Now I realize it starts much earlier.

It starts with something as simple as deciding which account you log in with.

IAM taught me that good security isn't about making things complicated.

It's about giving the right people the right access—and nothing more.

That lesson will probably stay with me long after I finish learning AWS.

Final Thoughts

When I first saw AWS warning me not to use the root account, I honestly thought it was just another recommendation that I could ignore.

Now I understand why AWS takes it so seriously.

The root account is incredibly powerful.

Using it every day isn't just unnecessary—it increases the risk if something ever goes wrong.

Learning IAM helped me understand that cloud security isn't only about firewalls or encryption.

Sometimes it starts with a simple decision:

Who should have access, and how much access do they really need?

For me, IAM was one of those topics that looked boring at first but turned out to be one of the most practical lessons I've learned in AWS.

Can a Website Run Without a Server? Understanding AWS Lambda

Anupa Supul — Thu, 09 Jul 2026 06:34:13 +0000

One day, while exploring AWS services, I came across a term that immediately caught my attention.

Serverless Computing.

My first reaction was honestly something like this:

"Wait... how can something run without a server?"

That didn't make any sense to me.

Every application has to run somewhere.

There has to be a computer.

There has to be memory.

There has to be a processor.

So how can AWS say it's serverless?

The more I learned, the more I realized something interesting.

Serverless doesn't mean there are no servers.

It simply means I don't have to manage them.

That small difference completely changed how I understood AWS Lambda.

Before Learning Lambda...

By this point in my AWS journey, I had already learned about Amazon EC2.

EC2 made perfect sense.

If I wanted to run an application, I would:

Launch an EC2 instance
Install my software
Configure everything
Keep the server running
Pay while it was running

It felt very similar to owning a computer in the cloud.

Then AWS introduced Lambda.

And suddenly...

Everything worked differently.

Let's Imagine a Small Example

Imagine I build a simple contact form for my website.

Every time someone clicks Submit, I want to:

Save their message
Send a confirmation email
Store the data in a database

Now I asked myself:

Do I really need a server running all day just to wait for someone to click one button?

Probably not.

Most of the time...

Nobody is clicking anything.

The server is simply waiting.

That doesn't feel very efficient.

So... What Is AWS Lambda?

The easiest way I understand Lambda is this:

AWS Lambda runs my code only when something happens.

That "something" is called an event.

For example:

A user uploads an image.
Someone submits a form.
A new file is added to Amazon S3.
An API request is received.
A scheduled task runs every night.

Instead of keeping a server running all day...

AWS simply waits for the event.

When it happens...

My code runs.

When it's finished...

Everything stops.

A Simple Way to Picture It

Instead of this:

24 Hours
──────────────────────────────
🖥️ Server running all day

Lambda looks more like this:

User clicks button
│
▼
AWS Lambda
│
Runs code
│
Stops

Nothing runs when nothing is happening.

The Analogy That Helped Me

Imagine hiring a photographer.

You have two options.

Option 1

Hire them for the entire day.

Even if they only take photos for one hour...

You still pay for the whole day.

That's similar to running an EC2 instance.

Option 2

Call the photographer only when you actually need photos.

They arrive.

Do the job.

Leave.

That's much closer to how Lambda works.

You only use computing resources when your code actually needs to run.

Where Can Lambda Be Used?

As I learned more, I realized Lambda appears in many real applications.

For example:

Sending emails
Resizing uploaded images
Processing payments
Running scheduled backups
Handling API requests
Automating small tasks

Most of these jobs don't need a server running 24 hours a day.

They only need to run for a few seconds.

That's exactly where Lambda shines.

I don't think one is better than the other.

They simply solve different problems.

What Changed My Perspective

Before learning AWS, I assumed every application needed a server that was always running.

Now I know that's not always true.

Sometimes all you need is a small piece of code that wakes up, does its job, and goes back to sleep.

That idea felt completely new to me.

It also made me realize how much cloud computing has evolved.

Instead of thinking about servers first...

We can simply think about solving problems.

Final Thoughts

When I first heard the word serverless, I thought AWS was trying to tell me that applications somehow ran without computers.

Now I understand it much differently.

The servers are still there.

I just don't have to think about them anymore.

And honestly...

That's one of the coolest things I've learned so far in my AWS journey.

It reminded me that cloud computing isn't just about bigger servers.

Sometimes it's about using less infrastructure to solve the same problem more efficiently.

I Finally Understood AWS Data Pipelines After Following a Single Customer Click

Anupa Supul — Wed, 08 Jul 2026 04:45:11 +0000

beginner has been there.

You memorize services like:

Amazon S3
Kinesis
Lambda
Glue
Athena
SageMaker

Then someone asks,

"How do these services actually work together?"
Silence.
The problem isn't the services.

It's that AWS documentation teaches them individually, while real companies use them together.
So let's forget the documentation for a minute.
Instead, let's follow one customer click inside an e-commerce application.
By the end, you'll understand why each AWS service exists.

Imagine This

A customer opens your shopping website.
They search for:
Wireless Headphones
A few seconds later...

The website recommends another product.
The sales dashboard updates.
Marketing learns about the search trend.

Inventory changes.

And somewhere in the background...
An AI model just became a little smarter.

How?
Let's trace the journey.

Step 1. Everything Starts with Data

Every action creates an event.
User Login
Search Product
Add to Cart
Purchase
Leave Review
That information needs somewhere to live.
Amazon DynamoDB
DynamoDB stores application data.

Examples include:

Customer profiles
Orders
Shopping carts
Product information
User sessions

Think of DynamoDB as the application's working database.
It is extremely fast because millions of users might be writing data at the same time.

Step 2. Don't Wait Until Tomorrow
Imagine Amazon waited until midnight before analyzing customer behavior.

Too late.
Modern applications react instantly.
That's where streaming begins.
Amazon Kinesis Data Streams
Kinesis continuously collects events as they happen.

Website
│
▼
Customer Events
│
▼
Amazon Kinesis

Every click...
Every purchase...
Every API request...
flows into Kinesis.
Think of it as a highway carrying millions of tiny data packets every second.

Step 3. Getting Data Where It Needs to Go

Collecting data is only half the job.
Now it needs to be delivered somewhere useful.
Amazon Data Firehose
If Kinesis is the highway,
Firehose is the delivery truck.

It automatically moves streaming data into destinations like:

Amazon S3
Amazon Redshift
Amazon OpenSearch

No servers.
No scripts.
No cron jobs.
Just continuous delivery.

Step 4. Raw Data Is Ugly

Real production data isn't clean.
It contains things like:

{
"name":"john",
"country":"usa",
"age":"25",
"status":"TRUE"
}

Another application might send:

{
"Name":"John",
"Country":"USA",
"Age":25
}

Now imagine millions of records like this.
Someone has to clean them.

AWS Lambda
Lambda automatically processes incoming data.

Typical tasks include:

Removing duplicates
Fixing formats
Validating records
Filtering bad data
Converting JSON into CSV

No servers are running.
The function executes only when data arrives.

Step 5. The Data Needs a Home

After processing, everything is stored.
Amazon S3

This is where many AWS architectures begin to make sense.
S3 is not just file storage.
It becomes the company's Data Lake.

Inside S3 you might find:

Images
Videos
CSV files
Application logs
Customer events
Machine learning datasets
Backups

Think of S3 as the central warehouse where every department stores information.

Step 6. Imagine Finding One File Among 50 Million

Storage isn't enough.

People need to know:

Where is the file?
What columns does it contain?
Which dataset owns it?

That's metadata.

AWS Glue Data Catalog

Glue Catalog doesn't store your data.

It stores information about your data.

Think of a library.

The books are the data.

The catalog tells you exactly where each book lives.

Without Glue,

your data lake becomes a giant messy folder.

Step 7. Finally... Someone Wants Answers

The business team doesn't care where the data came from.

They ask questions like:

Which products sold the most today?
Which country generated the highest revenue?
How many customers abandoned their cart?
Amazon Athena

Athena lets you query files stored in S3 using SQL.

SELECT country,
COUNT(*)
FROM sales
GROUP BY country;

No database setup.

No infrastructure.

Just SQL.

One of my favorite AWS services because it feels almost magical.

Step 8. This Is Where AI Enters

Now imagine months of customer data sitting safely inside S3.

That data becomes training material.

Amazon SageMaker AI

SageMaker helps data scientists:

Build models
Train models
Deploy models
Monitor models

Now the application can predict:

Which customer is likely to buy
Which transaction looks fraudulent
Which products should be recommended
Which inventory will run out next week

This is where raw data becomes business intelligence.

The Entire Journey
Customer

↓

DynamoDB
(Store application data)

↓

Kinesis
(Stream events)

↓

Data Firehose
(Deliver events)

↓

Lambda
(Clean and transform)

↓

Amazon S3
(Store everything)

↓

Glue Catalog
(Organize metadata)

↓

Athena
(Analyze with SQL)

↓

SageMaker
(Train AI models)

↓

Recommendations
Predictions
Dashboards
Business Insights
The Biggest Lesson I Learned

At first, AWS looked like hundreds of unrelated services.

Now I see something completely different.

Every service has one responsibility.

Service Responsibility
DynamoDB Store application data
Kinesis Capture live events
Firehose Move streaming data
Lambda Process data
S3 Store everything
Glue Organize metadata
Athena Query data
SageMaker Build AI models

Individually, they're simple.

Together, they power companies serving millions of users every day.

Final Thoughts

Learning AWS isn't about memorizing service names.

It's about understanding how data moves.

Once you can follow a single customer click through an entire system, AWS starts feeling less like a list of products and more like a complete ecosystem.

The next time someone asks,

"Why does AWS have so many services?"

You'll have a much better answer.

Because each service solves one specific problem, and together they build the systems behind the applications we use every single day.