AWS Application Load Balancer (ALB) now supports Amazon Application Recovery Controller’s zonal shift and zonal autoshift features on load balancers that are enabled across zones. Zonal shift allows you to quickly shift traffic away from an impaired Availability Zone (AZ) and recover from events such as bad application deployment and gray failures. Zonal autoshift safely and automatically shifts your traffic away from an AZ when AWS identifies potential impact to it. Enabling cross-zone on ALBs is a popular configuration for customers that require an even distribution of traffic across application targets in multiple AZs. With this launch, customers can shift traffic away from an AZ in the event of a failure just like they are able to for cross-zone disabled load balancers. When zonal shift or autoshift is triggered, the ALB will block all traffic to targets in the AZ that is impacted and remove the zonal IP from DNS. You can configure this feature in two steps: First, enable configuration to allow zonal shift to act on your load balancer(s) using the ALB console or API. Second, trigger zonal shift or enable zonal autoshift for the chosen ALBs via Amazon Application Recovery Controller console or API. Zonal shift and zonal autoshift support on ALB is available in https://aws.amazon.com/about-aws/global-infrastructure/regional-product-services/, including the https://aws.amazon.com/govcloud-us/. To learn more, please refer to the https://docs.aws.amazon.com/elasticloadbalancing/latest/application/load-balancer-integrations.html#zonal-shift.

AWS Application Load Balancer (ALB) now allows customers to provide a pool of public IPv4 addresses for IP address assignment to load balancer nodes. Customers can configure a public IP Address Manager (IPAM) pool that can consist of either Bring Your Own IP addresses (BYOIPs) that is customer owned or a contiguous IPv4 address block provided by Amazon. With this feature, customers can optimize public IPv4 cost by using BYOIP in public IPAM pools. Customers can also simplify their enterprise allowlisting and operations, by using Amazon-provided contiguous IPv4 blocks in public IPAM pools. The ALB's IP addresses are sourced from the IPAM pool and automatically switch to AWS managed IP addresses when the public IPAM pool is depleted. This intelligent switching maximizes service availability during scaling events. The feature is available in https://aws.amazon.com/about-aws/global-infrastructure/regional-product-services/ and https://aws.amazon.com/govcloud-us/Regions where Amazon VPC IP Address Manager (IPAM) is available. To learn more, please refer to the https://docs.aws.amazon.com/elasticloadbalancing/latest/application/application-load-balancers.html#ip-pools.  

AWS Network Load Balancer (NLB) now supports QUIC protocol in passthrough mode, enabling low-latency forwarding of QUIC traffic while preserving session stickiness through QUIC Connection ID. This enhancement helps customers maintain consistent connections for mobile applications, even when client IP addresses change during network roaming. With QUIC support, customers can reduce application latency by up to 30% through fewer packet round trips and ensure seamless user experiences across varying network conditions. This is especially useful for mobile applications that require users to move between cellular towers or switch from WiFi to cellular networks, without losing connection state. You can enable QUIC support on your existing or new Network Load Balancers through the AWS Management Console, CLI, or APIs. Once enabled, NLB forwards QUIC traffic to targets by using the QUIC Connection ID to maintain session stickiness even when a client roams. QUIC support is available at no additional charge in all AWS commercial and AWS GovCloud (US) regions. QUIC traffic is metered within existing UDP Load Balancer Capacity Unit (LCU) entitlements. To learn more, visit this AWS blog and NLB User Guide.

Today, Amazon Web Services (AWS) announces the general availability of Volume Clones for Amazon Elastic Block Store (Amazon EBS), our high-performance block storage service. This new capability allows you to instantly create and access point-in-time copies of EBS volumes within the same Availability Zone (AZ), accelerating software development workflows and enhancing operational agility. Customers use Amazon EBS volumes as durable block storage attached to Amazon EC2 instances. With Amazon EBS Volume Clones, you can instantly create copies of volumes and access the copied volumes with single-digit millisecond latency. Amazon EBS Volume Clones enables rapid creation of test and development environments from production volumes, eliminating manual copy workflows. Additionally, Volume Clones integrates with the Amazon EBS Container Storage Interface (CSI) driver, simplifying storage management for containerized applications. Amazon EBS Volume Clones is available in all AWS Commercial Regions and AWS GovCloud (US) Regions. You can access Volume Clones through the AWS Console, AWS Command Line Interface (CLI), AWS SDKs, and AWS CloudFormation. This capability supports all EBS volume types and works for volume copies within the same account and AZ. For detailed pricing information, please visit the EBS pricing page. To explore how Volume Clones can accelerate your software development processes and improve operational efficiency, visit the AWS documentation.

