- • 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 checks.
- • 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.
| - • 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 healthy at the time of the health check is InServiceThe 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.
- ◦ a specific portping path
- • ELB health checks do not support WebSockets.
- • 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.
- • The load balancer checks the health of the registered instances using either
- ◦ a specific portthe default health check configuration provided by Elastic Load Balancing or
- ◦ a specific porta health check configuration that you configure (auto scaling or custom health checks for example).
- • Network Load Balancers use active and passive health checks to determine whether a target is available to handle requests.
- ◦ a specific portWith active health checks, the load balancer periodically sends a request to each registered target to check its status. After each health check is completed, the load balancer node closes the connection that was established.
- ◦ a specific portWith passive health checks, the load balancer observes how targets respond to connections, which enables it to detect an unhealthy target before it is reported as unhealthy by active health checks. You cannot disable, configure, or monitor passive health checks.
- • Gateway load balancer health checks can use HTTP, HTTPS or TCP protocol to reach your targets. The default protocol is TCP.
| - • 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. This notification can come from one or more of the following sources:
- ◦ a specific portAmazon EC2 (default)
- ◦ a specific portElastic Load Balancing
- ◦ a specific portA 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 any 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 by 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 instance’s health information directly from your system to Amazon EC2 Auto Scaling.
|
