AWS ELB adds support for Host-based routing on Application Load Balancer | Hacker News Reader

AWS ELB adds support for Host-based routing on Application Load Balancer

aws.amazon.com

103 pointsmwarkentin21 comments

This is probably the least "shiny" thing AWS has announced, but to me it's the biggest one yet. I can finally have a single LB for all of prod. This is probably the first thing they've announced that I will be using on day one. It is kind of unbelievable that a feature such as this took so flipping long to add. But hey, it's here now.

Have been waiting for this for awhile. However, is needing to "warm up" the load balancer to deal with sudden spikes still an issue? This was a deterrent to going all-in on the ALB despite other benefits (SSL termination, etc.)

Also, wondering if there any obvious cons (perhaps performance?) to using one ALB to handle multiple routes vs. separating them.

I asked one of Amazon's ELB Product Managers this a few months ago and was told that no, there's no longer a need to warm up an ELB/ALB except perhaps in extreme cases.

Wow, if so, this should be "front and center" news. This best practices page [1], upd. 2014 still talks about "Pre-Warming"

Tangent: I wonder how often we utilize outdated "truths" in our best practices. For example, the "you must minimize the number of assets" rule was obsoleted with HTTP/2, but will probably take years to take hold.

[1] https://aws.amazon.com/articles/1636185810492479

The correct term is "priming"

AWS employee here.

You are welcome to check with AWS Support based on your predicted traffic load for extra assurance, but in my experience the new ALB no longer requires priming, even for significant traffic spikes.

If any of you are going to Dockercon in Austin stop by the AWS booth and I'd be happy to show you a demo app that uses an ALB with about ten rules to route traffic to different microservices running as tasks under EC2 Container Service. The demo includes a load test to drive traffic to the ALB and the services behind the ALB, verifying the consistent performance as traffic scales up.

This excites me more than a machine learning or speech-to-text API because I'll actually use this feature a lot.

With this announcement, is there still any benefit in having cloudfront in front of alb if you don't do any caching? I assume that aws has less latency on their internal network, but would love to see some numbers.

Cloudfront terminates ssl connections closer to the user, reducing initial startup time (and presumably maintains persistent connections to ALB's.

You are right. This is a big benefit!

Does that mean - If I have 4 ec2 instances sitting behind an ALB, I can target and hit 1 of the 4 ec2 instances if need be? For eg. debugging purposes?

That was already possible. You can make any number of 'target groups', each of which have one or more instances. In your case you would have all 4 instances in your 'service1' group, and 1 instance in your 'debug' group. You'd then point example.com/service to 'service1' and example.com/debug to 'debug'.

With this announcement, you can point service.example.com or www.example.com to 'service1 and private.debug.example.com to 'debug'. And you could also have free fully managed SSL on all subdomains as well.

Does this mean that ALB/ELB supports SNI now? Or they only allow you to do this with subdomains under a wildcard cert?

just from reading the docs there is no indication about SNI.

You can only configure a single SSL listener per load balancer, and that listener can only use a single certificate. That means you do indeed still need to use either wildcard certs or certs with multiple hostnames. Luckily you can very easily create those through the AWS certificate manager for free.

Wait - AWS has a service to generate wild card Certs that can be attached to ELB?

Did not realise this was a thing

Yes, and they automatically renew. It's fantastic. If you're using ELB/ALB, it's by far the easiest way to do SSL.

The only downside is that initial setup of a certificate requires email confirmation, so if you need to provision a lot, LE may still win.

And they're free! Although only can be used on AWS services, currently ELB and CloudFront. https://aws.amazon.com/certificate-manager/

Think ALB already supported only SNI. Cloudfront has an offering that supports the older standard, but that's really expensive because of the need for all the static IPs.

Think the load balancers never had the possibility of static IPs, so SNI from the start.

But yeah, like another comment said, with the built in ACM managing certs is a non issue. It's like having an AWS specific Lets Encrypt for any service you want.

ALB definitely does not support SNI yet.

Am I able to use a single ALB across many Elastic Beanstalk applications?

Reply on news.ycombinator.com