AWS Network Load Balancer Guide: What You Need to Know

After building and scaling his web application using Application Load Balancer (ALB), Arjun felt like a cloud champion.

He had:

Smart routing based on paths and domains
HTTPS termination
Health checks
And everything working behind one clean URL

But just when things were smooth… a new requirement landed on his desk.

📩 The New Use Case: Beyond HTTP

One of the backend teams was building a real-time multiplayer game server. They said:

“We need to handle TCP and UDP traffic, not HTTP.”

Arjun paused.

“But... ALB only works with HTTP and HTTPS... right?”

Correct. ALB is Layer 7, meaning it works only with web traffic (HTTP/HTTPS). It doesn't understand lower-level protocols like TCP or UDP.

That’s when Arjun was introduced to the Network Load Balancer (NLB).

💡 Why Do We Need a Network Load Balancer?

Feature	ALB	NLB
Layer	7 (Application)	4 (Transport)
Protocols	HTTP / HTTPS	TCP / UDP / TLS
Advanced Routing	Yes (based on URL, headers, etc.)	No
Speed	Good	⚡ Ultra-fast
Millions of Connections/sec	🚫 Not ideal	✅ Designed for it
Static IP Support	No	✅ Yes
Real-time, Low-Latency	🚫 Not optimal	✅ Perfect
Web Apps	✅ Great	✅ If needed
Network-level apps (VPNs, chat, games)	🚫 Not supported	✅ Best fit

A Network Load Balancer (NLB) is a Layer 4 load balancer in AWS that routes traffic using the TCP, UDP, or TLS protocols. It’s designed to handle millions of connections per second with ultra-low latency.

Unlike ALB, it doesn’t inspect web requests or support things like path-based routing. It just moves packets—fast and reliably.

Bottom line?
If you’re working with protocols other than HTTP/HTTPS, or need extreme performance + static IPs—NLB is the answer.

⚙️ What Is the Network Load Balancer?

Unlike ALB, it doesn’t inspect web requests or support things like path-based routing. It just moves packets—fast and reliably.

📡 Use Cases Where ALB Can’t Help

Here’s what made Arjun go for NLB:

1. TCP/UDP Traffic (Not HTTP)

Game servers
VPN gateways
IoT device communications
Chat and messaging apps

2. Static IP Requirements

One day, Arjun’s security team said:

“Our payment partner only accepts traffic from known IP addresses. Can we give them our app’s IP?”

Arjun checked—and realized Application Load Balancer (ALB) couldn’t help. ALB uses changing IPs, which can’t be whitelisted by other systems.

💡

You cannot assign an Elastic IP (EIP) to an Application Load Balancer (ALB). Because ALB uses AWS-managed IPs, which are Dynamic and Managed by AWS.

Why?

NLB gives you one static IP per Availability Zone
You can even attach Elastic IPs—which are fixed and owned by you
These IPs never change, even if the load balancer restarts

✅ This made it easy for Arjun to:

Share static IPs with partners
Set up firewall rules
Build integrations with systems that require fixed IPs

3. Extreme Performance Needs

The app needed to support hundreds of thousands of concurrent connections.

NLB is connection-based, not request-based
It can handle millions of connections per second without breaking a sweat

🔁 Connection-Based (NLB) vs. Request-Based (ALB) — SAA Focus

Network Load Balancer (NLB) is connection-based, which means it routes all data in a single TCP or UDP connection to the same backend server. It doesn’t inspect individual requests—just maintains and forwards the connection.

In contrast, an Application Load Balancer (ALB) is request-based. It looks at each HTTP/HTTPS request and can route different requests—even from the same connection—to different target groups based on things like path, headers, or hostnames.

✅ Summary:

Load Balancer	Routing Type	Works Best For
NLB	By connection (TCP/UDP)	Real-time apps, chat, VPN, IoT
ALB	By request (HTTP/HTTPS)	Websites, APIs, microservices

📘 SAA Tip: If the question mentions "connection persistence" or "non-HTTP protocols", think NLB. For smart HTTP routing, think ALB.

🧱 NLB Target Groups (Where the Traffic Goes)

Just like ALB, NLB uses target groups to define where traffic should go.

Supported target types:

EC2 Instances
Private IP addresses (even on-premises servers)

Note: With NLB, you can register IP addresses directly, including IPs in your own data center—perfect for hybrid environments.

🔀 Bonus: You Can Use NLB in Front of ALB

Here’s something cool Arjun didn’t expect:

He could put an NLB in front of an ALB.

Why?

NLB gave him static IPs and performance
ALB handled all his smart HTTP rules

This combo gave Arjun the best of both worlds.

💓 Health Checks in NLB

NLB performs health checks at the target group level.

It supports 3 types of health check protocols:

Protocol	Use Case
TCP	Just checks if the port is open
HTTP	Expects an HTTP response like `200 OK`
HTTPS	Encrypted health checks

If a target fails, NLB stops sending traffic to it—keeping the app reliable.

💰 Important Note: NLB Is Not in the Free Tier

Arjun noted this carefully:

“Unlike ALB, NLB is not included in the AWS Free Tier.”

He made sure to set it up only for production use or controlled testing.

🧠 Final Recap: When Should You Use Network Load Balancer?

Use NLB when:

✅ You need to handle TCP, UDP, or TLS traffic
✅ You require static IPs or Elastic IPs
✅ You want ultra-low latency
✅ You expect massive amounts of connections
✅ You have non-HTTP services, like games, messaging, VPNs
✅ You need to load balance across on-prem servers

🎉 Arjun’s Takeaway

Arjun realized that ALB and NLB aren’t competing tools—they’re designed for different layers of networking.

Use ALB for smart web traffic routing (Layer 7)
Use NLB for raw network-level traffic (Layer 4)

“Now I know when to use each one—and how they can even work together.”