AWS Network Load Balancer – NLB
- Network Load Balancer – NLB operates at the connection level (Layer 4), routing connections to targets – EC2 instances, and containers based on IP protocol data.
- NLB is suited for load balancing of TCP, UDP, TLS, and QUIC traffic.
- NLB is capable of handling millions of requests per second while maintaining ultra-low latencies (~100 ms vs 400 ms for ALB)
- NLB is optimized to handle sudden and volatile traffic patterns while using a single static IP address per Availability Zone.
- NLB also supports TLS termination, preserves the source IP of the clients, and provides stable IP support and Zonal isolation.
- NLB supports long-running connections that are very useful for WebSocket-type applications.
- NLB is integrated with other AWS services such as Auto Scaling, EC2 Container Service (ECS), CloudFormation, and AWS Certificate Manager (ACM).
- NLB supports connections from clients over VPC peering, AWS-managed VPN, Direct Connect, and third-party VPN solutions.
- NLB now supports security groups (since Aug 2023), enabling filtering of traffic that NLB accepts and forwards to applications.
- For TCP traffic,
- the load balancer selects a target using a flow hash algorithm based on the protocol, source IP address, source port, destination IP address, destination port, and TCP sequence number.
- TCP connections from a client having different source ports and sequence numbers and can be routed to different targets.
- Each individual TCP connection is routed to a single target for the life of the connection.
- For UDP traffic,
- the load balancer selects a target using a flow hash algorithm based on the protocol, source IP address, source port, destination IP address, and destination port.
- A UDP flow has the same source and destination, so it is consistently routed to a single target throughout its lifetime.
- Different UDP flows have different source IP addresses and ports, so they can be routed to different targets.
- For QUIC traffic,
- NLB supports QUIC protocol in passthrough mode, forwarding QUIC traffic directly to targets without terminating sessions.
- Session stickiness is maintained using QUIC Connection IDs, even when client IP addresses change during network roaming.
- QUIC and TCP_QUIC listeners are not allowed on dualstack load balancers or load balancers with associated security groups.
- back-end server authentication (MTLS) is not supported on NLB. mTLS is only supported on ALB.
Classic Load Balancer vs Application Load Balancer vs Network Load Balancer
Refer Blog Post @ Classic Load Balancer vs Application Load Balancer vs Network Load Balancer
Network Load Balancer Features
Connection-based Layer 4 Load Balancing
- Allows load balancing of TCP, TLS, UDP, TCP_UDP, QUIC, and TCP_QUIC traffic, routing connections to targets – EC2 instances, microservices, and containers.
High Availability
- is highly available.
- accepts incoming traffic from clients and distributes this traffic across the targets within the same AZ (except for Cross-zone load balancing).
- monitors the health of its registered targets and routes the traffic only to healthy targets
- if a health check fails and an unhealthy target is detected, it stops routing traffic to that target and reroutes traffic to remaining healthy targets.
- if configured with multiple AZs and if all the targets in a single AZ fail, it routes traffic to healthy targets in the other AZs
Availability Zones
- can be used to route traffic across multiple Availability Zones.
- However, AZ must be enabled before the traffic is routed to that AZ.
- AZ can be enabled, even after the NLB creation.
- AZ can now be disabled/removed (since Feb 2025) – you can remove one or more availability zones from NLB by updating the list of enabled subnets using the ELB API, CLI, or Console.
- Cross-zone load balancing works only for AZs enabled with NLB.
High Throughput
- is designed to handle traffic as it grows and can load balance millions of requests/sec.
- can also handle sudden volatile traffic patterns.
Low Latency
- offers extremely low latencies for latency-sensitive applications.
Security Groups
- NLB now supports security groups (since August 2023), enabling you to filter the traffic that your NLB accepts and forwards to your application.
- Security groups can be configured with rules to ensure that NLB only accepts traffic from trusted IP addresses and centrally enforces access control policies.
- Security group inbound rules can be enforced even when the load balancer converts IPv6 traffic to IPv4 or when targets are in peered VPCs.
- Security group association is optional – NLBs can still be created without security groups for backward compatibility.
- QUIC and TCP_QUIC listeners are not supported on NLBs with associated security groups.
Cross Zone Load Balancing
- enables cross-zone loading balancing only after creating the NLB
- is disabled, by default, and charges apply for inter-az traffic.
- only works for the AZs that are enabled on the NLB.
- can also be configured at the target group level, allowing per-target-group cross-zone settings.
Sticky Sessions
- Sticky sessions (source IP affinity) are a mechanism to route requests from the same client to the same target.
- Stickiness is defined at the target group level.
- For QUIC traffic, stickiness is maintained using QUIC Connection IDs.
Load Balancing using IP addresses as Targets
- allows load balancing of any application hosted in AWS or on-premises using IP addresses of the application backends as targets.
- allows load balancing to an application backend hosted on any IP address and any interface on an instance.
- ability to load balance across AWS and on-premises resources help migrate-to-cloud, burst-to-cloud or failover-to-cloud.
- applications hosted in on-premises locations can be used as targets over a Direct Connect connection.
- supports registering targets using IPv6 addresses (since Oct 2023).
Preserve Source IP Address
- preserves client-side source IP allowing the back-end to see the client IP address.
- Target groups can be created with target type as instance ID or IP address.
- If targets are registered by instance ID or ECS tasks, the source IP addresses of the clients are preserved and provided to the applications.
- If targets are registered by IP address
- for TCP & TLS, the source IP addresses are the private IP addresses of the load balancer nodes. Use Proxy Protocol.
- for UDP & TCP_UDP, it is enabled by default and the source IP addresses of the clients are preserved.
Static IP support
- automatically provides a static IP per Availability Zone (subnet) that can be used by applications as the front-end IP of the load balancer.
- creates a network interface for each enabled AZ. Each load balancer node in the AZ uses this network interface to get a static IP address.
- Internet-facing load balancer can optionally associate one Elastic IP address per subnet.
Elastic IP support
- an Elastic IP per Availability Zone (subnet) can also be assigned, optionally, thereby providing a fixed IP.
Configurable TCP Idle Timeout
- TCP idle timeout can now be configured to any value between 60-6000 seconds (since Sep 2024).
- The default idle timeout for TCP flows is 350 seconds.
- Previously, this was a fixed value of 350 seconds that could not be modified.
- Configurable timeout helps reduce latency for long-lived traffic flows by maintaining target stickiness for the optimal duration.
- The connection idle timeout for TLS listeners remains fixed at 350 seconds.
- UDP connections have a fixed 120 second idle timeout.
- Clients or targets can use TCP keepalive packets to restart the idle timeout.
Health Checks
- supports both network and application target health checks using HTTP, HTTPS, and TCP.
- Network-level health check
- is based on the overall response of the underlying target (instance or a container) to normal traffic.
- target is marked unavailable if it is slow or unable to respond to new connection requests
- Application-level health check
- is based on a specific URL on a given target to test the application health deeper
- Target group health settings can be configured to define minimum healthy target count/percentage and actions when thresholds are not met (since Nov 2022).
- Unhealthy target connection termination can be disabled, allowing active connections to persist even when targets fail health checks (since Oct 2023).
DNS Fail-over
- integrates with Route 53
- Route 53 will direct traffic to load balancer nodes in other AZs, if there are no healthy targets with NLB or if the NLB itself is unhealthy
- if NLB is unresponsive, Route 53 will remove the unavailable load balancer IP address from service and direct traffic to an alternate Network Load Balancer in another region.
Zonal Shift and Autoshift (Route 53 ARC)
- NLB integrates with Amazon Application Recovery Controller (ARC) for zonal shift capabilities.
- Zonal Shift allows you to manually shift NLB traffic away from an impaired Availability Zone.
- Zonal Autoshift allows AWS to automatically shift traffic away from an AZ when it detects a potential failure, reducing time to recovery.
- Zonal shift is disabled by default and must be enabled on each NLB.
- Works only when cross-zone load balancing is turned off (the default for NLB).
- Provides automated recovery without manual intervention during AZ impairments.
Integration with AWS Services
- is integrated with other AWS services such as Auto Scaling, EC2 Container Service (ECS), CloudFormation, Elastic Beanstalk, CodeDeploy, AWS Config, CloudTrail, and AWS Certificate Manager (ACM).
Long-lived TCP Connections
- supports long-lived TCP connections ideal for WebSocket-type of applications
- with configurable idle timeout (60-6000 seconds), long-lived connections can be maintained optimally.
Central API Support
- uses the same API as Application Load Balancer.
- enables you to work with target groups, health checks, and load balance across multiple ports on the same EC2 instance to support containerized applications.
Robust Monitoring and Auditing
- integrated with CloudWatch to report Network Load Balancer metrics.
- CloudWatch provides metrics such as Active Flow count, Healthy Host Count, New Flow Count, Processed bytes, ZonalHealthStatus, and more.
- integrated with CloudTrail to track API calls to the NLB
- Resource Map (since Apr 2024) provides a visual representation of load balancer resources and their relationships in the console.
Enhanced Logging
- NLB access logs capture information about TLS requests sent to the load balancer, stored in Amazon S3.
- Flow Logs feature helps record all requests sent to the load balancer.
- Flow Logs capture information about the IP traffic going to and from network interfaces in the VPC.
- Flow log data is stored using CloudWatch Logs.
Zonal Isolation
- is designed for application architectures in a single zone.
- can be enabled in a single AZ to support architectures that require zonal isolation
- automatically fails-over to other healthy AZs, if something fails in an AZ
- it’s recommended to configure the load balancer and targets in multiple AZs for achieving high availability
Zonal DNS Name
- supports DNS names for each of its nodes.
- by default, resolving the Regional NLB DNS name returns the IP address for all NLB nodes in all enabled AZs.
- can be used to determine the IP address of each node.
- useful to minimize latency and inter-az data transfer costs.
- Zonal DNS Affinity (since Oct 2023) allows clients resolving the load balancer DNS to receive an IP address in the same AZ they are in, supporting affinity levels of 100%, 85%, or 0%.
TLS Offloading
- NLB supports client TLS session termination, allowing TLS termination tasks to be offloaded to the load balancer while preserving the source IP address for back-end applications.
- Predefined security policies can be selected for TLS listeners to meet compliance and security standards.
- Supports SNI (Server Name Indication) to serve multiple secure websites using a single TLS listener.
- Supports RSA 3072-bit and ECDSA 256/384/521-bit certificates via ACM (since Jan 2024).
- Supports FIPS 140-3 cryptographic modules for TLS termination (since Nov 2023).
- Supports Post-Quantum TLS (PQ-TLS) key exchange using ML-KEM768 to protect against “Harvest Now, Decrypt Later” (HNDL) attacks (since Nov 2025).
- ALPN (Application-Layer Protocol Negotiation) policies supported for TLS listeners.
IP Address Types
- IPv4 – clients connect using IPv4 addresses only.
- Dualstack – clients can connect using both IPv4 and IPv6 addresses.
- UDP over IPv6 is supported for dualstack load balancers (since Oct 2024).
- Internal dualstack NLB access through the internet gateway is blocked to prevent unintended internet access.
Weighted Target Groups
- NLB supports weighted target groups (since Nov 2025), allowing multiple target groups per listener with configurable weights ranging from 0 to 999.
- Enables blue/green deployments, canary deployments, application migration, and A/B testing with zero downtime.
- Eliminates the need for multiple load balancers to perform traffic splitting.
- Provides precise control over traffic distribution between target groups.
QUIC Protocol Support
- NLB supports QUIC protocol in passthrough mode (since Nov 2025), forwarding QUIC traffic directly to targets without terminating sessions.
- Maintains session stickiness using QUIC Connection IDs, even when client IP addresses change during network roaming.
- Ideal for mobile-first applications where clients frequently switch between cellular and WiFi networks.
- Reduces end-to-end application latency by 25-30% compared to traditional protocols.
- TCP_QUIC listeners support HTTP/3 applications with automatic fallback to HTTPS on TCP 443.
- Limitations: QUIC/TCP_QUIC listeners are not allowed on dualstack load balancers, load balancers with associated security groups, or NLBs with UDP/TCP_UDP listeners. Only one QUIC or TCP_QUIC listener allowed per NLB.
Secondary IPv4 Addresses
- NLB supports configuring up to 7 additional (secondary) IPv4 addresses on its egress network interfaces (since Jul 2025).
- Increases concurrent connections per target from 64K to 512K by overcoming the 64K TCP ephemeral port constraint.
- Helps resolve port allocation errors in high-connection-count scenarios where source IP preservation cannot be used.
- Configurable via the
secondary_ips.auto_assigned.per_subnetattribute (valid range: 0-7). - Once set, this value cannot be decreased.
LCU Capacity Reservations
- NLB supports Load Balancer Capacity Unit (LCU) Reservations (since Nov 2024) to reserve a static minimum capacity.
- Ideal for planned events with sudden high traffic (product launches, sales, traffic migrations).
- NLB continues to auto-scale based on traffic, but capacity won’t go below the configured minimum.
- Each LCU equals 2.2 Mbps of processed bandwidth.
- You pay for reserved LCUs and any additional usage above the reservation.
Advantages over Classic Load Balancer
- Ability to handle volatile workloads and scale to millions of requests per second, without the need of pre-warming
- Support for static IP/Elastic IP addresses for the load balancer
- Support for registering targets by IP address, including targets outside the VPC (on-premises) for the load balancer.
- Support for routing requests to multiple applications on a single EC2 instance. A single instance or IP address can be registered with the same target group using multiple ports.
- Support for containerized applications. Using Dynamic port mapping, ECS can select an unused port when scheduling a task and register the task with a target group using this port.
- Support for monitoring the health of each service independently, as health checks are defined at the target group level and many CloudWatch metrics are reported at the target group level. Attaching a target group to an Auto Scaling group enables scaling each service dynamically based on demand
- Support for security groups, enabling centralized access control policies
- Support for QUIC protocol for low-latency mobile-first applications
- Support for weighted target groups enabling blue/green and canary deployments
Network Load Balancer Limitations
can’t associate Security Groups with NLBs– NLB now supports security groups (since Aug 2023)can’t disable/remove an AZ once you enable it– NLB now supports removing AZs (since Feb 2025)- can’t modify ENIs created by NLB in each AZ
- can’t change EIPs and Private IPs attached to the ENIs after NLB creation.
- can’t register EC2 instances by instance ID for instances in another VPC even if VPC peering is done.
- QUIC/TCP_QUIC listeners not allowed on dualstack NLBs or NLBs with security groups.
- mTLS (Mutual TLS) is not supported – only available on ALB.
- TLS listener idle timeout is fixed at 350 seconds and cannot be modified.
Network Load Balancer with AWS PrivateLink
- Interface Endpoints can be used to create custom applications in VPC and configure them as an AWS PrivateLink-powered service (referred to as an endpoint service) exposed through a Network Load Balancer. The custom applications can be hosted within AWS or on-premises.

