Availability and Health Monitoring

What it is

Availability monitoring answers a simple question: can users reach the service and does it work? AWS gives you several layers of signals, from the host, to the load balancer, to the user's view.

Good operators check these layers in order, so they know whether a fault is in the instance, the application path, the network or AWS itself.

How it works

EC2 status checks

EC2 runs two checks every minute. The system status check looks at the underlying host, such as power, network and hardware. The instance status check looks at the guest operating system and its network configuration.

A CloudWatch alarm on StatusCheckFailed_System can use the EC2 recover action. Recovery keeps the instance ID, private IP address and other identity details. This works for EBS (Elastic Block Store) backed instances, and not for instances with instance store volumes.

Load balancer metrics

Elastic Load Balancing publishes metrics that tell you where an error happens. Learn to separate errors produced by the load balancer from errors produced by your targets.

If target 5XX counts rise, look at the application and its logs. If load balancer 5XX counts rise while targets look fine, check target capacity, health checks and the load balancer's own limits.

Route 53 health checks

Amazon Route 53 health checkers around the world can probe an endpoint by HTTP, HTTPS or TCP. A health check can also be a calculated check that combines other checks, or one that follows a CloudWatch alarm state.

Health checks drive DNS failover, which is covered in the reliability chapter. They can raise a CloudWatch alarm too, which lets you notify people through SNS.

CloudWatch Synthetics

Synthetics runs canaries, which are scripts on a schedule that act like a user, for example loading a page or calling an API. A canary finds problems even when there is no real traffic, and it gives you a success rate and latency metric to alarm on.

Tracing with X-Ray

AWS X-Ray follows a request through several services and builds a service map. Use it to find which downstream call is slow or failing in a microservice or serverless application. The application must send trace data, for example through the X-Ray SDK or agent.

AWS Health

The AWS Health Dashboard has two parts. The service health view shows the status of AWS services, and the account view shows events that affect your own resources, such as scheduled maintenance or an instance that must be retired.

Health events also arrive in EventBridge, so you can route them to a team or an automation.

Typical diagnosis order
1. AWS Health: is AWS itself reporting a problem?
2. Load balancer metrics: 4XX or 5XX, which side?
3. Target health: healthy host count, status checks
4. Logs and traces: why the application failed