Study guide
Technical reference and lesson notes
Purpose of This Lesson
Elastic Load Balancing (ELB) provides a managed entry point for applications and distributes incoming connections across multiple targets. It improves availability and fault tolerance by spreading traffic across targets in multiple Availability Zones and removing unhealthy targets from service.
For SAP-C02 scenarios, the key decision is selecting the correct load balancer type based on the required protocol layer, routing behavior, performance, target type, and network appliance integration.
Key Concepts
ELB as a highly available application endpoint
A load balancer presents a single DNS endpoint to clients while distributing requests or connections across registered targets. Targets can include:
- EC2 instances
- ECS tasks or services
- Private IP addresses
- Lambda functions, where supported by the Application Load Balancer
- Other load balancers in architectures that require chaining
A typical architecture places an Auto Scaling group of EC2 instances across multiple subnets and Availability Zones behind a load balancer. The load balancer distributes traffic, while Auto Scaling maintains the desired capacity and replaces instances when necessary.
Target groups and health checks
A target group defines a set of targets and the configuration used to route traffic to them. Health checks are configured at the target-group level and determine whether a target should receive traffic.
For an HTTP application, a health check can connect to a port such as 80 and request a specified path. The load balancer evaluates the response against the configured success criteria, such as an expected HTTP status code.
When a target fails health checks repeatedly:
- The load balancer marks the target unhealthy.
- New traffic is routed to healthy targets instead.
- Existing connections may be handled according to the load balancer and protocol behavior.
- If the target belongs to an Auto Scaling group and the relevant health-check integration is enabled, Auto Scaling can terminate and replace the unhealthy instance.
The load balancer does not itself repair an EC2 instance. It stops routing traffic to the target; Auto Scaling is responsible for replacement when configured to use load-balancer health information.
Auto Scaling integration
Auto Scaling groups can span multiple Availability Zones. As instances launch, they are registered with the load balancer through the group integration. When instances terminate, they are deregistered.
This produces two complementary control loops:
- Elastic Load Balancing: routes traffic only to healthy registered targets.
- Auto Scaling: maintains capacity and replaces instances that fail the configured health criteria.
The load balancer provides traffic distribution, but it does not guarantee that an Auto Scaling group is correctly distributed across Availability Zones. The Auto Scaling group and subnet configuration must support the desired multi-AZ design.
Load Balancer Types
Application Load Balancer
The Application Load Balancer (ALB) operates at Layer 7 and understands HTTP and HTTPS requests. It is appropriate when routing decisions depend on application-level information such as the hostname or URL path.
Common capabilities include:
- Host-based routing, such as routing
api.example.comandwww.example.comto different target groups - Path-based routing, such as sending
/ordersand/accountto different target groups - HTTP and HTTPS listeners
- Routing to EC2 instances, containers, IP addresses, and Lambda functions
- Microservices and container-oriented architectures
Because an ALB examines HTTP requests, it is the appropriate choice when the architecture needs URL-aware or host-aware routing.
Network Load Balancer
The Network Load Balancer (NLB) operates at Layer 4 and handles connection-level traffic such as TCP and UDP. It does not make routing decisions based on HTTP paths or host headers.
Choose an NLB when the design requires:
- Very high performance
- Very low latency
- TCP or UDP traffic
- Static IP addresses
- Elastic IP addresses associated with the load balancer in Availability Zones
- TLS termination or offloading at high scale
- Support for VPC endpoint services using AWS PrivateLink
An NLB is useful for non-HTTP applications and for clients or firewalls that require stable, allowlisted IP addresses. An ALB’s DNS name should generally be used rather than attempting to treat its dynamically managed addresses as fixed firewall entries.
Gateway Load Balancer
The Gateway Load Balancer (GWLB) is designed for deploying, scaling, and managing virtual network appliances. Typical appliances include:
- Firewalls
- Intrusion detection systems
- Intrusion prevention systems
- Deep packet inspection systems
- Other third-party security or network appliances
GWLB uses the GENEVE protocol to transport traffic to and from appliance targets. Its purpose is centralized traffic inspection and appliance insertion, not HTTP path routing or ordinary application load balancing.
Classic Load Balancer
Classic Load Balancer is the legacy ELB type. New designs should normally use ALB, NLB, or GWLB based on the application and networking requirements rather than selecting Classic Load Balancer for new deployments.
Architecture Decision Guide
| Requirement | Recommended service | Reason |
|---|---|---|
| HTTP or HTTPS application with URL-path routing | ALB | Operates at Layer 7 and understands HTTP request attributes |
| Routing based on hostname | ALB | Supports host-based routing |
| Microservices or container workloads using HTTP | ALB | Can route requests to separate target groups and supports container-oriented targets |
| Lambda target behind an HTTP endpoint | ALB | Supports Lambda functions as targets |
| TCP application | NLB | Provides Layer 4 connection handling |
| UDP application | NLB | Supports UDP traffic |
| Extremely low latency and high throughput | NLB | Designed for high-performance Layer 4 traffic |
| Static or allowlisted IP addresses | NLB | Supports fixed Elastic IP addresses per enabled Availability Zone |
| TLS termination at high scale | NLB | Provides high-performance Layer 4/TLS handling |
| VPC endpoint service provider | NLB | Integrates with AWS PrivateLink endpoint services |
| Central inspection through virtual appliances | GWLB | Inserts and scales firewalls and other network appliances |
| HTTP path routing through a security appliance | Usually GWLB plus the appropriate appliance; ALB may be separate | GWLB handles appliance insertion, while ALB handles application-aware HTTP routing |
Exam-Relevant Takeaways
- ELB provides a single managed endpoint and distributes traffic among registered targets.
- Target groups own the health-check configuration and target registration behavior.
- An unhealthy target is removed from load-balancer rotation; it is not automatically repaired unless another service, such as Auto Scaling, replaces it.
- ALB is the Layer 7 choice for HTTP/HTTPS, host-based routing, and path-based routing.
- NLB is the Layer 4 choice for TCP/UDP, high performance, low latency, static IP requirements, and PrivateLink endpoint services.
- GWLB is the choice for scaling and inserting virtual network appliances.
- Multi-AZ availability depends on deploying targets and load-balancer capacity across appropriate Availability Zones.
- A load balancer and Auto Scaling group solve different problems: ELB routes traffic, while Auto Scaling maintains compute capacity.
- If a question emphasizes URL paths or hostnames, think ALB. If it emphasizes TCP/UDP, static IPs, or ultra-low latency, think NLB. If it emphasizes firewalls or inspection appliances, think GWLB.
Common Exam Traps
- Choosing NLB for path-based routing: NLB operates at Layer 4 and does not route based on URL paths or HTTP host headers.
- Choosing ALB solely because the workload uses EC2: Both ALB and NLB can route to EC2 targets. The protocol and routing requirements determine the choice.
- Assuming a failed health check terminates an instance: ELB removes the target from service. Instance termination and replacement require Auto Scaling behavior or another remediation mechanism.
- Confusing GWLB with a security service: GWLB distributes traffic to virtual appliances; it does not replace the firewall, IDS, or IPS functionality of those appliances.
- Assuming all load balancers provide static IP addresses: Static Elastic IP requirements strongly favor NLB. Do not assume ALB addresses are stable for allowlisting.
- Treating target health as application correctness: A basic health check can show that an endpoint returns an expected response, but it may not prove that every dependency or business function is healthy. Design health-check endpoints carefully.
- Ignoring Availability Zones: A load balancer alone does not make a single-AZ target fleet resilient. Targets should be distributed across multiple Availability Zones where the workload requires high availability.
- Assuming load balancing preserves application sessions automatically: If an application relies on in-memory session state, use an appropriate session-management design rather than assuming a user will always return to the same target.
Real-World Engineer Notes
- Use a dedicated, lightweight health-check endpoint. It should verify the level of dependency health needed to stop traffic from reaching an unusable target, but it should not be so dependency-heavy that a temporary downstream issue causes unnecessary mass deregistration.
- Configure Auto Scaling to use load-balancer health checks when an unhealthy application instance should be replaced rather than merely removed from traffic.
- Keep security groups and network ACLs aligned with the traffic path. Targets should accept application traffic from the load balancer or approved source path, not indiscriminately from the entire internet.
- Use separate target groups when different routes, services, ports, or deployment versions require independent health checks and scaling behavior.
- For static IP allowlisting, verify that an NLB is actually the required abstraction. If the consumer needs a stable service endpoint rather than appliance-style IP filtering, a DNS-based design may be simpler.
- GWLB architectures require careful traffic steering and return-path design. Inserting an appliance into a path without accounting for symmetric flows can cause connection failures.
- When chaining load balancers, document which layer makes each routing decision. For example, an NLB may provide stable Layer 4 entry while an ALB performs HTTP-aware routing behind it.
Quick Reference Summary
| Load balancer | Layer | Primary protocols or function | Key differentiators |
|---|---|---|---|
| ALB | 7 | HTTP/HTTPS | Host-based and path-based routing; application-aware targets |
| NLB | 4 | TCP/UDP and TLS use cases | High performance, low latency, static Elastic IP support, PrivateLink integration |
| GWLB | Appliance insertion | GENEVE-based virtual appliance traffic | Scales and centralizes firewalls, IDS/IPS, and inspection appliances |
| Classic Load Balancer | Legacy | Older ELB model | Avoid for new architecture decisions |
Flashcards
- Q: What is the main purpose of Elastic Load Balancing?
A: To provide a managed endpoint and distribute traffic across registered targets, improving availability and fault tolerance.
- Q: Where are ELB health checks configured?
A: In the target group configuration.
- Q: What happens when a target fails its load-balancer health checks?
A: The load balancer marks it unhealthy and stops sending new traffic to it.
- Q: Which service replaces an unhealthy EC2 instance in an Auto Scaling group?
A: Auto Scaling, when configured to use the relevant load-balancer health checks and replacement behavior.
- Q: Which load balancer supports path-based routing?
A: Application Load Balancer.
- Q: Which load balancer is designed for TCP and UDP traffic?
A: Network Load Balancer.
- Q: Which load balancer should be considered when static Elastic IP addresses are required?
A: Network Load Balancer.
- Q: Which load balancer is designed for virtual firewalls and intrusion detection appliances?
A: Gateway Load Balancer.
- Q: What protocol does Gateway Load Balancer use for appliance traffic?
A: GENEVE.
- Q: What is the major architectural distinction between ALB and NLB?
A: ALB makes Layer 7 HTTP-aware routing decisions, while NLB provides Layer 4 connection-level load balancing.
- Q: Which load balancer can use Lambda functions as targets?
A: Application Load Balancer.
- Q: Which load balancer integrates with VPC endpoint services?
A: Network Load Balancer through AWS PrivateLink.
Practice Questions
Question 1
A company hosts several HTTP microservices on ECS. Requests to /orders must go to one service, while requests to /customers must go to another. The company wants a managed load balancer in front of the services. Which solution best meets the requirement?
A. Network Load Balancer with UDP listeners
B. Application Load Balancer with path-based listener rules
C. Gateway Load Balancer with a firewall target group
D. Classic Load Balancer with TCP listeners
Correct answer: B.
An ALB operates at Layer 7 and can inspect the HTTP path to route requests to separate target groups. NLB and GWLB do not provide this application-level path-routing function.
Question 2
A provider exposes a private TCP-based service to customers in other VPCs. Customers connect through AWS PrivateLink and require a stable service endpoint. Which load balancer is the best fit behind the endpoint service?
A. Application Load Balancer
B. Network Load Balancer
C. Gateway Load Balancer
D. Classic Load Balancer
Correct answer: B.
NLB supports VPC endpoint services through AWS PrivateLink and is appropriate for TCP connection-level traffic. GWLB is intended for virtual appliance insertion rather than ordinary service exposure.
Question 3
An application runs on EC2 instances in an Auto Scaling group across three Availability Zones. One instance returns failures from its configured HTTP health-check path. What is the expected behavior when the failure persists?
A. The load balancer continues routing traffic until the instance is manually terminated.
B. The load balancer stops routing traffic to the target, and Auto Scaling can replace it if configured to use load-balancer health checks.
C. The load balancer repairs the operating system on the instance.
D. Auto Scaling immediately scales in the entire group.
Correct answer: B.
ELB removes the unhealthy target from rotation. With the appropriate Auto Scaling health-check configuration, the group can terminate and replace the failed instance while healthy targets continue serving traffic.
Question 4
A security architecture requires all traffic to pass through a fleet of third-party firewalls and intrusion prevention appliances. The appliances must be centrally deployed and automatically scaled. Which AWS service is designed for this requirement?
A. Application Load Balancer
B. Network Load Balancer
C. Gateway Load Balancer
D. Amazon Route 53 only
Correct answer: C.
GWLB is purpose-built to distribute traffic across virtual network appliances and provides the traffic-insertion model needed for centralized inspection. The appliances themselves provide the firewall or intrusion-prevention functions.
Question 5
A legacy UDP application requires very low latency and clients must allowlist fixed IP addresses for the service in their firewalls. Which load balancer is the most appropriate choice?
A. Application Load Balancer
B. Network Load Balancer with Elastic IP addresses
C. Gateway Load Balancer with HTTP listeners
D. Classic Load Balancer with path-based routing
Correct answer: B.
NLB supports UDP, is designed for low-latency Layer 4 traffic, and can use static Elastic IP addresses in enabled Availability Zones. ALB is an HTTP/HTTPS Layer 7 service and is not appropriate for this requirement.