Application Load Balancer (ALB) in AWS - Mini Project: Build & Apply

Create an Application Load Balancer (ALB) with Target Group in AWS

📖 Scenario: You are setting up a simple web application on AWS. To distribute incoming web traffic evenly across multiple servers, you need to create an Application Load Balancer (ALB) and connect it to a target group of servers.

🎯 Goal: Build an Application Load Balancer (ALB) with a target group and listener using AWS CloudFormation syntax. This will allow your web traffic to be balanced across your servers.

📋 What You'll Learn

Create a target group named MyTargetGroup listening on port 80 with protocol HTTP

Create an Application Load Balancer named MyALB in public subnets

Create a listener on the ALB for port 80 using HTTP protocol

Attach the listener to the target group MyTargetGroup

💡 Why This Matters

🌍 Real World

Load balancers are essential to distribute web traffic evenly across multiple servers, improving availability and performance.

💼 Career

Cloud architects and DevOps engineers often create and configure load balancers to ensure scalable and reliable web applications.

1

Create the Target Group

Create a resource called MyTargetGroup of type AWS::ElasticLoadBalancingV2::TargetGroup with Port set to 80, Protocol set to HTTP, and VpcId set to vpc-123456.

AWS

# Your code here to create MyTargetGroup resource

Hint

The target group needs a name, port, protocol, and VPC ID.

2

Create the Application Load Balancer

Add a resource called MyALB of type AWS::ElasticLoadBalancingV2::LoadBalancer with Subnets set to ["subnet-111111", "subnet-222222"] and Scheme set to internet-facing.

AWS

Resources:
  MyTargetGroup:
    Type: AWS::ElasticLoadBalancingV2::TargetGroup
    Properties:
      Name: MyTargetGroup
      Port: 80
      Protocol: HTTP
      VpcId: vpc-123456

# Your code here to create MyALB resource

Hint

The ALB needs to be internet-facing and placed in public subnets.

3

Create the Listener for the ALB

Add a resource called MyListener of type AWS::ElasticLoadBalancingV2::Listener with LoadBalancerArn referencing MyALB, Port set to 80, Protocol set to HTTP, and DefaultActions forwarding to the target group MyTargetGroup.

AWS

Resources:
  MyTargetGroup:
    Type: AWS::ElasticLoadBalancingV2::TargetGroup
    Properties:
      Name: MyTargetGroup
      Port: 80
      Protocol: HTTP
      VpcId: vpc-123456
  MyALB:
    Type: AWS::ElasticLoadBalancingV2::LoadBalancer
    Properties:
      Name: MyALB
      Subnets:
        - subnet-111111
        - subnet-222222
      Scheme: internet-facing

# Your code here to create MyListener resource

Hint

The listener connects the ALB to the target group on port 80 using HTTP.

4

Complete the CloudFormation Template

Add the Outputs section with an output named LoadBalancerDNSName that returns the DNS name of MyALB using !GetAtt MyALB.DNSName.

AWS

Resources:
  MyTargetGroup:
    Type: AWS::ElasticLoadBalancingV2::TargetGroup
    Properties:
      Name: MyTargetGroup
      Port: 80
      Protocol: HTTP
      VpcId: vpc-123456
  MyALB:
    Type: AWS::ElasticLoadBalancingV2::LoadBalancer
    Properties:
      Name: MyALB
      Subnets:
        - subnet-111111
        - subnet-222222
      Scheme: internet-facing
  MyListener:
    Type: AWS::ElasticLoadBalancingV2::Listener
    Properties:
      LoadBalancerArn: !Ref MyALB
      Port: 80
      Protocol: HTTP
      DefaultActions:
        - Type: forward
          TargetGroupArn: !Ref MyTargetGroup

# Your code here to add Outputs section

Hint

The output helps you find the ALB's DNS name after deployment.

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