AWS ALB and Auto Scaling Finally Clicked
What I learned from AWS SimuLearn about ALB, Target Groups, Health Checks, Auto Scaling, Security Groups, and Multi-AZ design for highly available applications.
I recently completed the AWS SimuLearn: Auto-Healing and Scaling Applications lab, and this was one of those labs where several AWS concepts finally connected together for me.
👉 Lab: https://skillbuilder.aws/learn/ND78HW21FD/aws-simulearn-autohealing-and-scaling-applications/1C6SZU2GKX?parentId=1UQVR262ZB
Before this lab, I understood the individual services:
- Application Load Balancer distributes traffic.
- Target Groups contain application targets.
- Auto Scaling Groups create and remove EC2 instances.
- Security Groups control network traffic.
- Multiple Availability Zones improve availability.
But I still did not have a clear picture of how all of these pieces work together as one architecture.
After completing the lab, the whole request flow became much easier to visualize.
1. The Application Load Balancer is the front door
The Application Load Balancer (ALB) is the component that receives incoming application traffic and distributes requests to healthy backend targets.
Instead of exposing every EC2 instance directly to the internet, users communicate with the ALB.
My mental model is:
1
2
3
4
5
6
7
Internet
|
v
Application Load Balancer
|
v
Web ServersThis also creates a cleaner security boundary.
The ALB can have its own Security Group that accepts traffic from users, while the EC2 instances use another Security Group that only accepts traffic coming from the ALB.
For example:
1
2
3
4
5
6
7
8
9
10
11
Internet
|
v
ALB Security Group
|
v
Application Load Balancer
|
| allowed by Web Server SG
v
EC2 InstancesThis was a good reminder that Security Groups can be used not only with IP addresses, but also by referencing another Security Group.
2. The Target Group is the connection between the ALB and the application
One concept that became much clearer during the lab was the Target Group.
I now think of it as the list of backend targets that the Load Balancer is allowed to send requests to.
The flow becomes:
1
2
3
4
5
6
7
8
9
10
11
Client
|
v
ALB
|
v
Target Group
|
+---- EC2-A
|
+---- EC2-BBut the Load Balancer should not blindly send traffic to every registered EC2 instance.
It needs to know whether each target is actually healthy.
That is where Health Checks become important.
3. Health Checks decide which servers should receive traffic
The ALB periodically checks the health of the targets inside the Target Group.
Instead of simply checking whether an EC2 instance exists, it can send a request to an application endpoint such as:
1
/healthIf a target repeatedly fails the health check, the Load Balancer stops routing new traffic to that target.
Conceptually:
1
2
3
4
5
6
7
8
9
ALB
|
| Health Check
v
/health
|
+---- Healthy EC2 → receives traffic
|
+---- Unhealthy EC2 → no new trafficThe health check can also be configured with values such as:
1
2
3
4
Interval
Timeout
Healthy threshold
Unhealthy thresholdThis made me realize that high availability is not simply about running multiple servers.
The system also needs a way to continuously determine which servers are safe to use.
One thing I would keep in mind in a real application is that the
/health endpoint should be designed carefully.A lightweight health check is usually better than performing too many expensive dependency checks on every request.
4. Auto Scaling Groups manage the EC2 fleet
The next part that clicked for me was the role of the Auto Scaling Group (ASG).
The ASG controls how many EC2 instances should be running.
For example:
1
2
3
Min capacity: 2
Desired capacity: 2
Max capacity: 6If a scaling policy determines that more capacity is needed, the ASG can launch additional EC2 instances.
If less capacity is needed, it can terminate instances and scale back in.
What made this especially useful is that the ASG can span subnets across multiple Availability Zones.
For example:
1
2
3
4
5
6
7
8
9
10
Availability Zone A Availability Zone B
Private Subnet A Private Subnet B
| |
EC2-A EC2-B
\ /
\ /
---- Target Group ----
|
ALBThis gives the application more resilience than placing every server inside a single Availability Zone.
5. The part I liked most: Auto Scaling and Target Groups work together
This was probably the biggest “aha!” moment for me.
An Auto Scaling Group can be attached to the Target Group used by the Load Balancer.
When the ASG launches a new EC2 instance, that instance can automatically become registered with the Target Group.
The ALB then performs health checks before routing traffic to it.
So the process looks like:
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
Scaling policy triggers
|
v
Auto Scaling Group
|
| launches
v
New EC2 Instance
|
| registers
v
Target Group
|
| health check
v
Healthy
|
v
ALB starts sending trafficThat connection between Auto Scaling → Target Group → Health Check → Load Balancer is what made the architecture finally make sense to me.
The complete traffic flow I now picture
After this lab, this is the architecture I visualize:
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
Users
|
v
Internet-facing ALB
|
| ALB Security Group
v
Target Group
|
| only healthy targets
|
+----------------------+
| |
v v
EC2-A EC2-B
AZ-A AZ-B
^ ^
| |
+---- Auto Scaling ----+
GroupAnd the request flow is:
1
2
3
4
5
6
7
Client
↓
Application Load Balancer
↓
Target Group
↓
Healthy EC2 instanceWhile in the background:
1
2
3
4
5
6
7
Health Checks → determine healthy targets
Auto Scaling → adjusts EC2 capacity
Multiple AZs → reduce the impact of an AZ failure
Security Groups → control which components can communicateThe mental model I'll keep
Before the lab, I thought about these AWS services separately.
After the lab, I now see them as one system:
ALB = receives and distributes traffic
Target Group = tells the ALB where traffic can go
Health Check = tells the ALB which targets are healthy
Auto Scaling Group = manages how many EC2 instances should exist
Multi-AZ = improves availability
Security Groups = control the allowed network paths
And together:
1
2
3
4
5
6
7
8
9
10
11
Users
↓
ALB
↓
Target Group
↓
Healthy EC2 Instances
↑
Auto Scaling Group
↓
Multiple Availability ZonesThe biggest takeaway for me was that high availability on AWS is not one service or one checkbox.
It comes from multiple components working together: traffic distribution, health monitoring, automatic capacity management, network security, and infrastructure spread across Availability Zones.
Another useful hands-on lesson from my AWS learning journey.
If you learned this architecture before, which part took the longest to click for you — Load Balancers, Target Groups, Health Checks, or Auto Scaling?
#AWS #AWSCloud #AutoScaling #ApplicationLoadBalancer #EC2 #HighAvailability #AWSSkillBuilder #AWSSimuLearn #CloudComputing #LearningInPublic
Enjoyed reading this content? Let the author know!
Your likes, comments, shares, and saves help creators reach more builders.
Loading recommendations
Loading article