Introducing QUIC Protocol Support for Network Load Balancer: Accelerating Mobile-First Applications

Today, AWS announces the launch of QUIC protocol support for Network Load Balancer (NLB). This capability enables customers to forward QUIC traffic to their targets with ultra-low latency while maintaining session stickiness using QUIC Connection IDs. In this blog we will provide an overview of QUIC, demonstrate how to enable it using the AWS Console and CLI, and provide additional considerations.

What is QUIC and Why Does It Matter?

QUIC (RFC 9000) represents a fundamental shift in how we approach network communication in our mobile-first world. QUIC is a transport protocol that runs over UDP and provides built-in encryption, congestion control, and multiplexing capabilities. QUIC is the transport protocol for HTTP/3, enabling applications to use HTTP/3 for their workloads to achieve better latency, connection resilience, and reduced head-of-line blocking. Unlike traditional networking protocols designed for static nodes, QUIC is built from the ground up for mobile devices and applications that demand:

• Ultra-low latency through minimized handshakes and reduced packet round trips
• Built-in security with TLS 1.3 encryption
• Connection resilience that maintains sessions even when client IP addresses or port numbers change

The Mobile Revolution Demands Better Performance

The explosive growth of smartphone applications has created new performance expectations. Companies providing mobile gaming, ride-sharing applications and other latency-sensitive industries have already implemented QUIC in their applications to deliver superior user experiences. On the client side, major browsers including Safari, Chrome, Edge, and Firefox support QUIC by default. QUIC can reduce end-to-end application latency by 25-30%, transforming user experiences from sluggish 500ms response times to snappy 350ms interactions. This improvement is particularly important in regions with limited cellular bandwidth and lower network quality.

NLB QUIC: Passthrough Mode for Maximum Performance

Network Load Balancer’s QUIC protocol passthrough complements Amazon CloudFront’s existing QUIC termination capabilities, giving customers flexibility to optimize performance at both the edge and core of their infrastructure. The Network Load Balancer implementation focuses on QUIC passthrough mode, which means the NLB forwards QUIC traffic directly to targets without terminating the client sessions. This approach delivers several key advantages:

• Minimal latency overhead – No additional processing delays
• High performance – Packet-level forwarding for maximum throughput
• Customer control – Customers maintain full control over TLS certificates and client-server interactions through end-to-end TLS of the payload.
• Flexibility – Customers can continue optimizing their applications without load balancer constraints
• Session Stickiness – Maintains connection continuity using QUIC Connection IDs, even when UDP 5-tuples change during sessions.
• Health Check Compatibility – Works with existing TCP health checks, simplifying migration from current architectures.
• Kubernetes Integration – Support for Amazon Elastic Kubernetes Service (EKS) deployments through the AWS Load Balancer Controller.
• Existing Metrics – Leverages current UDP metrics with additional QUIC-specific insights for connection tracking and routing decisions. See the monitoring section later on for details and recommendations.

This functionality leverages the QUIC load balancer specification from the Internet Engineering Task Force (IETF). The key concept is the QUIC Connection ID (a standard part of QUIC that server software generates for clients) has a Server ID encoded within it. NLB requires an 8-byte Server ID, which customers configure per instance, as discussed below.

Early adopters are already seeing substantial benefits. One customer expects to save a full network round trip in their latency-sensitive search service, directly improving their mobile user interface responsiveness. With usage projections of 145 TB/day and peak connection rates of 200,000 connections per second, the performance gains translate to measurable business value.

Getting Started

QUIC support is available for new and existing Network Load Balancers. You can enable QUIC protocol support through the AWS Management Console, CLI, APIs, or AWS Load Balancer Controller.

For customers currently using workarounds or considering alternatives, NLB QUIC support provides a native AWS solution that eliminates the complexity and additional costs of custom implementations.

To get started with the console:

1. Go to EC2 then Load Balancers
2. Click Create Load Balancer
3. Click Create under Network Load Balancer. On the next screen, you will see the new QUIC related options available when no security groups are defined, as shown in Figure 1.

Figure 1: New QUIC and TCP_QUIC protocol options in Load Balancer configuration

You can select QUIC as a protocol type, which supports standard QUIC over UDP. TCP_QUIC is a better choice for using QUIC to support an HTTP/3 application because it allows you to configure both QUIC on UDP 443 and the fallback standard HTTPS server on TCP 443 with one listener.

