Load balancer health checks are a critical component of AWS infrastructure that ensure high availability and reliability of your applications. In AWS, Elastic Load Balancing (ELB) continuously monitors the health of registered targets (EC2 instances, containers, or IP addresses) to route traffic on…Load balancer health checks are a critical component of AWS infrastructure that ensure high availability and reliability of your applications. In AWS, Elastic Load Balancing (ELB) continuously monitors the health of registered targets (EC2 instances, containers, or IP addresses) to route traffic only to healthy resources.
Health checks work by sending periodic requests to registered targets at configured intervals. The load balancer evaluates responses based on predefined criteria to determine if a target is healthy or unhealthy. Key configuration parameters include:
**Health Check Protocol**: You can configure HTTP, HTTPS, TCP, or SSL protocols depending on your application requirements.
**Health Check Path**: For HTTP/HTTPS checks, you specify a URL path that the load balancer will request. This endpoint should return a 200-299 status code when healthy.
**Interval**: The time between health check requests, typically ranging from 5 to 300 seconds.
**Timeout**: The duration the load balancer waits for a response before marking the check as failed.
**Healthy Threshold**: The consecutive successful checks required before marking an unhealthy target as healthy.
**Unhealthy Threshold**: The consecutive failed checks required before marking a healthy target as unhealthy.
When a target fails health checks, the load balancer stops sending traffic to it, preventing users from experiencing errors. Once the target passes the required number of consecutive health checks, traffic resumes.
For Application Load Balancers (ALB), health checks occur at the target group level. Network Load Balancers (NLB) support both TCP and HTTP health checks. Classic Load Balancers perform checks on registered instances.
Best practices include creating dedicated health check endpoints that verify application dependencies, setting appropriate thresholds to avoid false positives during brief issues, and monitoring health check metrics through CloudWatch. Proper health check configuration is essential for maintaining application availability and implementing effective auto-scaling policies based on instance health status.
Load Balancer Health Checks: Complete Guide for AWS SysOps Administrator Associate
Why Load Balancer Health Checks Are Important
Load balancer health checks are a critical component of building highly available and resilient applications in AWS. They ensure that traffic is only routed to healthy instances, preventing users from being directed to servers that are unresponsive or malfunctioning. This mechanism is fundamental to maintaining application uptime and providing a seamless user experience.
What Are Load Balancer Health Checks?
Health checks are automated tests performed by Elastic Load Balancers (ELB) to determine the operational status of registered targets (EC2 instances, containers, IP addresses, or Lambda functions). The load balancer periodically sends requests to targets and evaluates their responses to classify them as either healthy or unhealthy.
There are three types of load balancers in AWS, each supporting health checks: - Application Load Balancer (ALB): Layer 7, HTTP/HTTPS health checks - Network Load Balancer (NLB): Layer 4, TCP/HTTP/HTTPS health checks - Classic Load Balancer (CLB): Layer 4/7, TCP/HTTP/HTTPS health checks
How Load Balancer Health Checks Work
Configuration Parameters: - Protocol: HTTP, HTTPS, TCP, or SSL - Port: The port to check (can differ from traffic port) - Path: For HTTP/HTTPS checks, the endpoint to request (e.g., /health) - Interval: Time between health checks (default 30 seconds) - Timeout: Time to wait for a response (default 5 seconds) - Healthy Threshold: Number of consecutive successful checks to mark target healthy - Unhealthy Threshold: Number of consecutive failed checks to mark target unhealthy
The Health Check Process: 1. The load balancer sends a request to the target on the specified protocol, port, and path 2. The target must respond within the timeout period 3. For HTTP/HTTPS, the response must return a status code in the success range (200-399 by default) 4. The load balancer tracks consecutive successes or failures 5. Once thresholds are met, the target status changes accordingly 6. Unhealthy targets stop receiving traffic until they pass health checks again
Best Practices for Health Checks
- Create a dedicated health check endpoint that verifies application dependencies - Set appropriate intervals and thresholds based on your application's characteristics - Use health check paths that test actual application functionality, not just server availability - Ensure security groups allow health check traffic from the load balancer - Monitor health check metrics in CloudWatch for patterns
Common Health Check Issues
- Security groups blocking health check traffic - Incorrect health check path returning 404 errors - Timeout values shorter than application response time - Health check port not matching the application port - Application not listening on the expected protocol
Exam Tips: Answering Questions on Load Balancer Health Checks
Key Points to Remember:
1. Unhealthy targets do not receive traffic - The load balancer routes requests only to targets that pass health checks
2. Health check timing matters - Understand the relationship between interval, timeout, and thresholds. A target marked unhealthy will take (healthy threshold × interval) seconds to become healthy again
3. Security group configuration is essential - Targets must allow inbound traffic from the load balancer on the health check port
4. HTTP status codes 200-399 indicate success - For HTTP/HTTPS health checks, responses outside this range cause failures
5. Cross-zone load balancing affects health check behavior - When enabled, traffic is distributed across all healthy targets in all enabled Availability Zones
6. Target groups vs instance-level health checks - ALB and NLB use target groups with independent health check settings
7. Grace period for new instances - Auto Scaling groups have a health check grace period to allow instances time to bootstrap before being checked
Scenario-Based Question Strategies:
- If a question mentions instances being marked unhealthy unexpectedly, consider security group rules or application response times - When asked about minimizing detection time for failed instances, think about reducing intervals and unhealthy thresholds - For questions about application-level health verification, recommend custom health check paths that test dependencies - If traffic is going to unhealthy instances, verify that health checks are properly configured and not always passing
Remember: Health checks are the foundation of high availability. Questions often test your understanding of how they integrate with Auto Scaling, security groups, and overall fault tolerance strategies.