Search across all documentation pages
Elastic Load Balancing v2 gives you two load balancer types you provision from the SDK, and the choice between them shapes everything downstream - which protocols you can listen on, whether you get a fixed IP address, and how much routing intelligence you have.
This page maps the two types, the trade-offs at each layer of the network stack, and the single SDK parameter that commits you to one or the other. Both are created through the same @aws-sdk/client-elastic-load-balancing-v2 client (boto3 client elbv2), so the code is more alike than different.
Type field on CreateLoadBalancer (application or network), and it is immutable - to switch you create a new load balancer.An Application Load Balancer operates at Layer 7, the application layer. It understands HTTP and HTTPS, so it can read a request's path, host header, method, and cookies, and route on them. It terminates the client connection, inspects the request, and opens its own connection to a target. This is what lets one ALB serve /api from one target group and /images from another.
A Network Load Balancer operates at Layer 4, the transport layer. It forwards TCP and UDP (and TLS) at the connection level without reading the payload. It does not know or care whether the bytes are HTTP, gRPC, a database protocol, or a game server's custom UDP. That ignorance is a feature: it forwards enormous volumes of traffic with very low, consistent latency.
You choose between them with one field. Everything else about creation - subnets, scheme, tags - is nearly identical.
# --- Python (boto3) ---
import boto3
elbv2 = boto3.client("elbv2", region_name="us-east-1")
# Application Load Balancer (Layer 7)
alb = elbv2.create_load_balancer(
Name="web-alb",
Type="application",
Subnets=["subnet-0aaa", "subnet-0bbb"],
SecurityGroups=["sg-0web"],
Scheme="internet-facing",
)
# Network Load Balancer (Layer 4)
nlb = elbv2.create_load_balancer(
Name="tcp-nlb",
Type="network",
Subnets=["subnet-0aaa", "subnet-0bbb"],
Scheme="internet-facing",
)// --- TypeScript (AWS SDK v3) ---
import { ElasticLoadBalancingV2Client, CreateLoadBalancerCommand } from "@aws-sdk/client-elastic-load-balancing-v2";
const elbv2 = new ElasticLoadBalancingV2Client({ region: "us-east-1" });
// Application Load Balancer (Layer 7)
const alb = await elbv2.send(new CreateLoadBalancerCommand({
Name: "web-alb",
Type: "application",
Subnets: ["subnet-0aaa", "subnet-0bbb"],
SecurityGroups: ["sg-0web"],
Scheme: "internet-facing",
}));
// Network Load Balancer (Layer 4)
const nlb = await elbv2.send(new CreateLoadBalancerCommand({
Name: "tcp-nlb",
Type: "network",
Subnets: ["subnet-0aaa", "subnet-0bbb"],
Scheme: "internet-facing",
}));Notice the ALB takes SecurityGroups while the NLB historically did not require them. Both take Subnets, and both return a LoadBalancers[].LoadBalancerArn you use for every later call.
The two types share the same building blocks: a listener checks for connections on a port, and a target group holds the backends and runs health checks. The type changes which protocols those pieces can use.
Protocols. An ALB listener speaks HTTP or HTTPS. An NLB listener speaks TCP, UDP, TCP_UDP, or TLS. You cannot put an HTTP listener on an NLB or a TCP listener on an ALB - the API rejects it.
Routing power. An ALB supports CreateRule with conditions on path pattern, host header, HTTP header, query string, and source IP, so a single ALB fans traffic to many target groups. An NLB has no content-based routing; a listener forwards to one target group (or a weighted set), full stop.
Addressing. An ALB gives you a DNS name only - its IP addresses float and you must always resolve the name. An NLB can be pinned to a static private IP per subnet or an Elastic IP through SubnetMappings, which is why firewall-allowlist and hardcoded-IP scenarios reach for NLB.
Health checks. Both run health checks defined on the target group, but an ALB always uses HTTP/HTTPS checks, while an NLB can health-check with TCP, HTTP, or HTTPS. That lets an NLB front a non-HTTP service while still probing it with a simple TCP connect.
Source IP preservation. An ALB terminates the connection, so your target sees the ALB's IP; the original client IP arrives in the X-Forwarded-For header. An NLB with instance or IP targets preserves the client's source IP at the network level by default, which matters for IP allowlists, geolocation, and some compliance rules.
Performance envelope. An NLB is built for millions of requests per second with sub-millisecond added latency and absorbs sudden spikes without pre-warming. An ALB adds more per-request processing because it parses HTTP, which is the cost of its routing intelligence. For most web apps that cost is invisible and well worth it.
TLS handling. Both can terminate TLS using an ACM certificate: an ALB with an HTTPS listener, an NLB with a TLS listener. The difference is what happens after - the ALB then routes on the decrypted HTTP request, while the NLB just forwards the decrypted TCP stream. An NLB can also pass TLS straight through (a TCP listener) so the target does its own termination.
Target sharing. An NLB can even target an ALB (TargetType alb), a pattern that gives you a static IP in front of Layer 7 routing - the NLB provides the fixed address, the ALB provides the content routing.
The practical decision rule: if the workload is HTTP/HTTPS and you want path or host routing, choose an ALB. If it is non-HTTP, needs a static IP, demands the lowest possible latency at very high scale, or must preserve the client source IP, choose an NLB. Because the type is fixed at creation, decide before you call CreateLoadBalancer.
Type is immutable. You create a new load balancer of the other type and migrate.SubnetMappings.TLS listener and an ACM certificate, or passes it through with a TCP listener.elbv2 / @aws-sdk/client-elastic-load-balancing-v2 with the same listener and target-group operations.An ALB works at Layer 7 (HTTP/HTTPS) and can route on request content like path and host; an NLB works at Layer 4 (TCP/UDP/TLS) and forwards connections at very high throughput with low latency.
Set the Type field on CreateLoadBalancer to application for an ALB or network for an NLB. It defaults to application if omitted.
No. The type is fixed for the life of the load balancer. To switch, create a new one of the desired type and move traffic over.
The NLB. Using SubnetMappings you can assign a static private IP or an Elastic IP per subnet. An ALB only exposes a DNS name.
An ALB listener supports HTTP and HTTPS. An NLB listener supports TCP, UDP, TCP_UDP, and TLS.
Not at the network level - the target sees the ALB's IP and the real client IP arrives in X-Forwarded-For. An NLB preserves the client source IP by default for instance and IP targets.
Yes, with a TLS listener and an ACM certificate. It can also pass TLS through unmodified with a TCP listener so the target terminates it.
An NLB adds less per-connection latency and scales to millions of requests per second without pre-warming, because it does not parse HTTP. An ALB's extra processing buys content-based routing.
No. Both are created and managed through the ELB v2 client - elbv2 in boto3 and @aws-sdk/client-elastic-load-balancing-v2 in SDK v3 - with the same listener and target-group operations.
Stack versions: This page was written for boto3 1.43.x (Python 3.10+) and the AWS SDK for JavaScript v3 (Node.js 18+).
Reviewed by Chris St. John·Last updated Jul 23, 2026