Today, we are launching the ability to remove Availability Zones (AZ) of an existing Network Load Balancer (NLB). Prior to this launch, customers could add AZs to an existing NLB, but could not remove AZs. With this capability, customers can now change their application stack locations and move them between availability zones quickly. Changing business needs such as mergers & acquisitions, divestitures, data residency compliance requirements, and capacity considerations in a given region are some of the use cases that necessitate removing AZs of existing NLBs. Using this capability, customers can remove one or more availability zones from their NLB by simply updating the list of enabled subnets using ELB API, CLI or Console. Similar to any delete operation, removing a zone can be a potentially disruptive operation. When you remove a zone, the NLB zonal Elastic Network Interface (ENI) is deleted. All active connections to backend targets in that zone (including clients connecting through other zones) are terminated, the zonal IPs (and EIPs) are released and zonal DNS names deleted, and any backend target in the removed zone becomes “unused”. Refer to product documentation and AWS blog post for prescriptive guidance on how to use this capability in a safe manner. This capability is available in all AWS commercial and the AWS GovCloud (US) Regions.

AWS Application Load Balancer (ALB) now supports Amazon Application Recovery Controller’s zonal shift and zonal autoshift features on load balancers that are enabled across zones. Zonal shift allows you to quickly shift traffic away from an impaired Availability Zone (AZ) and recover from events such as bad application deployment and gray failures. Zonal autoshift safely and automatically shifts your traffic away from an AZ when AWS identifies potential impact to it. Enabling cross-zone on ALBs is a popular configuration for customers that require an even distribution of traffic across application targets in multiple AZs. With this launch, customers can shift traffic away from an AZ in the event of a failure just like they are able to for cross-zone disabled load balancers. When zonal shift or autoshift is triggered, the ALB will block all traffic to targets in the AZ that is impacted and remove the zonal IP from DNS. You can configure this feature in two steps: First, enable configuration to allow zonal shift to act on your load balancer(s) using the ALB console or API. Second, trigger zonal shift or enable zonal autoshift for the chosen ALBs via Amazon Application Recovery Controller console or API. Zonal shift and zonal autoshift support on ALB is available in all commercial AWS Regions, including the AWS GovCloud (US) Regions. To learn more, please refer to the ALB zonal shift documentation.

AWS Application Load Balancers (ALB) now supports Health Check Logs that allows you to send detailed target health check log data directly to your designated Amazon S3 bucket. This optional feature captures comprehensive target health check status, timestamp, target identification data, and failure reasons. Health Check Logs provide complete visibility into target health status with precise failure diagnostics, enabling faster troubleshooting without contacting AWS Support. You can analyze target’s health patterns over time, determine exactly why instances were marked unhealthy, and significantly reduce mean time to resolution for target health investigations. Logs are automatically delivered to your S3 bucket every 5 minutes with no additional charges beyond standard S3 storage costs. This feature is available in all AWS Commercial Regions, AWS GovCloud (US) Regions and AWS China Regions where Application Load Balancer is offered. You can enable Health Check Logs through the AWS Management Console, AWS CLI, or programmatically using the AWS SDK. Learn more about Health Check Logs for ALBs in the AWS documentation.

