Monitoring platform for keeping systems up and running at all times.
Full stack visibility across the entire stack.
Detect and resolve any incident in record time.
Conform to industry best practices.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
Dashbird now integrates with 5 new AWS services
Can AWS API Gateway act as a load balancer?
Everything you need to know about AWS API Gateway
In this article, we’re covering 4 tips for AWS Lambda optimization for production. Covering error handling, memory provisioning, monitoring, performance, and more.
In this article we’ll go through the ins and outs of AWS Lambda pricing model, how it works, what additional charges you might be looking at and what’s in the fine print.
Dashbird was born out of our own need for an enhanced serverless debugging and monitoring tool, and we take pride in being developers.
Dashbird gives us a simple and easy to use tool to have peace of mind and know that all of our Serverless functions are running correctly. We are instantly aware now if there’s a problem. We love the fact that we have enough information in the Slack notification itself to take appropriate action immediately and know exactly where the issue occurred.
Thanks to Dashbird the time to discover the occurrence of an issue reduced from 2-4 hours to a matter of seconds or minutes. It also means that hundreds of dollars are saved every month.
Great onboarding: it takes just a couple of minutes to connect an AWS account to an organization in Dashbird. The UI is clean and gives a good overview of what is happening with the Lambdas and API Gateways in the account.
I mean, it is just extremely time-saving. It’s so efficient! I don’t think it’s an exaggeration or dramatic to say that Dashbird has been a lifesaver for us.
Dashbird provides an easier interface to monitor and debug problems with our Lambdas. Relevant logs are simple to find and view. Dashbird’s support has been good, and they take product suggestions with grace.
Great UI. Easy to navigate through CloudWatch logs. Simple setup.
Dashbird helped us refine the size of our Lambdas, resulting in significantly reduced costs. We have Dashbird alert us in seconds via email when any of our functions behaves abnormally. Their app immediately makes the cause and severity of errors obvious.
End-to-end observability and real-time error tracking for AWS applications.