# Application Load Balancer

> Source: Courseiva IT Certification Glossary — https://courseiva.com/glossary/application-load-balancer

## Quick definition

An Application Load Balancer works like a smart traffic cop for your website or app. It takes incoming user requests and sends them to different servers so no single server gets overwhelmed. If one server fails, it stops sending traffic there and uses the healthy ones instead. This helps your application stay up and running smoothly even under heavy use.

## Simple meaning

Imagine you own a busy coffee shop with several baristas behind the counter. Without any system in place, customers would just crowd around one barista, leaving others idle and creating long lines. That would make everyone frustrated. An Application Load Balancer is like having a friendly host at the door who looks at the line, sees which barista is free, and sends the next customer to that barista. The host also checks if a barista is sick or on break and does not send customers there. The host works at the application layer, meaning they look at what the customer wants. If a customer wants a latte, the host might send them to a barista who specializes in espresso drinks. If another customer wants a cold brew, the host sends them to a different barista. This is what an Application Load Balancer does for web applications. It receives incoming requests from users, inspects the request details like the URL or the type of content requested, and then routes the request to the most appropriate server. Servers that are handling too many requests get a break, and those that are idle get more work. The load balancer also regularly checks if each server is healthy. If a server goes down or becomes slow, the load balancer stops sending traffic to it until it recovers. For users, this means faster load times and fewer errors. For the business, it means the application can handle more users without crashing. In AWS, the Application Load Balancer operates at Layer 7 of the OSI model, which means it understands web protocols like HTTP and HTTPS. This gives it the ability to make smart routing decisions based on the content of each request.

Think of it this way. Without an Application Load Balancer, if you have two web servers, one might get thousands of requests while the other gets only a few. That waste of resources can cause crashes. With an Application Load Balancer, the traffic is spread evenly, and each server only handles its fair share. This makes the whole system more efficient, more reliable, and easier to scale. When you need to handle more users, you simply add more servers, and the load balancer automatically starts sending traffic to them. You do not need to change anything in your application code.

## Technical definition

An Application Load Balancer (ALB) is a fully managed Layer 7 load balancing service provided by Amazon Web Services (AWS). It operates at the application layer of the Open Systems Interconnection (OSI) model, which means it can inspect the content of network packets beyond TCP and UDP headers. ALB supports HTTP, HTTPS, HTTP/2, WebSockets, and gRPC protocols. It is designed to distribute incoming traffic across multiple targets, such as Amazon EC2 instances, AWS Lambda functions, IP addresses, containers in Amazon ECS, or on-premises servers. One of the key features of ALB is content-based routing. This means the ALB can examine the request path, host header, query string, HTTP method, source IP, and headers to decide where to send the traffic. For example, you can configure rules that send requests for /api to a group of backend servers and requests for /images to a different group. This enables microservices architectures where each service runs on its own set of targets.

ALB uses listener configurations to define the ports and protocols it accepts. Each listener can have multiple rules that specify conditions and actions. Common actions include forwarding requests to a target group, redirecting to another URL, or returning a fixed response. Target groups are logical groupings of targets that share the same characteristics, such as the same application version or the same security group. Health checks are performed on each target in a target group to determine if it is healthy and able to receive traffic. If a target fails health checks, ALB stops sending traffic to it until it passes checks again. ALB supports two types of health checks: HTTP health checks and HTTPS health checks. You configure the health check path, interval, timeout, and threshold values. ALB also supports stickiness using cookies, which allows a user's requests to be consistently sent to the same target if needed. SSL/TLS termination is another critical feature. ALB can decrypt incoming HTTPS traffic, offloading the compute-intensive encryption and decryption work from the backend servers. This simplifies certificate management and improves backend performance.

