3.2.3.4. Health Check Capabilities in AWS Services (ALB Target Groups, Route 53)

3.2.3.4. Health Check Configuration (Route 53, ALB)

Health checks operate at different layers and serve different purposes. Misconfiguring them is a top cause of both false failovers and missed failures.

ALB health checks (target-level):

• Check individual targets (EC2 instances, containers, IPs)
• Configure: path, port, protocol, interval, thresholds
• Unhealthy targets are removed from the target group — traffic shifts to healthy targets

Route 53 health checks (endpoint-level):

• Check entire endpoints (ALB DNS, IP address, other health check status)
• Used for DNS failover between regions or availability zones
• Health checkers run from multiple global locations

# Route 53 health check with string match
aws route53 create-health-check --caller-reference $(date +%s) \
  --health-check-config '{
    "Type": "HTTPS_STR_MATCH",
    "FullyQualifiedDomainName": "api.example.com",
    "Port": 443,
    "ResourcePath": "/health",
    "SearchString": ""status":"healthy"",
    "RequestInterval": 10,
    "FailureThreshold": 3
  }'

Calculated health checks combine multiple health checks with AND/OR logic — "primary region is healthy if both the API endpoint and database endpoint are healthy."

Health check depth levels:

1. Shallow: TCP connection succeeds (port is open) — catches crashes only
2. Medium: HTTP 200 returned from / — catches web server failures
3. Deep: /health endpoint verifies all dependencies — catches partial failures

Exam Trap: Route 53 health checks originate from AWS's health checker IP ranges — your security groups must allow inbound traffic from these IPs. If you restrict the ALB's security group to only your VPC CIDR, Route 53 health checks fail (they come from outside your VPC). Either allow the Route 53 health checker IPs or use a CloudWatch alarm-based health check instead.