Cloud / Amazon Route 53 Interview questions

Amazon Route 53 is AWS's managed Domain Name System (DNS) web service, named after TCP/UDP port 53, the port DNS runs on.

It translates human-readable names like example.com into the IP addresses that browsers and applications actually use to connect, serving answers from a global network of authoritative name servers rather than one location.

Route 53 bundles three jobs into a single service: domain registration, DNS routing through several routing policies, and health checking of endpoints so unhealthy resources can be pulled out of DNS answers automatically.

Because it integrates tightly with EC2, S3, CloudFront, and Elastic Load Balancing, it's the default DNS layer for most AWS-hosted applications.

Route 53's capabilities fall into four areas: domain management, authoritative DNS, traffic routing, and availability monitoring.

• Domain registration - buy, transfer, and auto-renew domain names directly through AWS.
• Authoritative DNS hosted zones - answer queries for your domains from a globally distributed name server network.
• Routing policies - simple, weighted, latency-based, failover, geolocation, geoproximity, and multivalue answer, each suited to a different problem.
• Health checks - active endpoint monitoring that can automatically remove unhealthy resources from DNS answers.
• Route 53 Resolver - recursive DNS resolution plus hybrid forwarding between VPCs and on-premises networks.
• DNSSEC and Application Recovery Controller - zone signing for authenticity, and API-driven multi-region failover.

Together these let one service handle everything from purchasing a domain to routing millions of queries per second with sub-minute failover.

A hosted zone is a container that holds all the DNS records for a specific domain or subdomain, such as example.com.

When you create a hosted zone, Route 53 automatically assigns it four authoritative name servers drawn from four different top-level domains, so a single network failure can't take your DNS offline.

Every record you add - A, CNAME, MX, and so on - lives inside a hosted zone, and the zone's name server (NS) records are what you register with your domain's registrar so the internet knows Route 53 is authoritative for that domain.

Route 53 supports two kinds: public hosted zones, which answer queries from the internet, and private hosted zones, which only answer queries from VPCs you associate with them.

Route 53 supports two types of hosted zones, and picking the right one depends on who needs to resolve the domain.

You can even create a public and a private hosted zone with the identical domain name - a pattern called split-view (or split-horizon) DNS - so internal clients get different answers than external ones for the same name.

