Weighted Routing

What is weighted routing?

Weighted routing is a DNS routing policy that distributes traffic across multiple endpoints according to weights (percentages) you assign — send 90% of requests here, 10% there, and adjust the split whenever you like. In AWS it’s a Route 53 routing policy; other DNS providers and traffic managers offer the equivalent. Rather than sending every user to one place (or round-robining evenly), you get deliberate, tunable control over what fraction of traffic reaches each endpoint. That control is what makes it the DNS-level engine behind several important deployment and testing patterns.

What it’s actually used for

The weights are a means to an end, and the ends are what matter. Gradual rollouts / canary releases: point 5% of traffic at a new version, watch the metrics, and if it’s healthy raise the weight step by step (5 → 25 → 50 → 100) — weighted routing is how you shift that traffic at the DNS layer without changing anything clients do. A/B testing: split traffic between two variants (50/50, or any ratio) to compare behavior or conversion. Environment migrations: move users from an old system to a new one incrementally by shifting weight, so you can validate the new environment under growing real load and roll back by dialing the weight to zero if something breaks. Blue-green-style shifts at the DNS level: gradually move from blue to green rather than an instant cutover. In each case the appeal is the same — risk control through incremental exposure, with an easy escape hatch (lower the weight) if things go wrong.

The DNS caveats that bite people

Weighted routing is powerful but inherits DNS’s fundamental limitations, and forgetting them is where teams get burned. The big one is caching / TTL: DNS responses are cached by resolvers and clients for the record’s TTL, so when you change the weights, the shift is not instant — clients holding cached results keep going to the old distribution until their cache expires. This means weighted routing gives you approximate, eventually-applied percentages, not precise real-time control, and rollbacks aren’t immediate (you must wait out the TTL). The mitigation is setting low TTLs on records you intend to shift, but low TTLs increase DNS query volume. A second subtlety: weighted routing distributes based on DNS resolutions, not individual requests or users — a single resolver serving many users can send them all one way, so at low traffic the actual split can diverge from the configured weights (the same statistical-validity caveat that affects canaries). For finer, instant, request-level control, application-layer traffic splitting (at a load balancer, service mesh, or ingress) is more precise than DNS weighting — DNS weighted routing is the coarse, infrastructure-level tool, best for gradual shifts where minute-scale propagation is acceptable.

What people get wrong

• Expecting instant changes — DNS caching (TTL) means weight changes and rollbacks propagate gradually, not immediately; set low TTLs on records you’ll shift.
• Assuming exact percentages: routing is per-DNS-resolution, not per-user, so at low traffic the real split can drift from the configured weights.
• Using DNS weighting where request-level precision is needed — for instant, exact splits, do traffic splitting at the load balancer or service mesh instead.

Primary source: Amazon Route 53 routing policies