ALB and NLB Deployments: Target Groups, Routing, and Client IPs – SAP-C02 Study Guide | AWS Systems Architect Professional

Study guide

Technical reference and lesson notes

Purpose of This Lesson

Application Load Balancer (ALB) and Network Load Balancer (NLB) deployments use similar building blocks—load balancers, listeners, target groups, health checks, and registered targets—but they solve different architectural problems.

The key design decision is whether traffic must be understood at the HTTP application layer or handled at the TCP/UDP connection layer with extremely low latency and high connection rates.

Key Concepts

Load balancer nodes and Availability Zones

When you enable Availability Zones and subnets for a load balancer, AWS deploys load balancer nodes into those Availability Zones. For resilient architectures:

Enable multiple Availability Zones.
Use subnets in each selected Availability Zone.
Ensure targets are distributed across the enabled Availability Zones.
Configure security groups and network ACLs to permit traffic between the load balancer and targets.

The load balancer accepts client traffic through its listeners and forwards eligible requests or connections to registered targets in target groups.

Target groups

A target group defines how the load balancer communicates with back-end targets. Its important settings include:

Target type: instance, ip, lambda for ALB; instance, ip, or alb for NLB.
Target protocol and port: The protocol and port used to reach the application.
Health checks: The protocol, port, path, and thresholds used to determine target health.
Registered targets: The instances, IP addresses, Lambda functions, or ALBs that receive traffic.
VPC association: The network context in which compatible targets are registered.

A target group can be associated with an Auto Scaling group. Instances launched by the Auto Scaling group are registered automatically, and terminated instances are removed automatically.

A target can receive traffic only when it passes the target group health check. Health checks are therefore part of traffic management, not merely monitoring.

Listeners

A listener defines the protocol and port on which the load balancer accepts traffic. Listener settings do not have to match the target group settings.

For example, an ALB can accept HTTPS on port 443, terminate TLS using an AWS Certificate Manager certificate, and forward traffic as HTTP to targets on port 8080.

A load balancer can have multiple listeners, but only one listener can use a particular protocol and port combination on that load balancer. Different applications can be exposed through different listener ports.

ALB capabilities

An ALB operates at Layer 7 and understands HTTP request information. It supports:

HTTP and HTTPS listeners and target traffic.
Host-based routing using the HTTP Host header.
Path-based routing using the request path.
Routing rules based on additional HTTP request attributes, such as headers, methods, query strings, or source IP conditions.
Target types of instances, IP addresses, and Lambda functions.
TLS termination at the load balancer.

For example:

example.com/orders can route to an orders target group.
example.com/specials can route to a promotions target group.
members.example.com can route to a members target group.

Host-based and path-based routing can be combined to create application-aware routing rules.

An ALB is not appropriate when the application requires arbitrary TCP or UDP protocols. ALB target groups use HTTP or HTTPS application traffic, and ALB health checks use HTTP or HTTPS.

NLB capabilities

An NLB operates at Layer 4 and is designed for TCP, TLS, UDP, and TCP/UDP traffic. It is useful when an architecture requires:

Very low network latency.
High connection rates.
TCP or UDP support.
Static IP addresses or Elastic IP addresses per Availability Zone.
Source IP preservation in supported configurations.
Forwarding to instances, IP addresses, or another ALB.

NLB listener protocols include TCP, TLS, UDP, and TCP_UDP. Unlike an ALB, an NLB does not inspect HTTP headers and cannot perform host-based or path-based routing.

An NLB can still support multiple applications by using different listener ports. Each listener forwards traffic to its configured target group, but routing is based on network connection information rather than HTTP request content.

An NLB can also target an ALB. This pattern can combine NLB features—such as static IP addresses or Layer 4 behavior—with ALB features such as HTTP routing. It adds architectural complexity and should be used only when those combined capabilities are required.

NLB static IP addresses

You can associate an Elastic IP address with an NLB subnet. This provides a predictable public IP address for the NLB node in that Availability Zone.

This is useful for requirements such as:

Allowlisting fixed IP addresses with external partners.
Supporting clients that cannot use DNS-based endpoint changes.
Providing stable ingress addresses for certain integrations.

An ALB uses AWS-managed IP addresses and does not provide the same per-subnet Elastic IP association model.

Client source IP behavior

Client IP visibility depends on the load balancer type and target registration mode.

For an ALB, targets generally see the load balancer node’s private IP address as the network source address. The original client address is available through the X-Forwarded-For HTTP header, which the application or reverse proxy can use for logging, authorization, rate limiting, or auditing.

For an NLB using TCP or TLS:

