Monday, June 9, 2025

Routing Policies – Failover (Active-Passive)

 

Route 53 – Failover Routing Policy (Active-Passive)

Failover routing in Route 53 is used to configure high availability by directing traffic to a primary (active) resource and failing over to a secondary (passive) resource only if the primary becomes unhealthy.

 How It Works

  • Active (Primary) Record: Handles all traffic under normal conditions.
  • Passive (Secondary) Record: Takes over only if the active one fails a health check.
  • Route 53 checks the health status of the primary via a configured health check.
  • If the primary fails → traffic automatically routes to the secondary.

 Steps to Set Up Failover Routing Policy

  1. Create Health Check
    • Route 53 must monitor your primary endpoint (via HTTP, HTTPS, or TCP).
    • Health check must be associated with the primary record.
  2. Create Primary Record (Active)
    • Set Routing Policy: Failover
    • Set Failover Type: Primary
    • Associate the health check.
    • Example:

# yaml

 

Name: www.springapp.twtech.com 

Type: A or CNAME 

Value: 192.0.2.10 (Active server) 

Failover: Primary 

Health Check: Enabled

  1. Create Secondary Record (Passive)
    • Set Routing Policy: Failover
    • Set Failover Type: Secondary
    • No health check needed (optional).
    • Example:

# makefile

 

Name: www.twtech.click 

Type: A or CNAME 

Value: 192.0.2.20 (Backup server) 

Failover: Secondary 

twtech idea 

Condition

Route 53 Behavior

If Primary  is Healthy

Routes all traffic to Primary

If Primary  is Unhealthy

Instantly switches to Secondary (Passive)

 twtech Best Practices

  • Keep the health check interval short (e.g., 30 seconds) for faster failover.
  • Use multiple health checkers (3+ regions) to avoid false negatives.
  • Monitor CloudWatch metrics tied to health checks.
  • Combine with CloudFront or ELB for regional resilience if needed.

Project: Hands-on

How twtech  configures failover for resources.

Create a failover record: go to Hosted zone and select the DNS to use for the record.

Hosted zone selected for the record: twtech.click

Assign and name for the record: failoverpolicy.twtech.click



twtech idea is:

If the primary instance in us-east-2(Ohio) fails, traffic should be routed to the secondary instance in us-east-1(N. Virginia)

Try on the browser to see if the record url is reachable: failoverpolicy.twtech.click

Yes:  but traffic failover to the secondary instance in us-east-1 (N. Virginian), instead of the primary instance set or us-east-2(Ohio) region.


NB:

 Once the failover is fixed and the primary instance becomes healthy again, traffic will be routed back to the primary instance.

twtech insights:

Traffic is only routed to the secondary instance if the health check is determined to be unhealthy in the primary instance. For as long as the primary instance stays healthy, traffic will continue to route to the primary instance.


No comments:

Post a Comment

Kubernetes Clusters | Upstream Vs Downstream.

  The terms "upstream" and "downstream" in the context of Kubernetes clusters often refer to the direction of code fl...