AWS Application Load Balancer ALB EC2 Tutorial: Stickiness & Path-Based Routing Lab 2026

Introduction

If you’ve ever wondered how Netflix routes your traffic to the right microservice or how your bank keeps you logged into the same backend server during a session, you’re looking at Application Load Balancers doing their job. This lab is where you stop reading about ALBs and start building with them.

In this Lab, you’ll deploy an internet-facing Application Load Balancer, register EC2 instances into target groups, enable session stickiness, and configure path-based routing to serve multiple web applications from a single ALB endpoint. By the end, you’ll understand why ALBs are the backbone of modern AWS web architectures.

Who is this lab for? If you’re a DevOps engineer, cloud practitioner, or developer who’s comfortable launching EC2 instances but hasn’t gotten your hands dirty with Layer 7 load balancing, this is your starting point. You should have basic AWS networking knowledge and understand what a security group does.

Why ALB over Classic or NLB? I get this question constantly. Here’s the short answer: Classic Load Balancer is legacy—AWS keeps it around for backward compatibility, but you shouldn’t use it for new projects. Network Load Balancer operates at Layer 4 (TCP/UDP) and excels at ultra-low latency and millions of requests per second, but it doesn’t understand HTTP. ALB operates at Layer 7, meaning it can inspect HTTP headers, cookies, and URL paths. That’s why you can route /api to one set of servers and /static to another. For 90% of web applications, ALB is what you want.

Common beginner mistakes I’ve seen: Engineers configure ALB listeners but forget to open port 80 in the security group attached to EC2 instances. They set health check paths to /health when their app responds on /. They register instances in private subnets to an internet-facing ALB and wonder why nothing works. This lab will help you avoid all of that.

Lab Overview

What You’ll Build

You’re going to deploy a production-style architecture: an internet-facing ALB sitting in public subnets, distributing traffic to EC2 instances running two different web applications. One app lives at /app1, another at /app2. You’ll configure the ALB to route requests based on URL path and enable sticky sessions so users maintain affinity to specific backend instances.

Architecture at a High Level

Traffic flows from the internet through the ALB, which inspects incoming HTTP requests. Based on listener rules you configure, the ALB forwards requests to the appropriate target group. Each target group contains EC2 instances running your web apps. Session stickiness ensures that once a user hits a specific instance, subsequent requests go to the same instance for a configurable duration.

Skills You’ll Gain

After completing this hands-on lab, you’ll be able to create and configure ALBs from scratch, design target groups with proper health checks, implement path-based routing for microservices or multi-app architectures, enable and troubleshoot session stickiness, and validate load balancer behavior using browser tools and curl commands.

Real-World Use Cases

This exact pattern powers microservices architectures where /users routes to a user service and /orders routes to an order service. It enables blue/green deployments where you shift traffic between target groups. It supports monolith-to-microservices migrations where you peel off endpoints one path at a time. I’ve used this approach to gradually migrate a legacy monolith by routing new API paths to modern services while keeping the old paths pointed at the legacy app.

Prerequisites

Before starting this AWS tutorial, ensure you have the following ready.

AWS Account: A personal or sandbox account with permissions to create ALBs, target groups, and modify EC2 instances.

Existing VPC with Public Subnets: You need at least two public subnets in different Availability Zones. ALB requires multi-AZ subnet selection for high availability.

At Least Two Running EC2 Instances: These instances should be in public subnets, have public IPs or be behind a NAT gateway, and run a simple web server (Apache or Nginx). Each instance should serve content at /app1 and /app2 paths, or you can deploy different apps on different instances.

Security Group Basics: Understand that you’ll need security groups allowing HTTP traffic from the ALB to your instances.

Basic EC2 and Networking Knowledge: You should be comfortable with subnets, route tables, and security groups from previous labs. (Related post: {link to VPC fundamentals})

Step-by-Step Hands-On Lab

Step 1: Open EC2 Console and Navigate to Load Balancers

