Route53

Configuring Failover Routing Across Regions with Route 53

Overview

Domain expertise for active-passive failover of an application running in two AWS Regions for disaster recovery (DR): sending traffic to a primary endpoint by default, monitoring its health, and shifting to a secondary when the primary is unhealthy. Spans the failover records and the health check that drives the decision. Covers the active-active alternative, the control plane dependency trap, TTL and transition delay, internal-target health checks, and the static stability pattern.

Does not cover CloudFront-specific failover or general record creation. Those are separate skills.

Execute commands using the AWS MCP server when connected (sandboxed execution, audit logging, observability). Fall back to the AWS CLI otherwise.

Table of Contents

• Overview

• Workflow

• Decision: active-passive vs active-active

• Decision: how to health-check the failover target

• Decision: health-check-driven vs static stability

• Troubleshooting

• Procedure

• Additional Resources

Workflow

To build region-level failover, follow the procedure exactly. See the Procedure section below.

The procedure covers:

• Choosing active-passive vs active-active

• Creating the health check on the primary and the primary/secondary failover records

• Handling internal targets with ETH (alias) or a CloudWatch alarm-based health check (private endpoint)

• Setting TTL against the recovery target

• Surfacing the console links to verify

Decision: active-passive vs active-active

Decision: how to health-check the failover target

The PRIMARY failover record needs a health signal, or Route 53 always treats it as healthy and never fails over. Pick the mechanism by how the target is reached:

Decision: health-check-driven vs static stability

Constraints:

• You MUST set the record TTL deliberately. DNS failover transition delay is the record TTL plus the health check evaluation time; a long TTL makes traffic move slowly during a failover

• You MUST NOT rely on a standard (public-probe) health check for a private target, because Route 53's public health checkers cannot reach it. Use ETH when the target is an alias to a supported AWS resource; use a CloudWatch alarm-based health check when the private target is reached by a standard record and ETH does not apply

• For the most critical workloads, you SHOULD offer the static stability pattern: pre-create both records and shift traffic by flipping health check state (for example, an inverted health check the customer controls) rather than editing DNS during the event. A DR runbook that creates health checks or updates records during a disaster reintroduces the control plane dependency the customer is trying to remove. The data plane (resolution, health checks, failover) carries the 100% availability target; the control plane (creating checks, updating records) does not

• You SHOULD mention Route 53 Application Recovery Controller (ARC) Region Switch when the customer wants a managed multi-Region failover path rather than building it by hand

Troubleshooting

Traffic moves slowly during failover

A long record TTL adds to the transition delay. Lower the TTL deliberately based on the recovery target.

Health check unhealthy for a healthy internal target

Public health checkers cannot reach a private resource. Use ETH when the target is an alias to a supported AWS resource; use a CloudWatch alarm-based health check for a private endpoint behind a standard record.

Failover did not happen during a real outage

The runbook depended on a control plane change in the failed Region. Pre-create records and checks; use static stability for critical paths.

Both Regions serving when only one should

Active-active was built where active-passive was intended. Use the failover routing policy.

Procedure

Overview

This procedure configures active-passive failover for an application in two AWS Regions. It creates a health check on the primary endpoint and primary/secondary failover records, handles internal targets with ETH or a CloudWatch alarm-based health check, sets the TTL against the recovery target, and surfaces the console links to verify.

Parameters

• hosted_zone_id (required): The hosted zone ID for the failover records.

• record_name (required): The DNS name to fail over (e.g., app.example.com).

• primary_target (required): The primary Region's endpoint.

• secondary_target (required): The secondary Region's endpoint.

• ttl (optional, default: 60): TTL in seconds for the failover records. Set against the recovery target.

• target_reachability (optional, default: public): How the failover targets are reached, which selects the health-check mechanism:

  • public — publicly reachable endpoint → standard endpoint health check

  • alias_to_aws_resource — alias to a supported AWS resource (e.g., ALB/NLB, whether internet-facing or internal) whose health Route 53 evaluates directly → ETH (free, no probe)

  • internal_endpoint — private endpoint behind a standard record (e.g., private EC2/IP), where ETH does not apply → CloudWatch alarm-based health check