ALB scales automatically based on traffic. You do not need to pre-provision capacity. It can handle millions of requests per second. It integrates with AWS WAF (Web Application Firewall) to provide protection against common web exploits. Access logs can be enabled to record detailed information about each request, which helps with troubleshooting and analytics. ALB also supports connection idle timeout settings, cross-zone load balancing, and slow start modes. In AWS, ALB is often used in conjunction with Auto Scaling groups to automatically add or remove targets based on demand. For high availability, you deploy ALB across multiple Availability Zones. This means if one Availability Zone fails, traffic is routed to healthy zones. ALB supports private and public subnets, and you can associate an Elastic IP address or use a DNS name provided by AWS. The DNS-based endpoint ensures that clients always connect to the load balancer, and AWS handles the routing internally. When implementing an ALB, you must define security group rules to allow traffic from the load balancer to the targets, and from clients to the load balancer. ALB uses the well-known ports 80 (HTTP) and 443 (HTTPS) by default, but you can configure custom ports. Overall, the Application Load Balancer is a foundational component for building scalable, resilient, and secure web applications in AWS.

## Real-life example

Think about a busy airport with multiple check-in counters. Passengers arrive at different times, some with online check-in, some with luggage, some with special requests. Without a good system, all passengers might rush to the same counter, causing chaos. Now, imagine the airport has a smart digital board that directs each passenger to a specific counter based on their needs. The board checks if you have online check-in and sends you to a fast lane. If you have luggage, it sends you to a counter with a baggage belt. If you are a VIP, it directs you to a premium lane. This board also watches each counter. If a counter agent is slow or the line is too long, it stops sending passengers there and reroutes them to other counters. This is exactly how an Application Load Balancer works.

The passengers are web requests coming from users. The check-in counters are the backend servers. The smart digital board is the ALB. The ALB looks at the details of each request, just like the board looks at passenger details. If a request is for a login page, the ALB sends it to servers that handle authentication. If a request is for a product image, the ALB sends it to servers that store images. The ALB also checks if servers are healthy by doing a health check, similar to how the board checks if a counter is working. If a server goes down, the ALB stops sending traffic there, just like the board stops sending passengers to a closed counter.

the airport might have more counters open during peak hours and fewer during off-peak hours. The ALB works with Auto Scaling to automatically add new servers when traffic increases. This is like the airport opening extra counters when the terminal gets crowded. The ALB handles all this without any interruption to passengers. For IT teams, the ALB is a crucial tool that allows them to scale applications easily, improve performance, and ensure high availability.

## Why it matters

In modern IT infrastructure, applications must serve thousands or even millions of users simultaneously. A single server cannot handle that load reliably. An Application Load Balancer is essential because it distributes traffic across multiple servers, preventing any single server from becoming a bottleneck. This directly improves the user experience by reducing latency and preventing timeouts. When users encounter slow websites or error messages, they often leave and never return. Using an ALB helps businesses retain customers and maintain a professional image.

From an operational perspective, ALB simplifies maintenance. You can take a server offline for updates or patching without causing downtime because the load balancer stops sending traffic to it. This enables blue-green deployments, rolling updates, and A/B testing. For example, you can route a small percentage of traffic to a new version of your application, test it, and then gradually increase the traffic if it works well. This reduces the risk of deploying broken code. ALB also enhances security. By terminating SSL/TLS at the load balancer, you reduce the attack surface on backend servers. You can also integrate ALB with AWS WAF to filter out malicious requests before they reach your application.

For cloud architects, ALB is a key component for building highly available and fault-tolerant systems. By deploying ALB across multiple Availability Zones, you achieve resilience against data center failures. If one Availability Zone goes down, traffic is automatically redirected to the remaining zones. This is critical for applications that need to meet service level agreements (SLAs) of 99.99% uptime. The Application Load Balancer matters because it is the glue that holds scalable, secure, and resilient web applications together. It is not an optional add-on but a necessity for any production-grade system.

## Why it matters in exams

