Building Region-Aware Traffic Routing with CloudWatch and Route 53 (Dependency-Driven)

Shubham Soni

4 min read

·

Feb 6, 2026

--

Listen

Share

Modern cloud applications must assume that regional dependency failures will happen.
The goal is not to avoid failure, but to detect when a region can no longer safely serve traffic and route users only to healthy regions.

In this article, we’ll walk through a practical AWS design that connects:

Regional dependency probes → CloudWatch Metrics → CloudWatch Alarms → Route 53 Health Checks → Route 53 traffic routing

This pattern allows Route 53 to make routing decisions based on dependency availability, not business-logic side effects or transient application errors.

Press enter or click to view image in full size

Why This Pattern Matters

Traditional health checks (HTTP 200, TCP open) often miss:

• Downstream dependency outages (SQS, DynamoDB, KMS, EventBridge)
• Partial regional degradation
• Control-plane failures that don’t crash your application

At the same time, business-logic failures are a poor signal for traffic routing:

• They only occur under user traffic
• They stop emitting signals after failover
• They prevent automatic recovery

By deriving health from explicit dependency checks, routing decisions become:

• Traffic-independent
• Deterministic
• Self-healing

High-Level Architecture

Region (ap-south-1 / us-east-1 / eu-west-1)
   ↓
Dependency Probes (SQS, DynamoDB, etc.)
   ↓
CloudWatch Custom Metrics (regional)
   ↓
CloudWatch Alarms (regional)
   ↓
Route 53 Health Checks (alarm-based, global)
   ↓
Route 53 DNS routing (only healthy regions receive traffic)

Step 1: Actively Probe Critical Dependencies (Regional)

Each region runs lightweight, scheduled dependency probes (Lambda or CloudWatch Synthetics).

Examples of critical dependencies:

• SQS (SendMessage / GetQueueAttributes)
• DynamoDB (DescribeTable / conditional write)
• KMS (Encrypt / Decrypt)
• EventBridge (PutEvents)

These probes run independently of user traffic.

Example probe result:

{
  "dependency": "SQS",
  "status": "UNAVAILABLE",
  "region": "ap-south-1",
  "timestamp": "2026-02-05T10:00:00Z"
}

This avoids guessing health from application behavior.

Step 2: Convert Dependency Results to Metrics (Regional)

Each probe publishes a binary health metric.

Example:

• Metric name: SQSAvailability
• Namespace: Custom/DependencyHealth
• Value:
  → 1 → dependency healthy
  → 0 → dependency unhealthy
• Dimensions:
  → Region
  → Dependency

Why this matters:

• Logs explain what happened
• Metrics decide what to do

Step 3: Create Regional Health Alarms (Regional)

Each region defines alarms that represent regional safety, not business success.

Example alarm:

• Metric: SQSAvailability
• Threshold: < 1
• Evaluation periods: 2
• Treat missing data: breaching

Alarm states:

• OK → region can safely accept traffic
• ALARM → region must not receive traffic

Optional (recommended):

Use composite alarms to combine multiple dependencies:

• SQS unhealthy OR
• DynamoDB unhealthy OR
• KMS unhealthy

Step 4: Map Alarms to Route 53 Health Checks (Global)

Route 53 supports CloudWatch alarm–based health checks.

For each region:

1. Create a Route 53 health check
2. Select: CloudWatch Alarm, Region
3. Define logic:

• Alarm = OK → Healthy
• Alarm = ALARM → Unhealthy

This creates a clean boundary:

• CloudWatch decides health
• Route 53 decides traffic

Route 53 never evaluates business logic.

Step 5: Route Traffic Using Route 53 (Global)

Each DNS record is associated with its region’s health check.

Routing options:

Failover routing

• Primary → Secondary
• Simple and predictable

Latency-based routing (recommended)

• Multiple regions active
• Route 53 selects the lowest-latency healthy region
• Unhealthy regions are excluded automatically

Weighted routing

• Controlled traffic draining during degradation
• Useful for brownouts and gradual failover

End-to-End Behavior

SQS outage in ap-south-1
 ↓
 Dependency probe fails
 ↓
 CloudWatch metric drops to 0
 ↓
 Regional alarm enters ALARM
 ↓
 Route 53 health check fails
 ↓
 DNS stops routing traffic to ap-south-1
 ↓
 Traffic shifts to us-east-1
 ↓
 SQS recovers
 ↓
 Probe succeeds
 ↓
 Alarm returns to OK
 ↓
 Route 53 restores traffic automatically

No user traffic required for recovery.
No manual intervention.
No sticky failovers.

Key Design Principles

1. Health Is About Safety, Not Success

A region is healthy if it can safely accept traffic, not if business logic always succeeds.

2. Dependency Health > Business Errors

Dependencies fail independently of user traffic.
Health signals must do the same.

3. Detection Is Regional

Each region evaluates its own dependencies locally.

4. Decisions Are Global

Route 53 sees only a binary answer: route or don’t route.

5. DNS Is the Last Gate

Even a running application should not receive traffic if its dependencies are unavailable.

When to Use This Pattern

✔ Multi-region active-active systems
✔ Event-driven or async architectures
✔ Systems with critical AWS dependencies
✔ Designs requiring automatic recovery, not manual resets

Final Thoughts

Route 53 should never be driven by business-logic behavior or error rates.
Those signals disappear precisely when recovery is needed most.

By basing routing decisions on explicit dependency health, your system:

• Fails fast
• Recovers automatically
• Avoids permanent black-holing
• Behaves predictably under regional outages

Global resilience isn’t about clever routing —
it’s about choosing the right signal to trust.