A Network Load Balancer (NLB) is Elastic Load Balancing’s Layer 4 load balancer. Think of it as a very fast traffic switch for connections.
Clients open a connection (TCP, UDP, or TLS). The NLB picks a healthy target—often an EC2 instance—and keeps that connection flowing. It does not read website paths the way an Application Load Balancer does.
TCP / UDP / TLS — connection-level traffic, not just HTTP pages.
Static IP per AZ — each enabled zone gets a fixed front-end address (Elastic IP optional).
Ultra-low latency — built for sudden spikes and millions of requests per second.
Beginner tip.
If you are hosting a normal website or REST API over HTTP/HTTPS, learn the ALB first. Come back to NLB when you need Layer 4 features.
Why it matters
In Simple Words
What problem does it solve?
One server can fail or get overloaded. An NLB gives clients one place to connect, then spreads those connections across healthy targets. It also keeps a stable IP per Availability Zone, which some firewalls and partners require.
Is NLB the same as ALB?
No. An ALB understands HTTP—hosts, paths, headers, methods. An NLB understands connections—protocol and port. Choose ALB for most websites. Choose NLB for TCP/UDP apps, gaming, IoT, TLS passthrough or offload at scale, or when you need static IPs.
When should a beginner use it?
After you understand target groups and have tried an ALB. Use NLB when your app needs a protocol an ALB cannot handle, or when a partner says “give us a fixed IP.”
A tiny traffic picture
Client → NLB listener (TCP/UDP/TLS + port) → target group → healthy registered targets. Health checks decide who still gets new connections.
Website routing tip.
Need /api on one service and / on another behind one hostname? That is ALB territory, not NLB.
Confirm health checks use a path/port your app answers on.
Create the load balancer and wait until the state is active.
Target groups
How It Works
The listener is the front door for a protocol and port.
The target group is the back room of healthy instances or IPs.
Protocol mismatch breaks health—TCP listener + TCP target group is the simple starter combo.
For TLS listeners, attach an ACM certificate when you terminate TLS on the NLB.
Step 4 — Test the DNS Name (or Static IP)
Prove that clients can reach a healthy target through the NLB.
Open the NLB details and copy the DNS name.
Note the IP addresses listed per Availability Zone if you need fixed IPs for allow lists.
From your computer, connect with a tool that matches the protocol (browser for HTTP on TCP:80, or a TCP client for other ports).
If nothing answers, check target health, security groups on the instances, and that the listener port matches the app.
How It Works
DNS resolves to the NLB IPs for the enabled zones.
Only healthy targets should receive new connections.
Security groups still matter on the targets (and any rules you place around the NLB).
Later, point a domain with Route 53 alias records when you leave the raw NLB DNS name behind.
Avoid these
Common Beginner Mistakes
Choosing NLB for a simple website
HTTP host/path rules belong on an ALB. NLB will not route by URL path.
Wrong target group protocol
A TCP listener needs a TCP (or compatible) target group. Mix-ups leave targets unhealthy.
Targets only in one unused AZ
Enable the zones where your instances run, or enable cross-zone behaviour with a clear plan.
Ignoring health checks
Unhealthy targets get no new connections. Fix the app port/path before blaming the NLB DNS name.
Expecting WAF on NLB like ALB
AWS WAF attaches to HTTP fronts such as CloudFront or ALB. Plan protection differently for pure TCP/UDP.
Forgetting TLS certificates
TLS listeners need an ACM (or IAM) certificate if the NLB terminates TLS for clients.
Remember
Key Takeaways
NLB is Layer 4 for TCP, UDP, and TLS connections.
ALB is usually better for websites; NLB shines for speed, static IPs, and non-HTTP protocols.
Listeners + target groups still drive the design, just like other ELB types.
Static IP per AZ (and optional Elastic IP) is a common reason teams pick NLB.
One line: use NLB when you need Layer 4 performance or static IPs; use ALB when you need HTTP routing.
Frequently Asked Questions
A Network Load Balancer (NLB) is a Layer 4 load balancer that spreads TCP, UDP, and TLS connections across healthy targets with very low latency and a static IP address per Availability Zone.
Most website beginners should start with an Application Load Balancer. Use an NLB when you need TCP/UDP (not just HTTP), extreme performance, long-lived connections, or a fixed IP per zone.
ALB works at Layer 7 on HTTP and HTTPS and can route by host, path, headers, and method. NLB works at Layer 4 on connections (TCP/UDP/TLS), keeps latency very low, and gives you a static IP per Availability Zone.
No. An NLB does not read HTTP paths or hostnames the way an ALB does. It forwards connections based on protocol and port. For path-based website routing, use an ALB.
Yes. You still create a target group, register EC2 instances or IP addresses, set health checks, and point an NLB listener at that group.
Yes. An NLB can terminate TLS on a TLS listener using a certificate from ACM, while still preserving the client source IP for many target types.