The Application Load Balancer is a core topic for the AWS Cloud Practitioner and AWS SysOps Administrator Associate exams. For the Cloud Practitioner exam, you need to understand what an ALB is at a high level. The exam objective under 'High Availability and Fault Tolerance' specifically asks about elastic load balancing. You should know that ALB is a type of load balancer that operates at Layer 7 and can route based on content. You will not be asked to configure it in detail, but you must be able to identify the scenarios where ALB is used compared to other load balancers like the Network Load Balancer or Classic Load Balancer. Questions may present a scenario where a company needs to route traffic to different microservices based on URL paths, and the correct answer would be an Application Load Balancer.

For the SysOps Administrator Associate exam, ALB appears in multiple domains, including 'Monitoring, Logging, and Remediation', 'Deployment, Provisioning, and Automation', and 'Networking and Content Delivery'. You need to know how to configure listeners, rules, target groups, and health checks. You will face scenario-based questions about troubleshooting failing health checks. For example, a question might describe a situation where an ALB shows unhealthy targets even though the applications are running. You need to know that the health check must be configured with the correct path, port, and protocol. Another common question involves stickiness. If a user's session data is stored on a specific server, you must enable sticky sessions (session affinity) so that requests from the same user go to the same server. The exams also test integration with Auto Scaling. You should understand that an ALB can be attached to an Auto Scaling group, and new instances automatically register with the load balancer. Questions may ask about the order of operations when scaling events happen.

The exams also test security group configurations. You need to know that the security group for backend EC2 instances must allow traffic from the load balancer's security group, not from the internet directly. This is a common trap. You must be aware that ALB supports path-based routing and host-based routing. Exam questions might ask you to design a solution where different subdomains go to different services, and ALB with host-based rules is the best choice. For SysOps, you may also see questions about logging. ALB access logs can be stored in S3, and you need to know how to enable them and interpret the log entries for troubleshooting. Overall, ALB is a high-probability topic in both exams, and understanding its features and common configurations is essential for passing.

## How it appears in exam questions

In AWS certification exams, questions about Application Load Balancer typically fall into three categories: scenario-based, configuration, and troubleshooting. Scenario-based questions describe a company's requirements and ask you to select the best load balancer type. For example, you might see: 'A company runs multiple microservices behind a single domain. Each microservice has a unique URL path, such as /api, /auth, and /static. Which load balancer should be used?' The answer is Application Load Balancer because it supports path-based routing. Another scenario might involve a requirement to support static IP addresses for whitelisting or WebSocket traffic. In that case, a Network Load Balancer would be more appropriate. The exam expects you to know when to choose ALB over NLB or CLB.

Configuration questions test your knowledge of ALB setup. A typical question might present a step-by-step launch wizard and ask what you need to configure first. For instance: 'You are creating an ALB. Which of the following must be defined before you can add listeners?' The correct answer is the target groups, because listeners forward traffic to target groups. You might also see questions about SSL certificates. For example: 'You need to terminate HTTPS traffic at the ALB. What must you configure?' The answer is to upload or reference an SSL certificate in AWS Certificate Manager and select HTTPS on the listener. Questions about health checks are common: 'A target group has three instances. Two pass health checks, one fails. Where will traffic be routed?' The correct answer: traffic is routed only to the healthy instances.

Troubleshooting questions often involve a broken setup. For example: 'Users cannot access the application. The ALB is showing 503 errors. The target instances are running and responding on port 80. What is the most likely cause?' The answer could be that the security group for the instances does not allow inbound traffic from the ALB security group. Another common issue: health checks are failing because the health check path is not correct. For instance, if the application's health endpoint is /health but the ALB is configured with a path of /index.html, the health check will fail. You would need to update the health check path. Questions may also involve timeouts: 'The application works for a few seconds but then returns errors. The ALB idle timeout is set to 60 seconds. The application has a long-running process that takes 2 minutes.' The fix is to increase the idle timeout or implement a better design. These question patterns test your ability to diagnose and fix real-world problems, which is what the exams assess.

## Example scenario

