Create an Application Load Balancer with an Auto Scaling Group – SAP-C02 Study Guide

Purpose of This Lesson

This hands-on lesson demonstrates how to place an Application Load Balancer (ALB) in front of an Amazon EC2 Auto Scaling group spanning multiple Availability Zones. The configuration provides a single DNS endpoint for clients while distributing HTTP traffic across healthy EC2 instances.

The key operational pattern is dynamic target registration: instances launched or replaced by the Auto Scaling group are automatically registered with the ALB target group instead of being added manually.

Key Concepts

Application Load Balancer architecture

An ALB is a Layer 7 load balancer that accepts client connections through listeners and forwards requests to registered targets through target groups.

The request flow is:

1. A client resolves and connects to the ALB DNS name.
2. An ALB listener accepts traffic on a configured protocol and port.
3. A listener rule forwards the request to a target group.
4. The target group distributes traffic to healthy registered targets.

In this example:

• The ALB is internet-facing.
• The ALB is deployed across two Availability Zones.
• The listener uses HTTP on port 80.
• The target group contains EC2 instances.
• The target group forwards HTTP traffic to port 80 on the instances.

Target groups

A target group defines the destinations to which the load balancer forwards traffic. Depending on the load balancer and design, targets can include:

• EC2 instances
• IP addresses
• Lambda functions
• Another Application Load Balancer in supported configurations

For this architecture, the target type is Instances because the ALB forwards requests to EC2 instances managed by an Auto Scaling group.

A target group also defines important traffic and health-check settings, including:

• Target protocol and port
• IP address type, such as IPv4
• Health-check protocol
• Health-check path
• Health-check port
• Healthy and unhealthy thresholds
• Timeout and interval behavior

The health check in this example uses HTTP on port 80 and the root path, /. A custom endpoint such as /health is often preferable in production because it can verify application dependencies more accurately.

Dynamic registration through Auto Scaling

Do not manually add the current EC2 instances to the target group when the instances are managed by an Auto Scaling group. Manual registration creates a static configuration that can become stale when instances are:

• Replaced after a failure
• Terminated during scale-in
• Launched during scale-out
• Recreated during an instance refresh

Instead, associate the target group with the Auto Scaling group. The Auto Scaling group then registers newly launched instances and removes terminated instances automatically.

This integration is essential for resilient, elastic architectures.

Listener and routing

The listener is the ALB’s entry point. It specifies the protocol and port on which the load balancer accepts connections. A listener action then determines what happens to each request.

The basic rule in this example is:

HTTP :80 → forward to target group TG-1

In more advanced designs, ALB listener rules can route based on hostnames, URL paths, HTTP headers, query strings, or source conditions.

Health checks and target state

The ALB sends health-check requests to each registered target. A target is eligible to receive traffic only after it passes the configured health checks.

A newly registered target may initially appear in the initial state. This does not necessarily indicate failure; it means the load balancer has not completed enough checks to determine the target’s health.

If a target remains unhealthy, investigate:

• Whether the web server is running
• Whether the health-check path returns a successful response
• Whether the target is listening on the expected port
• Whether the instance security group allows traffic from the ALB security group
• Whether network ACLs or routing rules block the request
• Whether the application starts more slowly than the health-check timing allows

Security group design

The ALB and the EC2 instances should normally use separate security groups:

• ALB security group: permits client traffic, such as HTTP or HTTPS, from approved sources.
• Instance security group: permits application traffic only from the ALB security group.

For the example’s HTTP health checks, the instance security group must allow inbound TCP port 80 from the ALB security group. Allowing port 80 from 0.0.0.0/0 on the instances would bypass the intended network boundary and is generally less secure.

Internet-facing versus internal ALB

An internet-facing ALB has publicly reachable connectivity and is appropriate when clients access the application from the internet.

An internal ALB is reachable only through private network connectivity, such as within a VPC or through connected networks. It is appropriate for internal application tiers, service-to-service traffic, or private corporate applications.

The choice does not determine whether the registered targets are public or private. In a common design, an internet-facing ALB is placed in public subnets while its EC2 targets run in private subnets.

Architecture Decision Guide