Today, we are launching the ability to remove Availability Zones (AZ) of an existing Network Load Balancer (NLB). Prior to this launch, customers could add AZs to an existing NLB, but could not remove AZs. With this capability, customers can now change their application stack locations and move them between availability zones quickly. Changing business needs such as mergers & acquisitions, divestitures, data residency compliance requirements, and capacity considerations in a given region are some of the use cases that necessitate removing AZs of existing NLBs. Using this capability, customers can remove one or more availability zones from their NLB by simply updating the list of enabled subnets using ELB API, CLI or Console. Similar to any delete operation, removing a zone can be a potentially disruptive operation. When you remove a zone, the NLB zonal Elastic Network Interface (ENI) is deleted. All active connections to backend targets in that zone (including clients connecting through other zones) are terminated, the zonal IPs (and EIPs) are released and zonal DNS names deleted, and any backend target in the removed zone becomes “unused”. Refer to https://docs.aws.amazon.com/elasticloadbalancing/latest/network/availability-zones.html and https://aws.amazon.com/blogs/networking-and-content-delivery/exploring-new-subnet-management-capabilities-of-network-load-balancer/ for prescriptive guidance on how to use this capability in a safe manner. This capability is available in all https://aws.amazon.com/about-aws/global-infrastructure/regional-product-services/ and the AWS GovCloud (US) Regions.

Application Load Balancer (ALB) now offers Target Optimizer, a new feature that allows you to enforce a maximum number of concurrent requests on a target. With Target Optimizer, you can fine-tune your application stack so that targets receive only the number of requests they can process, achieving higher request success rate, more target utilization, and lower latency. This is particularly useful for compute-intensive workloads. For example, if you have applications that perform complex data processing or inference, you can configure each target to receive as few as one request at a time, ensuring the number of concurrent requests is in line with the target's processing capabilities. You can enable this feature by creating a new target group with a target control port. Once enabled, the feature works with the help of an agent provided by AWS that you run on your targets that tracks request concurrency. For deployments that include multiple target groups per ALB, you have the flexibility to configure this capability for each target group individually. You can enable Target Optimizer through the AWS Management Console, AWS CLI, AWS SDKs, and AWS APIs. ALB Target Optimizer is available in all AWS Commercial Regions, AWS GovCloud (US) Regions, and AWS China Regions. Traffic to target groups that enable Target Optimizer generates more LCU usage than regular target groups. For more information, see the pricing page, launch blog, and ALB User Guide.

Application Load Balancer (ALB) now offers Target Optimizer, a new feature that allows you to enforce a maximum number of concurrent requests on a target. With Target Optimizer, you can fine-tune your application stack so that targets receive only the number of requests they can process, achieving higher request success rate, more target utilization, and lower latency. This is particularly useful for compute-intensive workloads. For example, if you have applications that perform complex data processing or inference, you can configure each target to receive as few as one request at a time, ensuring the number of concurrent requests is in line with the target's processing capabilities. You can enable this feature by creating a new target group with a target control port. Once enabled, the feature works with the help of an agent provided by AWS that you run on your targets that tracks request concurrency. For deployments that include multiple target groups per ALB, you have the flexibility to configure this capability for each target group individually. You can enable Target Optimizer through the AWS Management Console, AWS CLI, AWS SDKs, and AWS APIs. ALB Target Optimizer is available in all AWS Commercial Regions, AWS GovCloud (US) Regions, and AWS China Regions. Traffic to target groups that enable Target Optimizer generates more LCU usage than regular target groups. For more information, see the https://aws.amazon.com/elasticloadbalancing/pricing/?nc=sn&loc=3, https://aws.amazon.com/blogs/networking-and-content-delivery/drive-application-performance-with-application-load-balancer-target-optimizer/, and ALB https://docs.aws.amazon.com/elasticloadbalancing/latest/application/target-group-register-targets.html#register-targets-target-optimizer.