When configuring the target group, you have two corresponding options: QUIC and TCP_QUIC. Ensure your target group and listener match.

Figure 2: NLB Target Group configuration with new QUIC and TCP_QUIC protocol options highlighted

After clicking through the target group creation, you will reach a Register targets screen that looks somewhat different than other modes (Figure 3). First, you must use Instance ID as your target type. Second, a new parameter for QUIC is the Server ID:

Figure 3: Target group target registration screen with new Server ID field highlighted.

This is where you configure which server ID corresponds to which instance. This mechanism (referred to as plaintext CID) allows NLB to route traffic without requiring your decryption keys, avoiding security risks. NLB uses the Server ID (part of the Connection ID) to steer traffic accordingly.

If you are using QUIC mode, your final listener configuration should look like this (Figure 4):

Figure 4: Completed listener configuration, with QUIC protocol and target group highlighted.

Follow best practice and configure health checks for your targets, as you would with any other NLB usage.

Performing these same steps in the AWS CLI or AWS SDKs works as expected:

1. Create the target group, again using QUIC or TCP_QUIC as the protocol:

   % aws elbv2 create-target-group --name API-QUIC --protocol QUIC --port 443 --vpc-id vpc-1234567890abcdef0
   {
        "TargetGroups": [
            {
                "TargetGroupArn": "arn:aws:elasticloadbalancing:ap-southeast-4:111122223333:targetgroup/API-QUIC/1234567890abcdef0",
                "TargetGroupName": "API-QUIC",
                "Protocol": "QUIC",
                "Port": 443,
                "VpcId": "vpc-1234567890abcdef0",
                "HealthCheckProtocol": "TCP",
                "HealthCheckPort": "traffic-port",
                "HealthCheckEnabled": true,
                "HealthCheckIntervalSeconds": 30,
                "HealthCheckTimeoutSeconds": 10,
                "HealthyThresholdCount": 5,
                "UnhealthyThresholdCount": 2,
                "TargetType": "instance",
                "IpAddressType": "ipv4"
            }
        ]
    }
   

2. Construct the listener to connect the NLB to the target group:

   % aws elbv2 create-load-balancer --name API-QUIC-LB --subnets subnet-1234567890abcdef0 subnet-1234567890abcdef1 subnet-1234567890abcdef2 --type network --scheme internet-facing        
   {
       "LoadBalancers": [
           {
               "LoadBalancerArn": "arn:aws:elasticloadbalancing:ap-southeast-4:111122223333:loadbalancer/net/API-QUIC-LB/021345abcdef67890",
               "DNSName": "API-QUIC-LB-021345abcdef67890.elb.ap-southeast-4.amazonaws.com",
               "CanonicalHostedZoneId": "Z12345678ABCDEFGHIJK",
               "CreatedTime": "2025-10-31T02:24:43.514000+00:00",
               "LoadBalancerName": "API-QUIC-LB",
               "Scheme": "internet-facing",
               "VpcId": "vpc-1234567890abcdef0",
               "State": {
                   "Code": "provisioning"
               },
               "Type": "network",
               "AvailabilityZones": [
                   {
                       "ZoneName": "ap-southeast-4a",
                       "SubnetId": "subnet-1234567890abcdef0",
                       "LoadBalancerAddresses": []
                   },
                   {
                       "ZoneName": "ap-southeast-4b",
                       "SubnetId": "subnet-1234567890abcdef1",
                       "LoadBalancerAddresses": []
                   },
                   {
                       "ZoneName": "ap-southeast-4c",
                       "SubnetId": "subnet-1234567890abcdef2",
                       "LoadBalancerAddresses": []
                   }
               ],
               "IpAddressType": "ipv4",
               "EnablePrefixForIpv6SourceNat": "off"
           }
       ]
   }
   

