AWS Builder Center

Builder Center

AWS Load Balancer + Auto Scaling: How AWS Keeps Applications Available When Traffic Changes

AWS Load Balancer + Auto Scaling: How AWS Keeps Applications Available When Traffic Changes

A beginner-friendly guide to combining Elastic Load Balancing and EC2 Auto Scaling to build applications that can handle changing traffic, distribute requests, and automatically replace unhealthy instances.

⚖️ AWS Load Balancer + Auto Scaling: How AWS Keeps Applications Available When Traffic Changes

After learning about EC2, I started thinking about a real-world problem:
What happens when my application suddenly gets 10x more traffic?
If I have only one EC2 instance, everything depends on that one server.
1
2
3
4
5
6
🌍 Users
│
▼
┌──────┐
│ EC2 │
└──────┘
What if:
  • Traffic suddenly increases?
  • The server becomes overloaded?
  • The instance fails?
  • I need to deploy across multiple Availability Zones?
A single EC2 instance isn't a very resilient architecture.
This is where two important AWS concepts come together:
Elastic Load Balancing (ELB)
EC2 Auto Scaling
My new mental model is:
1
2
3
4
5
6
7
8
9
10
11
12
13
14
🌍 Users
│
▼
┌─────────────────┐
│ Load Balancer │
└────────┬────────┘
│
┌────────┼────────┐
▼ ▼ ▼
EC2 EC2 EC2
│ │ │
└────────┴────────┘
│
Auto Scaling
This is one of the first AWS architectures that made "high availability" feel practical to me.

🧠 What Is a Load Balancer?

A load balancer distributes incoming application traffic across multiple targets.
Instead of users connecting directly to one EC2 instance:
1
2
3
4
5
Users
│
├──────► EC2
├──────► EC2
└──────► EC2
users connect to the load balancer:
1
2
3
4
5
6
7
🌍 Users
│
▼
Load Balancer
/ | \
▼ ▼ ▼
EC2 EC2 EC2
The load balancer becomes the entry point for the application.

⚖️ Why Do I Need Load Balancing?

Imagine my application receives 3,000 requests.
If one server receives everything:
1
2
3
4
5
6
3,000 Requests
│
▼
EC2
│
🚨
The instance could become overloaded.
With multiple instances:
1
2
3
4
5
6
7
8
3,000 Requests
│
▼
Load Balancer
/ | \
▼ ▼ ▼
EC2 EC2 EC2
1000 1000 1000
The traffic can be distributed across the available targets.
This improves the application's ability to handle traffic.

🏥 Health Checks

One of the most useful features of load balancing is health checking.
Imagine I have:
1
2
3
4
5
Load Balancer
/ | \
▼ ▼ ▼
EC2-A EC2-B EC2-C
✅ ❌ ✅
If EC2-B becomes unhealthy, the load balancer can stop sending new traffic to that unhealthy target, depending on the configured health-check behavior.
Instead of continuing to send users to a broken server:
1
❌ EC2-B
traffic can continue going to healthy targets.
This gives me a much better understanding of what availability means in practice.

🚀 What Is EC2 Auto Scaling?

Now comes the second part.
A load balancer distributes traffic.
But who decides how many EC2 instances I need?
That's where an EC2 Auto Scaling group comes in.
An Auto Scaling group can maintain a desired number of EC2 instances and adjust capacity according to configured policies.
For example:
1
2
3
Minimum: 2
Desired: 2
Maximum: 6
The application might normally run:
1
2
EC2-A
EC2-B
During increased demand, Auto Scaling can add instances:
1
2
3
4
EC2-A
EC2-B
EC2-C
EC2-D
When demand decreases, it can scale back according to the configured policy.

📈 Scaling With Traffic

Imagine my application normally receives:
1
100 requests/minute
Two EC2 instances might be enough.
Then traffic increases:
1
2
3
4
5
6
7
100
↓
500
↓
1,000
↓
5,000 requests/minute
I don't want to manually log into AWS and launch servers every time.
Instead:
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
Traffic increases
│
▼
CloudWatch metrics
│
▼
Auto Scaling policy
│
▼
More EC2 instances
│
▼
Load Balancer
│
▼
Traffic distributed
This is where monitoring, scaling, and load balancing start working together.