A record set (Route 53's term for a DNS resource record, or group of records sharing a name and type) defines how the service responds when a specific name is queried.

At minimum it needs a name, a record type such as A or CNAME, a routing policy, a TTL, and one or more values or targets.

When a routing policy other than Simple is used, several record sets can share the same name and type - for example, three weighted A records all answering for api.example.com - and Route 53's answer engine picks which one(s) to return based on the policy and current health check status.

Record sets are the actual working unit inside a hosted zone; the hosted zone is just the folder they live in.

Route 53 supports the standard DNS record types plus its own Alias extension.

Most application teams live almost entirely in A/AAAA, Alias, CNAME, MX, and TXT; the rest show up for specialized needs like DNSSEC or SIP.

An Alias record lets a Route 53 record point directly at an AWS resource - like a CloudFront distribution, an Application Load Balancer, an S3 static website endpoint, or another record in the same hosted zone - instead of pointing at a hard-coded IP address.

Unlike a CNAME, an Alias can be created at the zone apex (the naked domain, e.g. example.com), because Route 53 resolves it internally and returns an A or AAAA record to the client rather than exposing a CNAME chain.

Alias queries to supported AWS targets are free of charge, and Route 53 automatically tracks the target's IP changes, so you never need to update the record when, say, a load balancer's underlying IPs rotate.

{
  "Type": "A",
  "Name": "example.com",
  "AliasTarget": {
    "HostedZoneId": "Z35SXDOTRQ7X7K",
    "DNSName": "my-alb-1234567890.us-east-1.elb.amazonaws.com",
    "EvaluateTargetHealth": true
  }
}

TTL (Time to Live) is the number of seconds a DNS resolver is allowed to cache a record's answer before it must ask Route 53 again.

A low TTL, like 60 seconds, means changes propagate to clients quickly but Route 53 fields more queries; a high TTL, like 86400 seconds (24 hours), reduces query volume and cost but means a bad record takes longer to fix everywhere.

A common practice before a planned migration is to lower the TTL well in advance, make the change once caches expire, then raise the TTL back up afterward.

Alias records are the one exception - Route 53 manages their effective TTL automatically based on the target resource, so you don't set one yourself.

A routing policy is the rule Route 53 uses to decide which value to return when several records share a name - it's what turns a plain DNS zone into a traffic-management tool.

These policies can also be combined hierarchically using Route 53 Traffic Flow, letting one visual policy nest several of the above together.

Simple routing is the default policy: one record set answers for a name, typically pointing at a single resource with no health check logic involved.

If you list several values under one Simple record - for instance, four IP addresses in a single A record - Route 53 returns all of them in a random order, and it's up to the client which one it tries first; Route 53 itself doesn't check whether any of them are healthy.

It's the right choice for a single-server website, a static S3 bucket, or any name where you don't yet need traffic splitting, regional routing, or automated failover.

Weighted routing lets you assign a relative weight, from 0 to 255, to each record sharing a name, and Route 53 returns each one in proportion to its share of the total weight.

If record A has weight 90 and record B has weight 10, roughly 90% of queries get A's answer and 10% get B's - useful for canary releases, blue/green cutovers, or gradually shifting traffic during a database migration.

Setting a record's weight to 0 stops new traffic from going to it without deleting the record, which is handy for temporarily draining a target.

// Two weighted records for api.example.com
{ "Name": "api.example.com", "Type": "A", "SetIdentifier": "v1", "Weight": 90, "TTL": 60, "ResourceRecords": [{"Value": "10.0.1.10"}] }
{ "Name": "api.example.com", "Type": "A", "SetIdentifier": "v2", "Weight": 10, "TTL": 60, "ResourceRecords": [{"Value": "10.0.2.10"}] }

Latency-based routing sends each user to the AWS Region that historically gives the lowest network latency for their resolver's location, using Route 53's own latency measurements between AWS Regions and internet networks.

To use it, you create one latency record per Region pointing at that Region's endpoint, and Route 53 answers each query using the best-performing Region for that particular resolver - not necessarily the geographically nearest one, since network paths don't always follow geography.

It's commonly paired with health checks, so if the lowest-latency Region's resource becomes unhealthy, Route 53 skips it and returns the next-best-performing healthy Region instead.

Failover routing implements a classic active-passive setup: one record is marked Primary and another Secondary, and Route 53 normally answers with the primary.

A health check attached to the primary record is what triggers the switch - once it reports unhealthy, Route 53 starts answering with the secondary instead, and switches back automatically once the primary recovers and stays healthy.

It's the standard pattern for disaster recovery: an active production Region as primary and a warm or pilot-light standby Region as secondary, with no manual DNS change needed during an incident.

Geolocation routing answers a query based on where the requester is physically located - by continent, country, or in the US, by state - rather than on network performance.

Typical uses include serving localized content or pricing, restricting content to comply with licensing agreements, or blocking regions for regulatory reasons.

You can define a default record to catch any location you haven't explicitly mapped, which is important, because without one, users from an unmapped location get no answer at all (NXDOMAIN) rather than falling back to something reasonable.

Geoproximity routing routes traffic based on the geographic location of both your resources and your users, and - unlike geolocation - it lets you shift the boundary between regions using a bias value.

Increasing a resource's bias (0 to 99) expands the geographic area routed to it; decreasing it (0 to -99) shrinks that area, which makes it useful for gradually moving load away from a Region that's approaching capacity, without touching health checks or weights.

Geoproximity routing is only configurable through Route 53 Traffic Flow, not through simple record sets, because it needs the visual policy engine to calculate the resulting proximity boundaries.

Multivalue answer routing lets you attach a health check to each of several records sharing a name, and Route 53 returns up to eight healthy values in the response, chosen randomly each time.

It gives you DNS-level, client-side load spreading with basic failover - the client just tries whichever address it receives - but it's not a substitute for a real load balancer, since Route 53 doesn't do connection-level balancing or session stickiness.

It's a good fit when you want simple redundancy across a handful of endpoints without paying for or managing an Elastic Load Balancer.

A Route 53 health check is an automated, recurring probe that determines whether an endpoint, another health check, or a CloudWatch alarm is in a healthy state.

Checks run from a fleet of global checker locations at an interval you set (standard is every 30 seconds, or every 10 seconds for an extra fee), and an endpoint is marked unhealthy once enough checkers agree it's failing.

Health status feeds directly into DNS answers for Failover, Weighted, Multivalue, and latency-based records - Route 53 filters out unhealthy targets before deciding what to return - and it can also publish CloudWatch metrics and trigger alarms independent of DNS.

Route 53 offers three categories of health check, each answering a different question about "is this healthy?"

Calculated health checks are especially handy for "at least 2 of 3 AZs must be healthy" style logic across a fleet, without wiring that logic into the application itself.

• Single AWS bill - domain charges appear alongside your other AWS usage instead of a separate vendor invoice.
• Automatic hosted zone creation - Route 53 creates a matching public hosted zone the moment registration completes.
• IAM and CloudTrail integration - domain and DNS changes are controlled by IAM policy and logged like any other AWS API call.
• Free WHOIS privacy protection - contact details are masked by default for most TLDs, at no extra cost.
• Auto-renewal - domains renew automatically unless you turn it off, reducing the risk of accidental expiration.
• Wide TLD selection - hundreds of top-level domains are supported through a single console and API.

The trade-off is that Route 53's registrar features (like bulk WHOIS management or advanced transfer tooling) are simpler than some dedicated registrars, so large domain portfolios sometimes stay with a specialist registrar even while using Route 53 for DNS.

Route 53 Resolver is the recursive DNS resolver that's automatically available inside every VPC, reachable at the VPC's base network address plus two (for example, 10.0.0.2 for a 10.0.0.0/16 VPC).

By itself it handles standard lookups and private hosted zone resolution for resources in the VPC, but it can be extended with inbound and outbound endpoints to build hybrid DNS between AWS and on-premises networks, and with DNS Firewall to block queries to known-malicious domains.

It's a separate concept from public hosted zones - Resolver is about how resources inside a VPC ask DNS questions, while hosted zones are about how Route 53 answers questions about a domain.

A private hosted zone holds DNS records that only resolve inside the VPCs you explicitly associate with it - queries from the public internet never see it.

Because it's invisible externally, the domain name doesn't even need to be a real, registered domain; teams often use a made-up internal suffix like .internal or .corp for service discovery between microservices.

A private hosted zone must be associated with at least one VPC in the same account it was created in before it can be associated with VPCs in other accounts, and all associated VPCs must use Route 53 Resolver (the default) for DNS resolution.

The first VPC association happens automatically when you create the private hosted zone - you're required to specify one VPC and Region at creation time.

To add more VPCs in the same account, use the console or the AssociateVPCWithHostedZone API, supplying the hosted zone ID and the target VPC's ID and Region.

aws route53 associate-vpc-with-hosted-zone \
  --hosted-zone-id Z1PA6795UKMFR9 \
  --vpc VPCRegion=us-east-1,VPCId=vpc-0a1b2c3d4e5f6g7h8

Associating a VPC in a different AWS account is a two-step handshake: the zone's owner authorizes the target account and VPC first, then the target account calls the same API to complete the association.

Query logging captures the DNS queries that Route 53 receives for a public hosted zone and streams them to a CloudWatch Logs log group, giving visibility into which names are being queried, from where, and how often.

It's separate from Resolver query logging, which instead captures DNS queries made by resources inside a VPC (covering private hosted zones, public internet lookups from within the VPC, and Resolver rule forwarding) and can deliver to CloudWatch Logs, S3, or Kinesis Data Firehose.

Both are commonly used for security investigations, spotting misconfigured clients, and auditing which internal services actually talk to which domains.

The Start of Authority (SOA) record is created automatically the moment you create a hosted zone, and every zone has exactly one.

It carries zone-level metadata rather than routing information: the primary name server, an administrator contact (formatted as an email address with the @ replaced by a dot), a serial number that increments on changes, and refresh, retry, expire, and minimum TTL values that secondary/caching resolvers use to decide how long to trust a negative (NXDOMAIN) answer.

You rarely edit it by hand in Route 53 - the main field admins sometimes tune is the minimum TTL, which controls how long resolvers cache the fact that a name doesn't exist.

Traffic Flow is a visual policy editor and versioning system that lets you combine several routing policies into one nested decision tree, instead of manually wiring up multiple record sets by hand.

For example, a single traffic policy could first split by geoproximity between two Regions, then within each Region apply weighted routing across a canary and stable deployment, then fall back to a failover secondary if the primary's health check fails - all as one reusable, versioned policy.

A saved policy can be applied as a policy record to one or more hosted zones, and because policies are versioned, you can roll back to a previous version if a change causes problems.

Route 53 Profiles let you define a standard DNS configuration once and apply it consistently across many VPCs, even across AWS accounts, instead of configuring each VPC individually.

A single Profile can bundle private hosted zone associations, Resolver forwarding rules, DNS Firewall rule groups, interface VPC endpoints, and Resolver query logging configuration; updating the Profile propagates the change to every associated VPC automatically.

Profiles can be shared with other accounts using AWS Resource Access Manager (RAM), and as of March 2026 they also support granular IAM permissions, so administrators can restrict which users may associate, disassociate, or update specific resource types within a Profile.

The two share the same record types and mostly the same API, but they differ in who can resolve them and what they're used for.

A single account can hold both a public and a private hosted zone for the identical name, which is the split-view DNS pattern - internal clients see private records, external clients see the public ones, and Route 53 keeps the answers completely separate.

Both point one name at another name, but they resolve differently and have different restrictions.

The practical rule of thumb: use Alias whenever the target is an AWS resource Route 53 can recognize, and reserve CNAME for pointing at names outside AWS or outside your hosted zone's alias-eligible targets.

Choose latency-based routing when the goal is performance: you have the same application deployed in multiple Regions and want each user automatically sent to whichever deployment responds fastest for their network path.

Choose weighted routing instead when the goal is proportion, not performance - you want to control exactly what percentage of traffic hits a specific target regardless of latency, such as sending 5% of production traffic to a canary build or gradually shifting load during a database cutover.

The two aren't mutually exclusive: a common pattern nests weighted records for a canary release inside each Region, with latency-based routing choosing the Region first, via Route 53 Traffic Flow.

Failover relies on a fleet of Route 53 health checkers spread across roughly 15-18 global locations, each independently probing the primary endpoint on the interval you configured.

An endpoint only flips to unhealthy once enough checkers agree it's failing - by default, at least 18% of checker locations must report failure, which prevents one flaky network path from triggering a false failover.

Once the health status changes, the DNS answer engine starts serving the secondary record instead of the primary at the next query; existing cached answers at resolvers only expire once their TTL runs out, so a low TTL on the primary record shortens real-world failover time.

sequenceDiagram
    participant Checkers as Health Checkers
    participant R53 as Route 53
    participant Client
    Checkers->>Primary: probe every N seconds
    Primary-->>Checkers: timeout / error
    Checkers->>R53: report unhealthy (>=18% agree)
    R53->>R53: mark primary unhealthy
    Client->>R53: DNS query
    R53-->>Client: return Secondary record

Reach for weighted routing the moment you need more than one answer behind a name and want control over the split - simple routing has no concept of proportion.

Typical triggers are canary releases (send 5% of traffic to a new version before a full rollout), blue/green cutovers (shift traffic from 100/0 to 0/100 over time), A/B testing two implementations, or validating a database migration with a small slice of live traffic before moving everyone.

If you only ever need one resource behind the name, or several resources that are all equally acceptable with no traffic-split requirement, simple routing (or multivalue, if you also want basic health-based filtering) is simpler to reason about and maintain.

Once the attached health check reports the primary as unhealthy, Route 53 stops including the primary in its DNS answers and starts returning the secondary record instead - no manual DNS change or human intervention is required.

If the secondary also has a health check attached and it too is unhealthy, and there's no additional fallback record, clients get a failed lookup (effectively no usable answer) rather than a silent fallback to the primary, so most designs give the secondary either no health check or a check on a genuinely independent resource.

Route 53 also switches back to the primary automatically as soon as its health check reports healthy again, which is why teams often add a short delay or manual "pin" step in their runbooks before trusting an automatic switch-back during an active incident.

DNSSEC adds cryptographic signatures to DNS responses so a resolver can verify that an answer really came from the zone's authoritative source and wasn't tampered with in transit - protecting against cache poisoning and DNS spoofing attacks.

Enabling it means Route 53 signs your zone's records with a Zone Signing Key, and you publish a Key Signing Key's fingerprint as a DS record with your registrar, forming a chain of trust up to the DNS root.

The trade-off is operational: signed responses are larger (occasionally triggering DNS-over-TCP fallback), and key rotation must be done carefully - if the DS record at the registrar and the keys in Route 53 ever fall out of sync, the entire domain can become unresolvable for validating resolvers.

Start by creating the hosted zone in Route 53, then bring in existing records either by pasting a BIND-format zone file using the console's Import Zone File feature, or by scripting ChangeResourceRecordSets calls from an exported record list.

Before touching anything at the registrar, lower the TTL on the records at the old provider well in advance (ideally a day or more), so caches expire quickly once you cut over.

Verify every record and TTL inside the new Route 53 hosted zone against the old provider, keep the old provider's zone active and untouched during the cutover window, and only then update the domain's NS records at the registrar to point at Route 53's four assigned name servers.

Keep monitoring both providers for a few days; once traffic and query logs confirm resolvers have switched over, decommission the old zone.

This isn't a Route 53 quirk - it's a DNS protocol rule (RFC 1034/1035): if a name has a CNAME record, it can't have any other record type at that same name, but the zone apex (e.g. example.com) is required to hold NS and SOA records.

A CNAME at the apex would conflict directly with those mandatory records, so standard DNS forbids it, regardless of which provider you use.

Route 53's Alias record exists specifically to work around this: it isn't advertised on the wire as a CNAME at all, so it can legally coexist with the apex's NS and SOA records while still pointing at another name or AWS resource.

Two purpose-built endpoint types handle the two directions of hybrid DNS traffic.

An outbound endpoint, paired with a forwarding rule for a specific domain, sends matching queries from inside the VPC out to your on-premises DNS servers over VPN or AWS Direct Connect.

An inbound endpoint does the reverse: it gives on-premises systems a set of IP addresses inside the VPC they can point their own DNS servers at, letting them resolve private hosted zones and other VPC-based names.

sequenceDiagram
    participant OnPrem as On-Prem DNS
    participant Inbound as Resolver Inbound EP
    participant Outbound as Resolver Outbound EP
    participant VPC as VPC Resolver
    OnPrem->>Inbound: query for privatezone.internal
    Inbound->>VPC: resolve via private hosted zone
    VPC-->>OnPrem: answer
    VPC->>Outbound: query for corp.example.com (forwarding rule match)
    Outbound->>OnPrem: forward query
    OnPrem-->>VPC: answer

Standard DNS failover depends on health checks discovering a failure and TTLs expiring before clients see the new answer - both introduce delay and some uncertainty during a real incident.

Application Recovery Controller (ARC) instead gives you readiness checks that continuously verify your standby Region actually has enough capacity and matching configuration to take over, and routing controls - simple on/off switches, exposed over a highly available API, that you or an automated system can flip directly to redirect traffic deterministically.

ARC's safety rules also prevent operator mistakes, like accidentally turning off every Region's routing control at once, which is the kind of error that plain health-check-driven failover has no built-in protection against.

It's the right tool when a business genuinely needs faster, more certain, and better-tested failover than health checks alone can guarantee - critical payment or safety systems, for example - rather than for every workload by default.

They can look similar since both let several records answer for one name, but they solve different problems.

In short: reach for weighted when you need to control a percentage; reach for multivalue when you just want several interchangeable, health-checked answers spread across queries.

First check the TTL that was in effect before your change - if it was high, resolvers that already cached the old answer will keep serving it until that TTL expires, regardless of what Route 53 now says.

Query the authoritative name servers directly with a tool like dig @ns-123.awsdns-45.com example.com to confirm Route 53 itself already has the new answer; if that's correct but public resolvers still show the old value, the delay is caching, not a Route 53 problem.

Also check that the domain's NS delegation at the registrar still exactly matches the hosted zone's four name servers - a stale or partial delegation can make some resolvers query a completely different, outdated zone.

Finally, remember that CDNs, corporate proxies, browsers, and OS-level DNS caches all add their own layers on top of resolver caching, so testing from an incognito window or a different network can rule those out individually.

Choose geolocation when the decision has to be about where the user legally or categorically is - serving different content by country for licensing reasons, complying with data-residency rules, or blocking a specific region entirely. It maps fixed, named locations to fixed answers.

Choose geoproximity when the goal is instead about shifting the balance of traffic between resource locations for performance or capacity reasons, using the bias value to expand or shrink coverage gradually - something geolocation's fixed country/state mapping can't do.

A simple test: if your requirement sounds like "users in France must always see the French version," that's geolocation; if it sounds like "gradually send more European traffic to our new Frankfurt Region," that's geoproximity.

The domain must first be unlocked at its current registrar and, for most TLDs, an authorization (EPP/auth) code obtained from that registrar.

You initiate the transfer in the Route 53 console with that code, and the current registrant approves it via an email confirmation; ICANN-governed gTLDs require this manual approval step for security.

Existing DNS records don't automatically travel with the domain - if you want continuity, you create and populate a matching Route 53 hosted zone (or import a zone file) before or during the transfer window, so the domain isn't left without answers once it cuts over.

The transfer itself typically completes within about five to seven days, and ICANN rules place a 60-day transfer lock on a domain immediately after a transfer or new registration, during which it can't be transferred again.

Alias queries resolved to supported AWS targets - like an Application/Network/Classic Load Balancer, a CloudFront distribution, an S3 static website endpoint, an API Gateway, a VPC endpoint, or another record in the same hosted zone - are free specifically to encourage the AWS-native routing pattern Alias records enable.

Since Route 53 already has to track those targets' health and IP changes internally to serve correct answers, waiving the per-query charge removes any cost incentive to work around Alias in favor of a manually managed CNAME.

Standard DNS queries - including CNAMEs, and Alias records pointing at targets Route 53 can't recognize as AWS-managed - are still billed at the normal per-million-queries rate.

Every health check automatically publishes a HealthCheckStatus metric to CloudWatch, so you can build dashboards and set standard CloudWatch alarms on endpoint health without any extra plumbing.

The integration also runs in the other direction: a CloudWatch alarm health check lets a Route 53 health check mirror the state of any existing alarm, which means you can drive DNS failover off metrics Route 53 itself has no direct visibility into, such as an application-level error rate or a queue depth.

Pairing a CloudWatch alarm with an SNS topic lets you get notified the moment a failover happens, independent of whatever DNS-level automation is already occurring.

Both are Route 53 Resolver components for hybrid DNS, but they carry traffic in opposite directions.

A full hybrid setup typically uses both together: an outbound endpoint so cloud resources can reach corporate DNS, and an inbound endpoint so corporate systems can reach the VPC's private DNS.

The hosted zone's owning account starts by calling CreateVPCAssociationAuthorization, specifying the hosted zone ID and the target account's VPC ID and Region - this grants permission without yet creating the association.

aws route53 create-vpc-association-authorization \
  --hosted-zone-id Z1PA6795UKMFR9 \
  --vpc VPCRegion=us-west-2,VPCId=vpc-0abc123def456789

The target account then completes the link from its own side by calling AssociateVPCWithHostedZone with the same hosted zone and VPC IDs.

Once the association is active, the owning account can optionally call DeleteVPCAssociationAuthorization to close the door on the grant; note that only the owning account can add, edit, or delete records in the zone - associated accounts only get DNS resolution, not write access.

A client's stub resolver first asks its configured recursive resolver (an ISP resolver, a public one like 8.8.8.8, or a VPC's Route 53 Resolver) for app.example.com.