When targets are registered by instance ID, the client source IP can be preserved and visible to the target.
When targets are registered by IP address, the target may see the NLB node’s IP address instead.

Source IP behavior can vary with UDP, TCP_UDP, VPC endpoint, and AWS Global Accelerator configurations. Verify the exact behavior for the selected protocol and integration rather than assuming that all NLB deployments preserve the client address.

Exam-Relevant Takeaways

Use ALB for HTTP/HTTPS applications requiring host-based, path-based, or other Layer 7 routing.
Use NLB for TCP, TLS, UDP, or TCP/UDP applications, especially when low latency, high connection volume, or static IP addresses are required.
ALB target types are instance, ip, and lambda.
NLB target types are instance, ip, and alb.
ALB target and health check protocols are HTTP or HTTPS.
NLB listeners support TCP, TLS, UDP, and TCP_UDP. NLB health checks can use TCP, HTTP, or HTTPS, subject to the target group configuration.
Listener ports and target group ports can differ.
An Auto Scaling group can automatically register and deregister instances with a target group.
Health checks control whether traffic is sent to a target.
ALB performs HTTP-aware routing; NLB does not.
NLB can use Elastic IP addresses per enabled subnet, while ALB does not provide that same static-IP association capability.
For ALB client IP logging, use X-Forwarded-For rather than expecting the target’s network connection to contain the original source IP.
NLB client IP preservation depends on target type and protocol, so inspect the specific deployment design.

Architecture Decision Guide

Requirement	Recommended choice	Reason
Route requests by URL path	ALB	Layer 7 path-based routing
Route requests by hostname or subdomain	ALB	Inspects the HTTP `Host` header
Serve Lambda functions behind a load balancer	ALB	Supports Lambda target groups
Support arbitrary TCP traffic	NLB	Layer 4 TCP listener and target traffic
Support UDP traffic	NLB	Supports UDP and TCP_UDP listeners
Require static public IPs per Availability Zone	NLB	Supports Elastic IP association per subnet
Need extremely low latency and high connection rates	NLB	Optimized for Layer 4 connection handling
Preserve the client IP for supported TCP/TLS instance targets	NLB with instance targets	Source IP preservation is available in this configuration
Terminate HTTPS and route to multiple application services	ALB	TLS termination plus Layer 7 rules
Combine static IP ingress with HTTP routing	NLB in front of ALB	NLB provides the ingress characteristics; ALB provides application routing

Common Exam Traps

Choosing ALB for TCP or UDP: ALB is an HTTP/HTTPS application load balancer. Select NLB for non-HTTP protocols.
Assuming all load balancers preserve client IPs: ALB targets generally see the load balancer node’s IP at the network layer. Use X-Forwarded-For for the original client IP.
Assuming NLB always preserves source IP: NLB behavior depends on protocol and whether targets are registered by instance ID or IP address.
Confusing listener protocol with target protocol: An HTTPS listener can forward HTTP to a target group. They are separate configuration points.
Expecting NLB to perform path-based routing: NLB routes at Layer 4. It cannot inspect /orders or a hostname in an HTTP request.
Forgetting target health: A registered target does not necessarily receive traffic. It must pass the target group’s health checks.
Using an ALB when a partner requires fixed IP allowlists: Consider an NLB with Elastic IP addresses, or another architecture that meets the fixed-ingress requirement.
Assuming target groups register instances permanently: With an Auto Scaling group integration, targets are added and removed as the group scales.

Real-World Engineer Notes

Design health checks to test application readiness, not merely whether a process is listening on a port. A useful endpoint can verify critical dependencies while avoiding unnecessarily expensive checks.
Use separate target groups when application components have different ports, health endpoints, scaling policies, or deployment lifecycles.
When an ALB terminates TLS, secure the ALB-to-target connection with HTTPS when encryption in transit is required across the entire path.
Confirm that target security groups allow traffic from the load balancer on the target port. Do not expose target instances broadly just because the load balancer is public.
If application logs need the real user IP behind an ALB, configure the application or web server to trust and process X-Forwarded-For only from trusted proxy paths.
NLB in front of ALB is a specialized pattern. Evaluate DNS, health checks, TLS ownership, observability, and operational complexity before adopting it.
For source-IP-dependent controls, test the complete path, including NAT gateways, VPC interface endpoints, PrivateLink, Global Accelerator, and proxy layers.

Quick Reference Summary

