Fail over the layer that actually failed

Learning objective

Choose Route 53 health-check DNS failover for regional API endpoints versus application-level model fallback. Match the recovery mechanism to the unavailable dependency instead of treating all failures as a routing problem.

Core idea

DNS failover selects an application endpoint for clients resolving a name. Application model fallback selects a model path while handling a request. They operate at different boundaries and observe different signals. Route 53 cannot interpret a model’s answer quality unless your application turns that condition into a suitable health signal.

Use regional DNS failover when the application’s regional API cannot provide its promised service and an eligible secondary is ready. Use bounded application fallback when the API remains healthy but one model path fails. Compose both only with an explicit policy that prevents small dependency incidents from repeatedly moving all users between Regions.

How it works

Configure the regional endpoint pair

Route 53 failover routing uses primary and secondary records with the same name and record type. Associate health evaluation with the endpoints the records represent. A primary record supplies the normal route; the secondary is the alternative route when the primary is unhealthy under the configured evaluation.

For non-alias records, associate the appropriate health check. For supported alias targets, EvaluateTargetHealth can use the target’s health behavior. Check the target-specific support rather than assuming every AWS resource supports that field in the same way. A DNS record pointing at a resource does not by itself establish meaningful readiness.

Route 53 health checks can monitor endpoints, combine other health checks, or monitor the data stream associated with a supported CloudWatch alarm. For a regional API, expose a bounded readiness signal that reflects the service you promise. Avoid a check that merely proves a web process can return a static success page while all required dependencies are unavailable.

For HTTP or HTTPS checks, enable String matching and set Search string to a marker your readiness endpoint returns only when the service contract is satisfied. Route 53 requires the whole marker within the first 5,120 bytes of the response body. This makes the probe test explicit readiness content rather than a generic successful status.

Do not make every health probe perform an expensive full generation request. Define the readiness contract and complement it with controlled synthetic task checks. Your application can publish a measured readiness signal to CloudWatch; the Route 53 alarm-based health-check mechanism then evaluates the supported alarm’s underlying metric stream.

Understand the health decision

For a pair with health checks on both records, Route 53 returns the primary when it is healthy. It returns the secondary when the primary is unhealthy and the secondary is healthy. If both are unhealthy, the documented failover behavior returns the primary. DNS failover is therefore not a fail-closed policy that guarantees no request reaches an unhealthy endpoint.

If the secondary has no health check, Route 53 can return it when the primary is unhealthy even if the secondary cannot actually serve traffic. A configured backup record is not evidence of a functioning backup deployment. Test the secondary’s authorization, model path, artifacts, and capacity before relying on it.

CloudWatch-alarm health checks have documented restrictions. They use supported standard-resolution metrics and statistics, not arbitrary alarm constructs. Route 53 also does not wait for the CloudWatch alarm itself to enter ALARM; it evaluates the same data stream and criteria. Account for that mechanism when interpreting health transitions.

Budget detection and DNS caching

For endpoint checks, Request interval is 30 seconds, or 10 seconds with the Fast option at an additional charge; you cannot change it after creating the check. Failure threshold sets the number of consecutive passing or failing checks required to change health status. Tune these controls for detection and recovery sensitivity, separately from DNS caching. They are inputs to health evaluation, not a guarantee that failover completes after their simple product.

The time-to-live (TTL) controls how long recursive resolvers cache a record’s answer. A longer TTL reduces DNS query frequency but delays adoption of changed answers. Choose it from the recovery objective rather than optimizing DNS cost without regard to failure behavior.

The recovery interval includes health detection, resolver caching, and client reconnection behavior. DNS changes influence subsequent resolutions; they do not redirect an already established connection or recover a model response in progress. Measure the client-visible recovery path instead of equating TTL with the entire recovery time.

Test primary failure, secondary failure, both unhealthy, recovery of the primary, and stale cached answers. Include the clients you actually support. A command that resolves the name once from a fresh environment can miss the behavior of a long-lived client still using its previous endpoint.

Keep the secondary eligible for the same processing policy. Moving an API to another Region can move retrieval, model calls, and logging even if the DNS name stays constant. Check the approved processing envelope from 1.2.4 and the replicated-asset readiness from 1.2.11.

Keep model failures within the request boundary

If a regional API is available but its preferred model is throttled or unavailable, the application can execute the bounded plan from 1.2.5. It sees the structured model error, remaining deadline, and task compatibility. DNS has none of that request-specific context.

A model fallback should not bypass a denied request or a guardrail intervention. It also should not silently turn a location-constrained request into an unrestricted one. The application must preserve those boundaries independently of where DNS sent the client.

Define when model degradation makes the whole regional API unhealthy. If an approved fallback still meets the published task contract, moving every request to another Region can be unnecessary. If no regional path can serve the required task and the secondary can, a readiness policy can justify endpoint failover.

Key distinctions and trade-offs

Endpoint failover versus model fallback: Endpoint failover changes which regional API clients reach. Model fallback changes an inference target within a request.

DNS answer versus active connection: Returning a secondary record guides a new resolution. It does not transfer existing work to another server.

Health detection versus readiness: A probe measures what you configured. Readiness means the complete service can meet its contract under the expected demand.

Lower TTLs can reduce one component of recovery delay while increasing DNS query frequency. Broader readiness checks can detect real dependency failures while risking regional movement for a fault already handled locally. Choose both from the measured recovery contract.

Architecture / decision scenario

A two-Region drafting API has a primary and secondary Route 53 failover record. The secondary is deployed with its own approved model routes and readable regional assets. Both endpoints expose an explicit readiness contract.

One model in the primary Region becomes unavailable, but the application’s approved fallback still meets the task gate. The API stays ready, and the request router handles the incident locally. A later regional API failure makes the primary endpoint unhealthy, so new DNS resolutions select the ready secondary.

Clients with cached primary answers can still experience interruption until they reconnect through a fresh resolution. The recovery test includes that delay and verifies both-unhealthy behavior. The team reports measured client recovery, not a promise that the DNS record instantly moves every request.

Common exam traps

• Using DNS routing to replace a model within an in-flight request.
• Treating a static success page as complete API readiness.
• Assuming TTL equals the whole recovery time.
• Expecting both-unhealthy failover to refuse all DNS answers.
• Omitting secondary health and capacity verification.
• Moving all traffic for a model failure already handled safely by the application.

What to remember

• Use Route 53 for regional endpoint selection and application code for model selection.
• Define health signals around the service contract.
• Inspect alias-health support and both-unhealthy behavior.
• Include detection, caching, and client reconnection in recovery measurements.
• Validate the secondary’s complete dependency and location envelope.

Knowledge check

References

• AWS, Configuring DNS failover
• AWS, Types of Amazon Route 53 health checks
• AWS, How Amazon Route 53 chooses records when health checking is configured
• AWS, Values specific for failover records
• AWS, Values that you specify when you create or update health checks