Definition
- ALB (Application Load Balancer) – operates at Layer 7 (HTTP/HTTPS); reads the request path, host header, and cookies to route traffic with path-based and host-based rules; supports TLS termination, sticky sessions, HTTP/2, and WebSockets.
- NLB (Network Load Balancer) – operates at Layer 4 (TCP/UDP/TLS); forwards packets with ultra-low latency, gives a static IP per Availability Zone, preserves the client source IP, and handles millions of connections per second.
- GWLB (Gateway Load Balancer) – operates at Layer 3/4 using the GENEVE protocol; transparently inserts third-party virtual appliances like firewalls and intrusion-detection systems into the traffic path.
- Target group – the set of backend targets (EC2, ECS, Lambda, IP addresses) that a load balancer routes to.
Imagine the main branch of National Bank of India. The ALB is a smart receptionist who reads each form and sends loan forms to the loan desk and card complaints to the card desk based on what is written on them. The NLB is a very fast turnstile that just counts people and pushes them through to the next free counter without reading anything, so it is extremely quick. The GWLB is the security scanner at the entrance that every person must pass through before reaching any counter.
Understanding the Concepts
What is an Application Load Balancer (ALB)?
An ALB understands HTTP. Because it reads the full request, it can route based on the URL path, the host header, HTTP method, query strings, and headers. You configure listener rules that match conditions and forward to a target group. At National Bank of India we route /api/transfers/* to the transfer service target group and /api/statements/* to the statement service, all behind one ALB listener on port 443.
// ALB routing concept: path-based rules
package com.bank.infrastructure;
import java.util.Map;
public class AlbRoutingSimulator {
private static final Map<String, String> ROUTES = Map.of(
"/api/transfers", "transfer-service-tg",
"/api/statements", "statement-service-tg",
"/api/accounts", "account-service-tg"
);
public static String route(String pathPrefix) {
return ROUTES.getOrDefault(pathPrefix, "default-tg");
}
public static void main(String[] args) {
System.out.println("/api/transfers -> " + route("/api/transfers"));
System.out.println("/api/statements -> " + route("/api/statements"));
}
}
What is a Network Load Balancer (NLB)?
An NLB works at the transport layer. It does not read HTTP; it forwards TCP and UDP packets. Because it does so little per packet, it has ultra-low latency and can scale to millions of requests per second. It preserves the client source IP and gives a stable static IP per AZ (and supports Elastic IPs), which matters when a partner bank must whitelist a fixed IP in their firewall.
// NLB use case: partner whitelisting a static IP
package com.bank.infrastructure;
public class NlbStaticIpExplainer {
public static void main(String[] args) {
System.out.println("NLB provides one static IP per AZ:");
System.out.println(" AZ-a: 52.10.1.100 (Elastic IP)");
System.out.println(" AZ-b: 52.10.2.200 (Elastic IP)");
System.out.println();
System.out.println("Partner bank whitelists these two IPs in their firewall.");
System.out.println("Traffic passes through without reading HTTP.");
}
}
What is a Gateway Load Balancer (GWLB)?
A GWLB is for inserting virtual network appliances transparently into the traffic path. It uses the GENEVE protocol on port 6081 and works with GWLB endpoints so that all traffic in a VPC can be routed through a fleet of firewalls or deep-packet-inspection appliances before reaching the application, without the application knowing it is there.
// GWLB: transparent security appliance insertion
package com.bank.infrastructure;
public class GwlbExplainer {
public static void main(String[] args) {
System.out.println("Traffic flow with GWLB:");
System.out.println(" Client -> GWLB Endpoint -> GWLB -> Firewall appliance");
System.out.println(" Firewall inspects, then returns to GWLB");
System.out.println(" GWLB -> Application (traffic is clean)");
System.out.println();
System.out.println("Application sees no difference -- insertion is transparent.");
}
}
When do you choose ALB vs NLB?
Choose ALB when you need content-based routing (path, host, headers), TLS termination, HTTP-level health checks (calling /actuator/health and expecting 200), sticky sessions, or WebSocket support. This is the default for REST API microservices.
Choose NLB when the traffic is not HTTP (raw TCP settlement feeds, gRPC without HTTP/2 framing, database proxying), when a partner must whitelist a fixed IP, when you need the lowest possible latency, or when you must preserve the client source IP end to end.
// Decision logic for load balancer selection
package com.bank.infrastructure;
public class LoadBalancerSelector {
public static String select(boolean isHttp, boolean needsStaticIp, boolean needsPathRouting) {
if (!isHttp) return "NLB (Layer 4, non-HTTP traffic)";
if (needsStaticIp && needsPathRouting) return "NLB + ALB (static IP + L7 routing)";
if (needsStaticIp) return "NLB (static IP for partner firewall)";
return "ALB (default for HTTP microservices)";
}
}
How do health checks differ between ALB and NLB?
ALB health checks are at the HTTP level: the ALB calls a specific path (like /actuator/health) and checks the HTTP status code. NLB health checks are at the TCP level by default: the NLB checks whether a TCP connection can be established on the port. NLB can also do HTTP health checks, but it is not the default.
// Health check configuration comparison
package com.bank.infrastructure;
public class HealthCheckComparison {
public static void main(String[] args) {
System.out.println("ALB Health Check:");
System.out.println(" Path: /actuator/health");
System.out.println(" Matcher: HTTP 200");
System.out.println(" Interval: 30s, Threshold: 3");
System.out.println();
System.out.println("NLB Health Check:");
System.out.println(" Protocol: TCP");
System.out.println(" Port: 8080");
System.out.println(" Checks: can a TCP connection be established?");
}
}
Can you combine NLB and ALB?
A common pattern is an NLB in front of an ALB when you need a static IP (NLB) plus Layer 7 routing (ALB). The NLB forwards TCP traffic to the ALB's private IPs as targets. This gives you both fixed IP addresses for partner whitelisting and the full content-based routing of the ALB.
// NLB -> ALB pattern
package com.bank.infrastructure;
public class NlbAlbCombination {
public static void main(String[] args) {
System.out.println("Pattern: NLB in front of ALB");
System.out.println(" Partner -> NLB (static IP: 52.10.1.100)");
System.out.println(" NLB -> ALB (TCP forward to ALB private IPs)");
System.out.println(" ALB -> /api/transfers -> transfer-service-tg");
System.out.println(" ALB -> /api/statements -> statement-service-tg");
System.out.println();
System.out.println("Result: static IP + path-based routing");
}
}
What about cost and billing differences?
ALB bills per LCU (Load Balancer Capacity Unit) measured on active connections, new connections, bandwidth, and rule evaluations. NLB bills per NLCU measured on connections, bandwidth, and flow evaluations. For very high-throughput Layer 4 traffic, NLB is typically cheaper than ALB because it does less processing per packet.
// Cost consideration
package com.bank.infrastructure;
public class LoadBalancerCostAdvice {
public static void main(String[] args) {
System.out.println("ALB billing drivers:");
System.out.println(" - Active connections");
System.out.println(" - New connections per second");
System.out.println(" - Processed bytes");
System.out.println(" - Rule evaluations (more rules = higher cost)");
System.out.println();
System.out.println("NLB billing drivers:");
System.out.println(" - Active flows");
System.out.println(" - Processed bytes");
System.out.println();
System.out.println("Tip: pure L4 high-throughput traffic is cheaper on NLB.");
}
}
What should a senior engineer know?
These load balancers are not mutually exclusive. A production architecture at a bank often uses an ALB for customer-facing microservices and an NLB for partner-facing settlement feeds, plus a GWLB for centralized security inspection. Target groups can include EC2 instances, ECS tasks, Lambda functions, or IP addresses, and cross-zone load balancing is enabled by default on ALB but must be explicitly enabled on NLB.
Visual Overview
AWS Load Balancer Types Comparison
┌───────────────────────────────────────────────────────────┐
│ Client Request │
└─────────────────────────┬─────────────────────────────────┘
│
┌─────────────────┼─────────────────┐
▼ ▼ ▼
┌──────────────┐ ┌──────────────┐ ┌──────────────┐
│ ALB │ │ NLB │ │ GWLB │
│ Layer 7 │ │ Layer 4 │ │ Layer 3/4 │
│ │ │ │ │ │
│ Reads HTTP │ │ Forwards │ │ Inserts │
│ Path/Host/ │ │ TCP/UDP │ │ appliances │
│ Headers │ │ packets │ │ (firewall) │
│ │ │ │ │ │
│ TLS termin. │ │ Static IP │ │ GENEVE │
│ Sticky sess. │ │ Ultra-low │ │ Transparent │
│ HTTP/2, WS │ │ latency │ │ │
└──────┬───────┘ └──────┬───────┘ └──────┬───────┘
│ │ │
▼ ▼ ▼
┌──────────────┐ ┌──────────────┐ ┌──────────────┐
│ Target Group │ │ Target Group │ │ Appliance │
│ (ECS tasks) │ │ (TCP targets)│ │ Fleet │
└──────────────┘ └──────────────┘ └──────────────┘
NLB + ALB Pattern (Static IP + L7 Routing)
Partner ──→ NLB (52.10.1.100) ──→ ALB ──→ /api/transfers ──→ TG-A
(static IP) (L7) ──→ /api/statements ──→ TG-B
Key Takeaway
AWS Elastic Load Balancing gives three load balancer types, and I choose between them by the layer of the network I need to work at. The Application Load Balancer operates at Layer 7, the HTTP layer, so it reads the request path, host header, cookies, and methods, which lets me route by content. This is my default for microservices, because behind one HTTPS listener I can send one path to the transfer service and another to the statement service, do TLS termination, run HTTP-level health checks, and support HTTP/2 and WebSockets.
The Network Load Balancer operates at Layer 4, the TCP and UDP layer. It does not read application data; it just forwards packets, which makes it extremely fast and able to handle millions of connections per second with very low latency. I reach for it when the traffic is not HTTP, when I need a static IP that a partner can whitelist in their firewall, or when I must preserve the client source IP end to end.
The Gateway Load Balancer is a specialist that inserts third-party network appliances like firewalls transparently into the traffic path using the GENEVE protocol, so all traffic can be inspected before reaching the application without the application knowing.
At National Bank of India I used an ALB in front of customer-facing microservices because I needed path-based routing and TLS termination, and an NLB in front of a raw TCP settlement feed because the partner bank's firewall team would only allow a single fixed IP address. A senior point I always mention is that these are not mutually exclusive: when I need both a static IP and Layer 7 routing, I place an NLB in front of an ALB.
Remember one sentence: ALB routes by HTTP content at Layer 7 and is the default for microservices, NLB forwards packets ultra-fast at Layer 4 and gives static IPs, and GWLB inserts security appliances transparently.
---