ALB, NLB, GWLB and Target Groups

By the end of this lesson you will be able to

• Place the four Elastic Load Balancing types on the network layers and say what each one can see in a packet.
• Build ALB listener rules on path, host, header, method, query string and source IP, order them by priority, and choose the right action: forward (including weighted canary and blue/green), redirect, fixed response or authenticate.
• Explain why an application behind an ALB sees the ALB’s address, and use X-Forwarded-For, X-Forwarded-Proto and X-Forwarded-Port.
• Use an NLB for TCP, UDP and TLS: static IPs per AZ, Elastic IPs, client IP preservation, security groups, ALB as a target and PrivateLink.
• Explain how a GWLB puts a fleet of third-party appliances in the path of traffic with GENEVE, GWLB endpoints and route tables, and what happens when an appliance fails.
• Configure target groups: protocol, port, target type (instance, IP including on-premises, Lambda, ALB), health checks and attributes.
• Estimate a load balancer bill from the hourly charge and capacity units, and pick the right load balancer from any exam scenario.

#Three load balancers, three layers

Lesson 6.2 showed what every Elastic Load Balancer does: one stable entry point, health checks, and traffic spread across healthy targets in several Availability Zones. AWS offers four types, and the difference between them is how deep into each packet they look.

ALB, NLB and GWLB are the current generation, all managed through the same elbv2 API, and all send traffic to target groups. The CLB is the previous generation: one load balancer per application, no target groups, no content routing. It appears in this lesson only in the comparison table.

#Application Load Balancer (layer 7)

#What it understands

An ALB is a full HTTP proxy. It accepts the client’s connection, decrypts HTTPS if the listener is HTTPS (certificates and SNI are lesson 6.4), reads the request, decides where it goes, and opens its own connection to the chosen target.

• HTTP/1.1 and HTTP/2 from clients; to targets it speaks HTTP/1.1 by default, or HTTP/2 or gRPC if the target group’s protocol version says so (gRPC needs an HTTPS listener).
• WebSockets work natively: the ALB upgrades the connection and keeps it open.
• It has a security group of its own (mandatory), and targets should allow traffic only from that group (lesson 6.2).
• It has a fixed DNS name, such as web-alb-1234567890.us-east-1.elb.amazonaws.com, but no fixed IP. More on this below.
• AWS WAF can be attached to it, which no other ELB type allows.

#Listeners and rules

A listener is a protocol and port the ALB accepts traffic on, for example HTTPS 443. Each listener has a list of rules. A rule has a priority, one or more conditions, and one or more actions.

How rules are evaluated:

1. Lowest priority number first

   Rules are checked in priority order, 1 is checked first, up to 50,000. The first rule that matches wins and no later rule is looked at. A broad rule with a low number hides every specific rule after it.

2. Every condition in a rule must match

   A rule with host-header api.example.com and path-pattern /users* matches only when both are true. Inside one condition, up to three values work as alternatives: any one of them is enough (/users* or /accounts*). A rule can hold up to five match values in total.

3. The default rule catches everything else

   Every listener has exactly one default rule. It has no conditions, is always evaluated last, and cannot be deleted. Its action decides what happens to traffic that matched nothing: usually forward to a main target group, sometimes a fixed 404.

By default an ALB allows 100 rules (not counting the default rules); the quota can be raised.

#Actions

Each rule ends in exactly one routing action, and an HTTPS rule can put an authentication action before it.

A few details that matter:

• Weighted forwarding happens inside the ALB, so shifting traffic takes seconds and does not wait for DNS caches, unlike weighted DNS records.
• If one weighted target group is empty or completely unhealthy, the ALB does not fail over to the others: that share of requests fails. Watch the canary’s metrics.
• To keep a user on the same version during a canary, turn on target group stickiness on the forward action (cookie details in lesson 6.4).
• Since 2025 rules can also carry transforms that rewrite the host header or URL before forwarding. Good to know; the exam still expects the classic actions above.

#What the application sees: X-Forwarded headers

Because the ALB ends the client’s connection and opens a new one, the target’s socket shows the ALB’s private IP, not the client’s. The ALB passes the original details in three request headers:

Use X-Forwarded-For for logs, geolocation and rate limits, and X-Forwarded-Proto to build correct links and to decide whether to redirect to HTTPS. Clients can send their own fake X-Forwarded-For; the ALB appends the address it really saw at the end, so trust the right-most entry.

#Microservices and containers

