DEV Community: Anupa Supul

How a Real Website Works on AWS — Complete AWS Architecture

Anupa Supul — Fri, 04 Sep 2026 09:16:17 +0000

Let’s imagine we are building a MERN web application with a React frontend, Node.js/Express backend, database, file uploads, authentication, and thousands of users.

This is what the architecture could look like.

The Big Picture

                         USERS
                           │
                           ▼
                       Route 53
                           │
                           ▼
                      CloudFront
                       /       \
                      /         \
                     ▼           ▼
                  S3             ALB
             React Frontend      │
                                 ▼
                           Auto Scaling
                                 │
                    ┌────────────┼────────────┐
                    ▼            ▼            ▼
                   EC2          EC2          EC2
                    │            │            │
                    └────────────┼────────────┘
                                 │
                    ┌────────────┼────────────┐
                    ▼            ▼            ▼
                   RDS       ElastiCache      SQS
                Database        Cache        Queue
                    │                         │
                    │                         ▼
                    │                       Worker
                    │
                    ▼
                   S3
              File Storage

At first, this diagram can look complicated.

But the important thing is that each service has a specific responsibility.

Instead of thinking about AWS as one giant system, think of it as a collection of specialized building blocks.

1. What Happens When You Open a Website?

Let's say a user types:

www.mywebsite.com

into their browser.

The request doesn't simply jump directly to an EC2 server.

It goes through several layers.

First, Route 53 helps the browser find where the domain should go. The request can then reach CloudFront, AWS's content delivery network.

CloudFront decides where the request should be served from.

If the user requests a React file such as JavaScript, CSS, or an image, CloudFront can retrieve it from Amazon S3.

If the request is something like:

GET /api/users

CloudFront can send it toward the backend through an Application Load Balancer (ALB).

So even before our backend receives the request, AWS has already handled DNS, content delivery, and traffic routing.

2. Route 53 — Finding Our Website

Amazon Route 53 is AWS's DNS service.

DNS is basically the system that translates a human-friendly domain name into a destination.

For example:

www.mywebsite.com
        ↓
     DNS lookup
        ↓
   CloudFront

Without DNS, users would need to remember an IP address instead of a domain name.

Route 53 therefore acts like the phone book of our website.

It doesn't run our frontend or backend. Its job is mainly to help users find the correct destination.

3. CloudFront — Bringing Content Closer to Users

Once Route 53 points the request toward CloudFront, CloudFront can handle the delivery of content.

CloudFront is a CDN (Content Delivery Network).

Imagine our application is hosted in a region far away from a user. Sending every image, JavaScript file, and CSS file all the way from our origin would add unnecessary latency.

CloudFront solves this by caching content at locations around the world called edge locations.

So a simplified flow looks like:

User
  │
  ▼
CloudFront Edge Location
  │
  ├── Cached content → Return immediately
  │
  └── Not cached → Ask the origin

This is especially useful for static content such as:

React JavaScript files
CSS
Images
Videos
Documents

It can also sit in front of our API and work with services such as AWS WAF.

4. React Frontend — Where Users Interact

Our React application is the part users actually see.

The frontend contains things like:

Login page
Dashboard
Profile
Products
Buttons
Forms
Images

Because a React production build consists largely of static files, we don't necessarily need an EC2 server just to serve those files.

We can store the built frontend in Amazon S3.

For example:

React Project
     │
     ▼
npm run build
     │
     ▼
HTML + CSS + JS
     │
     ▼
Amazon S3
     │
     ▼
CloudFront
     │
     ▼
Users

This is one of the first things that changed how I looked at AWS.

Not everything needs a traditional server.

5. Application Load Balancer — Sending Users to the Right Server

Now suppose the frontend calls our backend:

POST /api/login
GET /api/products
POST /api/orders

We don't want every user connecting directly to one EC2 instance.

Instead, requests can go through an Application Load Balancer (ALB).

                  ALB
                   │
        ┌──────────┼──────────┐
        ▼          ▼          ▼
       EC2        EC2        EC2

The ALB distributes incoming requests across healthy backend instances.

It also performs health checks.

For example, if one EC2 instance stops responding:

EC2 #1 → Healthy
EC2 #2 → Healthy
EC2 #3 → Unhealthy

The ALB can stop sending new requests to the unhealthy instance.

This is much more reliable than depending on a single server.

