from Hacker News

AWS Application Load Balancer

by rjsamson on 8/11/16, 3:01 PM with 130 comments

• by encoderer on 8/11/16, 4:15 PM

  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 to stacking these up and we hit peak traffic many many times our resting baseline. At the time, our median ping traffic was around 8 requests per second, with peaks around 25x that.

  What's unfortunate is that in the first day after setting up the elb we didn't have problems, but soon after we started getting reports of intermittent downtime. On our end our metrics looked clean. The elb queue never backed up seriously according to cloud watch. But when we started running our own healthchecks against the elb we saw what our customers had been reporting: in the crush of traffic at the top of the hour connections to the elb were rejected despite the metrics never indicating a problem.

  Once we saw the problem ourselves it seemed easy to understand. Amazon is provisioning that load balancer elastically and our traffic was more power law than normal distribution. We didn't have high enough baseline traffic to earn enough resources to service peak load. So, cautionary tale of dont just trust the instruments in the tin when it comes to cloud iaas -- you need your own. It's understandable that we ran into a product limitation, but unfortunate that we were not given enough visibility to see the obvious problem without our own testing rig.

• by ihsw on 8/11/16, 3:38 PM

  Can we agree on the terminology for Application Load Balancer and Elastic Load Balancer?

  * ALB: Application Load Balancer

  * ELB: Elastic Load Balancer

  I have seen Application Elastic Load Balancer/AELB, Classic Load Balancer/CLB, Elastic Load Balancer (Classic)/ELBC, Elastic Load Balancer (Application)/ELBA.

  In any event, I think it is great that AWS is bringing WebSockets and HTTP/2 to the forefront of web technology.

• by tobz on 8/11/16, 4:52 PM

  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?

• by 0xmohit on 8/11/16, 3:15 PM

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

  Waiting for AWS to embrace IPv6.

• by boundlessdreamz on 8/11/16, 4:22 PM

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

• by fred256 on 8/11/16, 8:13 PM

  +1 for CloudFormation support on launch day. +1 for support for ECS services with dynamic ports (finally!) -1 for no CloudFormation support for ECS

  (To configure an ECS service to use an ALB, you need to set a Target Group ARN in the ECS service, which is not exposed by CloudFormation)

• by cheald on 8/11/16, 4:00 PM

  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.

• by agwa on 8/11/16, 3:27 PM

  > 25 connections/second with a 2 KB certificate, 3,000 active connections, and 2.22 Mbps of data transfer or

  >5 connections/second with a 4 KB certificate, 3,000 active connective, and 2.22 Mbps of data transfer.

  "2KB certificate" and "4KB certificate"? Is this supposed to read "2048 bit RSA" and "4096 bit RSA"?

• by indale on 8/11/16, 3:37 PM

  This looks pretty sweet. The next big thing for api versioning would be header instead of url based routing, looking forward to 'give you access to other routing methods'.

• by rjsamson on 8/11/16, 3:01 PM

  They finally added support for websockets! Really looking forward to giving this a try with Phoenix.

• by daigoba66 on 8/11/16, 7:38 PM

  These new features are cool... but they still pale in comparison to something like HAProxy.

  I guess the tradeoff is that with ELB/ALB, like most PaaS, you don't have to "manage" your load balancer hosts. And it's probably cheaper than running an HAProxy cluster on EC2.

  But for the power you get with HAProxy, is it worth it?

  Does anyone have experience running HAProxy on EC2 at large scale?

• by erikcw on 8/11/16, 4:22 PM

  I'm curious if this will Convox to route to multiple services with just a single ALB instead of the historical default of 1 ELB per service. Would be a real cost savings for a micro-services architecture.

• by avitzurel on 8/11/16, 3:27 PM

  This is very good. Recently my workflow has been ELB -> NGINX -> Cluster.

  Nginx was a cluster of machines that did routing based on rules into the ec2 machines. Now that the AELB has some of those capabilities it's time to evaluate it.

• by archgrove on 8/11/16, 3:20 PM

  Any love for Elastic Beanstalk with these? They seem well matched. Though EB always feels a bit of a red-headed stepchild in the AWS portfolio.

• by dblooman on 8/11/16, 6:11 PM

  It seems that routing is done in the following way /API/* goes to applications and expects :8080/api/ rather than the root. Would be nice to have the option to direct traffic to just :8080.

• by axelfontaine on 8/11/16, 4:42 PM

  It looks like the big missing piece is auto-scaling groups as target groups...

• by sturgill on 8/11/16, 4:03 PM

  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.

• by shawn-butler on 8/11/16, 8:51 PM

  Anybody know whether the new ALB handles a client TLS (SSL) when operating in http mode?

  I was trying secure an API Gateway backend using a client certificate but found ELB doesn't currently support client side certificates when operating in http mode.

  There was this complicated Lambda proxy workaround solution but I gave up halfway through...

  https://aws.amazon.com/blogs/compute/using-api-gateway-with-...

• by kookster on 8/11/16, 3:30 PM

  As a heavy ECS user, all I can say is thank you, finally!

• by renaudg on 8/12/16, 3:18 PM

  I'm the process of containerizing an app that includes a Websockets service, and given ECS / ELB limitations we'd just decided to go for Kubernetes as the orchestration layer.

  This ALB announcement + the nicer ECS integration could tip the balance though.

  Any thoughts on how likely it is that Kubernetes can/will take advantage of ALBs (as Ingress objects I suppose) soon ?

• by nodesocket on 8/11/16, 3:30 PM

  Do ALBs support more than a single SSL certificate?

• by manishsharan on 8/11/16, 3:29 PM

  This is definitely nicer than having to create subdomains for microservices and mapping each subdomain url to its own Elastic Loaad Balancer + Elastic Beanstalk instance. But I have already gone down this path so I am unlikely to use AWS Application Load balancer. I wish I had this option a year ago.

• by nailer on 8/11/16, 3:51 PM

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

• by DonFizachi on 8/11/16, 6:36 PM

  Any idea if sticky TCP sessions will be supported on ELB/ALB any time soon?

• by amasad on 8/11/16, 5:47 PM

  I wonder if they fixed the routing algorithm for TCP connections. It's round-robin on ELB, which is performs terribly for long lasting connections.

• by nodesocket on 8/11/16, 3:18 PM

  So what would be a use case for using ELBs now? Seems like ALBs do everything ELBs do, but with websocket and HTTP/2 support.

• by joneholland on 8/12/16, 10:22 AM

  Disappointing. I was hoping they were launching a service discovery stack to compliment ECS.

• by bradavogel on 8/11/16, 5:32 PM

  Does anyone know if it (finally) supports sticky websocket sessions?

• by merb on 8/11/16, 4:24 PM

  Virtual Host Load Balancer would be great.

• by NeckBeardPrince on 8/11/16, 8:04 PM

  Any idea if it's HIPPA compliant?