Imagine you are a cloud administrator for an online bookstore called BookNet. The application has three parts: a product catalog that runs on a group of EC2 instances, a payment processing service that runs on another group, and an image server that stores book covers on a third group. You want users to access the entire application through a single URL like www.booknet.com. Requests to /catalog should go to the catalog servers, requests to /checkout should go to the payment servers, and requests to /images should go to the image servers. You also want the application to handle up to 10,000 concurrent users without crashing.

To achieve this, you create an Application Load Balancer. You configure a listener on port 80 (HTTP) and port 443 (HTTPS) with an SSL certificate from AWS Certificate Manager. Next, you create three target groups: one for catalog, one for checkout, and one for images. Each target group registers the respective EC2 instances. You then create rules on the listener. The first rule says: if the path is /catalog*, forward to the catalog target group. The second rule: if the path is /checkout*, forward to the checkout target group. The third rule: if the path is /images*, forward to the images target group. You configure health checks on each target group to use the path /health. You set the health check interval to 30 seconds and the threshold to 2 consecutive failures before marking an instance unhealthy.

To handle high traffic, you create an Auto Scaling group for each target group. You attach the Auto Scaling groups to their respective target groups. Now, when traffic increases, Auto Scaling launches new instances, and the ALB automatically registers them. When traffic decreases, instances are terminated and deregistered from the ALB. You also enable cross-zone load balancing so traffic is evenly distributed across instances in different Availability Zones. Finally, you update the DNS record for www.booknet.com to point to the ALB’s DNS name. Now, users type the URL, the ALB inspects the request path, routes it to the correct service, and each service only handles its specific workload. The system is scalable, highly available, and easy to maintain. This scenario is typical of how an ALB is used in practice, and it reflects the kind of setup you might be asked to design or troubleshoot in the SysOps exam.

## Common mistakes

- **Mistake:** Thinking an Application Load Balancer works at Layer 4 (TCP) like a Network Load Balancer.
  - Why it is wrong: ALB operates at Layer 7 (Application) and can inspect HTTP headers, paths, and query strings. Layer 4 load balancers only see IP addresses and ports.
  - Fix: Remember that ALB is for HTTP/HTTPS traffic where you need content-based routing. Use NLB when you need ultra-low latency or TCP/UDP traffic.
- **Mistake:** Configuring security group rules to allow inbound traffic from the internet directly to backend EC2 instances.
  - Why it is wrong: This bypasses the load balancer and introduces security risks. Backend instances should only accept traffic from the ALB's security group.
  - Fix: In the backend instance security group, add an inbound rule that allows traffic from the ALB's security group (source: sg-xxxxx), not from 0.0.0.0/0.
- **Mistake:** Forgetting to open the correct health check port in the backend instance security group.
  - Why it is wrong: The ALB’s health checks come from its own IP addresses. If the security group blocks traffic on the health check port, the instances will appear unhealthy even if the app works.
  - Fix: Make sure the backend security group allows inbound traffic on the health check port from the ALB security group or from the VPC CIDR.
- **Mistake:** Assuming that an ALB automatically balances traffic across all targets equally without configuration.
  - Why it is wrong: By default, cross-zone load balancing is enabled on ALBs, but if it is disabled, traffic might not be evenly distributed across Availability Zones. Also, if you set stickiness, routing is not perfectly even.
  - Fix: To ensure even distribution, enable cross-zone load balancing and avoid using stickiness unless absolutely necessary for session persistence.
- **Mistake:** Using a Classic Load Balancer (CLB) when you need path-based or host-based routing.
  - Why it is wrong: CLBs operate at Layer 4 and do not support content-based routing. You would have to use multiple load balancers for different services, which is inefficient.
  - Fix: For modern applications that require routing by URL path, host header, or query string, always choose Application Load Balancer.

## Exam trap

{"trap":"A question says: 'An ALB is showing all targets as unhealthy, but the EC2 instances are running and can be pinged from the internet. What is the issue?'","why_learners_choose_it":"Learners often assume that if the instance is running and responds to ping, then everything is fine. They might suggest restarting the instance or checking the application code.","how_to_avoid_it":"Ping uses ICMP protocol, not HTTP. ALB health checks use HTTP or HTTPS to a specific path (like /health). The most common cause is that the health check path is incorrect or the web server is not configured to respond on that path. Always check the health check settings first. Also ensure the security group allows traffic from the ALB."}