• alarm_name / alarm_region (required when target_reachability is internal_endpoint): The CloudWatch alarm that reflects the primary endpoint's health, and its Region.

Constraints for parameter acquisition:

• You MUST ask for all required parameters upfront in a single prompt

• You MUST confirm the primary and secondary targets and the hosted zone before writing

• You MUST set the TTL deliberately against the customer's recovery target

Steps

1. Verify dependencies

Constraints:

• You MUST confirm credentials with aws sts get-caller-identity

• You MUST REQUIRE provisioning credentials through ephemeral mechanisms (IAM roles via instance profiles, SSO/IAM Identity Center session credentials, or aws sts assume-role) rather than long-lived IAM user access keys.

• You MUST enable Route 53 query logging to an encrypted destination where applicable, ensure CloudTrail is enabled to audit changes, and set CloudWatch alarms on health-check status where health checks are involved.

2. Choose active-passive vs active-active

Constraints:

• You MUST confirm whether the customer wants a standby secondary (active-passive, failover policy) or both Regions serving (active-active, any policy with unhealthy records excluded)

3. Create the health check on the primary

Constraints:

• If target_reachability is public, create a standard endpoint health check. Match the target field to {primary_target}: use "IPAddress": "{primary_target}" when the target is an IP, use "FullyQualifiedDomainName": "{primary_target}" when it is a hostname, or set both together to probe a specific IP with a Host header. Passing a dotted-decimal IP to FullyQualifiedDomainName is wrong because Route 53 then tries to DNS-resolve it:

  Copy

  # When primary_target is an IP:
  aws route53 create-health-check --caller-reference {ref} --health-check-config '{
    "Type": "HTTPS", "IPAddress": "{primary_target}", "Port": 443,
    "ResourcePath": "/health", "RequestInterval": 30, "FailureThreshold": 3
  }'
  
  # When primary_target is a hostname:
  aws route53 create-health-check --caller-reference {ref} --health-check-config '{
    "Type": "HTTPS", "FullyQualifiedDomainName": "{primary_target}", "Port": 443,
    "ResourcePath": "/health", "RequestInterval": 30, "FailureThreshold": 3
  }'

• If target_reachability is alias_to_aws_resource, do NOT create a standard health check against the target. Use ETH on the alias record instead (Step 4) — Route 53 evaluates the supported resource's own health directly, so a paid standard health check is unnecessary whether the resource is internet-facing or internal

• If target_reachability is internal_endpoint, the target is private and not an alias to a supported resource, so ETH does not apply. Create a CloudWatch alarm-based health check that watches a metric reflecting the endpoint's health, then attach it to the primary record in Step 4:

  Copy

  aws route53 create-health-check --caller-reference {ref} --health-check-config '{
    "Type": "CLOUDWATCH_METRIC",
    "AlarmIdentifier": {"Region": "{alarm_region}", "Name": "{alarm_name}"},
    "InsufficientDataHealthStatus": "Unhealthy"
  }'

  Set "Unhealthy" because this check drives failover: a data gap should force failover to the secondary rather than preserve a stale state on the primary.

4. Create the failover records

Constraints:

• You MUST create a primary failover record and a secondary failover record with the same name and type:

  Copy

  aws route53 change-resource-record-sets --hosted-zone-id {hosted_zone_id} --change-batch '{
    "Changes": [{
      "Action": "UPSERT",
      "ResourceRecordSet": {
        "Name": "{record_name}", "Type": "A",
        "SetIdentifier": "primary", "Failover": "PRIMARY",
        "TTL": {ttl}, "ResourceRecords": [{"Value": "{primary_target}"}],
        "HealthCheckId": "{health_check_id}"
      }
    }]
  }'

• For an alias_to_aws_resource target, set AliasTarget with EvaluateTargetHealth: true instead of a HealthCheckId. For public and internal_endpoint targets, attach the health check created in Step 3 via HealthCheckId