Before the ALB, each application needed its own Classic Load Balancer. One ALB with path and host rules can front dozens of services, each in its own target group with its own health check. That is why the exam links ALB with microservices and containers.

With Amazon ECS (containers on EC2) in bridge network mode you can set the host port to 0. Docker then gives each task a random high port, so several copies of the same container run on one instance. ECS registers each task in the target group as instance plus that port, and the ALB sends traffic to the right port automatically. This is dynamic port mapping. One rule to remember: the instances’ security group must allow the ALB’s security group on the whole ephemeral port range, not just port 80, or the tasks fail their health checks. With the awsvpc network mode (and always on Fargate) each task gets its own network interface and is registered by IP address instead.

#A fixed DNS name, not a fixed IP

A question that appears in many practice tests reads: “An Application Load Balancer and a Classic Load Balancer have a static ____: IPv4 address, IPv6 address, DNS name, or Elastic IP?” The answer is DNS name.

An ALB is not one machine. AWS runs load balancer nodes in each enabled AZ and adds, removes or replaces them as traffic changes. Each change can bring new IP addresses, so AWS never promises fixed IPs for an ALB or a CLB. What stays the same for the life of the load balancer is its DNS name, which always resolves to the current node IPs.

• To use your own domain, create a Route 53 Alias record that points at the load balancer’s DNS name. An Alias works at the zone apex (example.com), where a CNAME is not allowed, and Route 53 does not charge for Alias queries to AWS resources. For a subdomain such as www.example.com a CNAME also works, but Alias is still the better choice.
• Never put an ALB’s current IP into an A record, a client configuration or a partner’s firewall. It will change one day.
• If a partner really needs fixed IPs for an HTTP application, put an NLB in front of the ALB, or AWS Global Accelerator (two static anycast IPs) in front of it.

#Network Load Balancer (layer 4)

#What it does

An NLB forwards TCP, UDP and TLS (plus TCP_UDP on one port, and since late 2025 QUIC in passthrough mode). It never reads HTTP, it only looks at addresses and ports, picks a target by hashing the flow, and passes the packets on. That makes it:

• Very fast: millions of requests per second and very low latency, with no warm-up needed for sudden spikes.
• Good for any protocol: databases, IoT device protocols, game servers, VoIP, custom binary protocols.
• Long-lived friendly: one TCP connection or UDP flow stays on one target for its life.

The notes give the classic split. TCP is for traffic that must arrive complete and in order: databases, logins, most web traffic. UDP is for traffic where speed matters more than every packet: live voice (VoIP), real-time video, and the fast-moving state of multiplayer games. Many games use both: UDP for movement, TCP for login, chat and purchases.

#Static IPs and Elastic IPs

An NLB has one node in each enabled AZ, and each node gets one IP address that does not change for the life of the load balancer.

• An internet-facing NLB can use your own Elastic IP in each subnet (chosen at creation), so the addresses are ones you own and can keep on record.
• An internal NLB can use a private IP you pick from each subnet.
• The DNS name still exists and resolves to those fixed IPs.

This is the answer whenever a question says “static IP”, “Elastic IP” or “the client must allowlist the load balancer’s IP in its firewall”.

#Client IP preservation

An NLB does not open a second connection for TCP or UDP listeners, so the target can see the client’s real address. The exact default depends on the target type and protocol:

The flip side: when the client IP is preserved, the targets’ security group must allow the clients’ addresses (or the NLB’s security group, below), not just the VPC range.

#Targets and health checks

An NLB target group can hold:

• Instances (by instance ID),
• IP addresses (private ranges, including on-premises over VPN or Direct Connect and peered VPCs),
• One Application Load Balancer (target type alb), which gives an ALB static IPs and puts it behind PrivateLink. The ALB must be in the same VPC, the target group uses TCP, and its port must match an ALB listener.

Health checks use TCP, HTTP or HTTPS, never UDP. For a UDP service, run a small TCP or HTTP health endpoint on the instance. Prefer an HTTP check when you can: a TCP check only proves the port is open, not that the application works. Since November 2025 an NLB forward action can also use weighted target groups, like the ALB.

#Security groups: optional, decided at creation

Since August 2023 an NLB can have security groups, just like an ALB. They are optional, and there is one trap: you can add them only when you create the NLB. An NLB created without a security group can never have one; you would have to create a new NLB. Once an NLB has at least one, you can change them freely. With a security group on the NLB, targets can reference it as their source, exactly like the ALB pattern from lesson 6.2. Health checks follow the outbound rules.

