AWS ALB/NLB Load Balancing Setup Done Right
During migration to AWS, engineers often face the dilemma: which load balancer to choose? An incorrect choice leads to headaches in production. We have configured load balancing for dozens of projects, from startups with a single instance to enterprise environments with hundreds of microservices. This article covers real AWS documentation on Application Load Balancer (ALB) and official guide for Network Load Balancer (NLB) configurations running in production. ALB (layer 7) understands HTTP/HTTPS and can route by path, hostname, headers, and query parameters. NLB (layer 4) works with TCP/UDP, preserves the source IP, provides static IPs, and predictable low latency. Using NLB where ALB is needed means loss of functionality; using ALB for TCP protocols where source IP preservation is required means flawed architecture.
How to Choose Between ALB and NLB?
The choice depends on the protocol and requirements. If your application runs over HTTP/HTTPS, use ALB for advanced routing, path rewriting, weighted target groups, and built-in WAF. If you need low latency, UDP support, source IP preservation, or static IPs, choose NLB. When comparing performance, NLB delivers up to 10x lower latency for TCP traffic compared to ALB, making it ideal for real-time applications. NLB also serves as the foundation for PrivateLink, essential for cross-network communication. Sometimes a combination works: NLB in front of ALB to provide a static IP and preserve the source IP when needed.
ALB: Configuring Listeners and Rules
An ALB listener is defined by a port (80, 443) and protocol. Each listener has routing rules with priorities. Rules are evaluated from lowest to highest priority; the first match wins. ALB supports advanced features like path-based routing, host-based routing, weighted target groups, and sticky sessions via session cookies.
Typical rule configuration for microservices:
| Priority | Condition | Action |
|---|---|---|
| 1 | path /api/v2/* + header X-Version: 2 |
Forward → tg-api-v2 |
| 10 | path /api/* |
Forward → tg-api-v1 |
| 20 | path /auth/* |
Forward → tg-auth-service |
| 30 | host admin.example.com |
Forward → tg-admin |
| Default | — | Forward → tg-frontend |
Weighted target groups in a single rule enable built-in canary deployment. Rule: Forward 90% → tg-v1, 10% → tg-v2. Adjust weights without DNS or code changes. For blue/green: 100/0 → deploy new version to tg-v2 → test → switch 0/100 → remove tg-v1.
Why Health Checks Matter?
Incorrect health check parameters cause ALB to mark healthy instances as unhealthy (triggering Auto Scaling) or continue sending traffic to unhealthy targets.
Protocol: HTTP
Path: /health
Healthy threshold: 2
Unhealthy threshold: 3
Timeout: 5s
Interval: 30s
Success codes: 200-299The /health endpoint must respond quickly (< timeout) and check only the application's readiness. Do not include database checks in health checks: if the DB is down, removing traffic from all instances and shifting it elsewhere won’t help (they all share the same DB). Better: separate /readiness for traffic routing and /liveness for restarts.
Deregistration delay (connection draining) defaults to 300 seconds. ALB stops sending new requests to a decommissioning instance but waits for in-flight requests to complete. For stateless HTTP services with fast requests, reduce to 30-60 seconds for faster deployments. For stateless services, we recommend a deregistration delay of 30 seconds to reduce deployment time.
SSL Termination and HTTPS Configuration
An ACM certificate is attached to the ALB listener. ALB performs SSL termination—encrypted between client and ALB; optionally encrypted between ALB and the target group. For traffic within a VPC (private subnet), HTTP is sufficient; encryption at this level adds overhead without practical benefit if the network is isolated.
Security policy for TLS: choose ELBSecurityPolicy-TLS13-1-2-2021-06 for maximum security. It disables TLS 1.0/1.1 and keeps TLS 1.2 (for legacy clients) and TLS 1.3.
Redirect HTTP → HTTPS via a separate rule on port 80 listener:
Action: Redirect to HTTPS, port 443, status 301 More on Mutual TLS on ALB
Mutual TLS (mTLS) has been available recently. The client provides a certificate, and ALB validates it against a trust store. This is useful for service-to-service authentication, zero-trust architectures, and compliance. It is enabled on listeners on port 443. Our team of AWS Certified professionals guarantees a best-practice setup.NLB: When and How
NLB preserves the client's source IP in TCP packets—the application sees the real IP, not the ALB's IP. This is critical for application-level rate limiting by IP, geo-filtering, and audit logs with real client IPs. NLB also supports proxy protocol v2 to preserve client IP when behind another proxy.
Static IPs: each NLB has a fixed IP per Availability Zone. This is needed when an upstream must whitelist an IP (partner API, legacy firewall). ALB does not have static IPs.
UDP protocol support: NLB is the only AWS LB that supports UDP. DNS servers, NTP, game servers, VPN endpoints—all go through NLB.
PrivateLink is built on top of NLB for service-to-service connectivity across accounts or VPCs without VPC peering. NLB serves as the backend for endpoint services.
Monitoring ALB/NLB
CloudWatch metrics we always configure:
| Metric | Alert Threshold | Significance |
|---|---|---|
HTTPCode_ELB_5XX_Count |
> 10/min | LB errors (not target) |
HTTPCode_Target_5XX_Count |
> 5% of requests | Application errors |
TargetResponseTime |
P95 > SLO | Latency degradation |
UnHealthyHostCount |
> 0 | Targets dropped |
RejectedConnectionCount |
> 0 | LB overload |
ALB Access Logs → S3 → Athena is the standard schema for traffic analysis. Enable it in the LB attributes. Format: timestamp, ELB name, client IP, target IP, request, response code, latency, user agent.
Our Process
Load balancing setup consists of the following stages:
- Audit current architecture and traffic requirements.
- Design balancer configurations, routing rules, health checks.
- Implementation: create Target Groups, Listeners, Rules, configure SSL.
- Testing: verify routing, fault tolerance, latency.
- Deploy to production and monitor for one week.
Timelines: standard ALB setup with SSL and basic rules takes 1 day. Complex scenarios (NLB + PrivateLink, mTLS, weighted routing) take 2 to 3 days. Cost is calculated individually; infrastructure savings can reach 30% due to routing rule optimization—typical saving of $200 per month for a medium project. Our setup ensures 99.9% availability for applications.
What's Included
Our service includes:
- Documentation of the load balancing architecture (diagrams, rules, parameters).
- AWS access credentials and scripts for reproduction.
- Up to 2 hours of team training.
- Two weeks of post-deployment support.
With over 5 years of experience and 50+ projects, we deliver reliable load balancing solutions. Interested in a turnkey setup? Contact us—we'll evaluate your project in 1 day. Get a consultation on balancer selection and existing configuration optimization.