Sign in to the AWS Management Console. In the search bar, type “EC2” and select the EC2 service. In the left navigation pane, scroll down to “Load Balancing” and click “Load Balancers.” Click the orange “Create Load Balancer” button.

Why this matters: The Load Balancer section lives under EC2, not under a separate service. This trips up beginners who search for “ALB” in the console search bar and don’t find it.

Step 2: Choose Application Load Balancer

You’ll see three options: Application Load Balancer, Network Load Balancer, and Gateway Load Balancer. Click “Create” under Application Load Balancer.

What you should see: A configuration wizard opens with sections for basic configuration, network mapping, security groups, listeners, and target groups.

Step 3: Configure Basic Settings

Load balancer name: Enter something descriptive like web-alb-prod or lab-alb-demo. Names must be unique within your account and region.

Scheme: Select “Internet-facing.” This makes the ALB accessible from the public internet. Internal ALBs are for private traffic between services.

IP address type: Choose “IPv4” unless you specifically need IPv6 support.

Common misconfiguration: Choosing “Internal” when you want public access. I’ve seen engineers spend hours debugging why their ALB DNS doesn’t resolve publicly—because it was internal the whole time.

Step 4: Configure Network Mapping

VPC: Select your existing VPC from the dropdown.

Mappings: Select at least two Availability Zones and choose a public subnet in each. ALB distributes nodes across these subnets for high availability.

What you should see: Checkboxes next to each AZ with subnet dropdowns. The console shows the subnet CIDR blocks.

Critical point: The subnets must be public (have a route to an internet gateway). If you select private subnets for an internet-facing ALB, AWS will let you create it, but external traffic will never reach it.

Step 5: Configure Security Groups

Create a new security group or select an existing one. Your ALB security group needs an inbound rule allowing HTTP (port 80) from 0.0.0.0/0 (or your specific IP range for testing).

Sample configuration:

• Type: HTTP
• Protocol: TCP
• Port: 80
• Source: 0.0.0.0/0

Why this matters: The ALB itself needs to accept incoming traffic. Later, your EC2 security group will reference this ALB security group as its source—this is the secure pattern.

Step 6: Configure Listeners and Create Target Group

Under “Listeners and routing,” you’ll see a default HTTP listener on port 80. Click “Create target group” to open a new tab.

Target group configuration:

• Target type: Instances
• Target group name: web-tg-app1
• Protocol: HTTP
• Port: 80
• VPC: Select your VPC

Health check settings:

• Protocol: HTTP
• Path: / (or /health if your app has a dedicated health endpoint)

Advanced health check settings (expand this):

• Healthy threshold: 2
• Unhealthy threshold: 2
• Timeout: 5 seconds
• Interval: 30 seconds

Why health checks matter: I’ve seen production outages because the health check path returned 404. The ALB marked all instances unhealthy and stopped routing traffic. Always verify your health check path returns 200.

Step 7: Register EC2 Instances

After creating the target group, you’ll see a screen to register targets. Select your EC2 instances from the list, ensure port 80 is specified, and click “Include as pending below.” Then click “Create target group.”

What you should see: Your instances appear in the “Review targets” section with their instance IDs and AZ information.

Step 8: Complete ALB Creation

Return to the ALB creation tab, refresh the target group dropdown, and select the target group you just created. Review your settings and click “Create load balancer.”

What you should see: A success message and your ALB appearing in the load balancer list with a “Provisioning” state. Wait 2-3 minutes for it to become “Active.”

Step 9: Verify Target Health

Select your ALB, go to the “Target groups” tab, click on your target group, and check the “Targets” tab. Healthy instances show “healthy” in the status column.

If targets show “unhealthy”: Check that your EC2 security group allows traffic from the ALB security group on port 80. Verify your web server is running. Confirm the health check path returns HTTP 200.

Step 10: Enable Session Stickiness