ALB: Layer 7, HTTP/HTTPS, host/path/header-aware routing, instance/IP/Lambda targets.
NLB: Layer 4, TCP/TLS/UDP/TCP_UDP, very low latency, instance/IP/ALB targets.
Target group: Defines target type, target protocol and port, health checks, and registered targets.
Listener: Defines the protocol and port accepted by the load balancer.
Health checks: Only healthy targets receive forwarded traffic.
Auto Scaling integration: Instances are registered and deregistered automatically.
Static ingress IPs: Use Elastic IPs with NLB subnets when supported by the design.
ALB client IP: Retrieve the original address from X-Forwarded-For.
NLB client IP: Verify preservation based on protocol and target registration type.

Flashcards

Q: Which load balancer supports host-based and path-based routing?

A: Application Load Balancer (ALB), because it operates at Layer 7 and can inspect HTTP request data.

Q: Which load balancer should be used for UDP applications?

A: Network Load Balancer (NLB).

Q: What are the ALB target types?

A: Instance, IP address, and Lambda function.

Q: What are the NLB target types?

A: Instance, IP address, and Application Load Balancer.

Q: Can a listener port differ from the target group port?

A: Yes. For example, an ALB can listen on HTTPS 443 and forward HTTP traffic to targets on 8080.

Q: What happens to an instance associated with an Auto Scaling group and target group?

A: It is registered when launched and deregistered when terminated.

Q: Which load balancer can use Elastic IP addresses per subnet?

A: Network Load Balancer.

Q: How does an ALB expose the original client IP to an application?

A: Through the X-Forwarded-For HTTP header.

Q: Does an NLB support path-based routing?

A: No. NLB routing is based on Layer 4 connection information, such as protocol and port.

Q: Why might an NLB be placed in front of an ALB?

A: To combine NLB capabilities, such as static IP addresses or Layer 4 handling, with ALB Layer 7 routing.

Q: What determines whether a target receives traffic?

A: Its target group health check status. Only healthy targets receive forwarded traffic.

Q: What is a common reason to choose NLB instead of ALB for a web-facing service?

A: The service requires static IP addresses, TCP/UDP support, source-IP behavior available in a specific configuration, or very high connection performance.

Practice Questions

Question 1

A company hosts three HTTP services behind one load balancer. Requests to /orders must go to one target group, requests to /catalog to another, and requests to admin.example.com to a third. Which solution meets the requirement?

A. Network Load Balancer with one TCP listener
B. Application Load Balancer with host- and path-based listener rules
C. Network Load Balancer with UDP listeners
D. Gateway Load Balancer with separate target groups

Correct answer: B

Explanation: ALB operates at Layer 7 and can inspect both the HTTP host header and URL path. NLB cannot perform HTTP-aware routing.

Question 2

An application uses a proprietary TCP protocol and requires a fixed public IP address in each Availability Zone so a business partner can allowlist the service. Which design is most appropriate?

A. Public ALB with path-based routing
B. Internal ALB with an ACM certificate
C. NLB with TCP listeners and Elastic IP addresses associated with its subnets
D. ALB with a static private IP configured on each target

Correct answer: C

Explanation: NLB supports TCP traffic and can associate Elastic IP addresses with its subnet mappings. ALB is intended for HTTP/HTTPS and does not provide this same static per-subnet Elastic IP model.

Question 3

An HTTPS ALB must terminate TLS at the load balancer but forward unencrypted HTTP traffic to web servers listening on port 8080. Which configuration is valid?

A. HTTPS listener on 443 forwarding to an HTTP target group on 8080
B. HTTP listener on 8080 forwarding to an HTTPS target group on 443 only
C. TCP listener on 443 forwarding to a Lambda target group
D. UDP listener on 443 forwarding to an HTTP target group

Correct answer: A

Explanation: Listener protocol and target group protocol are independent. An ALB can terminate HTTPS on port 443 and forward HTTP traffic to targets on port 8080.

Question 4

A web application behind an ALB needs to record the original client IP address for auditing. The application currently records the source address from the network connection and sees the ALB node’s private IP. What should the architect recommend?

A. Replace the ALB with a UDP NLB
B. Read the client address from the X-Forwarded-For HTTP header
C. Read the target instance’s private IP address
D. Add a second ALB listener on port 443

Correct answer: B

Explanation: ALB forwards the original client address in the X-Forwarded-For header. The application must be configured to process the header safely.

Question 5

An Auto Scaling group launches new application instances, but the load balancer does not send traffic to them until they pass an application health endpoint. Which configuration provides this behavior?

A. Register instances manually and disable health checks
B. Attach the Auto Scaling group to a target group with an appropriate health check
C. Configure an NLB listener with a different port only
D. Add an Elastic IP to every application instance

Correct answer: B

Explanation: Associating the Auto Scaling group with a target group automatically registers and deregisters instances. The target group’s health check determines when each instance becomes eligible for traffic.