AWS Builder Center

Builder Center

Day 5: Building a Highly Available EC2 Application with Launch Templates, Target Groups, ALB and Auto Scaling 🧠 Launch Template → VPC/Subnets → Target Group → Application Load Balancer → Auto Scaling Group 🚀🚀🚀

Day 5: Building a Highly Available EC2 Application with Launch Templates, Target Groups, ALB and Auto Scaling 🧠 Launch Template → VPC/Subnets → Target Group → Application Load Balancer → Auto Scaling Group 🚀🚀🚀

As part of my AWS Solutions Architect learning journey, in my latest class with Sir Nabeel Hasan, I learned how individual EC2 configurations can be turned into a more scalable and highly available application architecture. The main focus was understanding how these AWS services work together: Launch Template → VPC/Subnets → Target Group → Application Load Balancer → Auto Scaling Group

Muhammad Umair Ashraf

Cloud Data Engineer
As part of my AWS Solutions Architect learning journey, I learned how individual EC2 configuration can be turned into a more scalable and highly available application architecture.
The main focus was understanding how these AWS services work together:
Launch Template → VPC/Subnets → Target Group → Application Load Balancer → Auto Scaling Group
This was an important step because instead of managing individual EC2 instances manually, we started designing an architecture that can automatically distribute traffic and launch replacement instances when required.

1. Launch Template — Define How EC2 Instances Should Be Created

A Launch Template is essentially a reusable blueprint for EC2 instances.
Instead of manually configuring every new EC2 instance, we can define the configuration once and reuse it whenever an instance needs to be launched.
A launch template can contain:
  • AMI
  • Instance type
  • Key pair
  • Security groups
  • EBS volumes
  • Network configuration
  • IAM instance profile
  • User Data
  • Instance and volume tags
  • Other EC2 launch parameters
AWS recommends launch templates for Auto Scaling because they support versioning and newer EC2 capabilities. (AWS Documentation )

Example

1
2
3
4
5
6
7
8
9
10
Launch Template
│
├── AMI
├── Instance Type
├── Security Group
├── Key Pair
├── EBS
├── IAM Role
├── User Data
└── Tags
The advantage is consistency.
If Auto Scaling needs five additional EC2 instances, those instances can be created from the same launch-template configuration.

2. VPC and Subnet Architecture

The next important component is the VPC.
A typical production architecture separates resources into public and private subnets.
For example:
1
2
3
4
5
6
7
8
9
10
11
12
Internet
│
▼
Public Subnets
│
▼
Application Load Balancer
│
▼
Private Subnets
│
EC2 Instances
A public subnet can contain resources that need to receive traffic from the internet, such as an internet-facing Application Load Balancer.
Application EC2 instances can instead be placed in private subnets, where they are not directly exposed to the internet.
The exact design depends on the application, but separating the load-balancing layer from the application layer can reduce the public attack surface.

3. Creating the Target Group

After the networking foundation, we created a Target Group.
A target group defines the destinations to which the load balancer sends requests.
For an EC2-based application, the targets can be EC2 instances.
AWS describes a target group as a collection of registered targets, with routing and health-check configuration defined for that group. (AWS Documentation )

Target Group Configuration

During creation, we selected:
Target type:
1
Instances
This means the target group will route traffic to EC2 instances.

Protocol and Port

For a basic web application:
1
2
Protocol: HTTP
Port: 80
The target group then forwards HTTP traffic to the application running on the target instance.

VPC

We selected the VPC in which our application resources are running.

Protocol Version

For this lab, we used:
1
HTTP/1.1

Health Check

Health checks are extremely important.
The load balancer periodically checks whether the registered targets are responding correctly.
For example:
1
2
3
Health Check Protocol: HTTP
Health Check Port: Traffic Port
Health Check Path: /
If an instance fails the configured health checks, the load balancer can stop routing normal traffic to that unhealthy target. (AWS Documentation )
This creates an important relationship:
1
2
3
4
5
6
7
ALB
│
├── EC2 #1 → Healthy ✓
│
├── EC2 #2 → Healthy ✓
│
└── EC2 #3 → Unhealthy ✗
Traffic can be directed to the healthy targets.

4. Application Load Balancer