Application Load Balancer (ALB) now supports HTTP request and response header modification giving you greater controls to manage your application’s traffic and security posture without having to alter your application code. This feature introduces three key capabilities: renaming specific load balancer generated headers, inserting specific response headers, and disabling server response header. With header rename, you can now rename all ALB generated Transport Layer Security (TLS) headers that the load balancer adds to requests, which includes the six mTLS headers and two TLS headers (version and cipher). This capability enables seamless integration with existing applications that expect headers in a specific format, thereby minimizing changes to your backends while using TLS features on the ALB. With header insertion, you can insert custom headers related to Cross-Origin Resource Sharing (CORS) and critical security headers like HTTP Strict-Transport-Security (HSTS). Finally, the capability to disable the ALB generated “Server” header in responses reduces exposure of server-specific information, adding an extra layer of protection to your application. These response header modification features give you the ability to centrally enforce your organizations security posture at the load balancer instead of enforcement at individual applications, which can be prone to errors. You can configure Header Modification feature using AWS APIs, AWS CLI, or the AWS Management Console. This feature is available for ALBs in https://aws.amazon.com/about-aws/global-infrastructure/regional-product-services/, https://aws.amazon.com/govcloud-us/ and https://aws.amazon.com/about-aws/global-infrastructure/regional-product-services/#AWS_China_Regions*. To learn more, refer to the https://docs.aws.amazon.com/elasticloadbalancing/latest/application/load-balancer-listeners.html#alb-http-headers.  

Gateway Load Balancer (GWLB) now supports Load Balancer Capacity Unit (LCU) Reservation that allows you to proactively set a minimum bandwidth capacity for your load balancer, complementing its existing ability to auto-scale based on your traffic pattern. Gateway Load Balancer helps you deploy, scale, and manage third-party virtual appliances. With this feature, you can reserve a guaranteed capacity for anticipated traffic surge. The LCU reservation is ideal for scenarios such as onboarding and migrating new workload to your GWLB gated services without the need to wait for organic scaling, or maintaining a minimum bandwidth capacity for your firewall applications to meet specific SLA or compliance requirements. When using this feature, you pay only for the reserved LCUs and any additional usage above the reservation. You can easily configure this feature through the ELB console or API. The feature is available for GWLB in US East (N. Virginia), US East (Ohio), US West (Oregon), Asia Pacific (Hong Kong), Asia Pacific (Singapore), Asia Pacific (Sydney), Asia Pacific (Tokyo), Europe (Frankfurt), Europe (Ireland), and Europe (Stockholm) AWS Regions. This feature is not supported on Gateway Load Balancer Endpoint (GWLBe). To learn more, please refer to the https://docs.aws.amazon.com/elasticloadbalancing/latest/gateway/capacity-unit-reservation.html.

AWS Application Load Balancers (ALB) now supports Health Check Logs that allows you to send detailed target health check log data directly to your designated Amazon S3 bucket. This optional feature captures comprehensive target health check status, timestamp, target identification data, and failure reasons. Health Check Logs provide complete visibility into target health status with precise failure diagnostics, enabling faster troubleshooting without contacting AWS Support. You can analyze target’s health patterns over time, determine exactly why instances were marked unhealthy, and significantly reduce mean time to resolution for target health investigations. Logs are automatically delivered to your S3 bucket every 5 minutes with no additional charges beyond standard S3 storage costs. This feature is available in all AWS Commercial Regions, AWS GovCloud (US) Regions and AWS China Regions where Application Load Balancer is offered. You can enable Health Check Logs through the AWS Management Console, AWS CLI, or programmatically using the AWS SDK. Learn more about Health Check Logs for ALBs in the https://docs.aws.amazon.com/elasticloadbalancing/latest/application/load-balancer-monitoring.html.

AWS Network Load Balancer (NLB) now supports QUIC protocol in passthrough mode, enabling low-latency forwarding of QUIC traffic while preserving session stickiness through QUIC Connection ID. This enhancement helps customers maintain consistent connections for mobile applications, even when client IP addresses change during network roaming. With QUIC support, customers can reduce application latency by up to 30% through fewer packet round trips and ensure seamless user experiences across varying network conditions. This is especially useful for mobile applications that require users to move between cellular towers or switch from WiFi to cellular networks, without losing connection state. You can enable QUIC support on your existing or new Network Load Balancers through the AWS Management Console, CLI, or APIs. Once enabled, NLB forwards QUIC traffic to targets by using the QUIC Connection ID to maintain session stickiness even when a client roams. QUIC support is available at no additional charge in all AWS commercial and AWS GovCloud (US) regions. QUIC traffic is metered within existing UDP Load Balancer Capacity Unit (LCU) entitlements. To learn more, visit this https://aws.amazon.com/blogs/networking-and-content-delivery/introducing-quic-protocol-support-for-network-load-balancer-accelerating-mobile-first-applications/ and https://docs.aws.amazon.com/elasticloadbalancing/latest/network/create-listener.html#add-listener. 

