Live data from Hacker News

AWS Application Load Balancer

aws.amazon.com

61–70 of 140 posts

Re: AWS Application Load Balancer

#61

Do ALBs support more than a single SSL certificate?

ELB Classic & ELB Application Load Balancer don't support multiple SSL certificates. There is support multiple Subject Alternative Names (SANs https://en.wikipedia.org/wiki/Subject_Alternative_Name)

And there is support for wildcard certificates, *.example.com

You can request a cert through AWS Certificate Manager with multiple names, more info https://docs.aws.amazon.com/acm/latest/userguide/gs-acm-requ...

This is not using Server Name Indicator / SNI.

Re: AWS Application Load Balancer

#62
post #28

Nice haproxy / nginx alternative. It's got http2 support though which puts it ahead of haproxy.

I wouldn't consider this a full haproxy/nginx replacement just yet. It doesn't support host based routing, so you would need a different ALB for each host in order to get the same thing you would get with haproxy/nginx.

Re: AWS Application Load Balancer

#64

So this is pretty much the same as Google HTTP load balancing https://cloud.google.com/compute/docs/load-balancing/http/ + websocket & http2?

Google's load balancer does do HTTP/2. It doesnt have native websocket protocol support (you have to use the network LB for that traffic) but it does provide cross-region balancing.

Websockets over SSL is in beta: https://cloud.google.com/compute/docs/load-balancing/tcp-ssl...

Re: AWS Application Load Balancer

#65
post #4

AWS still doesn't support IPv6. Good to see them talking about HTTP/2. Waiting for AWS to embrace IPv6.

ELBs (Classic and Application) do support IPv6. You can CNAME or ALIAS to dualstack.[elb-name].

The endpoints are available but traffic silently fails when you are in a VPC.

Re: AWS Application Load Balancer

#66
post #48

Earlier quoted context omitted.

I was coming here to ask whether pre-warming is still an issue with the ALB service. Maybe jeffbarr can comment on whether that's changed? GCE's load balancer does not use independent VM instances for each load balancer, instead balancing at the network level. So you can instantly scale from 0 to 1M req/s with no issues at all.

You can request pre-warming for additional ELB capacity, when you know far enough in advance that you will have a spike. AWS customer service responds by asking 10 clarifying questions via email. The thing is, we can't look under the hood to see currently provisioned and utilized ELB capacity, so we just have to trust that AWS engineers will properly allocate resources according to the answers to those questions. IMO…

its cumbersome, and not remotely useful in this specific situation from OP anyway.

Re: AWS Application Load Balancer

#67

Earlier quoted context omitted.

no, they replaced bandwidth costs with new pricing component $0.008 per LCU-hour[1]. If you have 1M idle websocket connections you will pay 100 times more for ALB vs ELB (i.e. $2K/mo vs $18/mo). Good thing ELB is still here, so you can choose between them depending on your workload. [1] LCU - Load Balancer Capacity Units https://aws.amazon.com/elasticloadbalancing/applicationloadb...

I don't believe classic ELB supports websockets[1] making this a tenuous comparison. There might be workarounds that I'm not aware of (our production network isn't currently on AWS so I'm a couple of years behind in my day-to-day experience with them). That said, I don't dispute that there might be use cases where classic ELB is a better option. And I'm glad it's still available (as opposed to ALB replacing classic).…

it supports any TCP-based protocol, like websockets or MQTT, similar to Network LB on GCE.
Post reply on HN