Application Load Balancer & AZ routing
I was using NLB (in 3 AZ) to rout traffic to a targets (ECS Fargate tasks). Then I've switched to Application Load Balancer with 3 AZ as well.
Soon I discovered increased cross AZ traffic. After investigating my VPC flow logs, I've found that ALB is sending data from it's ENI on AZ1 to a target's ENI in AZ2. In it happens in all combinations. In contrast, NLB never did this way.
My question is: is it done by design of ALB or I did something wrong in setting it up?
- 新しい順
- 投票が多い順
- コメントが多い順
This is the expected behavior of cross-zone load balancing. Cross-Zone load balancing is disabled by default on NLBs and always enabled for ALBs.
Edit 12/6/22: Cross-zone load balancing can now be turned off for ALBs: https://aws.amazon.com/about-aws/whats-new/2022/11/elastic-load-balancing-capabilities-application-availability/
Thank you for quick reaction :-) I know about Cross Zone load balancing in NLB. But didn't found such setting in ALB. Is ALB doing cross-zone by default?
Yes - on ALB it's always on, you can't turn it off!
Thank you Giorgio@AWS! Never saw it anywhere in documentation. Thank you again!
For me it is now clear that ALB is unacceptable in my scenario. I receive 60-70TB of data per month over HTTP to my ELB. ALB is very good, but it generates pretty significant cost for EU-DataTransfer-Regional-Bytes. BTW this cost are relates to a service which stand behind of ALB (Like EC2 or ECS). However NLB produces zero of such costs when cross-zone load balancing is disabled. It is a pity, because I like ALB for it's features related to HTTP :-(
ALB now supports the ability to turn off cross-zone load balancing (https://aws.amazon.com/about-aws/whats-new/2022/11/elastic-load-balancing-capabilities-application-availability/)
This is by design if you have enabled cross-zone load balancing (it's always on for ALB). For NLB, it's turned off by default, which is why you see that behavior. With cross zone load balancing, the load balancer will send traffic across AZs to all registered targets. See: https://docs.aws.amazon.com/elasticloadbalancing/latest/userguide/how-elastic-load-balancing-works.html
Thank you! Missed the line in documentation "With Application Load Balancers, cross-zone load balancing is always enabled."
I do believe this question is more relevant to ECS networking.
I would also recommend that you consider using service discovery and service mesh for inner-service communications of your container.
You can find more details of different patterns, including using ELB, here
For further details, a page that is simple to look at and understand the differences between NLB and ALB attributes: https://docs.aws.amazon.com/AWSCloudFormation/latest/UserGuide/aws-properties-elasticloadbalancingv2-loadbalancer-loadbalancerattributes.html
NLB cross-AZ by default is turned off. ALB is not. However, say you have a VPC in 3 tiers, and only use 2AZ for your ALB, sending traffic to tasks that are spread in 3 AZs, the ALB won't send traffic to tasks in that 3rd AZ.
関連するコンテンツ
AWS公式更新しました 1年前
For me it is now clear that ALB is unacceptable in my scenario. I receive 60-70TB of data per month over HTTP to my ELB.
ALB is very good, but it generates pretty significant cost for EU-DataTransfer-Regional-Bytes. BTW this cost are relates to a service which stand behind of ALB (Like EC2 or ECS). However NLB produces zero of such costs when cross-zone load balancing is disabled.
It is a pity, because I like ALB for it's features related to HTTP :-(
Keep in mind that ALB doesn't generate a charge for cross-zone traffic between ALB nodes and targets. (as per FAQ: "No. Since cross-zone load balancing is always on with Application Load Balancer, you are not charged for this type of regional data transfer.").
Would you be concerned about the ELB data processing cost and/or the extra hop? Or the benefits of a managed L7 LB outweigh some of the above concerns?
Also just curious here considering what Evgeny pointed out, are the applications able to resolve the endpoints through private IP, or they are talking through public IPs?