Route 53 is three products sold under one name. It is an authoritative DNS service: you put records in a hosted zone, and AWS name servers answer queries about them. It is a health-checking service: a fleet of checkers around the world probes endpoints you name and feeds the result back into DNS answers. And it is a domain registrar, which is the least interesting of the three and the one this article ignores.

The mental model the docs bury: Route 53 does not route traffic. It chooses which answer to hand out when someone asks a question, and then it is out of the picture. The client caches that answer for the record's TTL. Every "failover" you will ever build with Route 53 is therefore bounded by two clocks you control (how fast the health check notices, and the TTL) and one clock you do not (how well downstream resolvers and clients respect the TTL).

A hosted zone is a container for the records of a domain and its subdomains. A public hosted zone answers the internet. A private hosted zone answers only the VPCs you associate with it. AWS assigns four name servers per zone (a random selection by default, or a reusable delegation set if you create one through the API), and you must point your registrar at them for the zone to matter.

Records carry a name, a type, a TTL and a value. Alias records are the Route 53 extension: they point at certain AWS resources such as CloudFront distributions and S3 website endpoints, resolve to the target's current addresses, and can live at the zone apex where a CNAME cannot. Queries to alias records that map to supported AWS services are not billed.

The part worth your attention is the routing policy, which is the rule used to pick among records that share a name and type:

Two details from the docs matter more than the table. Latency routing "is based entirely on traffic between users and AWS data centers", so if your resource is not in an AWS Region, the real latency can differ significantly from what Route 53 believes. And the measurements change over time, so a user routed to Oregon this week might go to Singapore next week. Latency records pick the lowest measured Region; they do not guarantee the fastest path for a given user on a given day.

Health checks are where the engine lives. You can check an endpoint over HTTP, HTTPS or TCP, optionally with string matching against the first 5,120 bytes of the body. Each checker declares an endpoint healthy or not based on consecutive results (the failure threshold). Then Route 53 aggregates across checkers, and here is the rule people never learn: if more than 18% of health checkers report an endpoint healthy, Route 53 considers it healthy. At 18% or fewer, it is unhealthy. The docs say the value was chosen so that an endpoint is not marked down just because some locations are isolated from it, and that the number might change in a future release. It is deliberately a very lenient definition of "up".

HTTPS health checks do not validate certificates, so an expired certificate will not fail the check. A TCP check must connect within ten seconds; an HTTP check must connect within four seconds and get a 2xx or 3xx within two more.

The honest limit of DNS failover is that you are asking the internet to forget something. With a 60 second TTL, well-behaved resolvers refresh within about a minute after the answer changes, but you will always have a tail of clients that cached longer. If a minute of tail is unacceptable, you want something in the data path, not just in the answer.

From the Route 53 pricing page at time of writing:

The line that surprises people is the optional features. HTTPS counts as one. A basic health check on a non-AWS endpoint is $0.75; add HTTPS and it is $2.75; add string matching and fast interval and it is $6.75, per check, per month. Multiply by the number of endpoints and by the number of checks you create "just in case" and the health check line can exceed the hosted zone and query lines combined. Also note that latency-based queries cost 50% more than standard ones, so a latency policy on a high-traffic name is a real line item.

There is no free tier for Route 53 on that page. Following along below costs well under a dollar if you finish and clean up the same day. I could not find a statement of how partial months are prorated for health checks or whether a hosted zone deleted quickly is billed for a full month, so assume the worst case of about $6 per month (one zone plus two HTTPS health checks on non-AWS endpoints) and delete everything when you are done.

From the Route 53 quotas page:

The API has two separate throttles: request rate and change throughput. A throttled call returns HTTP 400 with the code Throttling and the message Rate exceeded, which is a confusing status for a rate limit. Bulk record changes through UPSERT consume the 1,000-element budget at double rate, so a "batch of 600 upserts" fails validation and you will not understand why until you remember that rule.