If that answer isn't already cached, the recursive resolver walks the DNS hierarchy: it asks a root server for the .com TLD servers, asks a .com TLD server for example.com's authoritative name servers, and finally sends the actual query to one of Route 53's authoritative servers for that hosted zone.

Route 53 sees that app.example.com has several latency records, one per Region, and identifies the recursive resolver's approximate network location from its source IP - not the end user's location directly, since the resolver is who's actually asking.

It consults its internally maintained latency measurements between AWS Regions and networks worldwide, filters out any Region whose attached health check is currently unhealthy, and returns the record for the lowest-latency healthy Region; that answer is then cached by the recursive resolver for the record's TTL and handed back to the client.

sequenceDiagram
    participant Client
    participant Resolver as Recursive Resolver
    participant Root as Root/TLD Servers
    participant R53 as Route 53 Authoritative NS
    Client->>Resolver: query app.example.com
    Resolver->>Root: find NS for example.com
    Root-->>Resolver: Route 53 name servers
    Resolver->>R53: query app.example.com
    R53->>R53: pick lowest-latency healthy Region
    R53-->>Resolver: Region X record (TTL cached)
    Resolver-->>Client: answer

Behind every health check sits a fleet of geographically distributed checker nodes, each independently probing the target on the configured interval (30 or 10 seconds) using the protocol you chose - HTTP, HTTPS, or TCP - and optionally matching a string in the response body.