🧩 The Complete Architecture

Now let's combine everything:
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
🌍 Users
│
▼
┌─────────────────┐
│ Load Balancer │
└────────┬────────┘
│
┌─────────────┼─────────────┐
▼ ▼ ▼
┌───────┐ ┌───────┐ ┌───────┐
│ EC2-A │ │ EC2-B │ │ EC2-C │
└───────┘ └───────┘ └───────┘
\ | /
\ | /
└──── Auto Scaling ───┘
The key responsibilities are different:
1
2
3
4
5
6
7
8
9
10
11
Load Balancer
→ Distributes traffic

Auto Scaling
→ Adjusts capacity

EC2
→ Runs the application

CloudWatch
→ Provides monitoring signals

🌍 Why Multiple Availability Zones Matter

Here's another important AWS concept.
Suppose all my instances are in one Availability Zone:
1
2
3
4
5
6
7
Region
│
└── Availability Zone A
│
EC2-A
EC2-B
EC2-C
If that Availability Zone experiences a problem, all my application instances could be affected.
A more resilient architecture can spread instances across multiple Availability Zones:
1
2
3
4
5
6
7
8
Load Balancer
/ \
/ \
▼ ▼
Availability Zone A Availability Zone B
│ │
EC2-A EC2-B
EC2-C EC2-D
Now my application isn't dependent on a single Availability Zone.
This is one of the most important ideas behind highly available AWS architectures.

🔄 What Happens When an EC2 Instance Fails?

Let's imagine:
1
2
3
4
5
Load Balancer
│
├── EC2-A ✅
├── EC2-B ❌
└── EC2-C ✅
The load balancer's health checks can identify that EC2-B isn't healthy.
The Auto Scaling group can also replace an unhealthy instance according to its configuration.
Eventually:
1
2
3
4
5
6
7
8
9
Old:
EC2-A ✅
EC2-B ❌
EC2-C ✅

New:
EC2-A ✅
EC2-C ✅
EC2-D ✅
The important point is that the application isn't designed around one permanent server.
Instead, the architecture expects instances to be replaceable.

🧠 "Pets vs Cattle" Thinking

This architecture introduced me to an interesting infrastructure mindset.

Traditional thinking

I might think:
"This particular EC2 server is important."
If that server fails, I worry.

Scalable cloud thinking

Instead:
"Any healthy EC2 instance should be able to serve the application."
So:
1
2
3
EC2-A
EC2-B
EC2-C
are interchangeable application capacity.
If one disappears:
1
2
3
EC2-A
EC2-C
EC2-D
the application can continue.
This is a powerful change in how I think about cloud infrastructure.

📊 Where Does CloudWatch Fit?

I learned about CloudWatch in my previous article.
Now I can see why monitoring matters.
The architecture becomes:
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
Users
│
▼
Load Balancer
│
┌─────────┼─────────┐
▼ ▼ ▼
EC2 EC2 EC2
│ │ │
└─────────┼─────────┘
│
CloudWatch
│
▼
Scaling Policy
│
▼
Auto Scaling
CloudWatch provides metrics that can be used by scaling policies.
For example, a scaling policy could respond to CPU utilization or other application-relevant metrics.

📉 Scaling Back Down

Auto Scaling isn't only about adding servers.
If traffic decreases, I don't necessarily want unnecessary capacity running forever.
For example:
1
2
3
4
5
6
7
Peak traffic

EC2-A
EC2-B
EC2-C
EC2-D
EC2-E
Later:
1
2
3
4
Normal traffic

EC2-A
EC2-B
Scaling policies can reduce capacity when demand falls.
This can help avoid paying for more compute capacity than the application needs.
Of course, scaling policies should be designed carefully so the application doesn't scale too aggressively.

🛠️ What Is a Launch Template?

