Network Load Balancer Health Checks: How to Configure NLB Health Checks on AWS
Network Load Balancers operate at Layer 4 of the OSI model, routing TCP and UDP traffic based on IP addresses and ports. Unlike Application Load Balancers that understand HTTP, NLBs make routing decisions based purely on network-level information. Health checks for NLBs verify that backend targets are reachable and accepting connections, but the configuration is different from what you might be used to with ALBs.
This guide covers how to configure NLB health checks, troubleshoot common issues, and optimize your health check configuration for production reliability.
NLB Health Check Types
AWS Network Load Balancers support three health check protocols. TCP health checks attempt to establish a TCP connection to the target on the configured port. If the connection succeeds, the target is healthy. This is the simplest and most common health check type, suitable for any TCP-based service.
HTTP health checks send an HTTP request to the target and evaluate the response. The health check considers the target healthy if it returns a 2xx or 3xx status code within the configured timeout. This is more sophisticated than TCP and can detect application-level issues, but it requires your service to respond to the health check path.
HTTPS health checks work like HTTP health checks but over a TLS connection. This verifies both that the target is reachable and that TLS is properly configured.
For most applications, TCP health checks are sufficient if you have application-level health monitoring separately. Use HTTP health checks when you want the load balancer to detect application failures without relying on external monitoring.
Configuring Target Groups
Health checks are configured at the target group level. Each target group has a health check configuration that applies to all targets in the group. The key parameters include the health check interval, which is the time between health checks, typically 30 seconds, the healthy threshold, which is the number of consecutive successful checks before a target is healthy, the unhealthy threshold, which is the number of consecutive failed checks before a target is unhealthy, and the timeout, which is the time the NLB waits for a response before considering the check failed.
A common misconfiguration is setting the interval too short, which generates excessive health check traffic, or setting the unhealthy threshold too low, which causes healthy targets to be removed during temporary network glitches. For most workloads, a 30-second interval with a 3x unhealthy threshold provides a good balance between responsiveness and stability.
Static IPs and NLB
One of the key advantages of NLB over ALB is support for static Elastic IP addresses. You can assign one or more static IPs to an NLB, and they remain constant for the life of the NLB. This is important for applications that need a fixed IP address for firewall rules, DNS configuration, or third-party integrations.
NLB also supports dual-stack IP addresses, meaning a single NLB can serve both IPv4 and IPv6 traffic. This simplifies your network architecture and future-proofs your application as IPv6 adoption grows.
Troubleshooting Failed Health Checks
When targets fail health checks, start by checking the basic connectivity. Can you reach the target directly from another host? Is the security group attached to the target allowing traffic from the NLB subnets? Is the target listening on the correct port?
Use the Deployxa Ping and Traceroute tool to test basic connectivity to your targets, and the Port Scanner to verify that the health check port is open and accepting connections. The Uptime Checker monitors your application availability from multiple global locations, complementing the NLB health checks with external monitoring.
NLB Stickiness
NLB supports session stickiness at the flow level using a duration-based approach. When stickiness is enabled, all packets from a client with the same source IP and port are routed to the same target for the duration of the stickiness period. This is useful for stateful protocols that require the client to communicate with the same backend for the duration of a session.
Common NLB Health Check Mistakes
- Security groups blocking health checks. The target security group must allow traffic from the NLB subnets on the health check port.
- Health check path not responding. For HTTP health checks, ensure the health check path returns 200 OK and responds within the timeout.
- Interval too aggressive. Short intervals increase health check load without significantly improving detection speed.
- Not monitoring NLB health check status. Set up CloudWatch alarms for unhealthy target counts to catch issues proactively.
Configure your NLB health checks with appropriate thresholds, use the free Deployxa tools for connectivity testing and monitoring, and set up alerts for health check failures.