Network Load Balancer (v2)

 

A Network Load Balancer (NLB) v2 is a high-performance, Layer 4 load balancer that operates at the connection level (TCP/UDP), designed to handle millions of requests per second while maintaining ultra-low latency. It’s commonly used in cloud environments like AWS, GCP, and Azure, with enhanced features compared to its earlier versions.

Key Features of Network Load Balancer (v2)

•  Layer 4 (Transport Layer) — Operates at TCP/UDP level, ensuring fast and efficient routing.
•  High throughput & low latency — Optimized for extreme performance and scalability.
•  Source IP Preservation — Maintains the original client IP.
•  Static IP support — Provides fixed IP addresses for consistent DNS mapping. NLB has one static IP per AZ, and supports any assigned Elastic IP.
•  TLS termination (with some providers) — Offloads SSL processing from backend services.
•  Health checks — Ensures traffic is routed only to healthy targets.
•  Integration with PrivateLink/VPC Lattice (AWS) — For secure, private connectivity.
• NLB does not work for AWS free tier.
• NLB shows ultra-low latency.
• NLB can handle millions of traffic requests per seconds 

twtech Common Use Cases

1. High-performance microservices architecture
• Directs TCP/UDP traffic to containerized services in Kubernetes or ECS with high concurrency.
2. Real-time communications
• Ideal for VoIP, gaming, and video streaming applications requiring low latency and high throughput.
3. IoT backends
• Handles millions of concurrent connections from IoT devices efficiently.
4. Hybrid and on-premise connectivity
• Acts as a front door for hybrid applications communicating across on-prem and cloud environments.
5. Financial services applications
• Serves trading platforms or payment gateways needing deterministic performance and high availability.
6. TCP/UDP based protocols
• Supports DNS servers, Syslog, SIP, MQTT, and other non-HTTP workloads.

A Network Load Balancer (NLB) primarily supports Layer 4 protocols, specifically:

Supported Protocols by NLB

1. TCP (Transmission Control Protocol)
2. UDP (User Datagram Protocol)
3. TLS (Transport Layer Security) – for termination and passthrough (in newer versions)
4. TCP_UDP (Dual-protocol listeners) – allows flexibility when clients use either TCP or UDP
5. HTTP/HTTPS (indirectly) – if you route TCP on port 80/443 to services handling HTTP at the application level

 Why These Protocols

NLB operates at OSI Layer 4, which means it routes traffic based on IP address and port — not on application-layer content (like URLs or headers). Here's why these protocols are supported:

1. TCP

• Widely used and connection-oriented, ensuring reliable delivery.
• Supports long-lived connections — great for applications like databases, SSH, or custom protocols.

2. UDP

• Lightweight, connectionless — used in DNS, video/audio streaming, gaming, and real-time applications.
• NLB is optimized to handle stateless high-throughput traffic that doesn’t require connection management.

3. TLS

• Enables secure connections (either terminated at the NLB or passed through to targets).
• Offloading TLS can improve backend performance.

4. TCP_UDP

• Ideal for applications where the protocol might vary per client or use case, e.g., SIP or certain IoT apps.

 twtech-insights

NLB does not inspect or understand the content of the traffic (as an Application Load Balancer does), which makes it extremely fast and scalable — especially useful for millions of simultaneous low-latency connections.

Project: Hands-on

How twtech creates the Network Load Balancer (NLB) and use it to route traffic for applications.

Select network Load Balancer as type

Create Network Load Balancer

The Network Load Balancer distributes incoming TCP and UDP traffic across multiple targets such as Amazon EC2 instances, microservices, and containers. When the load balancer receives a connection request, it selects a target based on the protocol and port that are specified in the listener configuration, and the routing rule specified as the default action.

Network Load Balancer now supports UDP for Dualstack

Set your IP address type as dualstack and enable prefix for IPv6 source NAT. Then configure UDP-based listeners to route to IPv6 targets

Basic configuration

Load balancer name

Name must be unique within your AWS account and can't be changed after the load balancer is created.

Network mapping

The load balancer routes traffic to targets in the selected subnets, and in accordance with your IP address settings.

Attach a security group to NLB: twtech-nlb-SG

Security groups

A security group is a set of firewall rules that control the traffic to your load balancer. Select an existing security group, or you can create a new security group .

Security groups - recommended

Security groups support on Network Load Balancers can only be enabled at creation by including at least one security group. You can change security groups after creation. The security groups for your load balancer must allow it to communicate with registered targets on both the listener port and the health check port. For PrivateLink Network Load Balancers, security group rules are enforced on PrivateLink traffic; however, you can turn off inbound rule evaluation after creation within the load balancer’s Security tab or using the API.

