No numbers, no examples, no use cases.
Very basic article to promote their service/solution.
This.
I suppose the 96% number might be just a fancy way to claim they reuse the same ALB to power 25 applications, but cost estimates in AWS aren't straight-forward, and instead they are outright cryptic.
Also, mentioning "96% cost reduction" can sound like an impressive achievement in open reduction. However, claiming that they share a single ALB with dozens of independent applications is a very bad ideal all-around which is very hard to justify in any way.
That's not saying that the right answer is AWS: simply that you really need to balance your budget against your time and capacity. For example, ALBs are “just” load-balancing — but if you try to build your own system with automatic failover and scaling, the various tools for logging, security, etc. it'll cost a lot more than $16/month. Now, if you're running 1,000 ALBs maybe that might no longer be true — but I would bet that you have other tasks for your engineers which would see comparable or greater returns, so it's still a business decision.
Only pay per requests: API Gateway/Lambda/Dynamo
Then there's no fixed costs or the need to share these services with unrelated services.
Works great for dev/staging environments (will probably cost 1$ per month each for low usage) and even prod could go a long way before becoming "expensive"
(We're doing that a lot in my company, the CDN caches 85% of requests coming to our serverless stack, with most responses having only 1/2 min cache times)
You work on cost-cutting after everything else is working. It's usually a sign you like the service well enough - if you didn't like it, maybe you're not cost cutting, you're trying to get it out of your stack.
If you like everything else about it, shopping around instead of doing cost optimization carries much larger risks.
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.
I can see the advantages of cost savings, but it's definitely a tradeoff.
[1]: https://docs.aws.amazon.com/elasticloadbalancing/latest/appl...
The thing which would be more interesting would be talking about the cost savings (~$16/month) relative to things like risks: mostly noisy-neighbor and the administrative concerns of coordinating changes to settings or the security considerations of someone being able to compromise multiple sites rather than just their own. There's no wrong answer there but it's an engineering decision which will lead to different results depending on your environment, budget, and projects.
Speaking of engineering, it sounds like they're using some Go code to avoid hitting the limit on certificates and target groups. That's certainly effective but I do wonder how many organizations have enough applications/certificates which are appropriate for shared infrastructure and hit that limit. If your sharing is within that range, the potential cost savings are going to be lower as well.
Our 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.