Navigate to your target group, select the “Attributes” tab, and click “Edit.”

Stickiness settings:

• Enable stickiness: On
• Stickiness type: Load balancer generated cookie
• Stickiness duration: 1 day (or 86400 seconds)

Click “Save changes.”

What this does: The ALB sets an AWSALB cookie in the browser. Subsequent requests with this cookie route to the same instance. This is essential for applications storing session data locally rather than in Redis or DynamoDB.

Architect’s note: Stickiness is a crutch for stateful apps. In a truly cloud-native architecture, your apps should be stateless with external session stores. But in the real world, you’ll inherit legacy apps that need stickiness, so learn to configure it correctly.

Step 11: Deploy Multiple Web Apps

SSH into your EC2 instances and create directories for /app1 and /app2:

# On Instance 1
sudo mkdir -p /var/www/html/app1
echo "<h1>App1 - Instance 1</h1>" | sudo tee /var/www/html/app1/index.html

sudo mkdir -p /var/www/html/app2
echo "<h1>App2 - Instance 1</h1>" | sudo tee /var/www/html/app2/index.html

Repeat on Instance 2 with different identifiers so you can see which instance serves each request.

Step 12: Configure Path-Based Routing Rules

Create a second target group (web-tg-app2) following Step 6, and register appropriate instances.

Return to your ALB, select the “Listeners” tab, and click on your HTTP:80 listener. Click “Manage rules” then “Add rules.”

Rule 1:

• Condition: Path is /app1*
• Action: Forward to web-tg-app1

Rule 2:

• Condition: Path is /app2*
• Action: Forward to web-tg-app2

Critical configuration: Rule order matters. AWS evaluates rules top-to-bottom. Place specific path rules above the default rule. The default rule (catch-all) should be last.

Step 13: Test Routing and Stickiness

Copy your ALB DNS name from the console (something like web-alb-prod-1234567890.us-east-1.elb.amazonaws.com).

Browser testing:

• Visit http://<ALB-DNS>/app1/ and note which instance responds
• Refresh multiple times—with stickiness enabled, you should hit the same instance
• Open an incognito window and visit again—you might hit a different instance

curl testing:

# Basic connectivity test
curl -I http://<ALB-DNS-NAME>

# Test path-based routing
curl http://<ALB-DNS-NAME>/app1/
curl http://<ALB-DNS-NAME>/app2/

# Check stickiness cookie
curl -c cookies.txt -b cookies.txt http://<ALB-DNS-NAME>/app1/
cat cookies.txt  # You should see AWSALB cookie

Real Lab Experiences: Architect Insights

Let me share what I’ve seen go wrong in production with ALBs.

Sticky sessions breaking stateless apps: A team enabled stickiness on an ALB fronting a stateless API. During peak load, one instance got overloaded because all requests from heavy users stuck to it while other instances sat idle. Stickiness defeated the load balancing they needed. Lesson: Only enable stickiness when your application truly requires it.

Health check path mismatch: An engineer configured the health check to hit /healthz, but the Kubernetes ingress expected /health. All pods showed unhealthy, traffic stopped, and the on-call engineer spent two hours debugging before checking the ALB target group configuration. Always confirm your health check path matches what your application serves.

Listener rule order disasters: A team added a new path rule but placed it after a wildcard rule. The wildcard caught everything, and the new path rule never triggered. Remember: specific rules go first, wildcards last.

Advice for junior engineers: Before deploying to production, test your ALB configuration in a non-prod environment. Verify health checks manually using curl against your instances directly. Document your listener rules and review them during code review—infrastructure configuration deserves the same scrutiny as application code.

Validation and Testing

Browser-based testing: Open Developer Tools (F12), go to the Network tab, and watch requests to your ALB. Check the Response Headers for Set-Cookie: AWSALB=.... Refresh the page and observe the Request Headers now include the cookie.

Confirm path-based routing works:

curl http://<ALB-DNS-NAME>/app1/
# Should return content from app1 target group