Create a security group and attach to the NLB:

From: Remove default security group

Create security group: twtech-nlb-SG

A security group acts as a virtual firewall for your instance to control inbound and outbound traffic. To create a new security group, complete the fields below.

Add inbound rules and create security group for NLB: twtech-nlb-SG to control traffic to the NLB

Go back to nlb console, refresh and attach security group to NLB: Remove default security group.

Configure the Listeners and routing:

A listener is a process that checks for connection requests using the port and protocol you configure. The rules that you define for a listener determine how the load balancer routes requests to its registered targets.

Create target group:

Specify group details

Your load balancer routes requests to the targets in a target group and performs health checks on the targets.

Register targets to: twtech-nlb

This is an optional step to create a target group. However, to ensure that your load balancer routes traffic to this target group you must register your targets.

Also, Verify that the application in the target is accessible: UI

From:

To:

Head back to the network load balancer , refesh and select the target group created:twtech-nlb-tg

Review and create the NLB: twtech-nlb

Review the load balancer configurations and make changes if needed. After you finish reviewing the configurations, choose Create load balancer.

Give it a couple of minutes for it to be full provisioned:

From: Provisioning

To: Active

Successful:

How twtech Accesses the application (httpd)  in the target (servers) using Network Load Balancer: UI

With the DNS (Domain Name service):

twtech-nlb-d9a39047b8f9xxxx.elb.us-east-2.amazonaws.com

NB

Default Configuration allows routing after 30 seconds:

From:

To:

Monitoring and observability 

How twtech troubleshoots unhealthy targert-groups: unhealthy checks (when target display: Unused)

Steps:

Edit the inbound rules : for the instance security group:

Go to instance and edit security group: twtech-nlb-SG

Edit the inbound rules

Allow http traffic from:  alb and nlb

Successful:

How twtech Accesses the application (httpd)  in the server using Network Load Balancer: UI

With the DNS (Domain Name service):

twtech-nlb-d9a39047b8f9xxxx.elb.us-east-2.amazonaws.com

NB

Default Configuration allows routing after 30 seconds:

From: twtech-server1

To:twtech-server2

twtech-insights: Looming Question

Is it possible to use the NLB and ALB simultaneously. How is that configured and what the benefits that come with that configuration for load balancing....

Yes, using both an NLB (Network Load Balancer) and an ALB (Application Load Balancer) simultaneously is possible and often beneficial, depending on your architecture needs. This is called a hybrid load balancing setup, and it allows you to leverage the strengths of both types of load balancers.

How to Use NLB and ALB Together

You can configure them in a chained or parallel setup:

1. Chained Configuration (NLB → ALB)

• The NLB is placed in front of the ALB.
• NLB receives traffic and forwards it to ALB as the target using IP addresses or private ALB endpoints.
• This is useful when you need TLS passthrough or static IP addresses (offered by NLB), but still want layer 7 features like path-based routing (from ALB).

2. Parallel Configuration

• Both NLB and ALB operate independently.
• You route different types of traffic to each:
• NLB for TCP, gRPC, or non-HTTP(S) traffic.
• ALB for HTTP/HTTPS web traffic with advanced routing.
• DNS (Route 53) can be used to route traffic to either, based on subdomain or traffic type.

 Configuration Steps (twtech-Chained Example)

1. Create an ALB with target groups, listeners, rules (path/host-based).
2. Create an NLB with a listener for TCP/UDP or TLS.
3. Register the ALB’s IPs or endpoints as targets in the NLB's target group.
• This usually means resolving ALB's private link (if internal) or IPs (via scripts).
4. Configure Route 53 or other DNS to direct traffic to the NLB.

 Benefits of Combining ALB and NLB

Feature	ALB	NLB	Combo Benefit
Layer	L7 (HTTP/HTTPS)	L4 (TCP/UDP/TLS)	Full protocol support
Routing	Path- and host-based	None	Application-level routing + L4 speed
TLS Termination	Yes	Yes or passthrough	Offload at ALB, use NLB for passthrough
Static IP	No	Yes	NLB gives stable IPs
High Performance	Moderate	Very High	Fast L4 with intelligent L7 logic
WebSockets & gRPC	Yes	Yes	More flexibility
Hybrid Workloads	Limited	Yes	Full support (IoT, APIs, Web Apps)

 twtech-Common Use Cases

• Security + Flexibility: Use NLB for WAF integration or TLS passthrough, then ALB for app logic.
• IoT + Web Apps: Route IoT (MQTT/TCP) to NLB and Web (HTTP) to ALB.
• Static IP Requirements: Clients require fixed IPs → use NLB + ALB behind it.