Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

AWS Application Load Balancer

aws.amazon.com

Post reply on HN
Print view View original

51–60 of 140 posts

Re: AWS Application Load Balancer

#51

Post by bgentry »

snug wrote: post #40
cheald wrote: post #31

Exciting! Disappointing that you can't route based on hostname yet, though. I've got 5 ELBs set up to route to different microservices for one app, and because we couldn't do path-based routing before, that's all segmented by hostname. As soon as ALB supports hostname routing, I can collapse those all into a single LB.

The "Hostname" is in the HTTP Header, "Host." The article states that you can route based on Layer 7 headers, so this shouldn't be an issue.

The article actually just states that layer 7 load balancers have access to the header information and typically allow you to route based on those headers. ALB, however, doesn't :(

Weird thing to highlight when the product being announced doesn't even have that feature.

Re: AWS Application Load Balancer

#53

Post by manigandham »

bgentry wrote: post #48
encoderer wrote: post #38

We plan to do a blog post about this at some point, but we had the pleasure of seeing exactly how elastic the elb is when we switched Cronitor from linode to aws in February 2015. Requisite backstory: Our api traffic comes from jobs, daemons, etc, which tend to create huge hot spots at tops of each minute, quarter hour, hour and midnight of popular tz offsets like UTC, us eastern, etc. There is an emergent behavior t…

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.

Yes, Google's load balancer is the best one available today. The lack of native websockets support is probably the only disadvantage but made up for with the scaling abilities and cross-region support.

ALB pricing is strange too, classic AWS style complexity.

Re: AWS Application Load Balancer

#55

Post by pgib »

pat2man wrote: post #23
nodesocket wrote: post #16

Do ALBs support more than a single SSL certificate?

Like via SNI? No mention of it and the screenshots make it seem unlikely.

The Amazon Certificate Manager uses SNI, and you can request certificates with multiple hosts and even wildcard domains. I would imagine if you upload your own multi-domain certificate that it would work in the same way, but I have never tested that.

Re: AWS Application Load Balancer

#56

Post by manigandham »

boundlessdreamz wrote: post #44

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.

Re: AWS Application Load Balancer

#57

Post by crb »

manigandham wrote: post #53
bgentry wrote: 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.

Yes, Google's load balancer is the best one available today. The lack of native websockets support is probably the only disadvantage but made up for with the scaling abilities and cross-region support. ALB pricing is strange too, classic AWS style complexity.

The Google load balancer supports proxy websockets over SSL (wss://) with the SSL Proxy mode: https://cloud.google.com/compute/docs/load-balancing/tcp-ssl...

Re: AWS Application Load Balancer

#58

Post by tobz »

The real question: does this provide a faster elasticity component than ELBs?

At a previous employer, we punted on ever using ELBs at the edge because our traffic was just too unpredictable.

Combining together all of the internet rumors, I've been led to believe that ELBs were/are custom software running on simple EC2 instances in an ASG or something, hence being relatively slow to respond to traffic spikes.

Given that ALBs are metered, it seems like this suggests shared infrastructure (binpacking peoples ALBs onto beefy machines) which makes me wonder if that is how it actually works now, because it would seem the region/AZ-level elasticity of ALBs could actually help the elasticity of a single ALB.

If you don't have to spin up a brand new machine, but simply configure another to start helping out, or spin up a container on another which launches faster than an EC2 instance... that'd be clutch.

Deep thoughts?

Re: AWS Application Load Balancer

#59

Post by bashcoder »

bgentry wrote: post #48
encoderer wrote: post #38

We plan to do a blog post about this at some point, but we had the pleasure of seeing exactly how elastic the elb is when we switched Cronitor from linode to aws in February 2015. Requisite backstory: Our api traffic comes from jobs, daemons, etc, which tend to create huge hot spots at tops of each minute, quarter hour, hour and midnight of popular tz offsets like UTC, us eastern, etc. There is an emergent behavior t…

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, it's a rather cumbersome process that would be better implemented as a form.

Re: AWS Application Load Balancer

#60

Post by sturgill »

nivertech wrote: post #39
sturgill wrote: post #33

This sentence sums up one of my main reasons for appreciating AWS: The hourly rate for the use of an Application Load Balancer is 10% lower than the cost of a Classic Load Balancer. They frequently introduce new features while cutting costs.

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).

[1]https://aws.amazon.com/elasticloadbalancing/classicloadbalan...

Post reply on HN