curl http://<ALB-DNS-NAME>/app2/
# Should return content from app2 target group

Confirm stickiness works:

# First request sets cookie
curl -c cookies.txt http://<ALB-DNS-NAME>/app1/

# Subsequent requests use cookie and hit same instance
curl -b cookies.txt http://<ALB-DNS-NAME>/app1/
curl -b cookies.txt http://<ALB-DNS-NAME>/app1/

You should see the same instance identifier in each response.

Troubleshooting Guide

Unhealthy targets: SSH to the instance and run curl localhost/ to confirm the web server responds. Check the security group allows inbound HTTP from the ALB security group. Verify the health check path in the target group matches a valid endpoint.

404 from listener rules: Confirm your path pattern matches the request. /app1* matches /app1/anything, but /app1 without a wildcard only matches exactly /app1. Check rule order—the first matching rule wins.

Stickiness not working: Ensure stickiness is enabled on the target group, not the listener. Verify cookies aren’t being blocked by browser settings. Check that your application isn’t setting conflicting cookies.

Security group mistakes: The ALB security group needs inbound from the internet. The EC2 security group needs inbound from the ALB security group (reference the SG ID, not an IP range).

Debugging commands:

# Check ALB response headers
curl -I http://<ALB-DNS-NAME>

# Verbose output showing connection details
curl -v http://<ALB-DNS-NAME>/app1/

# Test specific instance directly (for comparison)
curl http://<INSTANCE-PUBLIC-IP>/app1/

AWS Best Practices: Solutions Architect Level

Security: Apply least privilege by restricting ALB security groups to necessary ports and sources. Use HTTPS listeners with ACM certificates in production. Never expose backend instances directly to the internet—all traffic should flow through the ALB.

Reliability: Always deploy ALB across multiple Availability Zones. Register instances in at least two AZs. Configure appropriate health check intervals—too aggressive causes flapping, too lenient delays failure detection.

Cost optimization: ALB charges hourly plus per LCU (Load Balancer Capacity Unit). For simple use cases, one ALB with path-based routing is cheaper than multiple ALBs. Consider NLB for pure TCP workloads where you don’t need Layer 7 features.

Tagging strategy: Tag your ALB and target groups with environment, project, and cost-center tags. This enables cost allocation and simplifies resource management at scale.

Scaling considerations: Plan for Auto Scaling Groups behind your target groups (covered in Lab 3.5). ALB integrates natively with ASGs—as instances launch or terminate, they automatically register or deregister from target groups.

AWS ALB Interview Questions and Answers

When you’re interviewing for AWS Solutions Architect, DevOps Engineer, or Cloud Engineer roles, ALB questions come up constantly. Here are the questions I’ve asked candidates and been asked myself over the years.

Conceptual Questions

Q1: What is the difference between Application Load Balancer and Network Load Balancer?

Application Load Balancer operates at Layer 7 (HTTP/HTTPS) and can inspect request content including headers, cookies, and URL paths. This enables content-based routing, host-based routing, and path-based routing. Network Load Balancer operates at Layer 4 (TCP/UDP), handles millions of requests per second with ultra-low latency, and preserves the client’s source IP address. Choose ALB when you need HTTP-aware routing decisions and choose NLB when you need extreme performance or non-HTTP protocols.

Q2: Explain how path-based routing works in ALB.