6. EC2 + Auto Scaling — Running the Backend

Our Node.js and Express backend can run on Amazon EC2.

For example:

React
  │
  ▼
API Request
  │
  ▼
ALB
  │
  ├── EC2 #1
  ├── EC2 #2
  └── EC2 #3

But what happens when traffic suddenly increases?

This is where EC2 Auto Scaling becomes important.

During normal traffic:

2 EC2 instances

During heavy traffic:

4 EC2 instances

During extremely high traffic:

6 EC2 instances

The exact numbers depend on how we configure the scaling policy.

The important idea is that Auto Scaling adjusts computing capacity based on demand, while the ALB distributes traffic between the available instances.

These two services solve different problems:

Service	Main Responsibility
ALB	Distributes requests
Auto Scaling	Adjusts number of EC2 instances
EC2	Runs our application

7. RDS — Where Our Application Data Lives

Our backend needs somewhere to store permanent data.

For example:

Users
Orders
Products
Payments
Messages
Profiles

This is where Amazon RDS can be used.

Instead of installing and maintaining a database manually on an EC2 server, RDS provides a managed relational database environment.

The backend might perform:

React
  ↓
ALB
  ↓
EC2
  ↓
RDS

For example, when a user creates an account:

User submits signup form
        ↓
React sends API request
        ↓
Backend receives request
        ↓
Backend validates data
        ↓
Backend writes user to RDS

The database should normally be placed in private subnets, rather than being directly exposed to the public internet.

8. S3 — Not Just for the Frontend

One thing that can easily confuse beginners is S3.

S3 is object storage.

It can store much more than React files.

Our application might allow users to upload:

Profile pictures
PDF files
Documents
Product images
Videos
Reports

Instead of putting these large files inside the database, we can store them in S3.

The database can then store information such as:

User ID
File name
S3 object key
Upload date

So we can think of it like:

RDS → Application data
S3  → Files / Objects

This separation makes the architecture easier to scale.

9. SQS — When Everything Doesn't Need to Happen Immediately

Some operations don't need to happen while the user is waiting.

Imagine a user uploads a video.

Our application might need to:

Save the file
Generate thumbnails
Process the video
Send an email
Update another system

Doing everything inside the original request could make the application slow.

Instead, we can use Amazon SQS.

User
 │
 ▼
Backend
 │
 ▼
SQS Queue
 │
 ▼
Worker
 │
 ├── Process file
 ├── Send email
 └── Perform background task

The backend can put a message into the queue and respond to the user.

A worker can process the job separately.

This creates decoupling between different parts of the system.

10. ElastiCache — Making Frequent Requests Faster

Not every piece of data needs to be fetched from the database every time.

Imagine thousands of users are requesting the same popular information.

Instead of repeatedly doing:

EC2 → RDS → Return data

we can cache frequently accessed data.

EC2
 │
 ▼
ElastiCache
 │
 ├── Data found → Return quickly
 │
 └── Data missing → Query RDS

ElastiCache can provide an in-memory cache using technologies such as Redis/Valkey or Memcached.

The important idea is:

Database = persistent source of data

Cache = fast temporary copy of frequently used data

Caching is an optimization, so it isn't required for every application.

11. Security — Protecting the Architecture

Now we have a working architecture, but putting everything on the internet would be a terrible idea.

Security needs to exist at multiple layers.

IAM

AWS IAM controls who or what can access AWS resources.

For example, instead of putting AWS access keys directly inside our Node.js code, we can give an EC2 instance an appropriate IAM role.

EC2
 │
 ▼
IAM Role
 │
 ▼
Allowed AWS Services

The application gets only the permissions it actually needs.

Security Groups

Security Groups act like virtual firewalls around AWS resources.

For example:

Internet
   │
   ▼
  ALB
   │
   ▼
  EC2
   │
   ▼
  RDS

We can configure rules such as:

Internet → ALB       ✅
ALB → EC2             ✅
EC2 → RDS             ✅
Internet → RDS        ❌

This is much safer than exposing the database directly to the internet.

AWS WAF

AWS WAF protects web applications by inspecting incoming HTTP/HTTPS requests.

It can help block things such as malicious or unwanted web requests based on configured rules.

A simplified security flow becomes:

Internet
   │
   ▼
  WAF
   │
   ▼
CloudFront
   │
   ▼
  ALB
   │
   ▼
  EC2