• Repeat for the secondary with SetIdentifier: secondary and Failover: SECONDARY

5. Offer static stability for critical workloads

Constraints:

• You SHOULD offer the static stability pattern when the workload cannot tolerate a control plane dependency in the failover path: pre-create both records and shift traffic by flipping a health check state the customer controls, with no DNS edit during the event

• You SHOULD mention Route 53 ARC Region Switch as the managed alternative

6. Verify and surface the console links

Constraints:

• You MUST verify the records resolve to the primary while healthy, and that an unhealthy primary shifts traffic to the secondary within the expected window (TTL plus health check evaluation)

• You MUST present the console links, filling {hostedZoneId} and {healthCheckId}:

  • Records view:

    Copy

    https://console.aws.amazon.com/route53/v2/hostedzones#ListRecordSets/{hostedZoneId}

  • Health check details:

    Copy

    https://console.aws.amazon.com/route53/v2/healthchecks/home#/details/{healthCheckId}

Example

Example input

{
  "hosted_zone_id": "Z1234567890ABC",
  "record_name": "app.example.com",
  "primary_target": "192.0.2.1",
  "secondary_target": "198.51.100.1",
  "ttl": 60
}

Example output

Created failover records for app.example.com (primary 192.0.2.1, secondary 198.51.100.1)
with health check on the primary.
Verify in the console:
https://console.aws.amazon.com/route53/v2/hostedzones#ListRecordSets/Z1234567890ABC
https://console.aws.amazon.com/route53/v2/healthchecks/home#/details/abcd1234-...

Troubleshooting

Traffic moves slowly during failover

Long record TTL adds to the transition delay. Lower the TTL against the recovery target (Step 4).

Health check unhealthy for a healthy internal target

Public health checkers cannot reach a private resource. Use ETH for an alias to a supported resource, or a CloudWatch alarm-based health check for a private endpoint (Step 3/4).

Failover did not happen during a real outage

The runbook depended on a control plane change in the failed Region. Pre-create records and checks; use static stability (Step 5).

Both Regions serving when only one should

Active-active built where active-passive was intended. Use the failover routing policy (Step 2).

Security Considerations

• You SHOULD use least-privilege IAM credentials provisioned through ephemeral mechanisms (IAM roles, SSO/IAM Identity Center session credentials, or aws sts assume-role) rather than long-lived IAM user access keys, and prefer read-only credentials for inspection steps. Grant only the specific actions this procedure needs — route53:CreateHealthCheck, route53:ChangeResourceRecordSets, and route53:GetChange to create the health check and failover records and confirm propagation, plus route53:ListResourceRecordSets, route53:GetHostedZone, and route53:GetHealthCheckStatus for inspection — rather than route53:* or broader service:* wildcards.

• You MUST enable Route 53 query logging to an encrypted destination (KMS on CloudWatch Logs, SSE-S3/SSE-KMS on S3, or server-side encryption on a Data Firehose stream) and ensure CloudTrail is enabled to audit record and health-check changes.

• You SHOULD set a CloudWatch alarm on the primary health check's status metric with an SNS notification, so the team is alerted when a failover triggers rather than discovering it later. A failover configuration without monitoring leaves the team unaware that failover has occurred.

• You MUST enable KMS server-side encryption on the SNS topic used for health-check alarm notifications, because notification content can reveal endpoint and infrastructure topology.

• You MUST confirm the SNS topic's subscription list is limited to authorized personnel.

• You MUST keep the failover path free of control plane dependencies for the most critical workloads (static stability), so a Regional event does not also disable the mechanism that moves traffic away from it.

Additional Resources

• Active-active and active-passive failover (Route 53 Developer Guide)

• Creating Disaster Recovery Mechanisms Using Amazon Route 53 (Networking & Content Delivery blog)

• Manual Failover and Failback Strategy with Amazon Route 53 (Networking & Content Delivery blog)