Route 53 — DVA-C02 Mastery Guide

• Sources: course chapter 04 (Amazon Route 53). The course serves as the syllabus only; all wording here is original.
• Written 2026-10-12; values checked against AWS docs on 2026-10-12 (Route 53 Developer Guide, API Reference and document history, Route 53 pricing, SLA and FAQ pages, AWS What's New, the AWS CLI reference, plus the ELB, CloudFormation and AWS SDK for Java documentation). The marker ⚠️ Changed: <current>. Older material may say <old>. flags a value or behaviour that differs from the course or older practice tests: learn the current value. ⚠️ unverified marks something AWS documentation did not confirm: don't build an exam answer on it. Every change is listed in Changed vs older material.
• Tier 4 (skim: developer-facing features only), bank target 12 questions. Domains: Deployment (primary), Troubleshooting and Optimization.
• How to use it: /explain <topic> teaches from these sections (concept → exam facts → developer angle → traps → 3 check questions); /quiz route53 asks bank questions whose source_note links point at the ## N. headings below; /drill route53 fires short recall prompts from notes/route53-cheat-sheet.md. Suggested loop: read a section and answer its practice questions before opening the answers → /explain what is still unclear → /quiz route53 → /drill route53.
• Owned by other modules (one-line pointers only here): ALB/NLB listeners, target groups and target health → notes/ec2-mastery-guide.md §8; CloudFront behaviors, caching and origins → notes/cloudfront-guide.md §1–§3; API Gateway custom domain names and their certificates → notes/api-gateway-guide.md §2; Elastic Beanstalk URLs, swap-URL blue/green and traffic splitting → notes/beanstalk-guide.md §2, §7–§8; VPC DNS attributes and VPC endpoints → notes/vpc-guide.md §3; Lambda alias weights → notes/lambda-guide.md §7; CodeDeploy blue/green → notes/cicd-guide.md §8; CloudWatch alarms → notes/monitoring-guide.md §5; S3 static website hosting → notes/s3-guide.md §9; ACM certificates and DNS validation → notes/ec2-mastery-guide.md §9 and notes/other-services-guide.md §14; SDK retries and backoff → notes/cli-sdk-policies-guide.md §9.

How Route 53 appears on DVA-C02

DVA-C02 doesn't ask you to run DNS servers or design networks. Route 53 shows up as the switch that points a name at what you deployed, as a release tool, and as the first suspect when a name answers with the wrong place:

• Pointing names at deployed endpoints: alias records for ALBs, CloudFront, API Gateway custom domains, Beanstalk environments and S3 websites; the zone apex rule; which record type and target ID to use.
• Releasing safely: weighted records that send a slice of users to a new stack, shift them step by step and roll back; TTL decides how fast any of it takes effect.
• Resilience: health checks, failover records, latency records across Regions, and alarm-based checks for resources that only have private IPs.
• Troubleshooting: stale answers (TTL, negative caching, client DNS caches), health checks failing because of firewalls, SNI or status codes, and API errors such as InvalidChangeBatch, PriorRequestNotComplete and Throttling.

Typical question shapes: "point example.com at an ALB"; "send 10 % of users to the new version"; "show a maintenance page from S3 when the site is down"; "route each user to the fastest Region"; "serve the German catalog to users in Germany"; "health-check an instance in a private subnet"; "which TWO steps make clients pick up a new IP within minutes?".

Deciding constraints: zone apex (alias only), lowest cost (alias queries to AWS resources are free), fastest cutover (a low TTL set in advance), least operational overhead (health-check-driven failover instead of scripts that edit records), least privilege (record-level IAM conditions on route53:ChangeResourceRecordSets).

Domain map: Deployment → §2, §5 and the change API in §1 · Troubleshooting and Optimization → §1 (errors, negative caching), §2 (TTL), §3 (testing answers), §4.

Out of scope: operating DNS servers, Resolver endpoints and hybrid DNS architecture, domain registration and transfer procedures, DNSSEC operations.

1. Hosted zones and record types

Concept

• A resolver (your ISP's, or the VPC Resolver inside a VPC) walks from the root servers to the TLD servers to the domain's authoritative name servers and caches every answer for its TTL. Route 53 sells three separate things: registration, authoritative DNS (hosted zones) and health checking. Where the name was bought doesn't matter: once the registrar lists a Route 53 zone's four name servers, that zone answers for the domain.
• A hosted zone is the record container for one domain name and everything below it. Public zones answer the internet; private zones answer only inside their associated VPCs; a public and a private zone with the same name give split-view DNS. A record = name + type + value(s) + TTL + routing policy (simple unless you pick another one, §3).

Exam facts

• A new public zone comes with an NS record (4 name servers) and an SOA record; leave both alone. Delegate a subdomain to its own zone with an NS record in the parent zone.
• Types to know: A (IPv4), AAAA (IPv6), CNAME (name to another name; ACM DNS validation records are CNAMEs → notes/ec2-mastery-guide.md §9), NS, SOA, MX (priority + mail host), TXT (domain verification, SPF policies; the SPF type is no longer recommended), CAA (CAs allowed to issue certificates), SRV, PTR, NAPTR, DS (DNSSEC delegation). ⚠️ Changed: 17 types; HTTPS, SVCB, SSHFP and TLSA were added on 2024-10-30 (SSHFP and TLSA in public zones only). Older material may say the list ends with CAA, DS, MX, NAPTR, PTR, SOA, SPF, SRV and TXT.
• A CNAME can't sit at the zone apex, and a name that owns a CNAME can't own any other record.
• Private zones need the VPC attributes enableDnsHostnames and enableDnsSupport set to true. If a private zone matches the query name but has no record of that name and type, the VPC Resolver returns NXDOMAIN instead of asking public DNS. A zone can't be converted between public and private: create a new zone and its records.
• ChangeResourceRecordSets applies a batch of CREATE, DELETE and UPSERT changes atomically (all or nothing). The change is PENDING until every Route 53 name server has it, then INSYNC, generally within 60 s. Negative caching: NXDOMAIN and NODATA answers are cached for the lower of the SOA minimum TTL (default 86,400 s) and the SOA record's own TTL (default 900 s), so a name queried just before you created it can look missing for about 15 minutes.
• Cost, quotas, scope: $0.50 per hosted zone per month for the first 25 zones, $0.10 for each additional one (a zone deleted within 12 h of creation isn't charged); 500 hosted zones per account and 10,000 records per zone, both adjustable. Global service: CloudTrail events appear under US East (N. Virginia), and public DNS query logs must go to a CloudWatch Logs group in us-east-1. SLA: credits for any month in which a zone's DNS answers fall below 100 % uptime (GovCloud: 99.995 %), API and console excluded. ⚠️ unverified: the course's claim that it is the only AWS service with a 100 % SLA.

Developer angle

Create a zone, apply one atomic batch (change.json below: UPSERT creates or replaces; a DELETE must repeat every value of the record) and wait for INSYNC:

aws route53 create-hosted-zone --name example.com --caller-reference "zone-$(date +%s)"
CHANGE_ID=$(aws route53 change-resource-record-sets --hosted-zone-id Z0123456789ABCDEFGHIJ \
  --change-batch file://change.json --query 'ChangeInfo.Id' --output text)
aws route53 wait resource-record-sets-changed --id "$CHANGE_ID"   # polls GetChange every 30 s until INSYNC

{"Comment": "move api, add a verification token",
 "Changes": [
  {"Action": "UPSERT", "ResourceRecordSet": {"Name": "api.example.com", "Type": "A", "TTL": 60, "ResourceRecords": [{"Value": "192.0.2.10"}]}},
  {"Action": "CREATE", "ResourceRecordSet": {"Name": "_verify.example.com", "Type": "TXT", "TTL": 300, "ResourceRecords": [{"Value": "\"token-123\""}]}}]}

• Least privilege: allow route53:ChangeResourceRecordSets on arn:aws:route53:::hostedzone/<zone-id> and narrow it with ForAllValues:StringEquals on route53:ChangeResourceRecordSetsNormalizedRecordNames (lowercase, no trailing dot), route53:ChangeResourceRecordSetsRecordTypes and route53:ChangeResourceRecordSetsActions (values uppercase). Route 53 supports no tag-based condition keys. CreateHostedZone callers also need ec2:DescribeVpcs.
• Errors: InvalidChangeBatch (400: the batch fails validation and the response carries one message per bad change, for example a DELETE whose values don't match the record or the same record deleted twice in one batch); PriorRequestNotComplete (400: the zone is still processing an earlier request, retry after growing waits); NoSuchHostedZone (404); HostedZoneNotEmpty (400: deleting a zone that still holds records other than NS and SOA, or still has DNSSEC signing on).
• Throttled calls get HTTP 400 Throttling / Rate exceeded. ⚠️ Changed: per-account token buckets of 50 requests (burst) refilled at 10 per second, also per API action (CreateHealthCheck: one every 2 s), plus a change-throughput bucket of 1,500 record changes refilled at 100 per second (UPSERT costs 2). Older material may say 5 requests per second per AWS account (and at most 1,000 CreateHealthCheck calls per 24 h). One request carries at most 1,000 ResourceRecord elements and 32,000 value characters (UPSERT counts twice).

Traps

• Trap: "The domain was registered elsewhere, so Route 53 can't serve its DNS." → Reality: create a public hosted zone and replace the registrar's name servers with the zone's four.
• Trap: "Create a CNAME for example.com." → Reality: not at the apex; use an alias record (§2).
• Trap: "If the private zone lacks the record, the VPC falls back to the public answer." → Reality: the VPC Resolver returns NXDOMAIN.
• Trap: "A record created right after a failed lookup resolves everywhere at once." → Reality: resolvers may keep the cached negative answer for up to the SOA TTL (900 s by default).
• Trap: "Limit who edits records with aws:ResourceTag conditions." → Reality: Route 53 has no tag-based condition keys; use the record name, type and action keys.

Practice questions

1. A release pipeline runs five jobs in parallel, and each job calls aws route53 change-resource-record-sets to update one record in the same hosted zone. Some jobs fail with HTTP 400 and the error code PriorRequestNotComplete. Which change fixes the failures with the LEAST effort?

   • A. Ask AWS Support to raise the account's Route 53 API request-rate limit.
   • B. Lower the TTL of the five records to 60 seconds before the pipeline runs.
   • C. Send all five updates in one change batch and retry rejections after increasing waits.
   • D. Create a second hosted zone with the same name and send half of the updates to that zone.

2. A company hosts example.com in Route 53. A CI role must be able to create or update only the A and AAAA records named app.example.com, and must not be able to delete any record. Which TWO elements belong in the role's policy? (Select TWO.)

   • A. A condition on aws:ResourceTag/team that requires the hosted zone's team tag to match the role's own team tag.
   • B. An Allow for route53:ChangeResourceRecordSets on the hosted zone ARN with ForAllValues:StringEquals on route53:ChangeResourceRecordSetsNormalizedRecordNames set to app.example.com.
   • C. An Allow for route53:* on *, relying on the pipeline code to send only changes for app.example.com.
   • D. A ForAllValues:StringEquals condition on route53:ChangeResourceRecordSetsActions set to CREATE and UPSERT, and on route53:ChangeResourceRecordSetsRecordTypes set to A and AAAA.
   • E. The record name written as App.Example.com., with capitals and a trailing dot, in the name condition.

2. Alias records CNAME records and TTL

Concept

• An alias is Route 53's own record flavour, not standard DNS: you store a pointer to an AWS resource (or to another record of the zone) and Route 53 looks the target up at query time. Clients receive ordinary A/AAAA values that follow the resource's changing IPs. Alias-to-record works for most types (all except NS and SOA).
• A CNAME is plain DNS: it hands the resolver another name to look up. It works for any target, inside or outside AWS, but never at the zone apex.
• The TTL says how long resolvers may cache an answer. It trades freshness for query volume: a high value cuts queries and cost but makes edits and failovers show up late; a low value does the opposite.

Exam facts

• Alias targets: ELB (ALB, NLB, CLB), CloudFront distributions, API Gateway custom domain names (Regional or edge-optimized), Elastic Beanstalk environments whose domain contains the Region, S3 buckets configured as website endpoints, VPC interface endpoints, Global Accelerator accelerators and other records in the same hosted zone. ⚠️ Changed: also App Runner services (2022-08-30), OpenSearch Service custom domains (2025-01-14), AppSync domain names, VPC Lattice service custom domains (2025-06-25) and CloudFront distribution tenants (2025-04-28). Older material may say the list stops at the eight targets above.
• Not alias targets: EC2 instance DNS names, RDS endpoints or names outside AWS → an A record with an Elastic IP, or a CNAME below the apex. At the apex an alias works and a CNAME never does (exception: an apex alias can't point at a CNAME record of the zone).
• The record type follows the target: ELB A or AAAA; CloudFront A, plus AAAA when IPv6 is enabled; API Gateway, S3 website, Beanstalk, VPC endpoint and App Runner A; another record: that record's type (anything except NS and SOA).
• You can't set a TTL on an alias to an AWS resource: Route 53 uses the resource's TTL (60 s for ELB). An alias to another record uses that record's TTL.
• Price: alias queries to AWS resources are free; CNAME queries are billed, and a CNAME that points at another Route 53 name is billed as two queries. An alias answers only queries of its own type, a CNAME every type; dig shows an alias as a plain A/AAAA record (only the console or list-resource-record-sets shows AliasTarget).
• Target rules: S3 website → the record name must equal the bucket name; API Gateway and OpenSearch → the record name must match the custom domain name; CloudFront → the record name must be an alternate domain name of the distribution, no CloudFront alias in a private zone, and EvaluateTargetHealth (§4) can't be true; an alias can't reference a record in another hosted zone.
• TTL practice: lower the TTL (for example to 300 s, or 60 s for a fast cutover) at least one old-TTL period before a planned change and raise it again afterwards; keep 60 s or less on records that use health checks. NS records typically carry 172,800 s (2 days); lower them to 60–900 s before migrating a domain's DNS to Route 53.

Developer angle

• AliasTarget.HostedZoneId is the target's zone, not yours: ELB → CanonicalHostedZoneId from aws elbv2 describe-load-balancers (ALB in us-east-1: Z35SXDOTRQ7X7K); CloudFront → always Z2FDTNDATAQYW2; Global Accelerator → Z2BJ6XQ5FK7U4H; API Gateway → regionalHostedZoneId or distributionHostedZoneId from aws apigateway get-domain-names; S3 website and Beanstalk → the ID published for the Region. The console lists only targets of the same account (type the DNS name for others) and only those that fit the record type. CLI change batches carry the same AliasTarget block (example in §5).
• CloudFormation: an AWS::Route53::RecordSet with AliasTarget and no TTL (on non-alias records TTL is a string property; give HostedZoneId or HostedZoneName, not both; HostedZoneName needs the trailing dot):

ApexAlias:
  Type: AWS::Route53::RecordSet
  Properties:
    HostedZoneName: example.com.
    Name: example.com
    Type: A
    AliasTarget:
      DNSName: !GetAtt WebAlb.DNSName
      HostedZoneId: !GetAtt WebAlb.CanonicalHostedZoneID
      EvaluateTargetHealth: true

Traps

• Trap: "Point the apex at the ALB with a CNAME." → Reality: use an alias A (and AAAA) record.
• Trap: "Alias the instance's public DNS name." → Reality: EC2 names aren't alias targets; use an Elastic IP in an A record, or put the instance behind a load balancer.
• Trap: "Give the alias a 30-second TTL." → Reality: an alias to an AWS resource uses the resource's TTL.
• Trap: "Lower the TTL at the moment of the cutover." → Reality: resolvers that cached the old answer keep it for the old TTL; lower it in advance.
• Trap: "Alias www.example.com to the website bucket example-site." → Reality: the bucket must be named exactly like the record.

Practice questions

1. A startup serves its marketing site from an internet-facing ALB. Visitors must reach it at example.com and at www.example.com, and the team wants the lowest Route 53 query charges. Which records should the developer create?

   • A. CNAME records for both names that point to the ALB's DNS name.
   • B. Alias A records for both names that target the ALB.
   • C. A records for both names that list the ALB's current IP addresses.
   • D. A CNAME record for www.example.com, and an A record with the ALB's IP addresses for example.com.

2. A developer must move api.example.com, an A record with a TTL of 86,400 seconds, to a new IP address during a maintenance window tomorrow evening. Clients must start using the new address within a few minutes of the change. Which TWO actions meet the requirement? (Select TWO.)

   • A. Today, lower the record's TTL to 60 seconds.
   • B. During the window, convert the record into an alias that targets the new IP address.
   • C. Today, raise the record's TTL to 172,800 seconds.
   • D. During the window, lower the minimum TTL in the zone's SOA record to 60 seconds.
   • E. During the window, UPSERT the record with the new IP address.

3. Choosing a routing policy

Concept

• The routing policy decides which value(s) Route 53 puts into a DNS answer; Route 53 never proxies traffic. Records with the same name and type form a group, told apart by SetIdentifier, and a name/type pair uses one policy only (no simple record next to weighted ones). Read the requirement, then pick the row:

Exam facts

• Latency answers with the Region that Route 53's own measurements rate fastest for the user's network; the measurements drift over time, and the fastest Region isn't always the nearest. Only one latency record per Region for a given name and type. Geolocation answers by where the user is (localization, distribution rights, predictable regional load), not by speed or distance; without a default (*) record, users from unlisted or unmapped locations get an empty answer, and if a state's record is unhealthy, Route 53 tries the country, then the continent, then the default.
• Geoproximity: biased distance = actual distance × (1 − bias/100); a positive bias pulls traffic from a larger area; up to 30 records per name and type (100 for weighted, latency, geolocation, multivalue answer and IP-based). ⚠️ Changed: geoproximity is an ordinary routing policy for records in public and private hosted zones since 2024-01-10 (console, API, SDK, CLI). Older material may say it requires Route 53 Traffic Flow. Traffic Flow, the console's builder for routing trees stored as numbered policy versions ($50 per policy record per month), still draws the bias map.
• IP-based: a CIDR collection holds named locations, each with CIDR blocks (IPv4 /1 to /24, IPv6 /1 to /48); a query from a longer prefix matches a shorter block, and * is the default location. Typical use: routing one ISP's users, or overriding geolocation. Not available in private hosted zones.
• Multivalue answer: up to 8 healthy values per answer, different sets for different resolvers; a record without a health check always counts as healthy; when all are unhealthy, Route 53 still returns up to 8. It spreads clients over several IPs but balances nothing (no connection distribution, no draining), and it can't be an alias. Simple routing never health-checks its values (EvaluateTargetHealth has no effect on a simple alias).
• User location comes from the EDNS0 client subnet when the resolver forwards it, otherwise from the resolver's own IP. Private zones ignore EDNS0 (Route 53 uses VPC Resolver data from the zone's Region). ⚠️ Changed: private hosted zones accept simple, failover, multivalue answer, weighted, latency, geolocation and geoproximity records (latency and geolocation since 2022-03-16); only IP-based is unsupported. Older material may say private zones support only simple, failover, multivalue answer and weighted routing.

Developer angle

Check what Route 53 would answer for a given resolver and client subnet with test-dns-answer (public zones only). The batch below creates a country record plus the default record (for "fastest healthy Region", create one latency alias per Region with EvaluateTargetHealth: true instead):

aws route53 test-dns-answer --hosted-zone-id Z0123456789ABCDEFGHIJ --record-name www.example.com --record-type A \
  --resolver-ip 203.0.113.53 --edns0-client-subnet-ip 198.51.100.0 --edns0-client-subnet-mask 24

{"Changes": [{"Action": "CREATE", "ResourceRecordSet": {"Name": "www.example.com", "Type": "A", "SetIdentifier": "germany", "GeoLocation": {"CountryCode": "DE"}, "TTL": 60, "ResourceRecords": [{"Value": "198.51.100.20"}]}},
  {"Action": "CREATE", "ResourceRecordSet": {"Name": "www.example.com", "Type": "A", "SetIdentifier": "default", "GeoLocation": {"CountryCode": "*"}, "TTL": 60, "ResourceRecords": [{"Value": "192.0.2.20"}]}}]}

Traps

• Trap: "Latency routing sends users to the geographically closest Region." → Reality: it picks the lowest measured latency, which can be a farther Region.
• Trap: "Geolocation picks the closest endpoint." → Reality: it maps a location to the record you assigned; distance-based routing is geoproximity.
• Trap: "Simple routing with three IPs drops the dead one." → Reality: simple values aren't health-checked; use multivalue answer or a load balancer.
• Trap: "Geoproximity requires Traffic Flow." → Reality: not since January 2024.
• Trap: "IP-based routing for an internal private zone." → Reality: unsupported in private hosted zones.

Practice questions

1. A streaming company has a licensing deal for Canada. Viewers in Canada must reach the stack that serves the Canadian catalog, and every other viewer, including viewers whose location Route 53 can't determine, must reach the international stack. Which record configuration meets these requirements?

   • A. Latency records for the Canadian stack in ca-central-1 and for the international stack in eu-west-1.
   • B. A geolocation record for Canada that targets the Canadian stack, and a geolocation record for North America that targets the international stack.
   • C. Geoproximity records for both stacks, with a bias of +50 on the Canadian stack.
   • D. A geolocation record for Canada that targets the Canadian stack, and a default geolocation record that targets the international stack.

2. An application runs behind ALBs in us-east-1 and ap-southeast-1. Each user must be sent to the Region that responds fastest for that user, and when one Region's ALB has no healthy targets, its users must move to the other Region without manual action. Which TWO steps should the developer take? (Select TWO.)

   • A. Create geolocation records for North America and for Asia.
   • B. Create one simple record that lists the DNS names of both ALBs.
   • C. Create a latency alias record for each ALB, with the Region of that ALB.
   • D. Create Route 53 HTTP health checks against the current IP addresses of each ALB's nodes.
   • E. Set EvaluateTargetHealth to true on both alias records.

4. Health checks and DNS failover

Concept

• Health checks run on their own schedule, independently of DNS queries. A record points at a health check (HealthCheckId); when Route 53 chooses among records, it skips unhealthy ones. An alias record can instead inherit its target's health with EvaluateTargetHealth.
• Types: endpoint checks (HTTP, HTTPS, TCP, optionally with string matching) sent by checkers on the internet; calculated checks that combine child checks (at least N, all = AND, one or more = OR; a NOT comes from inverting a check); CloudWatch alarm checks, which read an alarm's metric data inside AWS and therefore cover private resources. The API adds RECOVERY_CONTROL for Application Recovery Controller.
• Failover routing is active-passive (primary, then secondary); health checks on any other policy give active-active.

Exam facts

• An endpoint is healthy when more than 18 % of checkers report it healthy. HTTP and HTTPS: TCP connection within 4 s, then a 2xx or 3xx status within 2 s; TCP: connection within 10 s; string matching: the body must follow within 2 more seconds and contain the search string (up to 255 characters, case-sensitive) in its first 5,120 bytes.
• HTTPS checks don't validate certificates, so an expired or private-CA certificate still passes; the endpoint must support TLS 1.0, 1.1 or 1.2. Set EnableSNI when the server needs the host name in the TLS handshake; without it such a check typically reports SSL alert handshake_failure.
• Request interval 30 s (default) or 10 s (fast, extra cost); with 30 s, the endpoint receives a request about every 2 s from all checkers together. Failure threshold 1–10 consecutive results (default 3), in both directions. Type, interval, string matching, latency measurement and "specify endpoint by" can't be changed after creation. Checker Regions: 8 to choose from (us-east-1, us-west-1, us-west-2, eu-west-1, ap-southeast-1, ap-southeast-2, ap-northeast-1, sa-east-1), at least 3 in a custom list. ⚠️ unverified: the course's "about 15 health checkers"; AWS publishes no count.
• Firewalls and security groups must admit the checkers: the ROUTE53_HEALTHCHECKS ranges in ip-ranges.json, or the managed prefix list com.amazonaws.<region>.route53-healthchecks (IPv6: com.amazonaws.<region>.ipv6.route53-healthchecks).
• Private resources: checkers can't reach private, local or non-routable addresses, so alarm on a CloudWatch metric and point a CLOUDWATCH_METRIC health check at that alarm (same account; standard-resolution metric; no metric math, extended statistics or M-out-of-N alarms). InsufficientDataHealthStatus = Healthy, Unhealthy or LastKnownStatus. The check reads the metric data, not the alarm state, so SetAlarmState can't trip it.
• Calculated checks can't monitor other calculated checks; HealthThreshold 0 means always healthy. ⚠️ unverified: the child limit, because AWS pages disagree (API ChildHealthChecks and the console page: 256; quotas page: 255); don't hinge an answer on it. A disabled check (child or not) counts as healthy, traffic keeps flowing and billing continues; to push traffic away, invert the check.
• Failover outcomes: primary healthy → primary; primary unhealthy and secondary healthy → secondary; both unhealthy → primary; secondary without a health check → used whenever the primary is unhealthy. A primary with neither a health check nor EvaluateTargetHealth always counts as healthy, so it never fails over. Failover alias records must set EvaluateTargetHealth to true, except an alias to a CloudFront distribution, which can't set it. In any other group, records without a health check are always healthy, and if every record is unhealthy, Route 53 treats them all as healthy.
• EvaluateTargetHealth on an ALB or NLB alias: healthy only if every target group that has targets has at least one healthy target; a target group with no registered targets counts as unhealthy as well, so one empty target group fails the alias even when another target group is healthy. Don't add Route 53 checks for instances behind a load balancer. Not allowed for CloudFront; allowed but of no benefit for S3, API Gateway, VPC endpoints, Global Accelerator, OpenSearch and VPC Lattice, where a health check of your own path is the useful signal. An alias with both a health check and EvaluateTargetHealth needs both to be healthy.
• Metrics (HealthCheckStatus, HealthCheckPercentageHealthy) exist only in CloudWatch in us-east-1. Quota: 200 active health checks per account (adjustable). Price: $0.50 per month for an AWS endpoint, $0.75 for others, optional features extra; the first 50 checks of AWS endpoints are free, and calculated and alarm checks bill as AWS-endpoint checks.

Developer angle

aws route53 create-health-check --caller-reference "orders-hc-$(date +%s)" --health-check-config \
  '{"Type":"HTTPS","FullyQualifiedDomainName":"orders-use1.example.com","Port":443,"ResourcePath":"/health","RequestInterval":30,"FailureThreshold":3,"EnableSNI":true}'
aws route53 create-health-check --caller-reference "orders-db-$(date +%s)" --health-check-config \
  '{"Type":"CLOUDWATCH_METRIC","AlarmIdentifier":{"Region":"eu-west-1","Name":"orders-db-errors"},"InsufficientDataHealthStatus":"LastKnownStatus"}'
aws route53 get-health-check-status --health-check-id 01234567-89ab-cdef-0123-456789abcdef
aws route53 get-health-check-last-failure-reason --health-check-id 01234567-89ab-cdef-0123-456789abcdef

• CallerReference makes CreateHealthCheck safe to retry; reusing it with different settings returns HealthCheckAlreadyExists (409).
• Maintenance page on failover: primary = alias to the ALB, secondary = alias to an S3 website bucket named like the record, both with EvaluateTargetHealth: true. S3 website endpoints speak HTTP only, so an HTTPS site needs CloudFront in front of the bucket for the secondary, and that secondary alias to the distribution takes EvaluateTargetHealth: false.
• A health check specified by domain name should use the endpoint's own host name (orders-use1.example.com), never the shared record name, or the results become unpredictable. Such checks use IPv4 only and fail with "DNS resolution failed" when the name has no A record.

Traps

• Trap: "Run an HTTPS health check against the instance's private IP." → Reality: checkers can't reach it; use a CloudWatch alarm health check.
• Trap: "An expired certificate makes the HTTPS check fail." → Reality: HTTPS checks don't validate certificates.
• Trap: "Disable the check to send traffic to the secondary." → Reality: a disabled check is healthy; invert it.
• Trap: "Switch the existing check to the 10-second interval." → Reality: the interval is fixed at creation; create a new check.
• Trap: "Failover works without a health check on the primary." → Reality: unless it's an alias with EvaluateTargetHealth, the primary then always counts as healthy.
• Trap: "With both records unhealthy, Route 53 returns nothing." → Reality: it returns the primary (in other groups, all records are treated as healthy).

Practice questions

1. An internal order API runs on EC2 instances that have only private IP addresses. A private hosted zone holds failover records for orders.internal.example.com that point to a primary and a standby fleet. The team wants Route 53 to fail over when the primary's 5xx error rate is high. What should the developer associate with the primary record?

   • A. A CLOUDWATCH_METRIC health check that monitors a CloudWatch alarm on the primary's error rate.
   • B. An HTTPS health check that targets the private IP address of one of the primary instances on port 443.
   • C. A calculated health check whose child checks are the EC2 instance status checks of the primary fleet.
   • D. EvaluateTargetHealth set to true on the non-alias primary failover record.

2. A Route 53 HTTPS health check for shop.example.com, an EC2-hosted site with a public IP address, reports unhealthy, although the site responds normally to the team's own tests. Which TWO causes could explain the status? (Select TWO.)

   • A. The health check path returns 302 Found and redirects to the login page.
   • B. The instance's security group allows HTTPS only from the company's office IP range.
   • C. The web server hosts several sites and requires SNI, and the health check was created without EnableSNI.
   • D. The server's TLS certificate was issued by the company's own private certificate authority instead of a public CA.
   • E. The endpoint returns its status code 1.5 seconds after the TCP connection opens.

5. Weighted routing for blue green releases

Concept

• Blue (current) and green (new) run as separate stacks with their own endpoints. Two weighted records share the public name and type and differ by SetIdentifier; moving weight from blue to green releases gradually, and putting green back to 0 rolls back. Nothing is redeployed: each step is a DNS change.
• DNS shifts resolvers, not requests: every resolver caches the answer it got for the TTL, and some clients cache longer, so splits are approximate and a rollback takes at least one TTL.
• Choose it when the versions live behind different endpoints (load balancers, environments, Regions or accounts). When both versions sit behind one load balancer, one function or one API, shift traffic there instead (see the alternatives below).

Exam facts

• Weight is 0–255 and relative: share = weight ÷ sum of the group's weights (the total doesn't have to be 100; weights of 1 and 255 send 1/256 to the first). Weight 0 stops answers for that record; all records at 0 → equal shares.
• Same name and type, a unique SetIdentifier (1–128 characters), at most 100 weighted records per name and type, and no non-weighted record with that name and type.
• A weighted group has one TTL: Route 53 applies the last value you set to all members. When the group mixes ELB aliases with non-alias records, give the non-alias records 60 s (the load balancers' TTL), or the weights skew.
• With health checks, unhealthy records drop out, and zero-weight records are used only when every non-zero record is unhealthy, so a weight-0 record can serve as a last-resort standby (it must give a working answer). An ALB alias with EvaluateTargetHealth counts as unhealthy while its target group is empty: register green's targets before giving it weight.
• Cutover and rollback speed are bounded by the TTL plus client caching, and long-lived keep-alive connections stay on the old stack until they close. ⚠️ Changed: the AWS SDK for Java guide recommends a JVM DNS cache TTL of 5 s (networkaddress.cache.ttl, a security property that -D doesn't set: use java.security or Security.setProperty; -Dsun.net.inetaddr.ttl=5 is only a JDK fallback). Older material may say no more than 60 seconds, the ceiling that the RDS User Guide still gives for Multi-AZ failover (notes/rds-guide.md §3); 5 s meets both. JVM defaults vary, and some configurations never refresh a cached lookup until the JVM restarts.
• Alternatives owned by other modules: Elastic Beanstalk swap environment URLs (also a DNS change, so also cached) and traffic splitting (notes/beanstalk-guide.md §7–§8); ALB listener rules that forward to weighted target groups (one endpoint, no DNS caching; notes/ec2-mastery-guide.md §8); Lambda alias weights (notes/lambda-guide.md §7); API Gateway canary releases (notes/api-gateway-guide.md §5); CodeDeploy blue/green for ECS and Lambda (notes/cicd-guide.md §8).

Developer angle

shift.json sets both weights in one atomic batch (90/10); apply it with aws route53 change-resource-record-sets --hosted-zone-id Z0123456789ABCDEFGHIJ --change-batch file://shift.json.

{"Comment": "release 42: 10 percent to green",
 "Changes": [
  {"Action": "UPSERT", "ResourceRecordSet": {"Name": "app.example.com", "Type": "A", "SetIdentifier": "blue", "Weight": 90,
    "AliasTarget": {"HostedZoneId": "Z35SXDOTRQ7X7K", "DNSName": "blue-alb-1111111111.us-east-1.elb.amazonaws.com", "EvaluateTargetHealth": true}}},
  {"Action": "UPSERT", "ResourceRecordSet": {"Name": "app.example.com", "Type": "A", "SetIdentifier": "green", "Weight": 10,
    "AliasTarget": {"HostedZoneId": "Z35SXDOTRQ7X7K", "DNSName": "green-alb-2222222222.us-east-1.elb.amazonaws.com", "EvaluateTargetHealth": true}}}]}

• A typical run: 100/0 → 90/10 → 50/50 → 0/100, checking each stack's ALB metrics (HTTPCode_Target_5XX_Count, TargetResponseTime) or alarms between steps; roll back with an UPSERT that sets green to 0; delete blue only after a full TTL plus connection draining.
• Infrastructure as code: keep both records in the template and pass the weights as parameters (Weight: !Ref GreenWeight), so each step is a stack update.
• Scope the pipeline role to these two records with the name, type and action condition keys from §1.

Traps

• Trap: "The weights must add up to 100." → Reality: they are relative values from 0 to 255.
• Trap: "A weight of 10 out of 100 means exactly 10 % of requests." → Reality: each resolver caches one answer for the TTL, so the split is approximate.
• Trap: "Setting green to 0 stops green traffic at once." → Reality: cached answers and open connections keep reaching green for at least a TTL.
• Trap: "Give blue a 300-second TTL and green a 60-second TTL." → Reality: the group shares one TTL; the last value set wins.
• Trap: "Weighted DNS is the way to canary a single Lambda function." → Reality: use alias weights or CodeDeploy.

Practice questions

1. A team runs version 1 of an application behind the ALB blue and version 2 behind the ALB green, each in its own CloudFormation stack in us-east-1. Today app.example.com is a simple alias record that targets blue. The team wants about 5 % of users on version 2 first and the ability to undo the change quickly. Which approach meets these requirements with the LEAST operational overhead?

   • A. Replace the simple record with multivalue answer records that return the addresses of both ALBs.
   • B. Replace the simple record with latency alias records for both ALBs, each one set to the us-east-1 Region.
   • C. Replace the simple record with weighted alias records: blue at weight 95 and green at weight 5.
   • D. Add a second simple alias record for app.example.com that targets the green ALB.

2. A company shifts traffic between two partner-hosted endpoints with weighted CNAME records for pay.example.com that use a TTL of 86,400 seconds. After the last rollback, the company's Java services kept calling the old endpoint for hours. Which TWO changes shorten the time that clients keep using the old endpoint after the next weight change? (Select TWO.)

   • A. Set the networkaddress.cache.ttl security property of the Java services to 5 seconds.
   • B. Raise the minimum TTL in the zone's SOA record to 86,400 seconds.
   • C. Give the new endpoint a weight of 255 and the old endpoint a weight of 0.
   • D. Lower the TTL of the weighted records to 60 seconds well before the next release.
   • E. Turn on latency measurement in the Route 53 health checks of both partner endpoints.

Quick decision rules

Records, alias and TTL (§1–§2)

• If you see a domain registered with another registrar that must use Route 53 DNS, think public hosted zone plus the registrar's name servers set to the zone's four NS values.
• If you see the zone apex (example.com) pointing at an ALB, CloudFront, API Gateway or an S3 website, think alias A/AAAA record.
• If you see "lowest DNS query cost" for an AWS target, think alias record (free queries) instead of CNAME.
• If you see an EC2 instance name or an RDS endpoint as the target, think A record with an Elastic IP or a CNAME below the apex; no alias.
• If you see "clients still use the old IP hours after the change", think TTL: lower it at least one old-TTL period before the change.
• If you see a new name that still resolves as non-existent, think negative caching (SOA TTL, 900 s by default).
• If you see PriorRequestNotComplete, think retry after growing waits and fewer, batched changes per zone.
• If you see Throttling / Rate exceeded from the Route 53 API, think exponential backoff and larger batches.
• If you see "let a pipeline change only one record", think route53:ChangeResourceRecordSetsNormalizedRecordNames plus record-type and action conditions.

Routing policies (§3)

• If you see "send each user to the fastest Region", think latency records with EvaluateTargetHealth.
• If you see language, legal or licensing rules per country, think geolocation records plus a default record.
• If you see "pull more users towards one Region by distance", think geoproximity with a positive bias.
• If you see "route the users of one ISP or IP range", think IP-based routing with a CIDR collection.
• If you see "return several IPs, only healthy ones, without a load balancer", think multivalue answer.

Health checks, failover and releases (§4–§5)

• If you see "fail over to a standby or a static page", think failover records plus a health check (or EvaluateTargetHealth on the primary alias).
• If you see a health check for a resource with only private IPs, think CloudWatch alarm health check (CLOUDWATCH_METRIC).
• If you see a health check failing while the site works, think security group blocking the checkers (com.amazonaws.<region>.route53-healthchecks), missing SNI, or a status outside 2xx/3xx.
• If you see "force traffic away from an endpoint without editing records", think invert the health check; disabling keeps it healthy.
• If you see "send 10 % of users to a new stack behind a different load balancer", think two weighted records with their own SetIdentifier.
• If you see "shift traffic between versions behind one ALB without DNS caching", think ALB weighted target groups, not Route 53.
• If you see Java clients ignoring a DNS change, think networkaddress.cache.ttl (AWS recommends 5 s).

Changed vs older material

Learn the Current column; older practice material may still show the Course / older material value. Rows marked ⚠️ unverified stay out of notes/current-facts.md and out of bank questions; the others move there once you confirm them during /ingest.