Secrets Manager

Our application also needs sensitive information such as:

Database password
API keys
Application secrets

These shouldn't simply be written directly inside source code.

AWS Secrets Manager provides a safer place to store and retrieve secrets.

12. VPC — The Network Behind Everything

All of these services don't just randomly exist on the internet.

Our backend architecture can be placed inside an Amazon VPC (Virtual Private Cloud).

A simple design could look like:

                    VPC
                     │
          ┌──────────┴──────────┐
          │                     │
    Public Subnets        Private Subnets
          │                     │
         ALB              EC2 / RDS / Cache

The public and private subnet design helps control which resources can be reached from the internet.

For a production architecture, we would normally distribute resources across multiple Availability Zones to improve availability.

13. Monitoring — Knowing What Is Happening

Building the infrastructure isn't enough.

We also need to know:

Is the application healthy?

Are servers running out of resources?

Are requests failing?

Is traffic increasing?

This is where Amazon CloudWatch becomes useful.

CloudWatch can provide metrics, logs, dashboards, and alarms.

For example:

CPU usage > threshold
        ↓
CloudWatch Alarm
        ↓
Auto Scaling / Notification

For auditing AWS API activity, CloudTrail records account and API activity.

So:

CloudWatch → Monitoring & Logs
CloudTrail  → AWS Activity & Auditing

14. HTTPS — Encrypting Communication

When users access:

https://www.mywebsite.com

their communication should be encrypted.

AWS Certificate Manager (ACM) can provide and manage TLS certificates for supported AWS services.

So instead of sending sensitive information over plain HTTP, we use HTTPS.

This is especially important for:

Login credentials
Personal information
Payments
API requests
Session information

15. Putting Everything Together

Now the individual services should make much more sense.

The complete request path can be summarized like this:

                         USER
                           │
                           ▼
                       Route 53
                           │
                           ▼
                      CloudFront
                       /       \
                      /         \
                     ▼           ▼
                  S3             ALB
             React Frontend      │
                                 ▼
                           Auto Scaling
                                 │
                    ┌────────────┼────────────┐
                    ▼            ▼            ▼
                   EC2          EC2          EC2
                    │            │            │
                    └────────────┼────────────┘
                                 │
                    ┌────────────┼────────────┐
                    ▼            ▼            ▼
                   RDS       ElastiCache      SQS
                Database        Cache        Queue
                    │                         │
                    │                         ▼
                    │                       Worker
                    │
                    ▼
                   S3
              File Storage

And around this architecture we have:

IAM
Security Groups
WAF
Secrets Manager
ACM
CloudWatch
CloudTrail
VPC

These aren't just extra AWS services added to make the diagram look impressive.

Each one solves a different operational problem.

The Most Important Thing I Learned

When I first started learning AWS, I looked at services individually.

EC2 = Server
S3 = Storage
RDS = Database
Route 53 = DNS
CloudFront = CDN

That is useful for getting started.

But real cloud architecture is about understanding how those services work together.

A real application isn't just:

User → EC2

It is closer to:

User
 ↓
DNS
 ↓
CDN
 ↓
Load Balancer
 ↓
Application Servers
 ↓
Database / Cache / Queue / Storage

And surrounding all of that are networking, security, monitoring, and scaling mechanisms.

That's when AWS started making much more sense to me.

Quick Cheat Sheet

Requirement	AWS Service
Domain / DNS	Route 53
CDN	CloudFront
React static files	S3
Backend	EC2
Load balancing	ALB
Automatic scaling	Auto Scaling
Relational database	RDS
File storage	S3
Background jobs	SQS
Caching	ElastiCache
Permissions	IAM
Network isolation	VPC
Firewall rules	Security Groups
Web protection	WAF
Secrets	Secrets Manager
HTTPS certificates	ACM
Monitoring	CloudWatch
AWS activity auditing	CloudTrail

Final Thoughts

The biggest shift in my AWS learning wasn't memorizing more services.

It was learning to ask:

“What problem is this service solving, and where does it fit in the architecture?”

Once I started thinking that way, AWS stopped feeling like a huge list of unrelated services.

Instead, it started looking like a set of building blocks.

And when those building blocks are combined properly, we can build applications that are scalable, secure, highly available, and easier to operate.

That, for me, is where learning AWS started becoming much more interesting.

Where Does My Website Actually Store Its Data? Understanding Amazon RDS

