Application Load Balancer (ALB) in AWS - Step-by-Step Execution

Process Flow - Application Load Balancer (ALB)

Client sends HTTP request

↓

ALB receives request

↓

ALB evaluates listener rules

↓

Select target group based on rules

↓

Forward request to healthy target instance

↓

Target instance processes request and responds

↓

ALB sends response back to client

The ALB receives client requests, checks rules to decide which server group to send to, forwards the request to a healthy server, and returns the response to the client.

Execution Sample

AWS

resource "aws_lb" "example" {
  name               = "example-alb"
  internal           = false
  load_balancer_type = "application"
  subnets            = ["subnet-123", "subnet-456"]
}

This code creates an Application Load Balancer named 'example-alb' in two subnets, ready to route HTTP requests.

Process Table

Step	Action	Input/Condition	Result/Output
1	Client sends HTTP request	Request to ALB DNS	Request arrives at ALB
2	ALB listener receives request	Listener on port 80 active	Listener accepts request
3	ALB evaluates listener rules	Rule: path /api/* -> target group A	Request matches /api/* rule
4	ALB selects target group	Target group A has 3 healthy instances	Target group A chosen
5	ALB forwards request	Select healthy instance from target group A	Request sent to instance i-12345
6	Instance processes request	Instance i-12345 receives request	Instance returns HTTP 200 response
7	ALB sends response to client	Response from instance	Client receives HTTP 200 response
8	End	No more requests	Waiting for next client request

💡 Execution stops after response is sent back to client and ALB waits for new requests.

Status Tracker

Variable	Start	After Step 3	After Step 4	After Step 5	Final
Request Path	/	/api/users	/api/users	/api/users	/api/users
Selected Target Group	None	None	Target Group A	Target Group A	Target Group A
Target Instance	None	None	None	i-12345	i-12345
Response Status	None	None	None	None	200 OK

Key Moments - 3 Insights

How does the ALB decide which target group to send the request to?

The ALB checks listener rules against the request path or host. In the execution table at Step 3, the request path '/api/users' matches the rule '/api/*', so target group A is selected at Step 4.

What happens if no target instances are healthy?

If no healthy targets exist in the selected target group, the ALB cannot forward the request, resulting in an error response. This is not shown in the current execution but would stop forwarding at Step 5.

Why does the ALB wait after sending the response?

After sending the response (Step 7), the ALB waits for new client requests to handle. This is shown in Step 8 where it is idle, ready for the next request.

Visual Quiz - 3 Questions

Look at the execution table, at which step does the ALB select the target group?

A Step 2

B Step 4

C Step 6

D Step 7

💡 Hint

Check the 'Action' column for 'ALB selects target group' in the execution table.

According to the variable tracker, what is the 'Response Status' after Step 7?

A None

B 404 Not Found

C 200 OK

D 500 Internal Server Error

💡 Hint

Look at the 'Response Status' row under the 'Final' column in the variable tracker.

If the request path was '/home' instead of '/api/users', how would the selected target group change?

A Target Group A would still be selected

B No target group would be selected

C A different target group would be selected if rules exist

D The ALB would forward to all target groups

💡 Hint

Refer to Step 3 in the execution table where rules are matched based on the request path.

Concept Snapshot

Application Load Balancer (ALB):
- Receives client HTTP/HTTPS requests
- Uses listeners and rules to route requests
- Forwards requests to healthy targets in target groups
- Supports path and host-based routing
- Returns responses from targets back to clients
- Automatically handles scaling and health checks

Full Transcript

An Application Load Balancer (ALB) receives HTTP requests from clients. It listens on specified ports and evaluates rules to decide which target group should handle the request. The ALB forwards the request to a healthy instance in the chosen target group. The instance processes the request and sends back a response. The ALB then returns this response to the client. After completing a request, the ALB waits for new incoming requests. This process ensures efficient and reliable routing of web traffic to backend servers.

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