After creating the target group, we created an Application Load Balancer (ALB).
AWS Elastic Load Balancing provides different load-balancer types for different networking requirements, including Application Load Balancers, Network Load Balancers, and Gateway Load Balancers. (AWS Documentation )
For our web application, we selected:

Load Balancer Type

1
Application Load Balancer
An ALB operates at the application layer and is designed for HTTP/HTTPS traffic.

Internet-Facing Scheme

We selected:
1
Scheme: Internet-facing
This means the load balancer can receive requests from clients over the internet.
The architecture becomes:
1
2
3
4
5
6
7
8
9
10
11
Internet User
│
│ HTTP/HTTPS
▼
Internet-facing ALB
│
▼
Target Group
│
▼
EC2 Instances
For an internal application, we could instead use an internal load balancer.

5. IP Address Type

For our configuration, we selected:
1
IPv4
The appropriate IP address type depends on the application's networking requirements.

6. Network Mapping

We selected our existing VPC and multiple Availability Zones.
Using multiple Availability Zones is important for availability because the load balancer can operate across the selected zones.
For example:
1
2
3
4
5
6
7
8
Application Load Balancer
/ \
/ \
▼ ▼
AZ-1 AZ-2
│ │
▼ ▼
EC2 Instances EC2 Instances
AWS recommends using multiple Availability Zones when designing load-balanced applications to improve fault tolerance. (AWS Documentation )

7. Security Group

Next, we configured the security group for the load balancer.
For a simple HTTP application:
1
2
3
4
Inbound:
HTTP
Port: 80
Source: Appropriate client range
For production applications, HTTPS on port 443 is normally preferred, with a TLS certificate configured on the load balancer.
A very important security principle is:
The EC2 security group should ideally allow application traffic from the load balancer rather than exposing the application port directly to the entire internet.
For example:
1
2
3
4
5
6
7
Internet
│
▼
ALB Security Group
│
▼
EC2 Security Group

8. Listener and Default Action

We then configured the listener.
For our basic configuration:
1
2
Listener Protocol: HTTP
Listener Port: 80
The default action was:
1
Forward to Target Group
So the request flow becomes:
1
2
3
4
5
6
7
8
9
10
11
12
Client
│
│ HTTP :80
▼
Application Load Balancer
│
│ Listener
▼
Target Group
│
▼
Healthy EC2 Instance
The target group determines which registered targets are eligible to receive traffic based on its health status. (AWS Documentation )

9. Load Balancer Tags

We also added tags to the load balancer.
For example:
1
2
Key: Name
Value: Production-Web-ALB
Tags become very useful when an AWS environment contains many resources.
They can help with:
  • Resource identification
  • Cost allocation
  • Environment management
  • Automation
  • Operations

10. Review and Create

Before creating the load balancer, we reviewed:
  • Load balancer name
  • Scheme
  • IP address type
  • VPC
  • Availability Zones
  • Security group
  • Listener
  • Target group
  • Tags
After verifying the configuration, we created the Application Load Balancer.

11. Creating the Auto Scaling Group

The next major component was the Auto Scaling Group (ASG).
This is where the architecture became much more powerful.
An Auto Scaling Group manages a fleet of EC2 instances and can maintain the desired capacity while responding to scaling requirements.
We created:
1
Auto Scaling Group
Then provided a name and selected our previously created:
1
Launch Template
The launch template provides the configuration that Auto Scaling uses when it launches EC2 instances. (AWS Documentation )

12. Auto Scaling Group and VPC

During ASG configuration, we selected:
1
VPC
Then selected the appropriate subnets across Availability Zones.
For example:
1
2
3
4
5
6
7
8
9
VPC
│
├── AZ-1
│ └── Private Subnet
│ └── EC2
│
└── AZ-2
└── Private Subnet
└── EC2
This allows the application instances to be distributed across multiple Availability Zones.

13. Integrating Auto Scaling with the Load Balancer

One of the most important steps was connecting the Auto Scaling Group to the existing target group/load balancer.
The architecture now becomes:
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
Internet
│
▼
Application Load Balancer
│
▼
Target Group
/ | \
/ | \
▼ ▼ ▼
EC2 EC2 EC2
\ | /
\ | /
Auto Scaling
Group
│
▼
Launch Template
When EC2 instances are launched by the Auto Scaling Group, they can be automatically registered with the load balancer's target group. When instances are terminated, they can be deregistered. (AWS Documentation )
This means we don't need to manually register every EC2 instance.