Three behaviors cost real incidents. First, Route 53 has a mode of last resort: when every record in a set is unhealthy, the algorithm reverts to treating all of them as healthy, rather than returning nothing. That is a good default, and it also means a misconfigured health check cannot take your whole name offline, but it also means "everything is down" looks like a normal answer from DNS. Second, you cannot change a health check's request interval after you create it; you recreate it. Third, the control plane for public hosted zones lives in one Region. Accelerated recovery, which you enable per public hosted zone before you need it, keeps a copy in US West (Oregon) so you can resume DNS changes within about 60 minutes of AWS detecting that US East (N. Virginia) is impaired. DNS answering itself keeps working during such an event; what you lose is the ability to change records. It does not cover private hosted zones, and during failover you cannot create or delete hosted zones or toggle DNSSEC signing.

You will deploy the same tiny Lambda function in us-east-1 and eu-west-1 behind function URLs, create a public hosted zone, attach one HTTPS health check per endpoint, publish two latency CNAME records, then break us-east-1 and watch Route 53 stop returning it. Lambda itself is covered in the Lambda article of this series.

A caveat in the interest of honesty: the code below follows the current AWS documentation and API references, but I did not execute it against a live account for this issue. Read the output of each step, and treat the timings as estimates from the documented interval and threshold, not as measurements.

A function URL with auth type NONE needs a resource-based policy with two statements, one for lambda:InvokeFunctionUrl and one for lambda:InvokeFunction, and AWS recommends the lambda:InvokedViaFunctionUrl condition on the second. Without them callers get 403 even though the auth type is NONE. The Route 53 checkers are anonymous callers, so this is the right setup for the lab, and it is public by design, which is why cleanup matters.

Check the runtime string against the currently supported list before you run this; runtimes are retired on a schedule. Verify each endpoint answers: curl https://<host>/ should print "hello from us-east-1" and "hello from eu-west-1" respectively.

The health check needs the bare hostname (no scheme, no path), port 443, type HTTPS. A request interval of 30 seconds with a failure threshold of 3 means a single checker needs roughly 90 seconds of consecutive failures to flip, and the aggregate then follows the 18% rule. Fast (10 second) intervals cost extra and cannot be changed after creation.

Each Region gets one CNAME on the same name, with a SetIdentifier, a Region, and its own HealthCheckId. A TTL of 60 seconds is a deliberate trade: shorter means faster failover for compliant resolvers and more billed queries.

TestDNSAnswer simulates a query against a public hosted zone and returns what Route 53 would answer. With no resolver IP it uses a resolver in us-east-1, so the expected answer is the us-east-1 host. It does not support private hosted zones.

Expect NOERROR and the us-east-1 hostname. Health checkers need a minute or two to report; a brand new health check is treated as healthy until there is enough data. To see the other direction, pass ResolverIP and Edns0ClientSubnetIP (an address you know is in Europe) to the same call; the client subnet only takes effect if that resolver supports EDNS0, and I have not verified which public resolver the simulator honors, so treat that as an experiment.

Setting reserved concurrency to zero deactivates a function URL: every request is throttled and returns HTTP 429, which fails the checker's 2xx or 3xx requirement.

On the documented numbers the flip should arrive after roughly three consecutive failed 30-second probes from enough checkers to push the healthy share to 18% or below, so expect it in the range of one and a half to a few minutes. When it flips, the answer changes to the eu-west-1 host. Because TTL is 60 seconds, real clients converge about a minute after that, give or take the stubborn tail.

Now the mode of last resort. Throttle eu-west-1 too, wait for both checks to go unhealthy, and call ask() again. You will still get an answer, not an error, because when all records are unhealthy Route 53 treats all of them as healthy. That is the behavior to remember at 3 a.m.: a DNS answer is not evidence that anything is up.

Restore with lam.delete_function_concurrency(FunctionName=FN) in each Region.

Order matters: records first, then health checks, then the zone, then the Lambda resources. A hosted zone cannot be deleted while it still holds anything other than its default NS and SOA records.

Deleting a function removes its resource-based policy with it; the docs warn that deleting only the URL does not remove a NONE policy, which is why the function itself is deleted here. Confirm in the Route 53 console that no hosted zones or health checks remain, since those are the two billed items that outlive a forgotten script.