Amazon Route 53 – Health
Checks are 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 a 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
- Endpoint Health Checks
- HTTP, HTTPS, or TCP.
- Checks response codes and connection success.
- Calculated Health Checks
- Combine multiple health checks using logic (e.g., 2 of
3 must be healthy).
- 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
- You're running a web app across us-east-1(Ohio) and us-west-2(N. California).
Create:
- 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-west-2(N. California).
Project: Hands-on
How twtech creates and use Health
check to monitor its resources across the regions.
Go to rout53 console and create
health checks for all the instances across the regions.
Create Health checks
Health check on Instance in: us-east-2
NB:
Follow the same steps to create
health checks for the rest of the instances across the regions.
Health check on Instance in: us-east-1
Health check on Instance in: us-west-1
Exiting and new Health checks
created:
Go to instance in any of the regions
and edit the security inbound rule:
Edit security inboud rules: delete the traffic port for the application.
To: delete the http port for the application
Save changes:
Port80 that allow traffic
to the application in us-east-2 has been removed: to trigger health failure.
Go back to health check in route53 to verify that
the instance in us-east-2 is giving an:
unhealthy status
From:
To :
Refresh page: unhealthy
More information can be go
from the health checkers:
Select a Health check then, Click
on it, to get to: Health checkers
Project: Hands-on
How twtech creates a : calculated Health check for its instances
No comments:
Post a Comment