Gateway Load Balancer (GWLB) now supports Load Balancer Capacity Unit (LCU) Reservation that allows you to proactively set a minimum bandwidth capacity for your load balancer, complementing its existing ability to auto-scale based on your traffic pattern. Gateway Load Balancer helps you deploy, scale, and manage third-party virtual appliances. With this feature, you can reserve a guaranteed capacity for anticipated traffic surge. The LCU reservation is ideal for scenarios such as onboarding and migrating new workload to your GWLB gated services without the need to wait for organic scaling, or maintaining a minimum bandwidth capacity for your firewall applications to meet specific SLA or compliance requirements. When using this feature, you pay only for the reserved LCUs and any additional usage above the reservation. You can easily configure this feature through the ELB console or API. The feature is available for GWLB in US East (N. Virginia), US East (Ohio), US West (Oregon), Asia Pacific (Hong Kong), Asia Pacific (Singapore), Asia Pacific (Sydney), Asia Pacific (Tokyo), Europe (Frankfurt), Europe (Ireland), and Europe (Stockholm) AWS Regions. This feature is not supported on Gateway Load Balancer Endpoint (GWLBe). To learn more, please refer to the GWLB documentation.

AWS Application Load Balancer (ALB) now allows customers to provide a pool of public IPv4 addresses for IP address assignment to load balancer nodes. Customers can configure a public IP Address Manager (IPAM) pool that can consist of either Bring Your Own IP addresses (BYOIPs) that is customer owned or a contiguous IPv4 address block provided by Amazon. With this feature, customers can optimize public IPv4 cost by using BYOIP in public IPAM pools. Customers can also simplify their enterprise allowlisting and operations, by using Amazon-provided contiguous IPv4 blocks in public IPAM pools. The ALB's IP addresses are sourced from the IPAM pool and automatically switch to AWS managed IP addresses when the public IPAM pool is depleted. This intelligent switching maximizes service availability during scaling events. The feature is available in all commercial AWS Regions and AWS GovCloud (US) Regions where Amazon VPC IP Address Manager (IPAM) is available. To learn more, please refer to the ALB Documentation.

Network Load Balancer now supports weighted target groups, allowing you to distribute traffic across multiple target groups with configurable weights for advanced deployment strategies. Weighted target groups enables key use cases like Blue-Green and Canary Deployments, Application Migration, and A/B Testing by allowing you to register multiple target groups with configurable weights ranging from 0 to 999, providing precise control over traffic distribution. Blue-Green and Canary Deployments allow you to gradually shift traffic between application versions, minimizing downtime during upgrades and patches; Application Migration enables seamless transitions from legacy stacks to new stacks without disrupting production traffic; and A/B Testing facilitates splitting incoming traffic across experimental environments. All target group types are supported, including instance, IP address, and Application Load Balancer (ALB) targets. Weighted Target Groups routing is available for all existing and new Network Load Balancers across AWS commercial and AWS GovCloud (US) regions at no additional charge. Standard Network Load Balancer Capacity Unit (LCU) pricing applies. To learn more, please refer to https://aws.amazon.com/blogs/networking-and-content-delivery/network-load-balancers-now-support-weighted-target-groups/, and the https://docs.aws.amazon.com/elasticloadbalancing/latest/network/listener-update-rules.html. 

Application Load Balancer (ALB) now supports HTTP request and response header modification giving you greater controls to manage your application’s traffic and security posture without having to alter your application code. This feature introduces three key capabilities: renaming specific load balancer generated headers, inserting specific response headers, and disabling server response header. With header rename, you can now rename all ALB generated Transport Layer Security (TLS) headers that the load balancer adds to requests, which includes the six mTLS headers and two TLS headers (version and cipher). This capability enables seamless integration with existing applications that expect headers in a specific format, thereby minimizing changes to your backends while using TLS features on the ALB. With header insertion, you can insert custom headers related to Cross-Origin Resource Sharing (CORS) and critical security headers like HTTP Strict-Transport-Security (HSTS). Finally, the capability to disable the ALB generated “Server” header in responses reduces exposure of server-specific information, adding an extra layer of protection to your application. These response header modification features give you the ability to centrally enforce your organizations security posture at the load balancer instead of enforcement at individual applications, which can be prone to errors. You can configure Header Modification feature using AWS APIs, AWS CLI, or the AWS Management Console. This feature is available for ALBs in all commercial AWS Regions, AWS GovCloud (US) Regions and China Regions. To learn more, refer to the ALB documentation.