Network Load Balancer Pricing
- charged for each hour or partial hour that an NLB is running and the number of Load Balancer Capacity Units (LCU) used per hour.
- An LCU is a metric for determining NLB pricing
- An LCU defines the maximum resource consumed in any one of the dimensions (new connections/flows, active connections/flows, bandwidth and rule evaluations) the Network Load Balancer processes your traffic.
- If using LCU Capacity Reservations, you pay for reserved LCUs per minute plus any additional LCUs used beyond the reservation.
AWS Certification Exam Practice Questions
- Questions are collected from Internet and the answers are marked as per my knowledge and understanding (which might differ with yours).
- AWS services are updated everyday and both the answers and questions might be outdated soon, so research accordingly.
- AWS exam questions are not updated to keep up the pace with AWS updates, so even if the underlying feature has changed the question might not be updated
- Open to further feedback, discussion and correction.
- A company wants to use load balancer for their application. However, the company wants to forward the requests without any header modification. What service should the company use?
- Classic Load Balancer
- Network Load Balancer
- Application Load Balancer
- Use Route 53
- A company is hosting an application in AWS for third party access. The third party needs to whitelist the application based on the IP. Which AWS service can the company use in the whitelisting of the IP address?
- AWS Application Load Balancer
- AWS Classic Load balancer
- AWS Network Load Balancer
- AWS Route 53
- A company wants to restrict inbound traffic to their Network Load Balancer to only specific trusted IP ranges. What is the recommended approach?
- Use NACLs on the NLB subnet
- Configure WAF with NLB
- Associate a security group with the NLB and configure inbound rules
- Use Route 53 health checks to filter traffic
- A company needs to perform a blue/green deployment for a TCP-based application running behind a Network Load Balancer. They want to gradually shift traffic from the old version to the new version. What is the MOST operationally efficient approach?
- Create two NLBs and use Route 53 weighted routing
- Use AWS CodeDeploy with two target groups
- Configure weighted target groups on the NLB listener to distribute traffic between blue and green target groups
- Manually deregister targets from the existing target group and register new targets
- A mobile gaming company uses Network Load Balancer for their real-time game servers. Players frequently switch between WiFi and cellular networks, causing connection drops. Which NLB feature helps maintain session continuity during network changes?
- Source IP affinity sticky sessions
- TCP keepalive packets
- QUIC protocol support with Connection ID-based stickiness
- Cross-zone load balancing
- A company runs a high-throughput application behind an NLB with IP-type targets. They are experiencing TCP port allocation errors because they have over 64,000 concurrent connections to a single target. What should they do?
- Enable cross-zone load balancing to distribute traffic
- Switch to instance-type targets
- Configure secondary IPv4 addresses on the NLB egress interface
- Add more targets to the target group
- A company wants to ensure their NLB can handle a planned traffic spike during a product launch event without relying on auto-scaling warm-up time. What feature should they use?
- Pre-warming request to AWS Support
- Cross-zone load balancing
- Multiple target groups with higher weights
- LCU Capacity Reservations
- An organization wants to protect their TLS-terminated NLB traffic against future quantum computing threats. Which NLB feature addresses this concern?
- FIPS 140-3 security policies
- Post-Quantum TLS (PQ-TLS) security policies with ML-KEM768
- RSA 3072-bit certificates
- ECDSA 521-bit certificates
References
AWS Documentation – Network Load Balancer
AWS Documentation – Network Load Balancers
AWS Documentation – NLB Listeners
AWS Documentation – NLB Security Groups
AWS Documentation – Zonal Shift for NLB
AWS Documentation – NLB Capacity Reservations