Auto Scaling needs to know how to create new EC2 instances.
A Launch Template can define configuration used when launching instances.
For example:
1
2
3
4
5
6
7
Launch Template
│
├── AMI
├── Instance type
├── Key pair
├── Security Group
└── Other configuration
Then Auto Scaling can use that template when it needs to launch additional instances.
This means I don't have to manually configure every new server.

🔐 Security Still Matters

Adding a load balancer doesn't remove the need for security.
A common pattern is:
1
2
3
4
5
6
7
Internet
│
▼
Load Balancer
│
▼
EC2
The Security Groups can be designed so that:
  • The load balancer accepts the required client traffic.
  • The EC2 instances accept application traffic from the load balancer.
  • Administrative access is restricted separately.
This creates a cleaner security boundary.

⚠️ Common Beginner Mistakes

❌ Mistake 1: Thinking Auto Scaling means unlimited scaling

It doesn't.
Capacity is controlled by limits and scaling policies.
For example:
1
2
Minimum = 2
Maximum = 6
doesn't mean AWS can automatically create 100 instances.

❌ Mistake 2: Running everything in one Availability Zone

This can create a single point of failure.
For highly available architectures, spreading resources across multiple Availability Zones is an important design consideration.

❌ Mistake 3: Thinking a load balancer automatically fixes application bugs

A load balancer distributes traffic.
It doesn't fix broken application code.

❌ Mistake 4: Forgetting health checks

If unhealthy instances remain in service, users can still experience failures.
Health checks are an important part of resilient architectures.

❌ Mistake 5: Scaling based on the wrong metric

CPU isn't always the best indicator of application demand.
Depending on the workload, other metrics such as request count or application latency may be more useful.
The correct metric depends on the application.

🏗️ My Complete AWS Architecture So Far

After learning EC2, EBS, CloudWatch, and now Load Balancing + Auto Scaling, I can visualize a more realistic application:
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
🌍 Internet
│
▼
┌─────────────────┐
│ Load Balancer │
└────────┬────────┘
│
┌───────────────┼───────────────┐
▼ ▼ ▼
┌─────────┐ ┌─────────┐ ┌─────────┐
│ EC2 │ │ EC2 │ │ EC2 │
│ AZ-A │ │ AZ-A │ │ AZ-B │
└────┬────┘ └────┬────┘ └────┬────┘
│ │ │
└───────────────┼───────────────┘
│
Auto Scaling
│
CloudWatch
Now this feels much closer to a production-style architecture.

🎯 What I Learned

This topic connected several AWS services and concepts together.

EC2

Provides compute.

EBS

Provides persistent block storage.

Load Balancer

Distributes incoming traffic.

Auto Scaling

Adjusts the number of EC2 instances.

CloudWatch

Provides monitoring metrics and alarms that can support scaling decisions.

Availability Zones

Help distribute resources for resilience.
The architecture becomes:
1
2
3
4
5
6
7
8
9
10
11
12
13
14
Users
│
▼
Load Balancer
│
┌──────┼──────┐
▼ ▼ ▼
EC2 EC2 EC2
│ │ │
└──────┼──────┘
│
Auto Scaling
│
CloudWatch

🚀 Final Takeaway

The biggest lesson for me was:
A scalable application shouldn't depend on one server.
Instead of thinking:
1
User → EC2
I'm now thinking:
1
2
3
4
5
6
7
8
9
User
↓
Load Balancer
↓
Healthy EC2 instances
↓
Auto Scaling
↓
CloudWatch
This architecture can help an application handle changing demand and recover from individual instance failures.
I'm starting to see AWS less as a collection of separate services and more as a set of building blocks that work together.
Build it. Monitor it. Scale it. Make it resilient. 🚀☁️
# elastic-load-balancing# amazon-ec2
Any opinions in this article are those of the individual author and may not reflect the opinions of AWS.
Enjoyed reading this content? Let the author know!

Your likes, comments, shares, and saves help creators reach more builders.

Loading recommendations

Loading article