14. Why This Architecture Is Better Than One EC2 Instance

Imagine we have only one EC2 instance:
1
2
3
4
User
│
▼
EC2
If that instance fails, the application can become unavailable.
With the architecture we learned:
1
2
3
4
5
6
7
ALB
/ \
▼ ▼
EC2 #1 EC2 #2
\ /
\ /
Auto Scaling
If demand increases, Auto Scaling can launch additional instances according to the configured scaling policy.
If an instance becomes unhealthy, the ASG can replace it depending on the configured health checks and desired capacity.

15. Pros of This Architecture

✅ High Availability

Running instances across multiple Availability Zones can reduce dependence on a single zone. (AWS Documentation )

✅ Automatic Scaling

The Auto Scaling Group can increase or decrease capacity based on configured policies.

✅ Load Distribution

The ALB distributes incoming application traffic across healthy targets.

✅ Health-Based Routing

Unhealthy targets can be removed from normal traffic routing.

✅ Consistent EC2 Configuration

The launch template provides a repeatable configuration for new instances.

✅ Better Security

EC2 instances can be kept in private subnets while the internet-facing ALB handles external traffic.

✅ Easier Operations

Instead of manually managing every EC2 instance, the combination of ALB + ASG automates much of the infrastructure lifecycle.

16. Considerations and Cons

This architecture is powerful, but it also introduces additional components and costs.

⚠️ More Complexity

Instead of managing one EC2 instance, we now manage:
1
2
3
4
5
6
7
8
9
VPC
Subnets
Security Groups
Launch Template
Target Group
ALB
Auto Scaling Group
Health Checks
Scaling Policies
Understanding how these components interact is important.

⚠️ Additional AWS Costs

ALB, EC2, EBS, NAT Gateway, data transfer, and other resources can generate charges depending on the configuration and traffic.
For learning environments, remember to delete resources that you no longer need.

⚠️ Configuration Dependencies

The following must work together correctly:
1
2
3
4
5
6
7
ALB
↓
Listener
↓
Target Group
↓
EC2
If the security groups, ports, health-check path, or application configuration are incorrect, targets can remain unhealthy.

⚠️ Scaling Doesn't Automatically Mean Cost Optimization

Auto Scaling helps match capacity to demand, but scaling policies should be designed carefully.

17. The Complete Architecture

After completing the exercise, the overall architecture looked conceptually like this:
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
Internet
│
▼
┌─────────────────────┐
│ Application Load │
│ Balancer │
│ Internet-Facing │
└──────────┬──────────┘
│
▼
┌───────────────┐
│ Target Group │
│ HTTP : 80 │
│ Health Check │
└───────┬───────┘
│
┌──────────────┴──────────────┐
│ │
▼ ▼
┌───────────┐ ┌───────────┐
│ EC2 │ │ EC2 │
│ AZ-1 │ │ AZ-2 │
└─────┬─────┘ └─────┬─────┘
│ │
└──────────────┬──────────────┘
▼
Auto Scaling Group
│
▼
Launch Template
This is the key relationship I took away from the class:
Launch Template defines the instance → Auto Scaling manages the instances → Target Group tracks the application targets → ALB receives and distributes traffic.

Key Takeaways

This class helped me understand that AWS architecture is not just about launching an EC2 instance.
It's about designing the components around that instance so the application can become:
Scalable → Available → Secure → Maintainable
The biggest learning for me was understanding how Launch Templates, Auto Scaling Groups, Target Groups, and Application Load Balancers work together as one architecture rather than treating them as separate AWS services.
I'm continuing my AWS Solutions Architect learning journey, one architecture at a time. ☁️🚀
Special thanks to Sir Nabeel Hasan for the practical explanation and hands-on learning.

Official AWS references

AWS — Create a Launch Template for an Auto Scaling Group 
AWS — Target Groups for Application Load Balancers 
AWS — Create Auto Scaling Groups Using Launch Templates 
AWS — Scaled and Load-Balanced Application Tutorial 
# aws-academy# aws-builders# aws-community# aws-community-builders# 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