ALB Calculation

The calculation of 660 LCUs for 25 new connections per second across 3 Availability Zones involves understanding how Load Balancer Capacity Units (LCUs) work with Application Load Balancers (ALBs).

First, it's important to understand that LCUs measure multiple dimensions of how an ALB processes traffic:

1. New connections per second (25 new connections per LCU)
2. Active connections per minute (3,000 per LCU, or 1,500 when using Mutual TLS)
3. Processed bytes per hour (1 GB per LCU for EC2 instances, containers, and IP addresses)
4. Rule evaluations per second (1,000 per LCU)

For your specific scenario with 25 new connections per second, the calculator is likely factoring in:

• The redundancy option for ALB, which reserves additional capacity to handle AZ failures
• The distribution of capacity across all 3 active Availability Zones
• Other dimensions beyond just new connections (active connections, processed bytes, rule evaluations)

When you enable redundancy for an ALB, the system recommends reserving additional LCUs to ensure your load balancer can handle increased traffic if an AZ fails. Even though ALBs have built-in redundancy within a Region, you still need sufficient capacity to handle the traffic redistribution during an AZ failure.

The 660 LCU calculation likely includes this redundancy factor, ensuring that if one AZ fails, the remaining AZs have enough capacity to handle the redistributed load without performance degradation or connection drops.
Sources
Question about capacity reservation for ALB and NLB | AWS re:Post
Why do I get billed for 4000+hours of alb usage for just two albs? | AWS re:Post
Using Load Balancer Capacity Unit Reservation to prepare for sharp increases in traffic | Networking & Content Delivery

With only 1 AZ, your calculation becomes simpler because there's no need to maintain redundant capacity across multiple AZs.

For your scenario with 25 new connections per second:

• Each LCU provides capacity for 25 new connections per second
• So you need 1 LCU per second to handle this load in your single AZ

Converting to hourly allocation (which is how AWS measures LCUs): 1 LCU per second × 60 seconds × 60 minutes = 3,600 LCUs per hour if measured by the second However, AWS averages over the hour, so this translates to 220 LCUs for your AZ With 1 AZ, you would need approximately 220 LCUs total to handle your load.

The key difference is that with 3 AZs (as in your previous question), you need 660 LCUs because: You need 220 LCUs per AZ for the same workload With 3 AZs: 220 × 3 = 660 LCUs total

The reason for the over-provisioning is high availability - if one or more AZs fail, the remaining AZ(s) need to be able to handle the entire load. This is particularly important for the Application Load Balancer which is designed to be a "redundancy within Region" service, as mentioned in the AWS re:Post answer.

Resource to help: https://repost.aws/questions/QUo-xZvt6ITnKLIXFaeakiMw/question-about-capacity-reservation-for-alb-and-nlb

In the calculator it mentions :

" The LCU reservation calculator uses data based on historical workloads AWS observe and may not represent your specific workload. For more accurate estimation based on your actual traffic, please use the ELB console Historic reference based estimate capability to estimate."

Why the calculator still shows 660 LCU even with one AZ :

The LCU reservation calculator appears to be calculating the total capacity needed for your load balancer rather than just what's needed per AZ. This means that even if you select one AZ in the calculator, it's still showing the total LCU capacity needed to handle your specified traffic requirements.

How 220 LCU is derived from 25 new connections per second Let me break down how the 220 LCU calculation works:

Each LCU provides capacity for 25 new connections per second For your requirement of 25 new connections per second, you need exactly 1 LCU when measured per second. However, AWS doesn't measure LCUs by the second, but rather averaged over an hour The 220 LCU figure comes from AWS's internal scaling calculations that determine how much capacity is needed to handle spikes in traffic within that hour.

The confusion comes from thinking that 220 × 25 = 5,500 connections, but that's not the correct interpretation. The 220 LCU is not about the total number of connections but rather the capacity allocation needed to reliably handle traffic at your specified rate over an hour.

From the AWS documentation below, we know that LCU reservation is designed to ensure your load balancer has sufficient capacity to handle your workload during traffic spikes. As mentioned in the re:Post question below :

"LCU reservation is primarily about scaling speed, not error prevention. The reservation ensures that your load balancer has a minimum capacity available."

In a single AZ configuration, you need approximately 220 LCUs to handle this traffic pattern reliably. When you have 3 AZs, you need 220 LCUs per AZ, which gives you the 660 LCU total (220 × 3).

The calculator is determining how much capacity you need to reserve based on historical workload patterns observed by AWS, which include considerations for traffic spikes and scaling needs that aren't immediately obvious from the simple "25 connections per second" requirement.

Sources: https://repost.aws/questions/QUZv8TnpxkT6GSqTOGqYZTGg/alb-lcu-capacity-reservation-metrics-confusion https://docs.aws.amazon.com/elasticloadbalancing/latest/application/capacity-unit-reservation.html