#PrivateLink endpoint services

To offer a service privately to other VPCs or other AWS accounts, without peering and without the internet, you publish it as a VPC endpoint service (AWS PrivateLink). The service side must have a Network Load Balancer (or, for appliances, a Gateway Load Balancer) in front. Consumers create an interface endpoint in their own VPC and reach your NLB through it. For an HTTP application with path rules, use NLB → ALB.

#Gateway Load Balancer (layer 3)

#Why it exists

Many companies must run every packet through a firewall or intrusion prevention product they already trust (Palo Alto Networks, Cisco, Fortinet, Check Point and others) as virtual machines in AWS. Doing that by hand is hard: the appliances must scale, a failed one must be bypassed, and traffic in both directions of a conversation must pass through the same appliance.

A Gateway Load Balancer combines two jobs:

1. A transparent network gateway: one entry and exit point that traffic is routed through. It does not change source or destination addresses; the application never knows it is there.
2. A load balancer for the appliance fleet: it spreads flows across healthy appliances and keeps each flow on one appliance.

#How traffic flows

1. Route tables send traffic to a GWLB endpoint

   The GWLB sits in a security (provider) VPC with the appliances. In each application VPC you create a GWLB endpoint, a PrivateLink endpoint of type Gateway Load Balancer, in its own subnet. Route tables make it the next hop: the internet gateway’s edge route table sends traffic for the app subnet to the endpoint, and the app subnet’s route table sends 0.0.0.0/0 to the endpoint.

2. GENEVE to an appliance

   The GWLB listens for all IP packets on all ports; there is no listener protocol or port to choose. It picks an appliance by hashing the flow (5-tuple by default, or 3-tuple or 2-tuple) and wraps the original packet, unchanged, in GENEVE on UDP port 6081. The appliance’s security group must allow UDP 6081 from the GWLB, and the appliance must support GENEVE.

3. Inspect, then back the same way

   The appliance inspects the inner packet and either drops it or sends it back to the GWLB in GENEVE. The GWLB returns it to the endpoint, and routing delivers it to its real destination. Replies are routed through the endpoint again and the hash sends them to the same appliance, so stateful inspection sees both directions.

More facts worth knowing:

• Target types: instance and IP. Health checks: TCP, HTTP or HTTPS.
• No security groups on the GWLB itself, and no AWS WAF.
• Cross-zone load balancing is off by default.
• The GWLB supports packets up to 8,500 bytes; GENEVE adds 68 bytes, so appliances need an MTU of at least 8,568. It does not fragment and does not support Path MTU Discovery.
• Idle flows time out after 350 seconds for TCP (adjustable from 60 to 6,000) and 120 seconds for other protocols.
• When an appliance fails, new flows go only to healthy appliances. Existing flows keep going to the failed one by default (no_rebalance) and are dropped until they time out; set target failover to rebalance to re-hash them, or keep no_rebalance and turn on TCP reset so clients reconnect quickly.
• With Transit Gateway (appliance mode) one GWLB can inspect traffic for many VPCs in a central inspection VPC; that design comes in the networking chapter.
• AWS Network Firewall is AWS’s own managed firewall. If a question asks for inspection without mentioning third-party appliances, Network Firewall may be the simpler answer.

#Classic Load Balancer, in one line

The CLB (lesson 6.2) handles basic TCP, SSL, HTTP and HTTPS, has a fixed DNS name and no target groups. AWS recommends migrating to ALB or NLB; on the exam it is almost always a wrong answer or the “old way”.

#Target groups

A target group is the list of destinations a listener rule sends traffic to, plus the rules for checking them. The load balancer accepts and routes the traffic; the target group says who receives it and whether they are healthy. (The notes say the load balancer “does not process traffic itself”; more precisely, an ALB does process and route each request, but the actual work is done by the targets in the group.)

#What you set on a target group

Rules that come up in questions:

• One target can be in many target groups, on the same or different ports. An instance can serve the website on port 80 in tg-web and an admin app on 8080 in tg-admin.
• One target group belongs to one load balancer.
• An Auto Scaling group registers and deregisters its instances in the target groups attached to it (lesson 6.5).
• The healthy and unhealthy state of each target is shown in the Target groups page of the EC2 console, not on the instance. An instance can be “running” in EC2 and “unhealthy” in its target group at the same time.

#Target types by load balancer