## Commonly confused with

- **Application Load Balancer vs Network Load Balancer:** A Network Load Balancer (NLB) operates at Layer 4, handling TCP, UDP, and TLS traffic. It does not inspect HTTP headers or paths. NLB is best for ultra-low latency, static IP addresses, or where you need to preserve the source IP of the client. ALB is best for HTTP/HTTPS applications needing content-based routing. (Example: Use NLB for a gaming server that uses UDP. Use ALB for a web application with multiple URL paths.)
- **Application Load Balancer vs Classic Load Balancer:** The Classic Load Balancer is the legacy AWS load balancer. It operates at both Layer 4 and Layer 7 but lacks advanced features like path-based routing, host-based routing, and native WebSocket support. AWS recommends using ALB or NLB instead. CLB does not support target groups or Lambda functions as targets. (Example: If you have a simple web app with one server group, CLB might work. But if you need routing by URL path, you must use ALB.)
- **Application Load Balancer vs Amazon API Gateway:** API Gateway is a fully managed service for creating, publishing, and managing APIs. It can perform content routing like ALB, but it is specialized for RESTful and WebSocket APIs. API Gateway offers features like request throttling, API keys, and request validation. ALB is more general-purpose for distributing traffic to any backend, not just APIs. (Example: Use API Gateway to expose a REST API with rate limiting and authorization. Use ALB to load balance traffic across multiple web servers hosting a dynamic website.)

## Step-by-step breakdown

1. **Client Sends a Request** — A user types a URL in their browser or an application makes an API call. The request goes to the DNS name of the ALB, which resolves to the ALB's IP addresses.
2. **ALB Listener Accepts the Request** — The ALB has listeners configured on specific ports (e.g., 80 for HTTP, 443 for HTTPS). The listener checks the protocol and verifies the SSL certificate if using HTTPS.
3. **ALB Evaluates Routing Rules** — The ALB inspects the request details such as the URL path, host header, query strings, and HTTP method. It then matches the request against the rules defined for that listener.
4. **ALB Forwards the Request to a Target Group** — Based on the matching rule, the ALB forwards the request to a specific target group. The ALB selects a target within that group based on the load balancing algorithm (default is round robin).
5. **Target Processes the Request and Sends a Response** — The chosen target (e.g., EC2 instance, Lambda function) processes the request and generates an HTTP response. The response is sent back to the ALB.
6. **ALB Returns the Response to the Client** — The ALB sends the response back to the original client. If the client's request was HTTPS, the ALB may have decrypted it and re-encrypts the response if needed.
7. **Health Check Monitoring** — The ALB continuously sends health check requests to each target in the target group. If a target fails to respond correctly, the ALB marks it as unhealthy and stops sending traffic to it. Once the target passes health checks again, it resumes receiving traffic.

## Practical mini-lesson

To set up an Application Load Balancer in AWS, start by creating a target group. You define the target type (instance, IP, or Lambda), the protocol (HTTP/HTTPS), and the port. Then you register targets, such as EC2 instances. It is important to set up health checks properly. The health check path should be a lightweight endpoint that returns a 200 status code quickly. For example, /health or /status. You configure the interval (how often to check), timeout (how long to wait for a response), and thresholds. A common mistake is setting the threshold too low, causing flapping. A typical setup uses an interval of 30 seconds, a timeout of 5 seconds, and a threshold of 2 for unhealthy and 5 for healthy.

