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.
What is Elastic Load Balancer (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.
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
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.
Top comments (0)