Introduction

ELB health checks and EC2 health checks are different layers of AWS health monitoring. ELB checks determine if an instance or target should receive traffic. EC2 checks determine whether the instance and underlying host are operational at infrastructure level.

ELB Health Checks: Traffic Readiness

Load balancers check target readiness using configured probes. For Application Load Balancer, this is commonly an HTTP endpoint like /ready.

ELB asks: should this target receive user requests now.

Typical ELB unhealthy reasons:

• application process not responding
• wrong health-check path
• dependency timeout inside readiness endpoint
• security group or ACL blocking probe traffic

aws elbv2 describe-target-health \
  --target-group-arn arn:aws:elasticloadbalancing:us-east-1:123456789012:targetgroup/web-tg/abc123

This command helps diagnose routing-level outages quickly.

EC2 Health Checks: Instance and Host Viability

EC2 status checks evaluate infrastructure and instance-level reachability:

• system status check for AWS host/network layer
• instance status check for guest OS responsiveness

EC2 asks: is this VM and host environment fundamentally healthy.

aws ec2 describe-instance-status \
  --instance-ids i-0123456789abcdef0 \
  --include-all-instances

An instance may pass EC2 checks while failing ELB checks if app processes are unhealthy. The reverse can also happen during transient host issues.

Auto Scaling Behavior

Auto Scaling groups can use EC2, ELB, or both health models depending on configuration.

1aws autoscaling update-auto-scaling-group \
2  --auto-scaling-group-name web-asg \
3  --health-check-type ELB \
4  --health-check-grace-period 120

If only EC2 checks are used, app-level failures can persist longer. ELB health checks usually provide better replacement behavior for stateless web services.

Grace period tuning is important:

• too short causes replacement during normal startup
• too long delays removal of genuinely bad targets

Designing Effective Health Endpoints

Readiness endpoints should be lightweight and deterministic. Heavy dependency checks can create false negatives under load.

A common split is:

• '/live for process liveness'
• '/ready for request serving readiness'

1from flask import Flask, jsonify
2
3app = Flask(__name__)
4
5@app.get('/ready')
6def ready():
7    return jsonify(status='ok'), 200
8
9if __name__ == '__main__':
10    app.run(host='0.0.0.0', port=8080)

Use deep diagnostics in monitoring jobs, not in high-frequency load balancer probes.

Incident Triage Sequence

During traffic loss, use layered triage:

1. Check ELB target health and reason codes.
2. Check EC2 system and instance status.
3. Review application logs and dependency latency.
4. Probe health endpoint locally on affected hosts.

This sequence isolates routing problems from infrastructure failures quickly.

Operational Guidance

Document health-check ownership and thresholds in runbooks. Include expected probe intervals, timeout values, and known startup warm-up behavior. This reduces confusion between platform and application teams during incidents.

For multi-environment deployments, validate health policies per environment because staging and production often differ in security rules and dependency topology.

Monitoring and Alerting Integration

Route ELB unhealthy-target metrics and EC2 status-check failures to separate alert channels. Keeping these alerts distinct helps responders identify whether they are handling app readiness degradation or infrastructure-level instability. Pair alerts with dashboard panels that show target health, autoscaling events, and instance status on one timeline so cross-layer correlation is fast during incidents.

Common Pitfalls

• Treating ELB and EC2 checks as interchangeable.
• Implementing expensive readiness checks that fail under normal load.
• Misconfiguring network rules so probes cannot reach targets.
• Setting autoscaling grace periods without measuring startup times.
• Looking at one health layer only and missing root cause.

Summary

• ELB checks control whether targets receive traffic.
• EC2 checks validate instance and host viability.
• Both are useful but answer different operational questions.
• Autoscaling outcomes depend on which health type is configured.
• Reliable triage requires checking routing and infrastructure layers in order.