Ref: https://learn.cantrill.io/courses/1820301/lectures/41301583

• Summary:
• Contents:

R53 Health Checks - Key Concepts

• 🔧 Monitor and evaluate the health and performance of resources

• 3 Types:

  

  1. Endpoint health checks: assess the health of a specified endpoint (of a resource)
     • State: healthy OR unhealthy
     • Endpoint moves between the two states based on conducted checks
     • Can be internal (AWS resource) or external
  2. Calculator health checks: evaluate application-wide health via status of other checks
     • 💡 “Checks of checks”
  3. CW Alarm health checks: react to CW alarms (which are configured separately)
     • e.g. for detailed in-OS or in-app checks if using CW Agent

• Many of the advanced R53 routing policies are supported by R53 health checks

  • 🔧 DNS records can use R53 health checks to take decisions
  • ‼️ Health checks are defined separately from DNS records, NOT within!

• A fleet of health checkers is distributed globally:

  • Diagram: https://github.com/acantril/aws-sa-associate-saac03/blob/main/1200-ROUTE53/00_LEARNINGAIDS/Route53HealthChecks.png
  • Frequency of checks (performed by all checkers):
    • Every 30 seconds by default
    • At an extra cost, they can happen every 10 seconds
  • For external endpoints, health checkers must be allowed to query the endpoints
    • 💡 Blocking them thinking they're bots or exploit attempts will cause false alarms
  • Health check considered healthy if 18%+ of health checkers report it as healthy
  • ‼️ In most cases unhealthy records are NOT returned in queries!!

R53 Endpoint Health Checks

Basic Configurations

• Endpoint can be specified by one of two options:
  1. IP address: perform health checks on given IP address
  2. Domain name: first resolve DNS name, then perform checks on retrieved IP address
     • ❗ IP address can differ depending on which health checker resolves the name
• Protocol configuration:
  • TCP
    • Endpoint healthy if (and only if!) TCP connection established successfully within 10 secs
  • HTTP/HTTPS
    • Endpoint healthy if (and only if!) BOTH these conditions apply:
      1. TCP connection established successfully within 4 secs
      2. Response sent with HTTP status code 2xx or 3xx within 2 secs after connecting
    • 💡 More accurate than TCP check

Advanced Configurations

• Failure threshold
  • Number of consecutive checks that must fail/succeed in order for health checker to change status of endpoint to unhealthy/healthy
  • Gives robustness if endpoint is a bit unstable
    • 💡 odd failed check will not influence health state
• String matching
  • Increases accuracy of HTTP/HTTPS health checks
  • Extra requirement for endpoint to be healthy:
    • R53 checks response's HTTP status code plus response’s HTTP body (tries to match a given string)
    • ❗ Provided string must be found entirely in the first 5120 bytes of the response body
• Latency graphs
  • Show how long endpoint took to answer