Anupa Supul — Mon, 17 Aug 2026 04:56:29 +0000

After learning how to run applications on EC2, I started thinking about something I had never really questioned before.

Where does all the data actually go?

When a user creates an account, where is that account stored?

When someone places an order, where does the order information live?

When I update my profile, how does the application remember that change the next time I log in?

As a MERN developer, I already understood the idea of a database.

I had worked with MongoDB and Mongoose.

But AWS made me think about the bigger question:

How do you run and manage a database reliably in the cloud?

That's when I started learning about Amazon RDS.

The Problem I Started With

Imagine I deploy my backend on an EC2 instance.

My application is running perfectly.

A user signs up.

Their information needs to be saved somewhere.

So my application needs a database.

The basic idea looks like this:

User
  │
  ▼
Backend
  │
  ▼
Database

At first, this seems simple.

But then I started thinking about everything that comes with managing a real database.

Someone has to:

Install the database
Configure it
Manage updates
Take backups
Monitor it
Handle failures
Protect it
Recover it when something goes wrong

That's a lot of responsibility.

And this is where managed database services become useful.

So What Is Amazon RDS?

The simplest way I understand Amazon RDS is:

Amazon RDS is a managed relational database service from AWS.

Instead of manually setting up and maintaining a relational database server yourself, AWS manages much of the underlying database infrastructure for you.

RDS supports database engines such as:

MySQL
PostgreSQL
MariaDB
Oracle
SQL Server
Amazon Aurora

So instead of spending most of my time managing the database server itself, I can focus more on my application and the data.

Running a Database Yourself vs RDS

This comparison helped me understand the difference.

If I Manage Everything Myself

Imagine I launch an EC2 instance and install MySQL manually.

EC2
 │
 ├── Operating System
 ├── MySQL
 ├── Configuration
 ├── Updates
 ├── Backups
 └── Monitoring

Now I'm responsible for all of it.

With Amazon RDS

With RDS, the architecture becomes much simpler:

Application
     │
     ▼
Amazon RDS
     │
     ▼
Relational Database

AWS handles much of the underlying infrastructure.

That doesn't mean I have no responsibility.

I still need to think about:

Database design
Queries
Users and permissions
Security
Application configuration
Cost

But AWS takes care of many infrastructure-level tasks.

A Real-World Example

Imagine I build an online store.

A customer creates an account.

Then they add a product to their cart.

Finally, they place an order.

The application needs to store information such as:

Customer
    │
    ├── Account
    │
    ├── Orders
    │
    ├── Products
    │
    └── Inventory

A relational database is useful for this kind of structured data.

The application architecture could look like:

User
  │
  ▼
Frontend
  │
  ▼
Backend API
  │
  ▼
Amazon RDS

The frontend doesn't directly communicate with the database.

The backend handles that communication.

Why Shouldn't Users Connect Directly to the Database?

This was another thing that became clear to me while learning AWS.

Imagine this:

Internet Users
      │
      ▼
   Database

That would be a terrible architecture.

You don't want random internet users connecting directly to your database.

Instead, we want:

Internet Users
      │
      ▼
   Frontend
      │
      ▼
  Backend API
      │
      ▼
  Amazon RDS

The backend controls how the application communicates with the database.

Security Groups can also be configured so the database only accepts connections from the backend resources that actually need access.

That creates a much safer architecture.

What Happens If the Database Fails?

This is where managing databases gets interesting.

Imagine my application has thousands of users.

Everything is working.

Then suddenly, the database server experiences a failure.

What happens to the application?

If I manually manage the database, I have to think about how to recover it.

RDS provides features designed to improve database availability and recovery.

One important feature is Multi-AZ deployment.

Multi-AZ

With Multi-AZ, AWS can maintain a standby database instance in another Availability Zone.

A simplified example:

                 AWS Region
                     │
          ┌──────────┴──────────┐
          │                     │
          ▼                     ▼
 Availability Zone A      Availability Zone B
          │                     │
          ▼                     ▼
     Primary RDS            Standby RDS

The application normally communicates with the primary database.

If a failure occurs, AWS can fail over to the standby.

What I found interesting here is that high availability isn't simply about having a backup file.

It's about designing the system so it can continue operating when something goes wrong.

What About Backups?

Another thing I started appreciating about managed databases is backups.

Imagine I accidentally delete important data.

