AWS Network Load Balancer

AWS Network Load Balancer handles traffic at layer 4 and is built for workloads that need high throughput, low latency, and stable endpoints. For DevOps teams, it matters because it is useful when clients speak TCP or UDP, when source IP preservation matters, or when you need static IP addresses for allow lists. Instead of relying on one fragile manual configuration, you can design a repeatable service boundary that stays stable while the workload behind it changes.

Core ideas

The main ideas to understand are NLB works with TCP, TLS, UDP, and TCP_UDP listeners instead of application-layer HTTP rules; each Availability Zone can expose static IP addresses that are easier to place behind firewall rules; TLS termination on the balancer can offload certificates while still keeping a fast network path; and you usually choose NLB over ALB when protocol performance and source IP preservation matter more than content-aware routing. These details shape architecture decisions, but they also shape day-to-day operations. When a team chooses defaults without understanding how the service behaves under failure, scale, or security review, the platform often becomes harder to debug than the application itself.

From an operations perspective, the goal is to align the listener protocol and target group protocol with the application so the balancer does not become a hidden bottleneck. The comparison below highlights the choices that usually matter first. It is often better to start with a simpler design and add sophistication only after metrics, incidents, or delivery requirements prove the change is necessary.

Practical commands

aws elbv2 describe-load-balancers --names my-nlb
aws elbv2 describe-listeners --load-balancer-arn arn:aws:elasticloadbalancing:REGION:ACCOUNT:loadbalancer/net/my-nlb/1234567890abcdef
aws elbv2 describe-target-health --target-group-arn arn:aws:elasticloadbalancing:REGION:ACCOUNT:targetgroup/tcp-tg/abcdef1234567890

Practical CLI checks make the service easier to support in real environments. Use the commands below to inspect the current state and confirm that automation matches intent. Before you promote a change, verify source connectivity, TLS listener settings, and whether target health checks succeed from every enabled zone. A safe default is cross-zone awareness and clearly documented port ownership so platform and application teams know who owns each endpoint. That discipline makes later troubleshooting, scaling, and security reviews far less painful.