Tuesday, June 10, 2025

Route 53 Health Checks | Overview & Hands-On.

 

Route 53 Health Checks - overview & Hands-On.

Scope:

  • Intro,
  • Purpose of Health Checks,
  • What Can Be Monitored,
  • Types of Health Checks,
  • Configurable Parameters,
  • Health Checkers,
  • Integration with DNS Routing Policies,
  • Notifications,
  • Limitations (What Health Checks Cannot Do),
  • Use Case,

Amazon Route 53  Health Check is a feature used to monitor the health and availability of resources (e.g., web servers, applications, endpoints) and route traffic accordingly based on that health status.

Here’s twtech breakdown of what Route 53 Health Checks do and how they work:

 Purpose of Health Checks

Route 53 health checks determine if a specified endpoint (like a web server or API) is healthy

If not, Route 53 can:

  • Stop routing traffic to it (failover).
  • Send alerts using CloudWatch.
  • Enable high availability using features like DNS failover.

 What Can Be Monitored

twtech may create health checks for:

  • Endpoints (IP addresses or domain names).
  • CloudWatch Alarms (to monitor custom metrics).
  • Other health checks (calculated health checks aggregate the status of others).

 Types of Health Checks

  1. Endpoint Health Checks
    • HTTP, HTTPS, or TCP.
    • Checks response codes and connection success.
  2. Calculated Health Checks
    • Combine multiple health checks using logic (e.g., 2 of 3 must be healthy).
  3. CloudWatch Alarm Health Checks
    • Use a CloudWatch alarm state as the health indicator.

 Configurable Parameters

When creating a health check, twtech would configure:

  • IP address or domain to check.
  • Port and protocol (HTTP, HTTPS, TCP).
  • Path for HTTP/HTTPS checks (e.g., /status).
  • Expected response codes.
  • Check interval (default 30s; can be 10s for faster checks).
  • Failure threshold (number of failed checks before marked unhealthy).
  • Optional latency and regional endpoint considerations.

 Health Checkers

Route 53 uses multiple health checker servers located around the globe to reduce false positives and increase accuracy.

 Integration with DNS Routing Policies

Health checks are often used with:

  • Failover routing – switch to a backup resource if primary is unhealthy.
  • Latency-based routing – only route to healthy endpoints with the lowest latency.
  • Geolocation/Geoproximity – combined with health to ensure availability per region.
  • Weighted routing – distribute traffic only to healthy endpoints based on weights.

 Notifications

Route 53 can trigger Amazon CloudWatch alarms, which can then send SNS notifications if a health check fails.

 Limitations (What Health Checks Cannot Do)

  • They do not monitor hosted zones or DNS names—only endpoints.
  • They do not automatically restart instances or fix errors (though they can trigger workflows that do).

twtech Use Case

  • twtech is running a web-app across us-east-1 (Ohio)  and us-west-2 (N. California).

 twtech Creates:

  • Health checks on both endpoints.
  • A failover routing policy in Route 53.
  • If us-east-1(Ohio) becomes unhealthy, Route 53 routes traffic to us-east-1 (N. virginia).


Project: Hands-on

  • How twtech creates and use Health check to monitor its applications across  regions.

Step-1:

  • Go to rout53 UI (console) and create health checks:  

  • Create Health checks


  • Health check on Instance in:  us-east-2 (Ohio)

Step-2:

  • twtech Follows the same steps to create health checks for the rest of the instances across all the regions where the appllication is running.

  • twtech creates Health check on Instance in:  us-east-1 (N.Virgina)



  • Step-3:
  • twtech creates Health check on Instance in: us-west-1(N. California)


  • twtech verifies all Exiting and new Health checks created: 


Step-4:
  • twtech creates a failing health check for a node (instance) by editing the security group of the instance and removing the traffic port. (delete port80). 
  • or shut down (Stop)  the instance from running.
  • twtech Goes to instance in any of the regions and edit the security inbound rule: 


  • twtech Edits the security inboud rules: delete the traffic port for the application.

  • From:

  • To: delete ( remove) the http port for the application

  • Save changes:


NB:

  • Port80 that allow traffic to twtech application running in the node in us-east-2 has been removed.
  • This triggers a health failure to the node.

Step-5:

  • twtech Goes back to health check in route53 UI to verify whether the instance in us-east-2 is giving an: unhealthy status

From:

To :

  • Refresh page:  unhealthy

NB:

  • More information can be got from the health checkers:
  • Select a Health check,  and click open to access details: Health checkers


Step-6:

  • twtech creates a  calculated Health check for its instances




Step-7:

  •  twtech integrates health check for its instances with: cloudwateh alarm 


twtech-insights:

  • If one of the instance display an unhealthy status, that would automatically trigger the calculated Heath check , unhealthy status & CloudWatch alarm.


No comments:

Post a Comment

Amazon EventBridge | Overview.

Amazon EventBridge - Overview. Scope: Intro, Core Concepts, Key Benefits, Link to official documentation, Insights. Intro: Amazon EventBridg...