ECS tasks are not a separate type: they are registered as instance (bridge mode, dynamic ports) or ip (awsvpc mode, Fargate).

#What it costs

Every current-generation load balancer costs an hourly charge plus capacity units. Each hour AWS measures several dimensions and bills only the highest one. Prices for us-east-1 at the time of writing:

Each GWLB endpoint is billed separately through PrivateLink: $0.01 per hour per AZ plus $0.0035 per GB.

Worked example (ALB). In a busy hour an ALB sees 50 new connections per second, 9,000 active connections, 2.5 GB processed, and 200 requests per second that each pass through 15 rules.

• New connections: 50 ÷ 25 = 2 LCU
• Active connections: 9,000 ÷ 3,000 = 3 LCU
• Processed bytes: 2.5 ÷ 1 = 2.5 LCU
• Rule evaluations: 200 × (15 − 10 free) = 1,000 per second ÷ 1,000 = 1 LCU

The highest is 3 LCU. That hour costs $0.0225 + 3 × $0.008 = $0.0465. At that level for a whole month (730 hours): about $33.95.

#Comparing them and choosing

#What goes wrong

#How they are used in system design

• Public web application: Route 53 Alias → ALB (with AWS WAF, HTTPS, HTTP → HTTPS redirect) → an Auto Scaling group per service. The default design for anything HTTP.
• Microservices on containers: one ALB, one target group per service, path and host rules, ECS registering tasks on dynamic ports or by IP.
• Gaming, IoT and real-time media: NLB with UDP or TCP listeners and Elastic IPs, often with Global Accelerator for players worldwide.
• Business-to-business APIs with allowlists: NLB with Elastic IPs → ALB for routing and WAF.
• SaaS sold to other AWS accounts: NLB as a PrivateLink endpoint service; customers connect from their own VPCs with no public exposure.
• Hybrid migration: an ALB with some target groups in AWS and an ip target group pointing at servers still on premises; shift weights as services move.
• Regulated traffic inspection: GWLB with a fleet of third-party firewalls in a central security VPC, and GWLB endpoints plus route tables in every application VPC.

#Try it yourself

# 1. ALB with path-based routing (two services and a default)
for TG in tg-users tg-search tg-web; do
  aws elbv2 create-target-group --name $TG --protocol HTTP --port 80 --vpc-id $VPC \
    --target-type instance --health-check-path /health
done
aws elbv2 register-targets --target-group-arn $TG_USERS --targets Id=i-0abc1234 Id=i-0def5678

ALB=$(aws elbv2 create-load-balancer --name web-alb --type application \
  --scheme internet-facing --subnets $SUBNET_A $SUBNET_B --security-groups $SG_ALB \
  --query "LoadBalancers[0].LoadBalancerArn" --output text)
LISTENER=$(aws elbv2 create-listener --load-balancer-arn $ALB --protocol HTTP --port 80 \
  --default-actions Type=forward,TargetGroupArn=$TG_WEB \
  --query "Listeners[0].ListenerArn" --output text)

aws elbv2 create-rule --listener-arn $LISTENER --priority 10 \
  --conditions Field=path-pattern,Values='/users*' \
  --actions Type=forward,TargetGroupArn=$TG_USERS
aws elbv2 create-rule --listener-arn $LISTENER --priority 20 \
  --conditions Field=host-header,Values=search.example.com \
  --actions Type=forward,TargetGroupArn=$TG_SEARCH
aws elbv2 describe-rules --listener-arn $LISTENER \
  --query "Rules[].[Priority,Conditions[0].Field,Actions[0].Type]" --output table

# 2. Canary: 90% to v1, 10% to v2 on the /users rule
aws elbv2 modify-rule --rule-arn $RULE_USERS --actions '[{"Type":"forward","ForwardConfig":{
  "TargetGroups":[{"TargetGroupArn":"'$TG_USERS'","Weight":90},
                  {"TargetGroupArn":"'$TG_BETA'","Weight":10}]}}]'

# 3. Fixed response for a blocked range
aws elbv2 create-rule --listener-arn $LISTENER --priority 5 \
  --conditions Field=source-ip,SourceIpConfig='{Values=["203.0.113.0/24"]}' \
  --actions Type=fixed-response,FixedResponseConfig='{StatusCode=403,ContentType=text/plain,MessageBody=blocked}'