Application Load Balancer (ALB) and Network Load Balancer (NLB) now support Load Balancer Capacity Unit (LCU) Reservation that allows you to proactively set a minimum capacity for your load balancer, complementing its existing ability to auto-scale based on your traffic pattern. With this feature, you can prepare for anticipated traffic surges by reserving a guaranteed minimum capacity in advance, providing customers increased scale and availability during high-demand events. LCU Reservation is ideal for scenarios such as event ticket sales, new product launches, or release of popular content. When using this feature, you pay only for the reserved LCUs and any additional usage above the reservation. You can easily configure this feature through the ELB console or API. The feature is available for ALB in all commercial AWS Regions, including the AWS GovCloud (US) Regions and NLB in US East (N. Virginia), US East (Ohio), US West (Oregon), Asia Pacific (Hong Kong), Asia Pacific (Singapore), Asia Pacific (Sydney), Asia Pacific (Tokyo), Europe (Frankfurt), Europe (Ireland), and Europe (Stockholm). To learn more, please refer to the ALB Documentation and NLB Documentation.

Application Load Balancer (ALB) and Network Load Balancer (NLB) now support Load Balancer Capacity Unit (LCU) Reservation that allows you to proactively set a minimum capacity for your load balancer, complementing its existing ability to auto-scale based on your traffic pattern. With this feature, you can prepare for anticipated traffic surges by reserving a guaranteed minimum capacity in advance, providing customers increased scale and availability during high-demand events. LCU Reservation is ideal for scenarios such as event ticket sales, new product launches, or release of popular content. When using this feature, you pay only for the reserved LCUs and any additional usage above the reservation. You can easily configure this feature through the ELB console or API. The feature is available for ALB in https://aws.amazon.com/about-aws/global-infrastructure/regional-product-services/, including the https://aws.amazon.com/govcloud-us/ and NLB in US East (N. Virginia), US East (Ohio), US West (Oregon), Asia Pacific (Hong Kong), Asia Pacific (Singapore), Asia Pacific (Sydney), Asia Pacific (Tokyo), Europe (Frankfurt), Europe (Ireland), and Europe (Stockholm). To learn more, please refer to the https://docs.aws.amazon.com/elasticloadbalancing/latest/application/capacity-unit-reservation.html and https://docs.aws.amazon.com/elasticloadbalancing/latest/network/capacity-unit-reservation.html.

Today, Amazon Web Services (AWS) announces the general availability of Volume Clones for Amazon Elastic Block Store (Amazon EBS), our high-performance block storage service. This new capability allows you to instantly create and access point-in-time copies of EBS volumes within the same Availability Zone (AZ), accelerating software development workflows and enhancing operational agility. Customers use Amazon EBS volumes as durable block storage attached to Amazon EC2 instances. With Amazon EBS Volume Clones, you can instantly create copies of volumes and access the copied volumes with single-digit millisecond latency. Amazon EBS Volume Clones enables rapid creation of test and development environments from production volumes, eliminating manual copy workflows. Additionally, Volume Clones integrates with the Amazon EBS Container Storage Interface (CSI) driver, simplifying storage management for containerized applications. Amazon EBS Volume Clones is available in all AWS Commercial Regions and AWS GovCloud (US) Regions. You can access Volume Clones through the AWS Console, AWS Command Line Interface (CLI), AWS SDKs, and AWS CloudFormation. This capability supports all EBS volume types and works for volume copies within the same account and AZ. For detailed pricing information, please visit the https://aws.amazon.com/ebs/pricing/. To explore how Volume Clones can accelerate your software development processes and improve operational efficiency, visit the https://docs.aws.amazon.com/ebs/latest/userguide/ebs-copying-volume.html.