AWS Load balancers, Lambda Health Check

What does it mean by AWS Lambda Health Checks from a ALB’s standpoint?

In modern application architectures, scalability and fault tolerance are key components that ensure a seamless user experience. AWS has simplified these aspects with services such as Elastic Load Balancing (ELB) and AWS Lambda. Recently, AWS extended the capability of ELB to support Lambda as a target, opening up new possibilities for application designs.

In this blog, we will explore what this new feature means, focusing on the concept of health checks and how they apply when Lambda functions are used as targets.

What Are Health Checks?

In load balancing, health checks are routine tests that the load balancer performs on registered targets to ensure that they can handle requests. If a target fails the health check, the load balancer will cease to send traffic to that target, rerouting it to other healthy targets.

Health checks are vital to maintaining the stability and efficiency of the system, and they play a crucial role in avoiding routing requests to malfunctioning components.

Lambda as a Target

Traditionally, Elastic Load Balancing has been used to distribute incoming application traffic across multiple targets such as EC2 instances, containers, and IP addresses. With the addition of Lambda as a target, you can now route client traffic directly to a Lambda function.

This approach simplifies the architecture by removing the need for EC2 instances or containers, reducing the operational complexity and cost. It also allows you to build serverless applications that scale with demand.

When you use Lambda as a target with ALB, the concept of Availability Zones becomes less relevant, and here’s why:

1. Lambda is Regional, not Zonal:

AWS Lambda operates at a regional level, not within specific Availability Zones. When an ALB routes traffic to a Lambda function, it sends invocations to a regional endpoint, rather than an endpoint within a specific AZ.

2. Unified Health Checks:

Health checks on Lambda functions do not differentiate between different AZs within the region. The health check ensures that the function itself is responding correctly, rather than checking the health of underlying infrastructure across different AZs.

3. Automatic Scaling Across AZs:

Since Lambda operates at a regional level, it automatically handles traffic across all AZs within that region. This abstracts away the complexity of managing traffic across different AZs.

Comparison and Implications

Here are the key differences and implications when comparing traditional ALB health checks in an AZ to ALB with Lambda as a target:

• Simplification: Using Lambda eliminates the need to manage health across different AZs, simplifying the architecture.
• Resilience: Lambda’s regional nature ensures high availability across all AZs in the region, enhancing fault tolerance.
• Consistency: With Lambda, all invokes go to a regional endpoint, providing a uniform way of handling traffic, independent of AZs.
• No Cross-AZ Data Transfer Costs: Since Lambda operates at a regional level, you don’t incur additional costs for transferring data across AZs, which might be the case with traditional ALB configurations.

Lambda Health Checks as Prewarming

Lambda health checks aren’t explicitly designed for “pre-warming” in the traditional sense. Pre-warming in the Lambda context means having instances of your function ready to respond to requests without the initial cold start delay. However, because health checks result in invocations of your Lambda function, they can indirectly cause the AWS Lambda service to maintain a “warmed” instance of your function, thereby potentially reducing cold starts.

That being said, it’s important not to solely rely on health checks for this purpose. If you’re aiming to reduce cold starts, it’s more effective to use mechanisms specifically designed for it, like provisioned concurrency.