# 4. On-premises server as an IP target (outside the VPC → AvailabilityZone=all)
aws elbv2 create-target-group --name tg-legacy --protocol HTTPS --port 443 \
  --target-type ip --vpc-id $VPC
aws elbv2 register-targets --target-group-arn $TG_LEGACY \
  --targets Id=10.20.0.15,AvailabilityZone=all

# 5. Internet-facing NLB with your own Elastic IPs and a security group (only possible now!)
NLB=$(aws elbv2 create-load-balancer --name game-nlb --type network \
  --subnet-mappings SubnetId=$SUBNET_A,AllocationId=$EIP_A SubnetId=$SUBNET_B,AllocationId=$EIP_B \
  --security-groups $SG_NLB --query "LoadBalancers[0].LoadBalancerArn" --output text)
aws elbv2 create-target-group --name tg-game --protocol UDP --port 7777 --vpc-id $VPC \
  --health-check-protocol HTTP --health-check-port 8080 --health-check-path /health
dig +short game-nlb-0123456789.elb.us-east-1.amazonaws.com    # always the same two IPs

# 6. NLB in front of the ALB (static IPs + path rules)
aws elbv2 create-target-group --name tg-alb --target-type alb --protocol TCP --port 80 --vpc-id $VPC
aws elbv2 register-targets --target-group-arn $TG_ALB --targets Id=$ALB

# 7. GWLB with an appliance fleet and an endpoint in the app VPC
GWLB=$(aws elbv2 create-load-balancer --name fw-gwlb --type gateway \
  --subnets $SEC_SUBNET_A $SEC_SUBNET_B --query "LoadBalancers[0].LoadBalancerArn" --output text)
aws elbv2 create-target-group --name tg-fw --protocol GENEVE --port 6081 --vpc-id $SEC_VPC \
  --health-check-protocol TCP --health-check-port 80
aws elbv2 create-listener --load-balancer-arn $GWLB --default-actions Type=forward,TargetGroupArn=$TG_FW
aws ec2 create-vpc-endpoint-service-configuration --gateway-load-balancer-arns $GWLB \
  --no-acceptance-required
aws ec2 create-vpc-endpoint --vpc-endpoint-type GatewayLoadBalancer --service-name $SVC_NAME \
  --vpc-id $APP_VPC --subnet-ids $ENDPOINT_SUBNET
aws ec2 create-route --route-table-id $APP_SUBNET_RT --destination-cidr-block 0.0.0.0/0 \
  --vpc-endpoint-id $GWLBE

# 8. Who is healthy, and why not?
aws elbv2 describe-target-health --target-group-arn $TG_USERS \
  --query "TargetHealthDescriptions[].[Target.Id,Target.Port,TargetHealth.State,TargetHealth.Reason]"

#Summary

Key takeaways

• ALB = layer 7 (HTTP, HTTPS, HTTP/2, gRPC, WebSockets). NLB = layer 4 (TCP, UDP, TLS). GWLB = layer 3 (all IP packets, GENEVE to appliances). CLB = legacy.
• ALB listener rules: conditions on path (case-sensitive), host, header, method, query string, source IP; lowest priority number wins; every condition in a rule must match; the default rule catches the rest.
• ALB actions: forward (up to five weighted target groups for canary and blue/green), redirect (HTTP → HTTPS), fixed-response, authenticate with Cognito or OIDC.
• Behind an ALB the app sees the ALB’s IP; the client is in X-Forwarded-For (plus X-Forwarded-Proto and X-Forwarded-Port).
• ALB and CLB have a fixed DNS name, not a fixed IP: use a Route 53 Alias record, never the IPs.
• ALB fits microservices and containers: one ALB, many target groups, ECS dynamic port mapping (allow the ephemeral range from the ALB’s security group).
• NLB: millions of requests per second, one static IP per AZ (Elastic IP possible), client IP preserved, targets instance / IP / ALB, health checks TCP/HTTP/HTTPS, security groups only at creation, front of PrivateLink endpoint services.
• GWLB: transparent gateway + load balancer for third-party firewalls, IDS/IPS, DPI; GENEVE on UDP 6081; GWLB endpoints and route tables in both directions; failed appliances are bypassed for new flows.
• Target groups: target type fixed at creation; health checks per group; one target in many groups; IP targets must be private (on-premises over VPN/Direct Connect); Lambda for ALB only.
• Price = hourly charge + the highest capacity-unit dimension (LCU, NLCU, GLCU).

Self-check: ALB, NLB, GWLB and target groups30 questions