Why Health checks with Route 53 in AWS? - Purpose & Use Cases

The Big Idea

What if your website could fix itself when a server breaks, without you lifting a finger?

The Scenario

Imagine you have a website running on several servers. You want to make sure visitors always reach a working server. Without health checks, you have to manually check each server's status and update your DNS settings if one fails.

The Problem

Manually checking servers is slow and tiring. You might miss a failure, causing visitors to see errors. Changing DNS records by hand takes time and can cause downtime. This approach is error-prone and stressful.

The Solution

Route 53 health checks automatically monitor your servers. If a server stops responding, Route 53 stops sending traffic to it. This keeps your website available without manual work, saving time and avoiding mistakes.

Before vs After

✗ Before

Check server status manually
Update DNS records manually

✓ After

Create Route 53 health check
Associate health check with DNS record

What It Enables

You can keep your website running smoothly and automatically route visitors away from broken servers.

Real Life Example

A company runs an online store on multiple servers. Using Route 53 health checks, they ensure customers never land on a broken server, keeping sales steady and customers happy.

Key Takeaways

Manual server checks are slow and risky.

Route 53 health checks automate monitoring and routing.

This keeps websites reliable and reduces downtime.

Practice

1. What is the main purpose of a health check in AWS Route 53?

easy

A. To monitor if a website or server is working properly

B. To increase the storage capacity of a server

C. To speed up the DNS resolution process

D. To encrypt data between users and servers

Solution

1. Step 1: Understand the role of health checks

   Health checks in Route 53 monitor the status of your website or server to see if it is working correctly.

2. Step 2: Identify the main purpose

   The main goal is to ensure traffic is sent only to healthy endpoints by checking their health status.

3. Final Answer:

   To monitor if a website or server is working properly -> Option A

4. Quick Check:

   Health check purpose = Monitor server health [OK]

Hint: Health checks watch if your site/server is up [OK]

Common Mistakes:

• Confusing health checks with encryption
• Thinking health checks speed up DNS
• Assuming health checks add storage

2. Which of the following is the correct way to configure a Route 53 health check to check an HTTP endpoint on port 80?

easy

A. Set Protocol to FTP and Port to 21

B. Set Protocol to HTTPS and Port to 443

C. Set Protocol to TCP and Port to 22

D. Set Protocol to HTTP and Port to 80

Solution

1. Step 1: Identify the protocol and port for HTTP

   HTTP uses protocol HTTP and port 80 by default.

2. Step 2: Match the correct configuration

   Setting Protocol to HTTP and Port to 80 correctly configures the health check for an HTTP endpoint.

3. Final Answer:

   Set Protocol to HTTP and Port to 80 -> Option D

4. Quick Check:

   HTTP = Protocol HTTP + Port 80 [OK]

Hint: HTTP always uses port 80 [OK]

Common Mistakes:

• Using HTTPS protocol for HTTP checks
• Choosing wrong ports like 22 or 21
• Confusing TCP with HTTP protocol

3. Given a Route 53 health check configured to check an HTTP endpoint every 30 seconds with a failure threshold of 3, how long will it take before Route 53 marks the endpoint as unhealthy after it stops responding?

medium

A. 30 seconds

B. 60 seconds

C. 90 seconds

D. 120 seconds

Solution

1. Step 1: Understand failure threshold and interval

   The health check runs every 30 seconds and requires 3 consecutive failures to mark unhealthy.

2. Step 2: Calculate total time to mark unhealthy

   3 failures x 30 seconds each = 90 seconds before marking unhealthy.

3. Final Answer:

   90 seconds -> Option C

4. Quick Check:

   3 failures x 30s = 90s [OK]

Hint: Multiply interval by failure threshold [OK]

Common Mistakes:

• Using interval time only without threshold
• Adding instead of multiplying
• Confusing seconds with minutes

4. You created a Route 53 health check for an HTTPS endpoint on port 443, but Route 53 always marks it unhealthy even though the site is up. What is the most likely cause?

medium

A. The health check is set to HTTP instead of HTTPS

B. The failure threshold is set too high

C. The endpoint is using port 80 instead of 443

D. The health check is configured with TCP protocol

Solution

1. Step 1: Check protocol mismatch

   If the health check is set to HTTP but the endpoint requires HTTPS, the check will fail.

2. Step 2: Confirm correct protocol and port

   HTTPS requires protocol HTTPS and port 443; using HTTP protocol causes failure.

3. Final Answer:

   The health check is set to HTTP instead of HTTPS -> Option A

4. Quick Check:

   Protocol mismatch causes failure [OK]

Hint: Match protocol exactly with endpoint [OK]

Common Mistakes:

• Ignoring protocol and port mismatch
• Assuming failure threshold causes failure
• Confusing TCP with HTTPS protocol

5. You want Route 53 to route traffic only to healthy web servers in multiple regions. You have health checks set up for each server. Which routing policy should you use to ensure traffic goes only to healthy servers and balances load across them?

hard

A. Simple routing policy

B. Weighted routing policy with health checks enabled

C. Latency routing policy without health checks

D. Failover routing policy

Solution

1. Step 1: Understand routing policies

   Simple routing sends traffic to one resource; failover sends to primary then backup; weighted distributes traffic by weights; latency routes to lowest latency.

2. Step 2: Choose policy that balances load and respects health

   Weighted routing with health checks enabled sends traffic only to healthy servers and balances load based on weights.

3. Final Answer:

   Weighted routing policy with health checks enabled -> Option B

4. Quick Check:

   Weighted + health checks = balanced healthy routing [OK]

Hint: Use weighted routing with health checks for balanced healthy traffic [OK]

Common Mistakes:

• Using simple routing which ignores health checks
• Failover only switches on failure, no load balance
• Latency routing without health checks risks unhealthy targets