Next, create the ALB. Choose Internet-facing if users access it from the internet, or Internal if it is for internal traffic. Select the VPC and at least two Availability Zones for high availability. Then configure listeners. On port 443, attach an SSL certificate. You can get one from AWS Certificate Manager (ACM) for free. On the listener, add rules. For example, if path is /images/*, forward to the images target group. If host is admin.booknet.com, forward to the admin target group. If no rule matches, a default action forwards to a default target group.

Once the ALB is created, update your DNS to point to the ALB's DNS name (e.g., myalb-1234567890.us-east-1.elb.amazonaws.com). Do not use an A record with an IP address because the ALB's IP addresses can change. Always use the DNS name. In production, you often use Route 53 with an Alias record for optimal routing.

What can go wrong? The most common issue is health checks failing. This could be because the security group on the target does not allow traffic from the ALB, the health check path returns a non-200 response, or the application is not running on the correct port. Another issue is SSL certificate mismatch. Ensure that the domain name on the certificate matches the domain used by clients. Finally, be careful with idle timeout. If your application has long-running processes (e.g., file uploads), the connection might time out. You can increase the idle timeout in the ALB settings, but also implement streaming or chunked transfer. Knowing these practical details will help you not only in exams but also in real-world deployments.

## Memory tip

ALB = 'App Layer Balancer' remembers Layer 7. Think 'App' for application, 'Layer' for Layer 7, 'Balancer' for distributing traffic.

## FAQ

**Can I use an Application Load Balancer to route traffic to Lambda functions?**

Yes. ALB can directly invoke Lambda functions as targets. The Lambda function receives the HTTP request as a JSON event and returns an HTTP response.

**Does an Application Load Balancer support sticky sessions?**

Yes. ALB supports sticky sessions using cookies. You enable stickiness on a target group, and ALB uses a load balancer-generated cookie or your own cookie to route requests from the same user to the same target.

**What happens if all targets in a target group are unhealthy?**

If all targets are unhealthy, the ALB will return a 503 Service Unavailable error to the client. The ALB keeps trying health checks, and as soon as a target becomes healthy, traffic resumes.

**Can I use the same ALB for multiple applications?**

Yes. Using different listener rules based on host headers or path patterns, you can route traffic to different target groups for different applications all through one ALB.

**Is it possible to use an ALB with on-premises servers?**

Yes. You can register on-premises servers as targets using their IP addresses, provided they are reachable from the ALB via AWS Direct Connect or VPN.

**What is the difference between an ALB and a Network Load Balancer in terms of pricing?**

ALB pricing is based on the number of Load Balancer Capacity Units (LCUs) consumed, which considers connections, active connections, and processed bytes. NLB pricing is based on the number of Network Load Balancer Capacity Units (NLCUs). ALB is generally more cost-effective for HTTP traffic, while NLB is better for high-throughput TCP traffic.

## Summary

An Application Load Balancer is a fully managed AWS service that distributes incoming web traffic across multiple targets at the application layer. It uses content-based routing to send requests to different target groups based on URL paths, host headers, or other HTTP attributes. This allows you to build microservices architectures, improve application performance, and achieve high availability. The ALB automatically scales to handle traffic spikes, performs health checks to route only to healthy targets, and integrates with other AWS services like Auto Scaling, Lambda, and AWS WAF.

Understanding ALB is critical for both the AWS Cloud Practitioner and SysOps Administrator Associate exams. In the Cloud Practitioner exam, you need to recognize when to use an ALB compared to other load balancers. In the SysOps exam, you must be able to configure listeners, rules, target groups, and troubleshoot common issues like health check failures and security group misconfigurations. Common mistakes include confusing ALB with Layer 4 load balancers, forgetting to secure backend instances, and misconfiguring health checks.

The key takeaway is that the Application Load Balancer is a versatile and powerful tool for any modern cloud application. It enables you to build systems that are scalable, resilient, and easy to maintain. In the exam, remember that ALB operates at Layer 7, supports content-based routing, and is the recommended load balancer for HTTP/HTTPS applications. Use the memory hook 'App Layer Balancer' to remember its layer. With this understanding, you are well prepared to answer questions and apply the concept in real-world scenarios.

---

Practice questions and the full interactive page: https://courseiva.com/glossary/application-load-balancer