AWS Communism: How we cut our Load Balancing cost by more than 96%
1–10 of 19 posts
Re: AWS Communism: How we cut our Load Balancing cost by more than 96%
#2Our way is AWS-native and allows for maximum efficient sharing – without complicating it for the user. When you can share a single ALB between 25 to 100 apps, the large cost saving comes in.
Re: AWS Communism: How we cut our Load Balancing cost by more than 96%
#3I can see the advantages of cost savings, but it's definitely a tradeoff.
[1]: https://docs.aws.amazon.com/elasticloadbalancing/latest/appl...
Re: AWS Communism: How we cut our Load Balancing cost by more than 96%
#4I'm not normally a fan of sharing ALBs between services as a lot of the metrics [1] are only recorded for the load balancer as a whole, not each individual target group (an application attached to the load balancer). I can see the advantages of cost savings, but it's definitely a tradeoff. [1]: https://docs.aws.amazon.com/elasticloadbalancing/latest/appl...
Re: AWS Communism: How we cut our Load Balancing cost by more than 96%
#5Re: AWS Communism: How we cut our Load Balancing cost by more than 96%
#6Nothing is free. Resource sharing comes with the noisy & problematic neighbour issue. An ALB consumes 16.43 USD per month. You need to decide if it's worth the risk, blast radius would be larger in case of incidents. I've seen ALBs timing out because the ALB itself did not scale fast enough, so in a shared environment with 100 different applications, this might be amplified.
Re: AWS Communism: How we cut our Load Balancing cost by more than 96%
#7Re: AWS Communism: How we cut our Load Balancing cost by more than 96%
#8No numbers, no examples, no use cases.
Very basic article to promote their service/solution.
Re: AWS Communism: How we cut our Load Balancing cost by more than 96%
#9Nothing is free. Resource sharing comes with the noisy & problematic neighbour issue. An ALB consumes 16.43 USD per month. You need to decide if it's worth the risk, blast radius would be larger in case of incidents. I've seen ALBs timing out because the ALB itself did not scale fast enough, so in a shared environment with 100 different applications, this might be amplified.
On the other hand sharing an ALB across 100 apps means that a single app's fluctuations are less significant. If your apps have completely independent traffic patterns then a 10x surge for one service would only be a 10% surge for the ALB if all applications have equal amounts of traffic. This likely can be handled with the current utilization buffer so the ALB scaling isn't even required (of course you hope that it will still scale up quickly to refill the buffer).
Of course in real life everything isn't this perfect, your traffic patterns are correlated between services and one service is the vast majority of your traffic but it can still be a nice buffer.