Each checker reports its individual pass/fail result back to a central aggregation system; the health check's overall status only flips once the fraction of checkers reporting failure crosses the configured threshold, which defaults to about 18% of checkers, guarding against one checker's local network issue causing a false failover.

That aggregated status is written to Route 53's internal health status store, typically within about 30 seconds of the threshold being crossed, and simultaneously published as a CloudWatch metric.

The DNS answer engine consults this status store at query time, not at probe time - so the moment a record's health check status flips, the very next incoming query for that name gets the updated answer, without needing to wait for anything except the resolver's own TTL-based cache to expire.

flowchart TD
    A["Global checker nodes probe endpoint"] --> B{Failure threshold crossed?}
    B -- No --> A
    B -- Yes --> C["Aggregate status set to Unhealthy"]
    C --> D["CloudWatch metric updated"]
    C --> E["DNS answer engine consults status at query time"]
    E --> F["Next query returns Secondary/backup record"]

Prefer Alias records over CNAMEs wherever the target supports it - Alias removes an entire extra DNS lookup hop since Route 53 resolves the target server-side and answers with A/AAAA directly.

Use latency-based or geoproximity routing (rather than a single static endpoint) so users are automatically sent to whichever healthy Region actually responds fastest for their network path, instead of a fixed, potentially distant, default.

