AWS Application Load Balancer

Load balancing is a significant part of every internet-facing software, and with Elastic Load Balancing (ELB), AWS offers a set of load balancers for every use case.

Since our latest update, Dashbird also gives you insights into these ELB services; let's look at them and see how they can be used in a serverless environment.

What is Elastic Load Balancing (ELB)?

ELB is a set of load balancing (LB) services offered by AWS. They include Classic Load Balancer, Gateway Load Balancer, Network Load Balancer, and Application Load Balancer.

Each of these LBs covers different use-cases.

The Classic Load Balancer is a good choice for EC2 based architectures
The Gateway Load Balancer helps with third-party VMs in VPCs
The Network Load Balancer focuses on high-performance low-level networking, think UPD based connections for games or IoT
The Application Load Balancer is a high-level solution for software that uses the HTTP protocol

In the case of serverless architectures, all services use HTTP APIs, which means the ALB is the best choice. So, this article will focus on the ALB.

AWS Elastic Load Balancer

What is Application Load Balancer (ALB)?

The ALB's focus on HTTP allows it to use parts of the protocol to make decisions about caching and save you some Lambda executions. This means your Lambda functions have to set their caching headers correctly.

Pricing

While ALB can integrate with Lambda, ALB isn't a serverless service; it has no pay-as-you-go model, which means you pay for times that aren't used. But if you have a service with continuous steady traffic requirements, it can be cheaper than API Gateway in the long run.

Limits

Also, API Gateway has a limit on 10k connections; the ALB doesn't. It's an API Gateway with more minor features; bare-bones, but built for performance. If you're going big, ALB might be your only solution.

Permissions

ALB is more of a traditional "strap in front of your public HTTP endpoint" kind of thing. So, while it integrates with Lambda, it doesn't offer permissions based on IAM. You have to take care of this inside your serverless functions.

Transformations

This traditional load balancing approach also means ALB can't do request and response transforms; it just pipes your data along. Again, this makes the ALB less flexible than the API Gateway and shifts more work to Lambda.

Multi-Region

You deploy the ALB to one region at a time. Again, this isn't a serverless service, so more work on your side is required. To get your traffic balanced between multiple regions, you need Route53's DNS-based balancing.

Configurations for Reliability or Costs

Using ALB with a Lambda target usually delivers good reliability because Lambda scales automatically. If you need more than out-of-the-box reliability, you must deploy ALB to multiple regions and put it behind Route53.

In terms of costs, Lambda can become your main offender. If you route every request to a Lambda function with a big memory config, things can get expensive quickly. So, follow the serverless best practice of keeping Lambda functions small and purpose-driven. Set up conditions for your ALB listeners, so you can use functions with a smaller memory footprint when possible.

Health Check Best Practices

While an EC2 target can easily get overwhelmed, a Lambda target has a bit more buffer because of its inherent autoscaling; there are still things that can go wrong in a serverless system.

AWS disables ALB health checks by default for Lambda targets, so you have to opt-in here.

While some issues can arise from buggy code pushed to Lambda, most problems come from upstream services your function uses. So set up your Lambdas to pipe the health check and later respond with the result from the upstream service.

If things are broken, the only quick solution is to tell Route53 to route the following requests to a different deployment.

Log Analysis in AWS and Dashbird

AWS lets you use Amazon Athena to analyze your ALB logs. Athena is a serverless query service. You need to activate query logs and save them to S3 to explore them with Athenas SQL queries.

Dashbird, on the other hand, comes with an ALB Diagram that groups all the essential metrics out of the box!

Also, more than a dozen of Well-Architected insights are available for all elastic load balancing services, seven alone for the ALB. These include notifications for security issues like missing redirects for HTTP to HTTPS and abandoned ALBs and reliability issues like no remaining healthy targets.

Hunting Bugs with Dashbird

The nice thing about Dashbird is it tracks your whole serverless deployment. A holistic view of your system allows you to find errors that show up with HTTP status codes at the ALB endpoint but are related to your upstream services.

For example, let's take the 502 -- Bad Gateway response. It's widespread for all sorts of upstream errors inside your architecture, so it has no more value than telling you "something behind the ALB is broken." But digging into Dashbird can reveal what's actually happening!

All these 502 responses might look like this:

And they all come with more details so that you can fix the error.

Summary

The ELB services in general, and the ALB, in particular, play a crucial role in scaling your systems. While Lambda targets scale automatically, ALB can still be a cheap alternative to an API Gateway for big workloads. This is especially true if you hit the limits of API Gateway.

But keep in mind that ALB has its own limits and doesn't give you as many features out-of-the-box as API Gateway.

Since Dashbirds new release, you can rest assured that all your AWS load balancers are monitored, and with the Well-Architected insights, you might find some issues in your architecture that have gone unnoticed before.

[Infographic] AWS Elastic Load Balancing from a Serverless perspective