My YouTube Channel

Blogs by Jay Tillu

How Amazon ELB Manages Traffic with Precision

Jay Tillu's photo
Jay Tillu
·

9 min read

Table of contents

After setting up DNS with Route 53 and launching his first EC2-based website, Arjun was feeling confident—until one morning, his manager dropped a new challenge:

“Our traffic is growing. We need our app to scale better. Can you look into load balancing with AWS?”

Arjun had heard of load balancers, but this was his first time dealing with one in the cloud. So he rolled up his sleeves and started exploring what Elastic Load Balancers (ELB) in AWS were all about.

🌉 What is Amazon ELB?

Arjun discovered that Amazon Elastic Load Balancer (ELB) is like a smart traffic cop:

  • ✅ It distributes incoming traffic across multiple targets—like EC2 instances, containers, and IPs.

  • ✅ It ensures high availability and fault tolerance.

  • ✅ It works automatically—no manual scaling needed.

  • ✅ It’s elastic—grows and shrinks based on traffic.

💡 "It’s how you avoid overloading a single server," Arjun thought.

A load balancer is a server (or group of servers) that distributes incoming traffic across multiple backend servers (like EC2 instances).

🧱 ELB Components: What Arjun Had to Know

To ace his AWS SAA exam and deploy confidently, Arjun broke ELB down into key building blocks:

ConceptWhat It Means
Load BalancerThe entry point for traffic
Target GroupGroup of destinations (EC2s, containers)
ListenerListens on a port (like 80 or 443)
Health CheckMonitors instance health for routing

🔍 How It Works: A Visual in Arjun’s Head

He imagined:

  • 3 EC2 instances running his web app.

  • 1 Elastic Load Balancer (ELB) in front.

  • 3 users accessing the site.

🧭 The load balancer receives all traffic and sends:

  • User 1 → EC2 Instance A

  • User 2 → EC2 Instance B

  • User 3 → EC2 Instance C

The users don’t know where they were routed. All they see is:
https://app.greatstartup.com

🛠️ Types of Elastic Load Balancers in AWS

Arjun was surprised to learn there are four types of load balancers in AWS.

1. 🕰️ Classic Load Balancer (CLB) – Legacy (2009)

  • Supports HTTP, HTTPS, TCP, and SSL.

  • Basic, older generation.

  • Deprecated in the console (not recommended for new use).

2. Application Load Balancer (ALB) - Layer 7

“Perfect for web apps!”

  • Introduced in 2016.

  • Works at Layer 7 (HTTP/HTTPS).

  • Supports WebSocket, host-based routing, path-based routing.

  • Smart routing: path-based (/api, /images) or host-based (api.example.com)

  • Works with containers (ECS, EKS)

📘 Arjun used this to route traffic between frontend.example.com and api.example.com.

3. Network Load Balancer (NLB) - Layer 4

“For extreme performance!”

  • Introduced in 2017.

  • Works at Layer 4 (TCP, TLS, UDP).

  • Extremely high performance with low latency. Handles millions of requests/sec

  • Ideal for real-time apps, gaming, or millions of connections.

📘 Arjun noted: “This is what fintech companies use for high-speed systems.”

4. Gateway Load Balancer (GWLB)

“For firewalls and inspection tools.”

  • Introduced in 2020.

  • Operates at Layer 3.

  • Works with third-party security appliances

  • Routes entire network traffic

  • Used to deploy third-party firewalls, deep packet inspection tools, etc.

  • Rare in everyday web apps—but crucial for advanced networking setups

📌 Tip Arjun noted:

  • ALB is best for web apps.

  • NLB is best for raw speed and connections.

  • GWLB is best for network-level traffic tools.

🔒 Security and Access Control

Arjun had to make sure only allowed traffic hit the backend servers.

📶 Load Balancer’s Security Group:

  • Inbound Rule:

    • Allow HTTP (80) or HTTPS (443)

    • Source: 0.0.0.0/0 (i.e., anywhere)

🔐 EC2 Instance’s Security Group:

  • Inbound Rule:

    • Allow HTTP (80)

    • Source: The security group of the load balancer, not the internet!

💡 “This way, only the load balancer can talk to the EC2s—keeping them protected.”

💓 Health Checks: The Secret Superpower

Arjun loved that ELB could check which EC2 instances were healthy—and route traffic only to those.

🩺 How It Works:

  • You define a protocol (e.g., HTTP)

  • A port (e.g., 4567)

  • A path (e.g., /health)

If an instance responds with a 200 OK, it’s considered healthy.

If it fails to respond correctly?
Route 53 stops sending traffic to it.

📘 “This is how we keep our apps online 24/7,” Arjun noted.

🔄 Load Balancer + Route 53 = Magic

Arjun recalled his DNS setup. Now he could connect his Route 53 domain to the ELB.

Example:

  • Route 53 A-record for app.greatstartup.com → points to ELB

  • ELB distributes traffic to healthy EC2s

This setup gave him reliability, scalability, and security.

🌐 Public vs Private Load Balancers