Tune TTLs deliberately: very low TTLs maximize how current an answer is but force more repeated lookups, so pick a TTL that matches how often the underlying answer realistically changes rather than defaulting to a single value everywhere.

Keep health check intervals fast enough (10-second checks, where the added cost is justified) that failover happens quickly, since a slow-to-detect failure adds directly to the latency users experience during an incident, and combine this with CloudFront in front of latency-sensitive HTTP workloads, since CloudFront's own anycast edge network often shaves more real latency off a request than DNS routing alone ever can.

The lifecycle starts with an availability check and purchase - registration periods run from one to ten years depending on the TLD - after which Route 53 automatically applies WHOIS privacy protection (for most TLDs) and a registrar lock to prevent unauthorized transfers.

A matching public hosted zone is created automatically, and auto-renew is enabled by default so the domain doesn't lapse silently; you'll get renewal reminder emails beginning roughly 45-60 days before expiration.

If a domain isn't renewed, most TLDs enter a grace period after expiration - commonly around 30-45 days for .com-style TLDs - where you can still renew it yourself before it moves into a longer, more expensive redemption phase, and finally into pending-delete before it's released back to the public.

flowchart LR
    A["Search & Purchase"] --> B["Privacy protection + registrar lock applied"]
    B --> C["Hosted zone auto-created"]
    C --> D["Active, auto-renew enabled"]
    D -->|Renewed in time| D
    D -->|Missed renewal| E["Grace period"]
    E -->|Renewed| D
    E -->|Not renewed| F["Redemption period, higher fee"]
    F -->|Not redeemed| G["Pending delete, then released publicly"]

