Weighted routing assigns each destination a relative value and uses those values to influence destination selection. With weights of 80 and 20, two eligible destinations receive approximately 80% and 20% of selections over a sufficiently large sample. The values normally represent ratios rather than mandatory percentages: weights of 4 and 1 express the same intended split. The configured ratio is a statistical distribution, not a guarantee for every group of requests.
In DNS-based implementations, an authoritative DNS service selects a record or answer according to the applicable weights. A recursive resolver can cache that answer and return it to many clients until its time to live, or TTL, expires. Consequently, an 80:20 DNS selection ratio does not guarantee an 80:20 distribution of application requests, users, connections, or bytes. A resolver serving a large enterprise might direct thousands of users to one destination, while another resolver represents only a few clients.
A practical use is migrating an application from an on-premises environment to the cloud. Engineers can initially assign most DNS weight to the existing endpoint and a small weight to the cloud endpoint, then increase the cloud share after checking errors, latency, and capacity. Both destinations must serve the same application hostname correctly, including certificates, authentication, and required data access. DNS does not make an endpoint reachable: private addresses still require suitable VPN, private connectivity, routing, and security controls.
Hybrid and multi-account DNS architectures also require careful placement of the routing policy. Public delegation determines which authoritative zone answers an internet-facing name. Private hosted-zone associations and DNS forwarding rules determine which namespace a workload can resolve. Weighted records must exist in the authoritative view actually used by the clients. Creating identically named zones in several accounts does not combine their records into one weighted pool, and forwarding a query does not itself perform weighted traffic selection.
Weighting differs from latency-based and geographic routing. Latency-based selection aims to choose a destination expected to provide lower network latency, while geographic policies select according to an inferred client or resolver location. Weighting expresses an operator-controlled allocation and does not automatically choose the nearest destination or adapt to backend utilization. Where supported, hierarchical policies can first select a geographic or latency-based branch and then apply weights within that branch.
Health evaluation is a separate consideration. Some implementations remove unhealthy destinations from selection and redistribute traffic across those still eligible. Others require explicit health-check configuration, and all-unhealthy behavior can differ substantially. For private hybrid endpoints, health signals may need to come from monitoring inside the reachable network rather than an internet-originated probe. A weight of zero also has implementation-specific semantics; it should not be treated as a universal guarantee that an endpoint can never receive traffic.
At the application layer, a proxy or load balancer can weight requests among backend groups, providing finer-grained control than DNS. However, session affinity, persistent connections, retries, and application behavior can still skew observed distribution. DNS and application-layer weights can also compound: if DNS directs approximately 20% of traffic to a region and a regional proxy directs 10% to a new version, the intended overall share is approximately 2%, subject to both layers' behavior.
Operate weighted routing as a measured change rather than a one-time configuration. Establish destination-specific metrics, confirm spare capacity, lower DNS TTLs sufficiently before a planned migration when appropriate, and increase exposure incrementally. Lower TTLs improve responsiveness but increase DNS query volume and do not eliminate client caching or existing connections. Rollback therefore requires both a policy change and time for cached answers and active sessions to stop influencing traffic.
Amazon Route 53