Mastering AWS Health Checks: ALB, Route 53, and Auto Scaling

Learning Objectives

By the end of this study guide, you should be able to:

• Distinguish between System Status Checks and Instance Status Checks in EC2.
• Configure and optimize health checks for Application Load Balancers (ALB) and Network Load Balancers (NLB).
• Implement Route 53 Health Checks for DNS-level failover and endpoint monitoring.
• Integrate Auto Scaling Groups (ASG) with ELB health checks to ensure automated recovery of impaired instances.
• Understand the impact of Health Check Grace Periods and lifecycle hooks on instance replacement.

Key Terms & Glossary

• Health Check Grace Period: The time Amazon EC2 Auto Scaling waits before checking the health status of an instance after it enters the InService state.
• Passive Health Check: Used primarily by NLBs; it observes how targets respond to connections without sending dedicated "probes."
• Target Group: A logical grouping of targets (EC2, Lambda, IP) that an ALB or NLB routes traffic to based on health status.
• Calculated Health Check: A Route 53 feature that monitors the status of other health checks to determine the health of a complex resource.
• ARP Request: Address Resolution Protocol; used by EC2 Instance Status checks to verify network reachability.

The "Big Idea"

In a distributed system, individual components will inevitably fail. Health checks act as the "nervous system" of AWS architecture, allowing the infrastructure to detect failures in real-time. Instead of manually intervening, services like ALB and Route 53 use these signals to reroute traffic, while Auto Scaling uses them to "self-heal" by terminating and replacing failed nodes. Mastery of health checks is the difference between a high-availability system and one prone to cascading failures.

Formula / Concept Box

Hierarchical Outline

1. EC2 Native Status Checks
   • System Status Checks: Detects issues requiring AWS involvement (e.g., loss of power, hardware failure).
   • Instance Status Checks: Detects issues requiring customer involvement (e.g., misconfigured networking, exhausted memory).
2. Elastic Load Balancing (ELB) Health Checks
   • ALB Logic: Application-layer (Layer 7). Checks specific Ping Paths (e.g., /health) and looks for specific HTTP codes.
   • NLB Logic: Transport-layer (Layer 4). Uses TCP/SSL handshakes. Supports Active (probes) and Passive (traffic monitoring) checks.
   • Target Groups: Traffic is ONLY routed to targets in the Healthy state.
3. Route 53 DNS Health Checks
   • Endpoint Monitoring: Monitors IP addresses or domain names.
   • CloudWatch Alarm Integration: Triggers a health check based on custom metrics (e.g., high CPU).
   • Failover Routing: Routes traffic to a secondary record if the primary health check fails.
4. Auto Scaling Integration
   • Health Check Types: Can be set to EC2 (default) or ELB (includes target group status).
   • Grace Period: Prevents premature termination while an application is still booting up.

Visual Anchors

ALB Health Check Decision Flow

Route 53 DNS Failover Mechanism

Definition-Example Pairs

• Ping Path: The specific URL endpoint the load balancer queries.
  • Example: A microservice exposes /api/v1/status. If this returns a 200 OK, the ALB considers the container ready for traffic.
• SSL Health Check: A check that validates the cryptographic handshake.
  • Example: For an NLB handling encrypted database traffic, the check succeeds only if the target completes the TLS handshake, ensuring the certificate and service are valid.
• Multivalue Answer Routing: A Route 53 policy that returns up to 8 healthy records.
  • Example: You have 10 web servers. Route 53 checks all 10; if 2 fail, it only returns the IP addresses of the 8 healthy ones in the DNS response.

Worked Examples

Scenario: Configuring a Resilient Web Cluster

Goal: Ensure instances are only replaced if the web server process (Nginx) crashes, not just if the EC2 hardware fails.

1. Step 1: Configure ALB Target Group: Set the health check to HTTP on Port 80, Path /health.html.
2. Step 2: Update Auto Scaling Group: Change the Health Check Type from EC2 to ELB.
   • Why? The default EC2 check only sees if the VM is up. ELB check sees if the web server is actually responding.
3. Step 3: Set Grace Period: Set a Health Check Grace Period of 300 seconds.
   • Calculation: If your app takes 2 minutes to load Java libraries, 300 seconds provides a safety buffer so ASG doesn't kill it at minute 1.

Checkpoint Questions

1. What is the main difference between a System Status Check and an Instance Status Check?
2. Why should you use ELB health checks in an Auto Scaling Group instead of the default EC2 checks?
3. An NLB is reporting a target as unhealthy, but the instance is running. What is the most likely cause if using active health checks?
4. Does the Health Check Grace Period start before or after a Lifecycle Hook completes?

Muddy Points & Cross-Refs

• Grace Period vs. Lifecycle Hooks: The grace period starts after the instance enters the InService state. If you have a Pending:Wait lifecycle hook for software installation, the timer doesn't start until that hook finishes.
• Route 53 vs. ELB Checks: Route 53 checks from outside the VPC (public internet), whereas ELB checks happen from inside the VPC. If your Security Group blocks external IPs but allows VPC CIDRs, Route 53 might fail while ELB succeeds.

Comparison Tables