Start by defining a recovery group that represents the application, containing one cell per Region, and configure readiness checks inside each cell to continuously confirm that Region has the capacity, configuration, and dependent resources needed to actually serve production traffic - not just that its servers are technically running.

Create a routing control per Region, exposed through ARC's highly available data plane, and wire each one into a Route 53 health check of type "Recovery Control" attached to that Region's DNS record - so flipping the routing control, rather than waiting for an organic health check failure, is what actually changes which Region(s) receive traffic.

Layer weighted or failover routing on top of those records depending on whether the goal is active-active load sharing or active-passive standby, and define safety rules that block invalid states, such as disabling every Region's routing control simultaneously or turning on a Region that failed its readiness check.

Finally, practice the actual failover regularly, either through scheduled game days or ARC's own zonal-shift capability for smaller, faster, AZ-level shifts that don't require a full regional cutover, so the control plane and your runbooks stay validated rather than untested until a real incident forces the first real use.

flowchart TD
    RG["Recovery Group"] --> C1["Cell: Region A"]
    RG --> C2["Cell: Region B"]
    C1 --> RC1["Routing Control A"]
    C2 --> RC2["Routing Control B"]
    RC1 --> HC1["Route 53 Recovery-Control Health Check A"]
    RC2 --> HC2["Route 53 Recovery-Control Health Check B"]
    HC1 --> DNS["Weighted/Failover DNS Records"]
    HC2 --> DNS
    SR["Safety Rules"] -.blocks invalid combos.-> RC1
    SR -.blocks invalid combos.-> RC2