Path-based routing allows a single ALB to route requests to different target groups based on the URL path. The ALB evaluates listener rules in priority order, matching the request path against configured patterns. For example, requests to /api/* can route to a backend API target group while /static/* routes to a static content server group. This pattern is fundamental for microservices architectures where different services handle different URL namespaces.

Q3: What happens when all targets in a target group become unhealthy?

When all registered targets fail health checks, the ALB behavior depends on your configuration. By default, the ALB returns HTTP 503 Service Unavailable to clients. However, if you enable the “fail open” behavior, the ALB will route traffic to all targets regardless of health status, which can be useful when health checks are too aggressive. In production, this scenario should trigger CloudWatch alarms and potentially invoke Auto Scaling policies to launch replacement instances.

Q4: How does ALB session stickiness work, and when would you use it?

ALB session stickiness uses cookies to maintain client affinity to specific backend targets. When enabled, the ALB generates an AWSALB cookie with a configurable duration. Subsequent requests containing this cookie route to the same target that originally set it. Use stickiness when your application stores session state locally on the server, such as shopping carts or authentication tokens stored in memory. However, modern best practice favors external session stores like ElastiCache or DynamoDB, making stickiness unnecessary for truly stateless applications.

Scenario-Based Questions

Q5: Your ALB shows all targets as unhealthy, but you can curl the application directly on the EC2 instances. What do you check?

This is a classic troubleshooting scenario. First, verify the security group attached to EC2 instances allows inbound traffic from the ALB security group on the health check port. Second, confirm the health check path configured in the target group actually returns HTTP 200 on your instances. Third, check that the health check port matches where your application listens. Fourth, verify instances are in subnets that have network connectivity to the ALB subnets. I’ve seen engineers spend hours on this when the simple answer was the health check path was /health but the app responded on /healthz.

Q6: A user reports that sometimes they get logged out randomly while using your application behind an ALB. What could cause this?

This typically indicates a session management problem combined with load balancing. If the application stores sessions locally and stickiness isn’t enabled, requests might hit different instances that don’t share session data. Solutions include enabling ALB stickiness as a short-term fix or migrating session storage to a shared store like Redis or DynamoDB as the proper architectural solution. I’d also check if any instance is failing health checks intermittently, causing the user’s sticky session to break when their target becomes unavailable.

Q7: You need to perform a blue-green deployment with zero downtime. How would you use ALB to accomplish this?

Create two target groups: blue (current production) and green (new version). Deploy the new version to instances registered in the green target group. Update the ALB listener rule to shift traffic from blue to green. You can do this instantly by changing the rule’s forward action, or gradually using weighted target groups where you send 10% to green initially, then increase over time. Monitor error rates and latency during the shift. If problems occur, immediately revert the listener rule to point back to blue. This approach requires no DNS changes and provides instant rollback capability.

Q8: Your application serves both API traffic and static assets. How would you architect this with ALB?

Configure path-based routing with multiple target groups. Create one target group for API servers optimized for compute and another for static asset servers optimized for I/O or served from S3 via CloudFront. Set up listener rules where /api/* routes to the API target group and /static/* routes to the static assets. Alternatively, for static assets, consider using CloudFront in front of the ALB with cache behaviors that serve static content from S3, reducing load on your EC2 instances entirely.

Advanced Questions

Q9: How do you secure an ALB in a production environment?

Security involves multiple layers. Attach security groups that restrict inbound traffic to required ports from known sources. Use HTTPS listeners with ACM certificates and redirect HTTP to HTTPS. Enable access logging to S3 for audit trails. Integrate with AWS WAF to protect against common web exploits like SQL injection and XSS. Use AWS Shield for DDoS protection. Place backend instances in private subnets with no public IPs, accessible only through the ALB. Implement least privilege IAM policies for any automation that modifies ALB configuration.

Q10: Explain ALB access logging and how you’d use it for troubleshooting.

ALB access logs capture detailed information about every request including client IP, latency, request path, response codes, and target information. Logs are stored in S3 in a structured format. For troubleshooting, you’d analyze these logs to identify patterns like which paths generate 5xx errors, which clients experience high latency, or which targets receive disproportionate traffic. Tools like Athena let you query these logs with SQL. I’ve used access logs to discover that a single misbehaving client was hammering an endpoint and causing cascading failures.

Frequently Asked Questions

These questions address the most common queries engineers have about Application Load Balancers. Each answer is structured to give you the direct answer first, followed by the context you need to apply it correctly.

Google Best Practices for ALB Deployments

Following industry-standard load balancing best practices helps you build reliable, secure, and performant architectures. These recommendations align with both AWS Well-Architected Framework and general cloud engineering principles.

Use Health Checks Effectively

Configure health checks that accurately reflect application readiness, not just process status. A health check endpoint should verify database connectivity, cache availability, and any critical dependencies. Set appropriate thresholds to avoid flapping where targets oscillate between healthy and unhealthy states. Use a dedicated health check path like /health that’s lightweight and doesn’t trigger expensive operations.

Implement Proper Timeout Configuration

Align your ALB idle timeout with your application’s expected response times. The default 60-second timeout works for most applications, but long-running operations like report generation may need longer. However, don’t set excessively high timeouts as this ties up connections during failures. Configure your backend application’s timeout to be slightly lower than the ALB timeout to ensure clean error handling.

Enable Access Logging from Day One

Don’t wait for an incident to enable access logging. Configure ALB to log all requests to an S3 bucket with appropriate lifecycle policies. These logs are invaluable for troubleshooting latency issues, identifying attack patterns, understanding traffic distribution, and performing capacity planning. Set up Athena tables to query logs efficiently when you need answers quickly.

Design for Failure

Assume any single component can fail. Register targets across multiple Availability Zones. Use Auto Scaling Groups so failed instances are replaced automatically. Configure CloudWatch alarms on UnhealthyHostCount, HTTPCode_ELB_5XX_Count, and TargetResponseTime metrics. Create runbooks for common failure scenarios so your team responds consistently during incidents.

Secure by Default

Never deploy an ALB without considering security. Use HTTPS with TLS 1.2 or higher. Attach AWS WAF to protect against common exploits. Restrict security groups to necessary traffic only. Enable deletion protection on production ALBs to prevent accidental removal. Log all configuration changes through CloudTrail for audit compliance.

Optimize for Cost

Right-size your architecture by understanding LCU pricing. Consolidate applications behind fewer ALBs using path-based routing instead of deploying separate ALBs for each application. Use connection draining appropriately during deployments to prevent wasted compute. Review access logs periodically to identify optimization opportunities like caching frequently requested static content.

Implement Graceful Degradation

Design your routing rules to handle failures gracefully. Configure a default action that returns a friendly error page rather than a generic 503. Use fixed-response actions for maintenance windows. Consider implementing circuit breaker patterns at the application level that work in conjunction with ALB health checks to prevent cascading failures across your target groups.

Monitor Key Metrics Continuously

Set up CloudWatch dashboards tracking RequestCount, TargetResponseTime, HTTPCode_Target_5XX_Count, and HealthyHostCount. Establish baselines during normal operation so you can detect anomalies quickly. Configure alarms with appropriate thresholds that alert your team before users notice problems. Integrate these metrics with your incident management system for automated escalation.

Conclusion and Next Steps

You’ve just built a production-grade load balancing architecture. You created an internet-facing Application Load Balancer, configured target groups with health checks, enabled session stickiness for stateful applications, and implemented path-based routing to serve multiple applications from a single endpoint.

This pattern is foundational in AWS. Whether you’re running a monolith, microservices, or something in between, ALBs will be part of your architecture. The skills you practiced here—configuring listeners, writing routing rules, troubleshooting health checks—translate directly to production environments.

Next Lab Recommendation: Ready to make this architecture truly production-ready? In Lab 3.5, you’ll integrate Auto Scaling Groups with your ALB. Your target groups will automatically scale based on demand, and you’ll never manually register instances again. (Related post: {link to Lab 3.5})

For more AWS step-by-step tutorials and DevOps hands-on labs, explore our AWS Fundamentals series. Questions about this lab? Drop a comment below.

External References:

• AWS Application Load Balancer Documentation
• Target Groups for Application Load Balancers
• Sticky Sessions for Application Load Balancers