Amazon Route 53 routing policies determine how authoritative DNS answers are selected when multiple records or endpoints could satisfy a query. They do not turn DNS into a packet-by-packet proxy. Route 53 answers the DNS request, resolvers cache the result according to the TTL, and the client then connects to the returned destination.<\/p>\n
Route 53 policy selection starts with the desired DNS answer, not a promise about every downstream connection. Weighted records support gradual distribution, latency records prefer suitable regional answers, and failover relies on the configured health behavior. For SAA-C03 architecture practice<\/a>, state whether the requirement is rollout, regional response selection or active-passive recovery, then account for resolver caching before interpreting traffic percentages. The policy still operates on DNS records<\/a> and cannot by itself repair an unhealthy application endpoint.<\/p>\n Route 53 evaluates the routing policy when it answers a DNS query. That distinction matters because clients and recursive resolvers can cache answers. A weighted policy of 90\/10 does not guarantee that exactly 90 percent of individual HTTP requests reach one endpoint. It influences the proportion of DNS responses over time, subject to resolver caching, health, record configuration, and client behavior.<\/p>\n Alias records add another AWS-specific dimension. They can point to supported AWS resources such as load balancers and can evaluate target health in supported configurations. Unlike a traditional CNAME, an alias can also be used at the zone apex. The routing policy still controls how Route 53 chooses among records in the same routing set.<\/p>\n When analyzing a scenario, therefore separate the DNS decision from the application connection. Route 53 may select the endpoint, but health checks, load balancers, application retries, and the endpoint’s own availability determine what happens afterward.<\/p>\n Simple routing is appropriate when one resource or one straightforward record set performs the function. Route 53 can return multiple values from a simple record, but it does not associate health checks with the individual records in the same way as multivalue answer routing. Simple is the baseline when no traffic distribution policy is required.<\/p>\n Multivalue answer routing is useful when several healthy resources can answer the same name and Route 53 should return a subset of healthy records. Route 53 can return up to eight healthy records selected from the configured set. This provides DNS-level distribution with health evaluation, but AWS explicitly does not position it as a replacement for a load balancer.<\/p>\n Use a load balancer when the architecture needs connection-level distribution, application health management, listeners, target groups, or Layer 7 features. Use multivalue DNS when independent endpoints can be returned directly and the lighter DNS behavior meets the requirement.<\/p>\n Weighted routing assigns relative weights to records with the same name and type. If two healthy records have weights of 90 and 10, Route 53 is configured to return the first approximately nine times as often as the second over many DNS responses. The weights are relative; they do not need to add up to 100.<\/p>\n This is useful for canary releases, blue\/green migrations, gradual regional shifts, or distributing traffic across endpoints with different capacities. A weight of zero can also be used in specific designs to suppress normal selection while retaining a record for health or transition purposes, but health-check and all-zero-weight behavior should be understood before relying on it.<\/p>\n TTL matters during a cutover. A long TTL means recursive resolvers may keep returning an old answer after weights change. For planned migrations, teams often reduce the TTL ahead of the event, wait for older cached values to age out, perform the shift, and later raise the TTL again if appropriate.<\/p>\n Latency-based routing is designed for applications deployed in multiple AWS Regions. Route 53 uses AWS latency measurements to determine which configured Region is expected to provide the lowest latency for the user and returns the corresponding record.<\/p>\n This is not the same as geographic routing. A user in one country may receive an endpoint in a neighboring or more distant Region if AWS latency data indicates that path is better. It is therefore appropriate when the business requirement is performance rather than legal or content policy based on user location.<\/p>\n Latency records are associated with Regions, and health evaluation can be combined with the design so that unhealthy endpoints are not selected. The application must still be architected for multi-Region data, session, and dependency behavior. DNS can direct the user to a Region; it does not replicate the application’s state.<\/p>\n Failover routing creates primary and secondary records. When the primary is healthy, Route 53 returns it. When health evaluation determines that the primary should not be used, Route 53 can answer with the secondary. This is the classic active-passive DNS pattern.<\/p>\n The quality of the health signal is critical. A health check that only tests whether a TCP port opens may not detect an application that is returning errors. Conversely, a health check that depends on every downstream service can cause unnecessary failover during a limited dependency problem. The health check should represent whether the endpoint can perform the function for which DNS is sending traffic.<\/p>\n DNS caching also means failover is not instantaneous for every client. Existing connections and cached answers can continue using the former endpoint until they reconnect and resolve again. Recovery objectives should include application retry behavior and TTL, not only the Route 53 health-check interval.<\/p>\nTreat routing policy as DNS answer selection<\/h2>\n
Use simple and multivalue routing for straightforward answers<\/h2>\n
Use weighted routing for controlled traffic shifts<\/h2>\n
Use latency routing for multi-Region performance<\/h2>\n
Use failover routing for active-passive recovery<\/h2>\n
Distinguish geolocation from geoproximity routing<\/h2>\n