3. Construct the listener to connect the NLB to the target group:

   % aws elbv2 create-listener --load-balancer-arn arn:aws:elasticloadbalancing:ap-southeast-4:111122223333:loadbalancer/net/API-QUIC-LB/1234567890abcdef0 --protocol QUIC --port 443 --default-actions Type=forward,TargetGroupArn=arn:aws:elasticloadbalancing:ap-southeast-4:111122223333:targetgroup/API-QUIC/1234567890abcdef0
   {
       "Listeners": [
           {
               "ListenerArn": "arn:aws:elasticloadbalancing:ap-southeast-4:111122223333:listener/net/API-QUIC-LB/1234567890abcdef0/abcdef01234567890",
               "LoadBalancerArn": "arn:aws:elasticloadbalancing:ap-southeast-4:111122223333:loadbalancer/net/API-QUIC-LB/1234567890abcdef0",
               "Port": 443,
               "Protocol": "QUIC",
               "DefaultActions": [
                   {
                       "Type": "forward",
                       "TargetGroupArn": "arn:aws:elasticloadbalancing:ap-southeast-4:111122223333:targetgroup/API-QUIC/1234567890abcdef0",
                       "ForwardConfig": {
                           "TargetGroups": [
                               {
                                   "TargetGroupArn": "arn:aws:elasticloadbalancing:ap-southeast-4:111122223333:targetgroup/API-QUIC/1234567890abcdef0"
                               }
                           ],
                           "TargetGroupStickinessConfig": {
                               "Enabled": false
                           }
                       }
                   }
               ]
           }
       ]
   }
   

4. Finally, register your instances with the target group, using the new QuicServerId field in addition to the usual entries:

   % aws elbv2 register-targets --target-group-arn arn:aws:elasticloadbalancing:ap-southeast-4:111122223333:targetgroup/API-QUIC/1234567890abcdef0 --targets Id=i-1234567890abcdef0,Port=443,QuicServerId=0x1122334455667788

You can register the same instance with multiple target groups, using the same QuicServerId for all of them. Different instances must use different QuicServerIds.

Monitoring

QUIC Network Load Balancers provide new Amazon CloudWatch metrics that customers should add to their monitoring and alerting systems:

• NewFlowCount_QUIC – This metric provides the number of newly initiated QUIC flows seen through the load balancer. Customers should monitor this metric for changes that deviate from their workload patterns.
• ProcessedBytes_QUIC – This metric shows the total number of bytes processed by QUIC listeners. Customers should monitor this metric for changes that deviate from their baseline workload patterns.
• QUIC_Unknown_Server_ID_Packet_Drop_Count – This metric increments when the load balancer receives a Server ID that is not registered with NLB. Customers should set alarms for increases in this count, as this indicates invalid server IDs are being generated. Increments can occur when servers are deregistered and removed before clients have finished their sessions.

Considerations

• The QUIC load balancer specification from IETF (QUIC-LB) is currently in draft state. AWS offers support based on the current draft, which has remained stable for several months. Details may change between now and when QUIC-LB becomes an RFC. Monitor the specification for changes you will need to implement.
• QUIC is used for internet-facing traffic with a single port, so the option to add additional security groups in front of NLB is not available. To handle restrictions, implement them in your server software.
• QUIC-LB is a new technology, and server software platforms have not yet implemented it in their main codebases. To test this functionality, we built a server in Rust using AWS’s s2n-quic library and its support for custom Connection ID generators. The s2n-quic library provides a good starting point if your use case requires that level of customization. Fast-moving software branches are also available for evaluation, or you can ask your software vendor when they will add support for QUIC-LB.
• For networking professionals, note that the QUIC RFC states in section 14 that UDP packets must not be fragments, which reduces implementation complexity.
• Your server software encodes specific server IDs in the connection ID and NLB uses that encoding instead of sticky sessions or other techniques to keep sessions tied to one target. Consider how your application will handle failover. Amazon’s CTO, Werner Vogels, says that ‘Everything Fails All the Time’. Plan how your software will handle cases when your server fails or needs to be replaced.
• This feature is supported in all AWS Commercial and GovCloud (US) Regions.
• This is no additional charge for using this feature beyond standard NLB charges

Conclusion

This launch demonstrates AWS’s commitment to supporting mobile and web applications. NLB’s QUIC protocol passthrough complements existing Amazon CloudFront QUIC termination capabilities, giving you flexibility to optimize performance at both the edge and core of your infrastructure. AWS provides the tools and services you need to deliver high-quality user experiences. QUIC support on Network Load Balancer advances this capability.

Enable QUIC support on your Network Load Balancer today to improve your mobile application performance. For detailed technical specifications and implementation guidance, visit the AWS documentation.

About the authors