Decision	Use this option when	Notes
Target type: Instances	EC2 instances are managed by an Auto Scaling group	Associate the target group with the Auto Scaling group for automatic registration and deregistration
Target type: IP addresses	Traffic must be sent directly to specific IP endpoints or workloads not registered as instances	Useful for hybrid or container-oriented designs, depending on the deployment model
Target type: Lambda functions	An ALB must invoke Lambda-based application logic	Supported by Application Load Balancers, not every load balancer type
Internet-facing ALB	Clients connect from the internet	Requires appropriate public subnet and security-group design
Internal ALB	Traffic is private to a VPC or connected network	Common for internal service tiers
HTTP listener	The application accepts unencrypted HTTP traffic or TLS is terminated elsewhere	For production internet traffic, HTTPS is usually preferred
HTTPS listener	The ALB should terminate TLS	Requires an appropriate certificate and may forward HTTP or HTTPS to targets
Default health-check path /	The root page reliably represents application health	A dedicated health endpoint is often more precise
Multi-AZ deployment	High availability and distribution across failure domains are required	The ALB should have subnets in multiple Availability Zones, and the Auto Scaling group should use corresponding zones

Exam-Relevant Takeaways

• An ALB uses listeners to accept connections and target groups to identify backend destinations.
• A target group is not the same as an Auto Scaling group. The Auto Scaling group manages instance capacity; the target group determines where the load balancer sends requests.
• Associate the target group with the Auto Scaling group so instances are registered and deregistered automatically.
• ALB health checks determine which targets can receive traffic. A running EC2 instance is not necessarily a healthy application target.
• Health-check protocol, port, and path must match an endpoint that the application serves successfully.
• The target instance security group must allow the health-check and application traffic from the ALB security group.
• Deploying the ALB and Auto Scaling group across multiple Availability Zones improves availability and distributes traffic across failure domains.
• The ALB DNS name is the client-facing endpoint in this configuration. Clients do not need to connect directly to individual EC2 instance addresses.
• An internet-facing load balancer and public EC2 instances are separate design decisions. Backend instances can remain private.
• ALB target registration can be dynamic when integrated with Auto Scaling, preventing stale instance membership during scaling and replacement events.

Common Exam Traps

• Manually registering Auto Scaling instances: This fails to account for future scale-out, scale-in, or instance replacement. Attach the target group to the Auto Scaling group instead.
• Confusing listener ports with target ports: The ALB may listen on one port and forward to a different target port. Both sides must be configured intentionally.
• Assuming instance health equals application health: EC2 status checks can pass while the web application or required endpoint is unavailable.
• Forgetting the target security group: The ALB must be able to reach the target port, and the target security group should permit traffic from the ALB security group.
• Testing before targets become healthy: Newly registered targets may remain in initial status while health checks are being evaluated.
• Using the wrong load balancer type: ALB is suited to HTTP/HTTPS Layer 7 routing. Network Load Balancer is designed for high-performance Layer 4 TCP/UDP/TLS use cases.
• Assuming the ALB’s public DNS name is a fixed IP address: Clients should use the DNS name. Do not design around fixed ALB node IP addresses.
• Placing an internet-facing ALB in only one Availability Zone: This introduces an unnecessary failure-domain dependency.

Real-World Engineer Notes

• Prefer HTTPS for user-facing applications and use AWS Certificate Manager certificates on the ALB where appropriate.
• Use a dedicated health endpoint that returns success only when the application is ready to serve requests. Decide carefully whether the endpoint should validate downstream dependencies such as databases.
• Configure the instance security group to accept application traffic only from the ALB security group, not directly from the internet.
• Ensure the Auto Scaling group’s health-check behavior is integrated with the load balancer when the application’s serving status should influence instance replacement.
• Confirm that the ALB subnets have suitable routing and that the target instances have return paths for the load balancer’s traffic.
• ALB access logs, CloudWatch metrics, and target health information are useful for diagnosing uneven traffic, failed health checks, elevated latency, and backend errors.
• A simple refresh test may appear to alternate between instances, but request distribution is not a strict guarantee that every successive request goes to a different target. Load-balancing behavior depends on connections, algorithms, and client behavior.
• If the application maintains session state locally, evaluate stateless application design or configure ALB stickiness deliberately. Stickiness can reduce distribution flexibility and should not replace a shared session store when broad elasticity is required.

Quick Reference Summary

Client
  ↓
Internet-facing ALB
  └─ Listener: HTTP :80
       ↓ forward
Target group: EC2 instances
       ↓
Healthy instances across multiple Availability Zones

Configuration sequence:

1. Create a target group with an EC2 instance target type.
2. Configure the target protocol, port, and health-check path.
3. Create an internet-facing ALB across the required Availability Zone subnets.
4. Attach an ALB security group that allows approved client traffic.
5. Create a listener and forward requests to the target group.
6. Associate the target group with the Auto Scaling group.
7. Verify that instances move from initial to healthy.
8. Test using the ALB DNS name rather than an individual instance address.

Flashcards

1. Q: What is the role of an ALB listener?