As Arjun was setting up his Application Load Balancer (ALB), he noticed something in the AWS console:

"Do you want this load balancer to be public or internal?"

He paused. “Wait… aren’t all load balancers just public-facing?”
Turns out, they’re not.

🧭 The Difference: Visibility Scope

TypeWhat it MeansWho Can Access It
Public (External)The load balancer has a public IPAnyone on the internet
Private (Internal)The load balancer has no public IPOnly resources inside the same VPC

🧍‍♂️💻 Public Load Balancer – For Real Users Like You and Me

Arjun imagined this like a storefront on a busy street.

Anyone can walk in, browse, and interact.

If your app or API needs to be accessed from outside AWS, like by customers or users on their phones or laptops—then you need a public load balancer.

📌 Use Case Examples:

These load balancers are internet-facing and route traffic to EC2 instances or containers in the backend.

🔐🏢 Private Load Balancer – For Internal Traffic Only

Then Arjun clicked on the private/internal option and learned it’s like a VIP entrance behind the building—only employees with access can use it.

These load balancers are not exposed to the internet. They are only reachable within your VPC (Virtual Private Cloud).

📌 Use Case Examples:

  • Internal admin dashboards

  • Backend microservices that talk to each other

  • Internal APIs used by Lambda functions or ECS

  • Databases and internal reporting tools

If Arjun set up an internal dashboard at admin.arjunapp.internal, he'd use a private ALB—so only EC2 instances or developers inside the VPC can access it.

🎯 Why This Matters

Arjun realized this feature was critical for architecture design:

  • ✅ Public ELB keeps things open to the world

  • ✅ Private ELB protects sensitive services behind a firewall

  • ✅ You can use both together in modern microservice environments

For example:

  • A public ALB receives traffic from the internet

  • It routes requests to internal services behind a private ALB

  • Each layer is secured and modular

💡 “It’s like building a public office in front, and a restricted R&D lab in the back.”

✅ SSL Termination – Let ELB Handle HTTPS for You

Arjun knew that modern websites must use HTTPS to keep data secure. But setting up SSL certificates on every EC2 instance? That sounded like a nightmare.

Then he discovered that ELB can do SSL termination.

🔐 What it means:
ELB handles the HTTPS encryption and decryption at the load balancer level, so backend servers can stick with regular HTTP.

Even better, ELB integrates with AWS Certificate Manager (ACM), so:

  • He could request free SSL certificates

  • Install them with just a few clicks

  • ELB would manage renewal automatically

📘 “No need to manually install or renew certificates on each server. Huge time saver!”

📈 Auto Scaling Integration – Making Your App Truly Elastic

After setting up his Application Load Balancer (ALB), Arjun noticed something important:

“Okay, my traffic is now spread across multiple EC2 instances… but what if traffic suddenly spikes? Or drops?”

That’s when he discovered Auto Scaling Groups (ASGs)—a perfect partner for ELB.

🤝 What Happens When You Combine ELB + Auto Scaling?

Think of it like this:

  • Auto Scaling controls how many EC2 instances are running based on the load.

  • ELB controls where the traffic goes.

Together, they make a self-adjusting system that can grow or shrink based on demand—automatically.

🔄 A Real Example: Arjun’s App on a Busy Day

Let’s say Arjun usually runs 2 EC2 instances behind his load balancer.

Then one day, traffic triples because his app goes viral.

Here’s what happens:

  1. CloudWatch alarms detect the rising CPU or request count.

  2. Auto Scaling launches 2 more EC2 instances to handle the spike.

  3. ELB automatically detects the new instances, checks they’re healthy, and starts sending traffic to them.

  4. Arjun doesn’t lift a finger—the system adapts automatically.

Later that night, traffic dies down.

  1. Auto Scaling terminates the extra instances to save costs.

  2. ELB removes them from routing.

💡 Arjun realized:

“This means I can handle a spike to 100,000 users—or just 10—and I’ll only pay for what I use.”

🔄 Integration with Other AWS Services

Arjun noted how deeply ELB connects with the AWS ecosystem:

  • Route 53 – for DNS and global routing

  • ACM – for SSL certificates

  • CloudWatch – for monitoring

  • WAF – for web application firewall protection

  • ECS / EKS – for containerized apps

  • Lambda – for serverless backend targets

It was clear: ELB isn’t just a standalone tool—it’s a central piece of cloud architecture.

🎉 Wrapping It All Up

Arjun started with a single EC2 instance and a dream. But as his app grew, so did his understanding of the cloud.

With Elastic Load Balancing, he learned to:

  • Scale his traffic gracefully

  • Handle failures automatically

  • Secure his app with HTTPS

  • Route users smartly and safely

And best of all, he did it without managing a single load balancer server himself.

📘 Final Thoughts

If you’re building any kind of web application on AWS, Elastic Load Balancing is a must. It’s secure, scalable, integrated, and battle-tested.

Whether you're handling 10 users or 10 million, ELB will route the traffic so your backend can breathe.

More AWS SAA Articles

Follow me for more such content