Why Application Load Balancer (ALB) in AWS? - Purpose & Use Cases

The Big Idea

What if your website never crashes even when thousands visit at once?

The Scenario

Imagine you run a busy online store with many customers visiting at once. You try to send all their requests to just one server manually, hoping it can handle everything.

The Problem

This manual way is slow and risky. One server gets overloaded and crashes, making your site slow or unreachable. You have to watch and fix problems all the time, which is stressful and error-prone.

The Solution

An Application Load Balancer (ALB) automatically spreads incoming customer requests across many servers. It checks which servers are healthy and sends traffic only to those, keeping your site fast and reliable without manual work.

Before vs After

✗ Before

Send all requests to server1.example.com

✓ After

Use ALB DNS to distribute requests to multiple servers automatically

What It Enables

With ALB, your application can handle many users smoothly and stay online even if some servers fail.

Real Life Example

Big websites like online shops or streaming services use ALB to keep their apps running fast and avoid crashes during busy times like sales or new releases.

Key Takeaways

Manual routing overloads servers and causes downtime.

ALB automatically balances traffic to healthy servers.

This improves reliability, speed, and user experience.

Practice

1. What is the primary purpose of an Application Load Balancer (ALB) in AWS?

easy

A. To create virtual private clouds (VPCs)

B. To distribute incoming web traffic across multiple targets for better availability

C. To monitor network traffic for security threats

D. To store large amounts of data securely

Solution

1. Step 1: Understand ALB's role in traffic management

   ALB distributes incoming HTTP/HTTPS requests to multiple backend servers to balance load and improve availability.

2. Step 2: Compare options with ALB's function

   Options A, B, and C describe other AWS services, not ALB's main function.

3. Final Answer:

   To distribute incoming web traffic across multiple targets for better availability -> Option B

4. Quick Check:

   ALB = traffic distribution [OK]

Hint: ALB balances web traffic to keep apps available [OK]

Common Mistakes:

• Confusing ALB with storage services
• Thinking ALB handles security monitoring
• Mixing ALB with network setup services

2. Which of the following is the correct way to specify a listener protocol for an ALB in AWS?

easy

A. ListenerProtocol: HTTP

B. ListenerProtocol: FTP

C. ListenerProtocol: TCP

D. ListenerProtocol: SMTP

Solution

1. Step 1: Identify supported ALB listener protocols

   ALB supports HTTP and HTTPS protocols for listeners, not TCP, FTP, or SMTP.

2. Step 2: Match correct protocol syntax

   ListenerProtocol: HTTP uses HTTP, which is valid for ALB listeners.

3. Final Answer:

   <code>ListenerProtocol: HTTP</code> -> Option A

4. Quick Check:

   ALB listener protocol = HTTP or HTTPS [OK]

Hint: ALB listeners use HTTP/HTTPS, not TCP or FTP [OK]

Common Mistakes:

• Using unsupported protocols like FTP or SMTP
• Confusing ALB with Network Load Balancer protocols
• Incorrect syntax for listener protocol

3. Given an ALB with two target groups: tg1 and tg2. The ALB uses a rule to route requests with path /api/* to tg1 and all other requests to tg2. What happens when a user requests /api/users?

medium

A. The request is routed to target group tg1

B. The request is routed to target group tg2

C. The request is rejected with an error

D. The request is routed to both tg1 and tg2 simultaneously

Solution

1. Step 1: Analyze the ALB routing rule

   The rule states requests with path starting /api/ go to tg1.

2. Step 2: Match the request path

   The request path /api/users matches the /api/* pattern, so it routes to tg1.

3. Final Answer:

   The request is routed to target group <code>tg1</code> -> Option A

4. Quick Check:

   Path /api/* routes to tg1 [OK]

Hint: Path rules route matching requests to correct target group [OK]

Common Mistakes:

• Assuming default target group handles all requests
• Thinking requests route to multiple target groups
• Ignoring path-based routing rules

4. You configured an ALB with HTTPS listener but forgot to attach an SSL certificate. What issue will occur?

medium

A. The ALB will route requests without encryption

B. The ALB will automatically generate a certificate and accept requests

C. The ALB will downgrade HTTPS requests to HTTP

D. The ALB will reject all HTTPS requests with a TLS handshake failure

Solution

1. Step 1: Understand HTTPS listener requirements

   HTTPS listeners require a valid SSL certificate to establish secure connections.

2. Step 2: Consequence of missing certificate

   Without a certificate, TLS handshake fails, causing ALB to reject HTTPS requests.

3. Final Answer:

   The ALB will reject all HTTPS requests with a TLS handshake failure -> Option D

4. Quick Check:

   HTTPS needs SSL cert; missing cert = handshake failure [OK]

Hint: HTTPS listeners must have SSL certificates attached [OK]

Common Mistakes:

• Assuming ALB auto-generates SSL certificates
• Thinking ALB downgrades HTTPS to HTTP automatically
• Believing ALB routes unencrypted traffic on HTTPS listener

5. You want to design a scalable web app using ALB that routes traffic based on user device type: mobile users to tg-mobile and desktop users to tg-desktop. Which ALB feature should you use to implement this?

hard

A. Use ALB path-based routing with /mobile and /desktop paths

B. Use ALB health checks to detect device type

C. Use ALB listener rules with HTTP header-based routing on the User-Agent header

D. Use ALB sticky sessions to route users based on device

Solution

1. Step 1: Identify how to detect device type in requests

   User device type is typically indicated in the HTTP User-Agent header.

2. Step 2: Choose ALB feature for routing based on headers

   ALB supports listener rules that route traffic based on HTTP headers like User-Agent.

3. Step 3: Evaluate other options

   Health checks do not detect device type; path-based routing requires URL changes; sticky sessions maintain session but don't route by device.

4. Final Answer:

   Use ALB listener rules with HTTP header-based routing on the User-Agent header -> Option C

5. Quick Check:

   Header-based routing = device type routing [OK]

Hint: Use header-based routing on User-Agent for device detection [OK]

Common Mistakes:

• Using health checks to detect device type
• Relying on path-based routing without URL changes
• Confusing sticky sessions with routing logic