A: It accepts connections on a configured protocol and port and applies routing actions to those requests.

1. Q: What does a target group contain?

A: The backend targets that receive forwarded traffic, along with routing and health-check configuration.

1. Q: Why should instances in an Auto Scaling group not be registered manually?

A: Manual registration becomes stale when instances are launched, terminated, or replaced. Auto Scaling integration provides dynamic registration.

1. Q: What does an ALB health check determine?

A: Whether a registered target is eligible to receive traffic.

1. Q: What does the initial target state mean?

A: The target has recently been registered and the load balancer has not completed enough checks to establish its health.

1. Q: Which security group should normally permit inbound application traffic to EC2 targets?

A: The instance security group should permit traffic from the ALB security group on the target port.

1. Q: What is the difference between an internet-facing and internal ALB?

A: An internet-facing ALB has public connectivity for internet clients; an internal ALB is reachable through private network paths.

1. Q: What endpoint do clients use to access an ALB?

A: The ALB DNS name, rather than a fixed load balancer IP address.

1. Q: Can the ALB listener port differ from the target group’s port?

A: Yes. The listener and target group have separate protocol and port settings.

1. Q: Why deploy an ALB across multiple Availability Zones?

A: To improve availability and distribute requests across independent failure domains.

1. Q: What happens when an Auto Scaling group launches a replacement instance after a failure?

A: When the target group is associated with the Auto Scaling group, the replacement can be registered automatically and subjected to health checks.

1. Q: What is a common reason for an instance to remain unhealthy?

A: The health-check path or port is incorrect, the application is not responding successfully, or the instance security group blocks the ALB.

Practice Questions

Question 1

An organization runs an EC2 Auto Scaling group across two Availability Zones. An ALB is configured, but instances launched during scale-out do not receive traffic. Existing instances were manually registered with the target group. What should the architect do?

A. Register a larger number of standby instances manually.
B. Associate the target group with the Auto Scaling group.
C. Replace the ALB with a Network Load Balancer.
D. Assign Elastic IP addresses to all instances.

Correct answer: B

Explanation: Associating the target group with the Auto Scaling group enables automatic registration of newly launched instances and deregistration of terminated instances. Manual registration is static and does not support elastic membership.

Question 2

An ALB target group shows two EC2 instances in an unhealthy state. The web server responds successfully when accessed locally on each instance. The ALB health check uses HTTP on port 80, and the instance security group allows port 80 only from the corporate office CIDR. What is the best corrective action?

A. Allow port 80 from the ALB security group in the instance security group.
B. Allow port 443 from the corporate CIDR.
C. Disable ALB health checks.
D. Register the instances using their public IP addresses.

Correct answer: A

Explanation: The instance security group must permit the ALB to reach the health-check port. Referencing the ALB security group is more precise than allowing all internet sources.

Question 3

A public web application must remain available if one Availability Zone fails. The application runs on EC2 instances managed by an Auto Scaling group. Which design best meets the requirement?

A. Use one ALB subnet and one instance in a single Availability Zone.
B. Use an internet-facing ALB across multiple Availability Zones and an Auto Scaling group spanning those zones.
C. Use an internal ALB and place all instances in public subnets.
D. Place a public IP address on every instance and use DNS round-robin.

Correct answer: B

Explanation: A multi-AZ ALB and multi-AZ Auto Scaling group distribute both the load-balancing and compute tiers across failure domains. The other options either create a single-AZ dependency or expose and manage instances directly.

Question 4

An ALB listens for HTTP traffic on port 80 but forwards requests to a target group configured for port 8080. The application listens only on port 80. What is the most likely result?

A. The ALB automatically changes the target port to 80.
B. The targets fail health checks or cannot receive forwarded traffic.
C. The ALB converts the traffic to HTTPS.
D. The Auto Scaling group changes the application port automatically.

Correct answer: B

Explanation: Listener and target ports are separate settings. If the target group sends traffic to port 8080 while the application listens on port 80, connections and health checks fail unless the target configuration is corrected.

Question 5

A team wants to verify that an application is ready before the ALB sends it production requests. The root path returns HTTP success even when a required backend dependency is unavailable. What is the best improvement?

A. Remove health checks so all instances receive traffic.
B. Configure a dedicated health-check path that reflects the desired readiness state.
C. Use the ALB DNS name as the health-check path.
D. Register only the oldest instances in the target group.

Correct answer: B

Explanation: A dedicated health endpoint can provide a more meaningful readiness signal than /. The endpoint’s dependency checks should be designed carefully to avoid causing unnecessary removal of instances during transient downstream failures.