EC2 Instance Health Check vs ELB Health Check vs Auto Scaling and Custom Health Check Flashcards
EC2 Instance Health Check
Amazon EC2 performs automated checks on every running EC2 instance to identify hardware and software issues
Status checks are performed every minute and each returns a pass or a fail status
If all checks pass, the overall status of the instance is OK.
If one or more checks fail, the overall status is impaired
Status checks are built into EC2, so they cannot be disabled or deleted
You can create or delete alarms that are triggered based on the result of the status check
There are two types of status checks:
System Status Checks: These checks detect underlying problems with your instance that require AWS involvement to repair. When a system status check fails, you can choose to wait for AWS to fix the issue, or you can resolve it yourself
Instance Status Checks: Monitor the software and network configuration of your individual instance. Amazon EC2 checks the health of an instance by sending an address resolution protocol (ARP) request to the ENI. These checks detect problems that require your involvement to repair
BREAK
Elastic Load Balancer (ELB) Health Check
To discover the availability of your registered EC2 instances, a load balancer periodically sends pings, attempts connections or sends requests to test the EC2 instances
The status of the instances that are health at the time of the health check is InService. The status of any instances that are unhealthy at the time of the health check is OutOfService
When configuring a health check, you would need to provide the following:
a specific port
protocol to use
HTTP/HTTPS health check succeeds if the instance returns a 200 response code within the health check interval
A TCP Health check succeeds if the TCP connection succeeds
An SSL health check succeeds if the SSL handshake succeeds
ELB Health Checks do not support Web Sockers.
The load balancer routes requests only to the healthy instances.
When an instance becomes impaired, the load balancer resumes routing requests to the instance only when it has been restored to a healthy state
BREAK
Auto Scaling and Custom health checks
All instances in your Auto Scaling group start in the healthy state.
Instances are assumed to be healthy unless EC2 Auto Scaling receives notification that they are unhealthy
The unhealthy notification can come from one or more of the following sources:
A specific port Amazon EC2
a specific portElastic Load Balancing
a specific Port A custom health check
After Amazon EC2 Auto Scaling marks an instance as unhealthy, it is scheduled for replacement.
If you do not want instances to be replaced, you can suspend the health check process for any individual Auto Scaling group.
If an instance is in any7 other state other than running or if the system status is impaired, Amazon EC2 Auto Scaling considers the instance to be unhealthy and launches a replacement instance
If you attached a load balancer or target group to your Auto Scaling group, Amazon EC2 Auto Scaling determines the health status of the instances byb checking both the EC2 status checks and the Elastic Load Balancing health checks
Amazon EC2 Auto Scaling waits until the health check grace period ends before checking the health status of the instance. Ensure that the health check grace period covers the expected startup time for your application
Health check grace period does not start until lifecycle hook actions are completed and the instance enters the InService state
With custom health checks, you can send an instances health information directly from your system to Amazon EC2 Auto Scaling
