AWS Pass traffic from NLB to an ALB?
Master System Design with Codemia
Enhance your system design skills with over 120 practice problems, detailed solutions, and hands-on exercises.
AWS Networking and Load Balancing
Amazon Web Services (AWS) provides a comprehensive suite of networking services designed to facilitate efficient user traffic handling and management. Among them, the Network Load Balancer (NLB) and Application Load Balancer (ALB) are significant components of AWS's Elastic Load Balancing (ELB) service. While both NLB and ALB serve the primary purpose of distributing incoming application traffic, they are optimized for different use cases. Understanding how to pass traffic from an NLB to an ALB is crucial for architecting sophisticated AWS infrastructure for applications that require high availability and fault tolerance.
Network Load Balancer and Application Load Balancer Overview
Network Load Balancer (NLB)
The Network Load Balancer operates at Layer 4 (Transport layer) of the OSI model. It is designed to handle millions of requests per second while maintaining ultra-low latencies. NLB is suitable for scenarios that require high performance and speed, such as handling TCP traffic. It can continue to function in the face of sudden and volatile traffic patterns without sacrificing packet delivery.
Key features of NLB:
- Static IPs: Provides a static IP address per Availability Zone.
- Preservation of Source IP: Maintains the original client's IP, which can be essential for certain applications.
- Cross-Zone Load Balancing: Distributes requests evenly across registered instances regardless of Availability Zone.
Application Load Balancer (ALB)
The Application Load Balancer operates at Layer 7 (Application layer) and provides advanced request routing to microservices or container-based applications. It is capable of forwarding HTTP(S) requests to different backend targets based on the content of the request, such as headers, path, or host.
Key features of ALB:
- Advanced Routing: Routes based on URL path, query string, and headers.
- WebSockets Support: Useful for real-time applications.
- HTTP/2 Support: Improved loading speed and reduced latency.
Passing Traffic from NLB to ALB: Use Cases and Configuration
A common architecture pattern is to use an NLB to handle incoming TCP connections, which are then forwarded to an ALB for more complex Layer 7 processing. This is particularly useful in scenarios where high-speed packet processing is needed alongside content-based routing, such as with modern microservices.
Configuration Steps
- Setup NLB: Start by creating an NLB in the desired VPC. Define listeners (usually on TCP port 80 or 443) and target groups that will forward traffic to the ALB.
- Configure ALB: Create an ALB and set it to listen on the TCP or HTTP port defined in the NLB target group.
- Target Groups and Health Checks: For both NLB and ALB, carefully configure target groups and health checks. The NLB target group will have the ALB's targets, and the ALB's target group will direct traffic to the actual application servers.
- Security Groups and NACLs: Ensure that the security groups and Network ACLs permit traffic between NLB and ALB as well as from ALB to backend hosts.
- DNS and Domain Setup: Utilize Route 53 (or another DNS management tool) to route traffic to NLB which serves as your initial entry point before passing traffic onto ALB.
Example: Traffic Flow
Suppose a user accesses https://example.com
. The Route 53 DNS routes them to the NLB. The NLB, upon receiving the request, forwards the traffic based on transport-level attributes to the corresponding ALB using the correct target group. The ALB then handles Layer 7 processing based on request details before distributing it to appropriate backend services.
Benefits and Considerations
Benefits
- Robust Scalability: Combining NLB with ALB allows for handling vast amounts of data and sophisticated application logic.
- High Availability: Supports failover mechanisms across Availability Zones.
- Operational Efficiency: Separates concerns of raw data throughput (NLB) from HTTP logic (ALB).
Considerations
- Cost: Utilizing multiple load balancers incurs additional costs.
- Latency: While both NLB and ALB are optimized for low latency, the chaining of load balancers might introduce marginal delays.
- Complexity: The architecture can be more complex with multiple components needing configuration and management.
Summary Table
| Feature / Aspect | Network Load Balancer (NLB) | Application Load Balancer (ALB) |
| OSI Layer | Transport (Layer 4) | Application (Layer 7) |
| Traffic Type | TCP/UDP | HTTP/HTTPS |
| Use Case | High throughput with low latency | Advanced request routing |
| IPs | Static IPs in each AZ | Managed by AWS |
| Source IP Preservation | Yes | No (Can be added to header) |
| Pricing Consideration | Per LCU and hours | Per LCU and hours |
In conclusion, bridging NLB to ALB is a powerful strategy to leverage the strengths of both load balancing models, enhancing the throughput, security, and application logic handling capabilities of your AWS deployment. Architects must carefully plan and configure each component to maximize performance and cost-efficiency while ensuring application availability and user satisfaction.