Without a backup strategy, recovering it could become a nightmare.

RDS provides automated backup capabilities and supports database snapshots.

So instead of thinking:

"I'll configure backups later."

I can make backups part of the infrastructure from the beginning.

That was another important mindset shift for me.

What If My Application Gets Bigger?

Let's say my application starts with:

100 users

Then it grows to:

10,000 users

And eventually:

1,000,000 users

The database now has much more work to handle.

Eventually, database scaling becomes its own engineering problem.

Depending on the workload, there are different ways to improve database performance and capacity.

For example:

Increasing the database instance size
Using read replicas
Adding caching
Optimizing queries
Choosing the right database architecture

So scaling isn't only about EC2.

The database needs to scale too.

RDS With Everything I've Learned So Far

This was probably the most useful part for me.

I've already learned about:

Route 53
CloudFront
Elastic Load Balancer
EC2
Auto Scaling
Security Groups

Now I can finally see where the database fits into the bigger picture.

A simplified AWS architecture could look like this:

Users
  │
  ▼
Route 53
  │
  ▼
CloudFront
  │
  ▼
Load Balancer
  │
  ▼
Auto Scaling Group
  │
  ▼
EC2 Instances
  │
  ▼
Amazon RDS

Each service has a different responsibility.

Route 53 helps users find the application.

CloudFront helps deliver content efficiently.

Load Balancer distributes incoming traffic.

Auto Scaling adjusts the number of EC2 instances.

EC2 runs the application.

RDS stores the relational data.

Seeing all these pieces together made AWS feel much less like a list of services and more like an actual system.

One Thing I Finally Understood

Before learning AWS, I mostly thought about databases from the application developer's perspective.

I would:

Create Database
      ↓
Connect Backend
      ↓
Write Queries
      ↓
Done

But production systems are different.

Now I have to ask:

What happens if it fails?
        ↓
How are backups handled?
        ↓
Who can access it?
        ↓
Can it scale?
        ↓
How do I keep it available?

Those questions become increasingly important as an application grows.

The Bigger Picture

After learning EC2, ELB, Auto Scaling, and RDS, I started seeing cloud architecture differently.

It's not about memorizing:

"EC2 does this."

"RDS does that."

It's about understanding how the pieces work together.

For example:

                    Users
                      │
                      ▼
                  Route 53
                      │
                      ▼
                 CloudFront
                      │
                      ▼
              Load Balancer
                      │
                      ▼
              Auto Scaling
                 │      │
                 ▼      ▼
               EC2     EC2
                 │      │
                 └──┬───┘
                    │
                    ▼
                Amazon RDS

Now the architecture actually tells a story.

Users arrive.

Traffic is routed.

Content is delivered.

Requests are distributed.

Servers scale.

The application runs.

Data is stored.

That's when AWS started making much more sense to me.

What Changed My Perspective

Before learning AWS, I thought about databases mainly as something my application connects to.

Now I understand that the database itself is an important part of the architecture.

Questions like:

What happens if the database fails?

How do I protect it?

How do I back it up?

How will it handle more users?

How do I make it highly available?

These aren't just database questions.

They're system design questions.

And that's probably the biggest thing RDS taught me.

Final Thoughts

When I first started learning AWS, EC2 was exciting because I could actually see my application running on a cloud server.

But RDS taught me something different.

Running an application is only one part of the system.

The application also needs somewhere reliable to store the information that makes it useful.

And managing that database involves much more than simply creating a database and connecting to it.

That's where managed services like Amazon RDS become valuable.

For me, the biggest lesson was simple:

A database isn't just where data lives. It's part of the architecture that needs to be designed for security, availability, backups, and growth.

The more I learn AWS, the more I realize that building software isn't only about making the application work.

It's about making sure the entire system can keep working when real users start depending on it.

🚀 What I'm Learning Next

The more AWS services I learn, the more I realize that each one solves a different piece of the same puzzle.

EC2 taught me where applications can run.

ELB taught me how traffic can be distributed.

Auto Scaling taught me how applications can adapt to demand.

And RDS taught me where the application's important data can live reliably.

The next step is understanding how these pieces work together in a real application.

I'm continuing to document my AWS learning journey by taking the concepts I learn and explaining them in the simplest way I can.

If you're learning AWS too, I hope this made Amazon RDS a little easier to understand.

Happy learning! 🚀

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.