AWS Network Load Balancer (NLB) Explained

What is AWS Network Load Balancer?

AWS Network Load Balancer is a managed load balancer that operates at the transport layer, also known as Layer 4 in the OSI model. It is designed to handle very large volumes of network traffic efficiently while keeping latency low.

Instead of making routing decisions based on URLs, hostnames, or HTTP headers, NLB forwards traffic based on network connection information such as protocol and port.

Why NLB matters in AWS networking

Not all workloads are web applications. Many systems rely on raw TCP or UDP flows, require very fast connection handling, or need backend systems to see the original client IP. This is where NLB becomes highly useful.

How AWS NLB works

NLB receives traffic from clients on configured listeners and forwards connections to target groups. Those target groups can contain EC2 instances, IP addresses, containers, or other backend destinations depending on the architecture.

Client
  |
  v
Network Load Balancer
  |
  v
Listener (TCP / UDP / TLS)
  |
  v
Target Group
  |
  v
EC2 / ECS / EKS / IP targets

Step-by-step flow

1. A client opens a TCP, UDP, or TLS connection.
2. The connection reaches the NLB listener.
3. NLB checks the associated target group.
4. Traffic is sent to a healthy backend target.
5. The backend responds to the client through the NLB path.

Key features of AWS NLB

NLB vs ALB

NLB and ALB solve different problems. Choosing the wrong one can create routing limitations, operational complexity, or performance issues.

When to use NLB

Use NLB when

• Your workload uses TCP, UDP, or TLS instead of relying on HTTP routing logic.
• You need high throughput and low-latency network traffic handling.
• You want backends to see the original client source IP.
• You have integrations that care about stable network entry behaviour or IP-based allowlists.
• Your application is performance-sensitive and does not need Layer 7 features.

Typical use cases

Real-world NLB architecture example

A common NLB-based architecture for non-HTTP or performance-sensitive services may look like this:

Client
  |
  v
Route 53
  |
  v
Network Load Balancer
  |
  v
Target Group
  |
  v
EC2 instances / Container services / IP-based backends

In this design:

• Route 53 resolves the service name to the NLB endpoint.
• NLB accepts the connection on a listener such as TCP 443 or UDP 53.
• NLB sends traffic to healthy backends in the target group.
• The backend processes the request while preserving network-level visibility.

Health checks in NLB

Like other load balancers, NLB uses health checks to determine which backend targets are available. If a target becomes unhealthy, NLB stops routing traffic to it.

Why health checks matter

• They help prevent traffic from going to failed backends.
• They improve resilience across Availability Zones.
• They reduce the chance of partial outages being exposed to users.

What to validate

• Correct health check protocol
• Correct target port
• Expected response behaviour from backend
• Security rules allowing health check traffic

Terraform example for AWS NLB

Below is a simple example that creates a Network Load Balancer and a TCP listener.

resource "aws_lb" "nlb" {
  name               = "example-nlb"
  internal           = false
  load_balancer_type = "network"
  subnets            = ["subnet-aaa111", "subnet-bbb222"]
}

resource "aws_lb_target_group" "app" {
  name        = "example-nlb-tg"
  port        = 443
  protocol    = "TCP"
  vpc_id      = "vpc-12345678"
  target_type = "instance"

  health_check {
    protocol = "TCP"
    port     = "traffic-port"
  }
}

resource "aws_lb_listener" "tcp_443" {
  load_balancer_arn = aws_lb.nlb.arn
  port              = 443
  protocol          = "TCP"

  default_action {
    type             = "forward"
    target_group_arn = aws_lb_target_group.app.arn
  }
}

What this Terraform does

• Creates a public Network Load Balancer.
• Creates a target group listening on TCP 443.
• Configures TCP health checks.
• Creates a listener that forwards traffic to the target group.

Common NLB mistakes

Using NLB when ALB is actually needed

Teams sometimes choose NLB and later realise they needed path-based or host-based routing. NLB cannot provide that application-layer intelligence.

Expecting HTTP-aware features

NLB is not designed to inspect URLs, cookies, or HTTP headers. It is a transport-layer load balancer.

Misconfigured health checks

Wrong protocol, wrong port, or blocked security rules can cause healthy backends to appear unhealthy.

Ignoring source IP implications

Source IP preservation can be beneficial, but backend services and logs should be designed to use it properly.

Wrong expectations around architecture choice

Choosing NLB only because it sounds “faster” is not enough. You still need to match the load balancer to the workload’s actual routing needs.

NLB troubleshooting guide

Practical checklist

• Check listener protocol and port.
• Confirm the target group protocol matches the backend.
• Verify registered targets are healthy.
• Check security groups and network rules around backend ports.
• Confirm whether NLB is really the right load balancer for the use case.

NLB interview questions

Frequently asked questions

Related cloud networking resources