Route 53 – Routing Policies

• Simple – one record (or several records returned randomly).

• Weighted – split traffic by percentage.

• Failover – active–passive setup for high availability.

• Latency-based – return the endpoint with the lowest latency.

• Geolocation – route based on the user’s location.

• Geoproximity – route based on proximity and optional bias (requires Traffic Flow).

• IP-based – route based on the client’s IP address.

• Multi-Value – return multiple healthy records for basic load distribution.

Simple Routing

• Returns a single resource, or multiple IPs/values without traffic control logic.

• With multiple records of the same name, Route 53 returns them all, and the client randomly picks one.

• When using an Alias in Simple Routing, you can point to only one AWS resource.

• Health checks are not supported.

• Single record: foo.example.com → A 11.22.33.44

• Multiple: foo.example.com → A 11.22.33.44, A 55.66.77.88

Weighted Routing

• Distributes traffic between records based on assigned weights.

• Percentage formula:

• Weights don’t need to total 100.

• Records must have same name and type.

• Can be combined with health checks.

• Gradual application rollouts.

• A/B testing.

• Balancing load between environments.

• Weight 0 → record excluded unless all records are 0 (then all are returned).

Latency-based Routing

• Routes to the resource with lowest network latency from the user’s location.

• AWS measures latency between regions and network edge locations.

• May route a user to a non-closest region if it offers better latency.

• Supports health checks for failover.

Failover Routing (Active–Passive)

• Implements disaster recovery by defining a primary and secondary resource.

• Route 53 will always return the primary resource if it passes its health check.

• If the primary becomes unhealthy, Route 53 automatically returns the secondary resource.

• Health checks are mandatory for failover to work.

1. DNS request reaches Route 53.

2. Health check for the primary endpoint is evaluated.

3. If healthy → primary IP is returned.

4. If unhealthy → secondary IP is returned.

• Disaster recovery setups.

• Mission-critical services where downtime is unacceptable.

Geolocation Routing

• Different from latency-based routing — here the decision is purely based on the geographic location of the user.

• Location can be specified as:
• Continent (e.g., Europe)
• Country (e.g., France)
• US State (for US-based users)

• If there’s overlap, most specific match wins (state > country > continent).

• It’s best practice to define a Default record for requests that don’t match any location rule.

• Localized content delivery (e.g., language-based sites).

• Regional restrictions (e.g., compliance or licensing).

• Distributing load across regions in a location-aware way.

• Can be combined with health checks.

Geoproximity Routing (requires Traffic Flow)

• Routes based on the geographic proximity between the user and the resource.

• Can adjust distribution with a bias value:
• Positive bias (+1 to +99) → enlarge the region, send more traffic to that resource.
• Negative bias (-1 to -99) → shrink the region, send less traffic to that resource.

• Works with:
• AWS resources (region-based)
• Non-AWS resources (latitude/longitude)

• Gradually shift traffic during migrations.

• Balance load dynamically between regions.

IP-based Routing

• Uses CIDR collections to map client IP ranges to specific endpoints.

• Useful for:
• Routing based on ISP or corporate network.
• Optimizing network cost or latency.

Multi-Value Routing

• Returns multiple healthy records for the same DNS name.

• Can be associated with health checks (only healthy endpoints are returned).

• Up to 8 records per query.

• Not a replacement for a load balancer — this is DNS-based load distribution without state awareness.