When did Amazon Route 53 launch?

Amazon Route 53 was announced on December 5, 2010, and became generally available on May 24, 2011, together with ELB integration (alias records) and Weighted Round Robin routing.

When did Amazon Route 53 add domain registration?

Domain registration became available on Amazon Route 53 on July 31, 2014, together with the Geolocation routing policy. Amazon Registrar became an ICANN-accredited registrar for the .com and .net top-level domains on October 19, 2015.

How have Amazon Route 53 routing policies evolved?

Weighted Round Robin arrived with GA on May 24, 2011, Latency-based routing on March 21, 2012, Failover routing (with health checks) on February 11, 2013, Geolocation routing on July 31, 2014, Geoproximity routing within Traffic Flow on September 1, 2017 (standalone since January 10, 2024), Multivalue Answer routing on June 21, 2017, and IP-based routing in June 2022.

When did Amazon Route 53 Resolver launch, and what is Route 53 VPC Resolver?

Amazon Route 53 Resolver, which provides recursive DNS for VPCs and hybrid name resolution through inbound and outbound endpoints, became available on November 19, 2018. On November 30, 2025, it was renamed Amazon Route 53 VPC Resolver when the internet-reachable anycast resolver Amazon Route 53 Global Resolver was announced in preview; Global Resolver became generally available on March 9, 2026.

When did Amazon Route 53 support DNSSEC?

DNSSEC for domain registration (when using other DNS services) was supported on August 9, 2016, and DNSSEC signing for public hosted zones together with DNSSEC validation in Route 53 Resolver became available on December 17, 2020.

When did Amazon Route 53 Resolver DNS Firewall launch and how has it evolved?

Amazon Route 53 Resolver DNS Firewall launched on March 31, 2021. Query-type filtering was added on January 10, 2024, domain-redirection handling on May 1, 2024, DNS Firewall Advanced (detecting DNS tunneling and DGA anomalies) on November 15, 2024, AWS Security Hub integration on January 13, 2025, and dictionary-based DGA protection on November 17, 2025.

What are Amazon Route 53 Profiles?

Amazon Route 53 Profiles, introduced on April 22, 2024, bundle DNS settings such as private hosted zone associations, Resolver rules, and DNS Firewall rule groups into a standard configuration that can be applied to many VPCs and shared across accounts with AWS Resource Access Manager.

When did Amazon Route 53 Application Recovery Controller and zonal autoshift launch?

Amazon Route 53 Application Recovery Controller became available on July 27, 2021, providing readiness checks and routing controls. Zonal autoshift, which automatically shifts traffic away from an impaired Availability Zone, launched on November 30, 2023.

AWS History and Timeline regarding Amazon Route 53 - Overview, Functions, Features, Summary of Updates, and Introduction

First Published: 2023-06-16
Last Updated: 2026-07-04

Last time, in the article "AWS History and Timeline regarding AWS Systems Manager - Overview, Functions, Features, Summary of Updates, and Introduction to SSM", I introduced the feature list of AWS Systems Manager (SSM), the transition of feature integration, and more.
This time, I have created a historical timeline for Amazon Route 53, which provides various related features including the Domain Name System (DNS) in the cloud.
Like before, I have compiled the major features of Amazon Route 53, along with additions and updates, into a "Current Overview, Functions, Features of Amazon Route 53".
I hope these will provide clues as to what has remained the same and what has changed, in addition to the features and concepts of each AWS service.

Background and Method of Creating Amazon Route 53 Historical Timeline

The reason I created a historical timeline for Amazon Route 53 this time is because Amazon Route 53 has provided a variety of functions such as operations through APIs, various routing, and health checks at an early stage in the history of AWS. I wanted to organize the information about Amazon Route 53 with the following approach.

Tracking the history of Amazon Route 53 and organizing the transition of updates
Summarizing the feature list and characteristics of Amazon Route 53

This timeline primarily references the following blogs and document history regarding Amazon Route 53.

There may be slight variations in the dates on the timeline due to differences in the timing of announcements or article postings in the references used.
The content posted is limited to major features related to the current Amazon Route 53 and necessary for the feature list and overview description.
In other words, please note that the items on this timeline are not all updates to Amazon Route 53 features, but are representative updates that I have picked out.

Amazon Route 53 Historical Timeline (Updates from December 5, 2010)

So, from here on, I have a timeline of the features of Amazon Route 53.
The history of Amazon Route 53 exceeds 15 years from December 2010, and the timeline is quite long, so please use the year index below or scroll as necessary.

2010 | 2011 | 2012 | 2013 | 2014 | 2015 | 2016 | 2017 | 2018 | 2020 | 2021 | 2022 | 2023 | 2024 | 2025 | 2026

* You can sort the table by clicking on the column name.

Date	Summary
2010-12-05	Announcement of Amazon Route 53 [Source]
2011-05-24	Amazon Route 53 becomes GA [Source]
2011-11-16	Amazon Route 53 becomes available from AWS Management Console. [Source]
2011-12-21	Alias records that support Zone Apex (Naked Domain, Root Domain) even with domain specification can now be used for Elastic Load Balancing (Classic Load Balancer). [Source]
2012-03-21	Latency records are supported, and Latency Routing Policy becomes available. [Source]
2013-02-11	Support for Health Check functionality and Failover functionality. [Source]
2013-05-30	Support for health checks of EC2 instances associated with ELB. [Source]
2013-06-11	Alias records support routing DNS queries to alternate domain names of Amazon CloudFront distributions. [Source]
2013-06-26	Amazon CloudWatch supports monitoring of Amazon Route 53 health checks. [Source]
2013-08-14	Support for importing BIND format zone files [Source]
2014-01-07	Support for health check response character display [Source]
2014-02-18	Support for health check interval, failover threshold [Source]
2014-04-09	The health of health checks can now be assessed as a percentage. [Source]
2014-04-18	Support for HTTPS, port-specified health checks [Source]
2014-04-30	Support for domain-specified health checks [Source]
2014-07-02	Support for tagging health checks, obtaining health check counts [Source]
2014-07-31	Domain registration becomes available on Amazon Route 53. Support for Geolocation Routing Policy. [Source]
2014-11-05	Support for managing internal domains of VPC with private DNS, reuse of name server delegation set, and support for reasons for health check failures. [Source]
2014-11-25	Support for editing comments on hosted zones [Source]
2015-01-22	Support for internationalized domain names in Amazon Route 53 domain registration [Source]
2015-02-05	Domain contact information can now be updated from the management console [Source]
2015-02-11	Integration of Amazon Route 53 and AWS CloudTrail. Support for simplified display of daily health check status on management console. Support for creating 1-minute Amazon CloudWatch alarm simultaneously with health check creation. Tagging is now possible for zones and domains. [Source]
2015-02-26	Support for obtaining a list of hosted zones and the number of hosted zones with Amazon Route 53 API [Source]
2015-03-03	You can now configure white label name servers (vanity name servers, private name servers). [Source]
2015-09-15	Support for creating health checks whose status is determined based on the status of other health checks. Support for measuring latency of health checks. Support for updating health check dashboard. [Source]
2015-10-19	Amazon Registrar becomes ICANN accredited registrar for ".com" and ".net" top level domains (TLD). Support for privacy protection feature of ".com" and ".net" domains. [Source]
2015-12-03	Support for visual editor that can configure and associate traffic flow routing policy [Source]
2016-01-19	Alias records now support AWS Elastic Beanstalk. [Source]
2016-01-27	Support for domain registration for over 100 top-level domains (TLDs). [Source]
2016-02-23	Support for sending the hostname in the "client_hello" message during TLS negotiation for endpoints, enabling responses to HTTPS requests using SSL/TLS certificates. [Source]
2016-04-05	Support for health checks based on CloudWatch metrics, region selection for health checks. Support for alias records in private hosted zones and failovers. [Source]
2016-05-26	Support for billing reports for domain registration fees. Newly supports domain registration for .college, .consulting, .host, .name, .online, .republican, .rocks, .sucks, .trade, .website, and .uk. [Source]
2016-07-07	Support for manually extending domain registration periods (up to 10 years for generic TLDs and many country code TLDs). [Source]
2016-08-09	Support for DNSSEC with Amazon Route 53 domain registration. [Source]
2016-08-11	Alias records can now be used with Elastic Load Balancing (Application Load Balancer). [Source]
2016-08-30	Support for NAPTR record type. DNS query testing tool now available. [Source]
2016-11-21	Support for using IPv6 addresses for endpoints with health checks. [Source]
2017-04-10	Name servers associated with domain transfers to Amazon Route 53 can now be selected. [Source]
2017-06-21	Support for Multivalue Answer Routing policy for up to 8 records. [Source]
2017-08-21	Support for Certification Authority Authorization (CAA) records. [Source]
2017-09-01	Support for Geoproximity Routing Policy. [Source]
2017-09-07	Support for public DNS query logs in public hosted zones. [Source]
2017-09-11	Alias records can now be used with Elastic Load Balancing (Network Load Balancer). [Source]
2017-10-03	Amazon Route 53 becomes a HIPAA eligible service. [Source]
2017-12-05	Support for Amazon Route 53 Auto Naming API for automatic creation and deletion of DNS names for instances (later becomes AWS Cloud Map). [Source]
2018-02-06	Amazon Route 53 Auto Naming supports alias records and CNAME records. [Source]
2018-03-09	IAM managed policies added for Amazon Route 53 Auto Naming. [Source]
2018-03-13	Amazon Route 53 Auto Naming supports health checks by third-party checkers. [Source]
2018-10-18	Support for pausing health checks. [Source]
2018-11-07	The routing effect on end users by Geoproximity Routing Policy can now be visualized on a map. [Source]
2018-11-19	Amazon Route 53 Resolver, which resolves DNS names between Amazon VPC and on-premises over AWS Direct Connect and VPN connections, becomes available. [Source]
2018-11-28	Amazon Route 53 Auto Naming API becomes a part of AWS Cloud Map features. [Source]
2018-12-20	Alias records can now be used with API Gateway API and Amazon VPC interface endpoints. [Source]
2020-09-01	Resolver query logs become available in Amazon Route 53 Resolver. [Source]
2020-12-17	Amazon Route 53 Resolver supports DNSSEC signing and DNSSEC validation. [Source]
2021-03-31	Amazon Route 53 Resolver DNS Firewall, which protects outbound DNS requests from VPC, becomes available. [Source]
2021-07-27	Amazon Route 53 Application Recovery Controller, which manages and coordinates failovers with readiness checks and routing controls, becomes available. [Source]
2021-10-26	Default reverse lookup DNS rules can now be disabled and reverse lookup DNS namespace queries can be forwarded to external servers. [Source]
2022-03-16	Private hosted zones support Geolocation Routing and Latency Routing policies. [Source]
2022-06-01	IP-based Routing policy is supported. [Source]
2022-09-06	Alias records can now be used with AWS App Runner. [Source]
2022-09-21	Support for IAM policy permissions for groups of DNS record sets for public or private hosted zones. [Source]
2023-03-10	Amazon Route 53 Resolver endpoints support IPv6. [Source]
2023-11-30	Amazon Route 53 Application Recovery Controller launches zonal autoshift. Zonal autoshift automatically and safely shifts application traffic away from an Availability Zone when AWS identifies a potential failure such as a power or networking outage, and shifts it back once the issue is resolved, with practice runs that proactively test whether an application can tolerate losing one AZ. [Source]
2023-12-20	Amazon Route 53 Resolver endpoints support DNS-over-HTTPS (DoH). DoH encrypts DNS queries passing through inbound and outbound Resolver endpoints, protecting hybrid-cloud DNS traffic from eavesdropping and manipulation. [Source]
2024-01-10	Geoproximity routing becomes available as a standalone routing policy outside of Traffic Flow. Previously geoproximity routing required Traffic Flow; it can now be configured directly as a routing policy for DNS records in public and private hosted zones via the Route 53 console, API, SDK, and CLI. [Source]
2024-01-10	Amazon Route 53 Resolver DNS Firewall supports filtering by DNS query type (QTYPE). DNS Firewall rules can filter outbound DNS traffic based on the query type in addition to the query domain name, for example blocking outbound queries for TXT records commonly abused for DNS tunneling. [Source]
2024-04-22	Amazon Route 53 Profiles are introduced for centralized VPC DNS configuration. A Profile bundles private hosted zone associations, Resolver forwarding rules, and DNS Firewall rule groups into a standard DNS configuration that can be applied to multiple VPCs in a Region and shared across AWS accounts via AWS Resource Access Manager. [Source]
2024-05-01	Amazon Route 53 Resolver DNS Firewall adds automatic domain-redirection handling for CNAME and DNAME chains. DNS Firewall can automatically skip inspection of every domain in a CNAME/DNAME redirection chain when allow-listing a domain, removing the earlier requirement to explicitly list each domain in the chain. [Source]
2024-10-30	Support for the HTTPS, SSHFP, SVCB, and TLSA DNS resource record types is announced. HTTPS and SVCB records let clients discover connection details such as HTTP/3 support without extra round trips, TLSA records associate TLS certificates or public keys with a domain for DANE via DNSSEC, and SSHFP records let clients validate SSH host key fingerprints. SSHFP and TLSA are supported for public hosted zones, while HTTPS and SVCB are supported for both public and private hosted zones. [Source]
2024-11-15	Amazon Route 53 Resolver DNS Firewall Advanced is introduced. DNS Firewall Advanced adds real-time monitoring and blocking of DNS traffic based on anomalies in queried domain names, targeting advanced threats such as DNS tunneling and Domain Generation Algorithms (DGA) that evade conventional threat-intelligence domain lists. [Source]
2025-01-13	AWS Security Hub integrates with Amazon Route 53 Resolver DNS Firewall. The integration adds new finding types covering DNS queries blocked or alerted on by AWS Managed Domain Lists, customer domain lists, and DNS Firewall Advanced, so DNS-related security findings appear alongside those from services such as Amazon GuardDuty. [Source]
2025-04-04	Public authoritative DNS for public hosted zones becomes generally available in the AWS GovCloud (US) Regions. Public DNS queries can now be served from within AWS GovCloud (US) without depending on commercial AWS Region accounts, including authoritative DNS query logging and DNSSEC signing. [Source]
2025-06-24	Amazon Route 53 Resolver endpoints add DNS delegation support for private hosted zone subdomains. Organizations can delegate authority for a subdomain between on-premises infrastructure and Route 53 Resolver inbound and outbound endpoints using name server records, instead of maintaining conditional forwarding rules. [Source]
2025-11-17	Amazon Route 53 Resolver DNS Firewall Advanced adds protection against dictionary-based DGA attacks. This variant of Domain Generation Algorithm attack pseudo-randomly concatenates dictionary words into human-readable domain names designed to blend in with legitimate traffic and evade detection. [Source]
2025-11-26	An accelerated recovery option for managing DNS records in public hosted zones is announced. Accelerated recovery targets a 60-minute recovery time objective (RTO) for regaining the ability to change DNS records in Route 53 public hosted zones if AWS services in US East (N. Virginia) become temporarily unavailable, addressing business continuity and disaster recovery requirements common in banking, FinTech, and SaaS. [Source]
2025-11-30	Amazon Route 53 Global Resolver is announced in preview, and the original Amazon Route 53 Resolver is renamed Amazon Route 53 VPC Resolver. Global Resolver is an internet-reachable anycast DNS resolver that lets authorized clients anywhere resolve both public internet domains and private Route 53 hosted zone domains, with DNS Firewall based query filtering and centralized query logging; the existing per-VPC recursive resolver is renamed Route 53 VPC Resolver to distinguish it from the new service. [Source]
2026-03-09	Amazon Route 53 Global Resolver becomes generally available. General availability expands the anycast DNS resolver previewed at AWS re:Invent 2025, adding support for both IPv4 and IPv6 DNS query traffic and protection against dictionary-based DGA threats. [Source]
2026-06-15	Amazon Route 53 Resolver DNS Firewall begins a preview integration with Palo Alto Networks Advanced DNS Security. Security administrators can enforce Palo Alto Networks DNS threat-protection categories, including command and control, malware, and phishing, directly within the DNS Firewall rule creation workflow, complementing AWS managed domain lists with third-party threat intelligence. [Source]

Amazon Route 53 has evolved over the years to offer not just general hosted zone and record registration functions that other DNS services provide, but also features such as health checks, failovers, and DNS routing, which control traffic by altering the return values of DNS queries based on conditions. Numerous updates have been implemented to enhance these features.
Such functions have not only allowed AWS to provide a DNS service with high affinity to its services but also enabled Disaster Recovery (DR) across the cloud, as typified by the construction of hybrid environments that failover between on-premise and AWS.
In this way, the use of Amazon Route 53's health checks, failovers, and DNS routing is not limited to AWS but can also be set up with the IP addresses of on-premise and other cloud environments, making it a highly versatile service.

Current Overview, Functions, Features of Amazon Route 53

From here, I will introduce the current list and overview of Amazon Route 53 features at the time of writing this article.
The functions of Amazon Route 53 can be broadly divided into domain management, DNS services, health checks, and resolvers.
Among these, the resolver primarily provides name resolution functionality within Amazon VPC, means for Inbound Endpoint and Outbound Endpoint to mutually resolve names between Amazon VPC and on-premises, and a DNS Firewall to control outbound DNS queries.
Also, DNS services and health checks provide DNS routing according to conditions such as failovers, related to each other.
This DNS routing can provide advanced and flexible settings for reducing downtime and improving reliability by using the Amazon Route 53 Application Recovery Controller, which offers monitoring of the prepared state of failover configurations and routing control based on specified rules.
In recent years, the resolver side has grown significantly: Amazon Route 53 Profiles centralize VPC DNS configuration, DNS Firewall Advanced detects anomaly-based DNS threats, and Amazon Route 53 Global Resolver, generally available since 2026-03-09, extends recursive DNS resolution beyond the VPC to clients anywhere (with the original resolver renamed Amazon Route 53 VPC Resolver).

Amazon Route 53 Use Cases

Amazon Route 53 is typically used in the following scenarios:

Public authoritative DNS hosting: Hosting the DNS records of a domain in public hosted zones, including alias records that route the zone apex to AWS resources such as ELB, Amazon CloudFront, Amazon S3, and Amazon API Gateway.
Domain registration and management: Registering, renewing, and transferring domains with Amazon Route 53 as an ICANN-accredited registrar.
Global traffic routing: Steering users with routing policies such as latency-based, geolocation, geoproximity, weighted, multivalue answer, and IP-based routing.
High availability and failover: Combining health checks, DNS failover, and Amazon Route 53 Application Recovery Controller (including zonal shift and zonal autoshift) to reduce downtime.
Private DNS for VPCs: Managing internal domain names with private hosted zones and resolving names within and across VPCs.
Hybrid cloud name resolution: Resolving DNS names between on-premises networks and Amazon VPC with Route 53 VPC Resolver inbound and outbound endpoints.
DNS-level security: Filtering outbound DNS queries with Resolver DNS Firewall and DNS Firewall Advanced, and validating DNS responses with DNSSEC.
Centralized DNS management at scale: Applying standard DNS configurations to many VPCs and accounts with Amazon Route 53 Profiles.

Amazon Route 53 Key Functions and Features

The main functions and features that Amazon Route 53 currently provides are as follows. Each of them is described in detail in the sections below.

Domain Management: Domain registration, renewal, transfer, WHOIS privacy protection, and DNSSEC for domain registration.
DNS Services: Public and private hosted zones, a wide range of record types (including HTTPS, SVCB, SSHFP, and TLSA), alias records, routing policies, Traffic Flow, and DNSSEC signing.
Health Check: Endpoint, calculated, and CloudWatch metric based health checks, and DNS failover.
Resolver: Route 53 VPC Resolver (formerly Route 53 Resolver), inbound/outbound endpoints with DoH and IPv6, Resolver query logging, DNS Firewall and DNS Firewall Advanced, Route 53 Profiles, and Route 53 Global Resolver.
Amazon Route 53 Application Recovery Controller: Readiness checks, routing controls, and zonal shift / zonal autoshift.

Domain Management

Amazon Route 53 allows you to use domain management services such as domain registration (new acquisition), renewal, and transfer.
Here, I will describe the features of domain registration, renewal, and transfer on Amazon Route 53.

Domain Registration

At the time of writing this article, Amazon Route 53 domain registration supports more than 300 types of domains, including generic top-level domains (such as .com) and geographic top-level domains (such as .jp).
For information on the domains supported and the domain registration fees, please refer to the following.
Domains that you can register with Amazon Route 53
*Please note that AWS credits (coupons obtained through campaigns and promotions) cannot be used for domain registration and renewal fees on Amazon Route 53.
Domain registration requires contact information such as address, email address, and phone number, but there is also a privacy protection setting that hides contact information from WHOIS queries.
Also, typically, a domain that has been registered becomes available by setting up the name servers of the hosted zone, but it is also possible to register name servers other than the four name servers created in the Amazon Route 53 hosted zone.
In other words, a domain registered with Amazon Route 53 can be used not only with AWS services but also by setting up name servers prepared with DNS services in other clouds or on-premises.
For registered domains, it is also possible to use transfer lock to prevent unauthorized transfers to other registrars, and if supported by the TLD registry, you can also use DNSSEC (adding and removing public keys to/from the domain's TLD registry).

Domain Renewal

Normally, the domain validity period in Amazon Route 53 is one year, so it needs to be renewed every year, but you can also set it to auto-renew.
Also, if you prepay the fees, you can extend the domain validity period from one year up to ten years at the time of writing this article.
However, please note that AWS credits (coupons obtained from campaigns or promotions) cannot be used for domain registration and renewal fees on Amazon Route 53.

Domain Transfer

There are several patterns for domain transfer with Amazon Route 53.

Transferring a Domain from Another Registrar to Amazon Route 53

The following are some of the requirements for transferring a domain from another outgoing registrar to Amazon Route 53:

The top-level domain of the domain being transferred is supported by the recipient registrar (in this case, Amazon Route 53)
The domain is already registered with the outgoing registrar
If the domain has been transferred to the outgoing registrar, at least 60 days must have passed since the transfer
If the domain was restored after it expired on the outgoing registrar, at least 60 days must have passed since the restoration
The status code of the domain name on the outgoing registrar does not match any of the following:
pendingDelete, pendingTransfer, redemptionPeriod, clientTransferProhibited, serverTransferProhibited
The domain transfer lock has been removed on the outgoing registrar
DNSSEC is disabled on the outgoing registrar
The contact information of the domain registrant on the outgoing registrar is up to date
For some top-level domains, changes to owner information must be completed
For some geographical top-level domains, the expiration date will not be automatically renewed after the transfer, so you need to extend the expiration date during the transfer to prevent it from expiring

The general outline of the transfer process is as follows:
1. Transfer your DNS service (such as hosted zone settings) to Amazon Route 53 or another DNS service (reproduce the settings in advance)
2. If you are using a DNS service other than Amazon Route 53, obtain the name server information
3. Obtain an authorization code from the outgoing registrar (not required for some top-level domains)
4. Request a transfer from the Amazon Route 53 console (enter the authorization code mentioned above, configure the name server of the DNS service you will use, configure privacy protection, etc.)
5. Carry out the transfer approval process from links such as the transfer request confirmation email
6. Wait for the domain transfer process to complete (generic top-level domains: up to 7 days, geographical top-level domains: up to 10 days)
7. Configure the domain in Amazon Route 53 (set up auto-renewal, transfer lock, DNSSEC, etc.)

Transferring a Domain from Amazon Route 53 to Another AWS Account

The methods for transferring a domain from the current AWS account's Amazon Route 53 to another AWS account include using the Amazon Route 53 API (AWS CLI, AWS SDK) and getting assistance from AWS support.
Here is an example of the transfer command to another AWS account using the AWS CLI.

Example of an AWS CLI command at the source (transfer request)

# aws route53domains transfer-domain-to-another-aws-account --domain-name [Domain to be transferred] --account-id [Recipient AWS account ID]
{
    "OperationId": "xxxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxxxxx",
    "Password": "[Password from the result of the transfer command]"
}

Example of an AWS CLI command at the destination (acceptance of transfer)

# aws route53domains accept-domain-transfer-from-another-aws-account --domain-name [Domain to be transferred] --password [Password from the result of the transfer command]

Transferring a Domain from Amazon Route 53 to Another Registrar

The requirements for transferring a domain from Amazon Route 53 to another recipient registrar include the same items mentioned in "Transferring a Domain from Another Registrar to Amazon Route 53." In addition, it is necessary to check the requirements in accordance with the specifications of the recipient registrar.
The general outline of the transfer process is as follows:
1. If you are transferring the DNS service (such as hosted zone settings), reproduce the settings in advance on another DNS service (you can continue to use the Amazon Route 53 DNS service).
* For functions specific to Amazon Route 53, such as Alias Records, you will need to investigate how to reproduce equivalent functions on the recipient DNS service.
2. Obtain the name server information from Amazon Route 53 or the DNS service to be transferred
3. Obtain an authorization code from the Amazon Route 53 console (not required for some top-level domains)
4. Request a transfer from the recipient registrar (enter the authorization code mentioned above, configure the name server of the DNS service you will use, configure privacy protection, etc.)
5. Carry out the transfer approval process from links such as the transfer request confirmation email
6. Wait for the domain transfer process to complete (generic top-level domains: up to 7 days, geographical top-level domains: up to 10 days)
7. Configure the domain on the recipient registrar (set up auto-renewal, transfer lock, DNSSEC, etc.)

DNS Services

Host Zones

In Amazon Route 53's hosted zones, name servers are assigned for associating with domains, and records are created using the record types described later, for routing configurations to resources.
Amazon Route 53 allows you to use public hosted zones for external release and private hosted zones for Amazon VPC.

Public Host Zones

Public hosted zones create and use records in the zone by setting record types, routing policies, health checks, etc. described later.
Here, I describe the main features of the public hosted zone other than the record settings mentioned later.

Name servers and delegation sets
When you create a public hosted zone, it automatically creates NS records and SOA records.
Four name servers assigned by Amazon Route 53 for each hosted zone are set in the NS records.

These four name servers are called delegation sets, and you can create a reusable delegation set using the CreateReusableDelegationSet API from AWS CLI, AWS SDK, etc (as of the time of writing this article, delegation sets cannot be created from the Amazon Route 53 console).
Because reusable delegation sets can use the same four name servers for all domains used with Amazon Route 53's DNS services, they can simplify DNS service configuration tasks in Amazon Route 53, such as when using domains and subdomains across multiple AWS accounts.
Also, if the hosted zone and the reusable delegation set are created in the same AWS account, the hosted zone can use white label name servers.
While Amazon Route 53 name servers are in the domain format such as ns-0000.awsdns-00.com. (where arbitrary numbers are filled in 0000, 00), by setting up white label name servers, you can use them as subdomain names of your own domain, such as ns1.example.com..

Public DNS Query Logs
Query logs for public hosted zones can be set for each public hosted zone and are stored in Amazon CloudWatch Logs.
The format of the query log is as follows.

[log format version] [query timestamp] [hosted zone ID] [query name] [query type] [response code] [layer 4 protocol] [Route 53 edge location] [resolver IP address] [EDNS client subnet]

Here is an example of a query log.

1.0 2023-06-01T00:00:00Z Z0123456789ABCDEFGHI hidekazu-konishi.com AAAA NOERROR UDP XXX00-XX1 203.0.113.0 -

Private Host Zones

Limitations of private hosted zone routing policies and health checks
Amazon Route 53's private hosted zones provide name resolution for private DNS queries from within Amazon VPC.
To use a private hosted zone, set both enableDnsHostnames and enableDnsSupport in Amazon VPC settings to true and associate Amazon VPC with the private hosted zone.
Private hosted zones have more restrictions on the routing policies and health checks mentioned later than public hosted zones.
Specifically, the Geoproximity routing policy cannot be used in private hosted zones.
The situation as of the time of writing this article is shown in the following table.

Routing Policy	Use in Private Host Zones	Health Check Association in Private Host Zones
Simple Routing	Yes	−
Failover Routing	Yes	Yes
Geolocation Routing	Yes	Yes
Geoproximity Routing Policy	No	No
Latency-based Routing	Yes	Yes
IP-based Routing Policy	No	No
Multivalue Answer Routing	Yes	Yes
Weighted Routing	Yes	Yes

Also, if you are using health checks to monitor the endpoints of Amazon Route 53, it does not support private IP addresses. Therefore, if you want to monitor an instance within a VPC, you need to allocate a public IP address.
On the other hand, the health checks that monitor the metric data streams of Amazon CloudWatch alarms can use the metrics of instances within a private VPC, so they can be used without assigning a public IP address.
Please refer to the routing policy, health check, and failover that will be described later for more details.

Split-view DNS
Private hosted zones in Amazon Route 53 support split-view DNS.
Split-view DNS is a setting that uses the same domain for public and private use.
(Example: Use www.example.com for public and internal.example.com for private)
(Example: Change the returned IP address for console.example.com for public and private use)

You can implement split-view DNS by creating a public hosted zone and a private hosted zone separately and associating the Amazon VPC with the private hosted zone.

Routing priority in case of overlapping namespaces
The private DNS resolver of Amazon VPC is called Amazon Route 53 Resolver (formerly Amazon Provided DNS).
When setting up split-view DNS and there are private and public hosted zones with overlapping namespaces, Amazon Route 53 Resolver routes traffic based on the most specific match with the requested domain name.
Let's give a concrete example of the routing priority when the namespaces overlap in the private hosted zone and the public hosted zone.

(Example) When the namespace example.com overlaps in the private hosted zone and the public hosted zone, and a DNS query for portal.internal.example.com is requested from within Amazon VPC

Amazon Route 53 Resolver searches for a match in the private hosted zone for portal.internal.example.com. If a matching private hosted zone exists, it searches for a record matching the requested domain name, and if a record exists, it returns the value. If there is no matching record, it returns NXDOMAIN (non-existent domain).
If it does not exist, it searches for a match in the private hosted zone for internal.example.com.
If a matching private hosted zone exists, it searches for a record matching the requested domain name, and if a record exists, it returns the value. If there is no matching record, it returns NXDOMAIN (non-existent domain).
If it does not exist, it searches for a match in the private hosted zone for example.com.
If a matching private hosted zone exists, it searches for a record matching the requested domain name, and if a record exists, it returns the value. If there is no matching record, it returns NXDOMAIN (non-existent domain).
If there is no matching namespace in the private hosted zone, it forwards the request to the public DNS resolver.

In other words, when requesting a DNS query from within a VPC in case of overlapping namespaces, the private hosted zone will be searched before the public hosted zone.

Priority of Amazon Route 53 Resolver rules
If the Amazon Route 53 Resolver rule mentioned later routes traffic to the same domain as the private hosted zone, the Amazon Route 53 Resolver rule takes precedence.
Private DNS query log
Query logs of private hosted zones are obtained in the query log of Amazon Route 53 Resolver.
For more information, please refer to the description of the resolver below.

Records

Record Types

The record types supported by Amazon Route 53 are as follows.

A, AAAA, CAA, CNAME, DS, HTTPS, MX, NAPTR, NS, PTR, SOA, SPF, SRV, SSHFP, SVCB, TLSA, TXT

(The HTTPS, SSHFP, SVCB, and TLSA record types were added on 2024-10-30. SSHFP and TLSA are supported for public hosted zones, while HTTPS and SVCB are supported for both public and private hosted zones.)
Among these, you can select alias records in the A records, which I will explain next.

Alias Records

Alias records allow you to associate the Zone Apex, which is the top node of the DNS namespace, with the domain name of a specific AWS resource.
The Zone Apex refers to the domain name itself, which does not include hostnames such as www used in subdomains (e.g., example.com). It is also sometimes referred to as Naked Domain or Root Domain.
Although you can specify a domain as the value in a CNAME record, you cannot specify the Zone Apex.
Therefore, it is useful when associating a domain name (with a variable IP address in the background) used with AWS resources that correspond to the following alias records with your custom domain name.

Amazon API Gateway's custom region APIs and edge-optimized APIs
Amazon CloudFront distribution
AWS Elastic Beanstalk environment
ELB load balancers
AWS Global Accelerator
Amazon S3 buckets
Amazon VPC interface endpoints
Records within Amazon Route 53 hosted zones

About Evaluate Target Health

There is an item called "Evaluate target health" in the Amazon Route 53 record settings.
"Evaluate target health" is an option that you set to "Yes" or "No" to determine whether to assess the health of the AWS resource referred to by the alias record instead of the Amazon Route 53 health check.
For example, if you set "Evaluate target health" to "Yes" with the Application Load Balancer (ALB) as the target, the DNS failover judgment described later will be performed based on the result of the ALB health check.

Routing

Amazon Route 53 has a DNS routing function that changes the value returned to the source of the query depending on the conditions.
Among them, the Geolocation routing policy, Geoproximity routing policy, Latency routing policy, and IP-based routing policy adopt the EDNS0 extension protocol of DNS, and determine the location of the DNS query source using the sender network information sent by the DNS resolver supporting the edns-client-subnet extension.
For DNS queries from DNS resolvers that do not support the edns-client-subnet, the location of the DNS query source is estimated using the source IP address of the DNS resolver.

Routing Policy

Simple Routing Policy
The simple routing policy sets standard DNS records without specifying any conditions for routing.
To use simple routing, set up a simple routing policy and create a record.
Unlike other routing policies, it doesn't allow the creation of multiple records of the same type and name based on conditions, but it allows you to specify multiple values (such as IP addresses).
When multiple values are specified, a random value from the specified ones is returned for each request, but the health check cannot be used, so it is not possible to verify the healthiness of the resource corresponding to the returned value.
If you want to route using health checks for multiple values, use the later mentioned multiple value answer routing policy.
On the other hand, in simple routing policy, only one resource can be specified for alias records.
Failover Routing Policy
The failover routing policy fails over from a record specified with a primary record type to a record specified with a secondary record type, based on the status of the associated health check.
To use failover routing, create a record for the primary record type with an associated health check and a record for the secondary record type.
If the health check status is normal, the record specified with the primary record type is returned; if the health check status is abnormal, the record specified with the secondary record type is returned.
In failover routing policy, alias records can also be used.
Geolocation Routing Policy
The geolocation routing policy routes traffic based on the geographical location (continent-specific, country-specific, or state-specific in the U.S.) of the DNS query origin.
To use latency routing, create a record with a geolocation routing policy set for each geographical location (continent-specific, country-specific, or state-specific in the U.S.) you want to route.
However, geolocation routing uses the location mapped to IP addresses, so some IP addresses that are not mapped to any location cannot be conditioned by geographical location.
In geolocation routing policy, you can also create a default record to route certain IP addresses that are not mapped to any location or that do not match the conditions of any geographical location.
When using a health check with a geolocation routing policy, it searches for a record with a normal health check status in the order of country→continent→default from the records with the same record name, type, and routing setting, and returns it.
In geolocation routing policy, alias records can also be used.
Geoproximity Routing Policy
The geoproximity routing policy routes traffic based on the geographical location of the DNS query source and the resource (the AWS region where the resource to be routed is located, or an area size adjusted by bias based on latitude and longitude).
To use geoproximity routing, create a traffic flow using a traffic policy with a geoproximity rule set (as of the time of writing this article, it cannot be created from the record settings of the hosting zone).
Geoproximity rules define the geographical location based on the AWS region where the resource to be routed is located or the latitude and longitude where non-AWS resources are located, and adjust the range of geographical locations that accept traffic by changing the value of the bias.
While the geolocation routing policy routes by clearly specifying by continent, country, and state in the U.S., the geoproximity routing policy flexibly sets the geographical range across countries and adjusts the amount of traffic to accept.
In geoproximity routing policy, alias records can also be used.
* As of the time of writing this article, the "Geoproximity Routing Policy" is not supported in private hosted zones.
Latency Routing Policy
The latency routing policy routes to the AWS region with the lowest network latency based on the traffic occurring between the end user and the AWS data center.
To use latency routing, create a record with a latency routing policy set for each AWS region you want to route to.
When using a health check with a latency routing policy, it searches for and returns a record in a healthy state among the records with the same record name, type, and routing settings.
Alias records can also be used with the latency routing policy.
IP-based Routing Policy
The IP-based routing policy routes traffic from the source of the query that matches the conditions by referring to the CIDR block of the IP range of the routing target pre-registered.
To use an IP-based routing policy, register multiple CIDR blocks in the CIDR collection as CIDR locations, and create a record with an IP-based routing policy set by selecting the CIDR location to be routed from the CIDR collection.
When routing traffic from an IP range not registered in the CIDR collection as a CIDR block, create a record by selecting the default location.
However, the CIDR block that can be specified to the CIDR collection used for the IP-based routing policy is an IP range from /0 to /24 for IPv4 and /0 to /48 for IPv6, and /32 etc. cannot be specified.
* As of the time of writing this article, "IP-based routing policy" is not supported in private hosted zones.
Multivalue Answer Routing Policy
The multivalue answer routing policy routes by randomly returning after checking the health of multiple values (such as IP addresses) that can be set up to eight, using a health check.
To use multivalue answer routing, register each of the multiple values to be routed in a record using a multivalue answer routing policy and specify a health check.
* Alias records are not supported in the multivalue answer routing policy.
Weighted Routing Policy
The weighted routing policy routes by distributing traffic relatively according to the weight in response to the traffic volume, by allocating a weight to each record that becomes a ratio to the total weight of all routing target records.
To use weighted routing, create a record with a weighted routing policy set for each weight to be routed.
When using a health check with a weighted routing policy, it searches for and returns a record in a healthy state among the records with the same record name, type, and routing settings.
Alias records can also be used with the weighted routing policy.

Health Check

Amazon Route 53 health checks not only have high compatibility with AWS services but can also be used for external monitoring of cloud services and servers outside of AWS.

Types of Health Checks

Endpoint Health Checks
Endpoint health checks are assessed based on response time and number of failures by health checkers around the world.
If more than 18% of the health checkers deem the endpoint as healthy, the endpoint is considered healthy. On the other hand, if the percentage of health checkers considering it healthy is 18% or less, the endpoint is considered unhealthy.
The following are the methods for health checks monitoring endpoints.
- TCP
  This is a health check that is considered healthy if a health checker establishes a TCP connection with the endpoint within 10 seconds.
- HTTP/HTTPS
  This is a health check that is considered healthy if a health checker establishes a TCP connection with the endpoint (IP address or domain) using the HTTP/HTTPS protocol within 4 seconds, and receives a response with HTTP status code 2xx or 3xx within 2 seconds after the connection.
- HTTP/HTTPS and String Match
  This is a health check that is considered healthy if a health checker establishes a TCP connection with the endpoint (IP address or domain) using the HTTP/HTTPS protocol within 4 seconds, receives a response with HTTP status code 2xx or 3xx within 2 seconds after the connection, and then receives a response body containing the specified string within the first 5,120 bytes within an additional 2 seconds.
* When using health checks that monitor endpoints, such as failover records for private hosted zones, for instances within a VPC, you need to assign a public IP address.
Health checks that monitor values calculated from other health checks
Health checks that monitor values calculated from other health checks are those that form a parent-child relationship with health checks and determine healthiness based on the threshold set for the parent health check based on the total number of healthy child health checks, which can be set up to 256.
The following can be used for healthiness judgment of health checks that monitor values calculated from other health checks.
- At least a certain number of all the monitored child health checks are healthy
- All monitored child health checks are healthy
- At least one of all the monitored child health checks is healthy
Health checks monitoring the metrics data stream of Amazon CloudWatch Alarms
You can create a health check that selects an alarm created in Amazon CloudWatch and determines healthiness based on the metrics data stream used in the alarm.
What to note is that this health check uses the metrics data stream monitored by the Amazon CloudWatch Alarm for healthiness judgment, not the result of the Amazon CloudWatch Alarm. That is, this health check detects anomalies without waiting for the result of the Amazon CloudWatch Alarm to become ALARM state.
Since the metrics data stream of Amazon CloudWatch is used, it can monitor without assigning a public IP address to instances within a VPC, even when setting failover records for private hosted zones.

DNS Failover

Amazon Route 53's DNS failover is configured by combining the aforementioned routing policy and health checks (including the Evaluate target health setting for alias records).
If a health check or the Evaluate target health setting in an alias record is set, DNS failover will be conducted in the following sequence:

Select a record with high priority according to the routing policy
If the Evaluate target health of the selected record is Yes through a health check or an alias record, the status of the AWS resource referred to is used to determine its health
If the health of the selected record is normal, return the corresponding record value
If the health of the selected record is abnormal, select the record with the next highest priority according to the routing policy and return to step 2
If the health of the selected record is abnormal and there is no record to select next according to the routing policy, return the value of the last selected record

Note, If there is no health check and the Evaluate target health setting in an alias record is set to No, the selected record according to the routing policy will be returned without determining its health.

Resolver

Amazon Route 53 Resolver

The Amazon Route 53 Resolver is a DNS server that provides the functionality of both a forwarder and a full-service resolver created in the Amazon VPC.
Before the announcement of the Amazon Route 53 Resolver, it was known as the Amazon Provided DNS, supporting only private name resolution within the Amazon VPC.
When an Amazon VPC is created, the default Amazon Route 53 Resolver that is automatically created associates with a DNS server on a reserved IP address, which is the VPC network address plus 2 (for example, if it's 10.0.0.0/16, it would be 10.0.0.2). This functionality corresponds to the former Amazon Provided DNS.
In addition, The Amazon Route 53 Resolver provides inbound and outbound endpoints for name resolution via DNS queries between resolvers located in the Amazon VPC and other networks such as on-premise or other VPCs (hereafter referred to as target networks).
When creating these endpoints, you must assign an IP address to each endpoint and create two or more Elastic Network Interfaces (ENIs) in different Availability Zones (AZs).

Inbound Endpoint

An inbound endpoint is an endpoint for DNS resolvers in the target network to forward DNS queries to the Amazon Route 53 Resolver.
To use an inbound endpoint, the Amazon VPC where the Amazon Route 53 Resolver is located needs to be connected to the network via AWS Direct Connect or VPN.
In the DNS resolver in the target network, it is necessary to set up forwarding DNS queries containing the applicable domain name to the IP address of the inbound endpoint.
The flow of name resolution using an inbound endpoint from the target network is as follows.

A client sends a DNS query with a domain name to be forwarded to the DNS resolver in the target network
The DNS resolver in the target network forwards the DNS query to the IP address of the inbound endpoint
The DNS query is forwarded from the inbound endpoint to the Amazon Route 53 Resolver
The Amazon Route 53 Resolver retrieves the value corresponding to the domain name of the DNS query either by internal name resolution or by recursive query to the public name server
The Amazon Route 53 Resolver returns the value to the inbound endpoint
The inbound endpoint returns the value to the DNS resolver in the target network
The DNS resolver in the target network returns the value to the client

Outbound Endpoint

An outbound endpoint is an endpoint for the Amazon Route 53 Resolver to forward DNS queries to the DNS resolver in the target network.
To use an outbound endpoint, the Amazon VPC where the Amazon Route 53 Resolver is located needs to be connected to the network via AWS Direct Connect, VPN, or NAT Gateway.
An outbound endpoint uses forwarding rules to control the domain names of queries being forwarded to the DNS resolver in the target network.
When creating forwarding rules for outbound endpoints, the following items are specified.

Rule name
Rule type (Forward or System)
Forward: Used when forwarding DNS queries of specific domain names to the DNS resolver in the target network
System: Used when resolving names for specific subdomains out of the specific domain names set with Forward, using Amazon Route 53 Resolver
Target domain name (or subdomain name)
Outbound endpoint
Amazon VPC associated with the rule (origin of the query transfer)
IP address of the DNS resolver in the target network (destination of the query transfer)
*Only specified when the rule type is Forward
Tag

In addition to the forwarding rules for outbound endpoints, there are also auto-defined rules that the Amazon Route 53 Resolver automatically creates for responses to AWS-specific domains and others. If you create a forwarding rule with the same domain as the auto-defined rule, the forwarding rule takes precedence and the query is forwarded to the DNS resolver in the target network.
Additionally, in rule types, besides Forward and System, there is Recursive, which is automatically created under the name "Internet Resolver".
The Recursive rule type is set to perform recursive queries when a domain not existing in the forwarding rules or auto-defined rules is queried.
To avoid recursive queries by the "Internet Resolver" rule and forward all queries to the target network, you should create a rule specifying "." (dot) in the forwarding rules.

Note that the Amazon Route 53 Resolver described here was renamed Amazon Route 53 VPC Resolver on 2025-11-30, when the new internet-reachable anycast resolver, Amazon Route 53 Global Resolver, was announced. The per-VPC behavior described in this section is unchanged.
Resolver endpoints have also continued to evolve: IPv6 support was added on 2023-03-10, DNS-over-HTTPS (DoH) support on 2023-12-20, and DNS delegation for private hosted zone subdomains on 2025-06-24.

Overview of Inbound Endpoint and Outbound Endpoint

I summarize the name resolution of the Amazon Route 53 Resolver's Inbound Endpoint and Outbound Endpoint in a diagram.
* The brown line represents name resolution from Amazon VPC to on-premise environment
* The blue line represents name resolution from the on-premise environment to the Amazon VPC via Amazon Route 53 Resolver
* The green line represents name resolution from the on-premise environment to the Internet via Amazon Route 53 Resolver

Amazon Route 53 Resolver DNS Firewall

Amazon Route 53 Resolver DNS Firewall is a DNS-level firewall that filters the destination domain name for outbound DNS queries sent from Amazon VPC via Amazon Route 53 Resolver, through a blacklist and whitelist.
As the Amazon Route 53 Resolver DNS Firewall is integrated with AWS Firewall Manager, you can deploy DNS firewall rules to multiple member account VPCs from a management account within an AWS Organizations organization.
Also, using the AWS Resource Access Manager (RAM), it is possible to share DNS Firewall rule groups between AWS accounts.
Amazon Route 53 Resolver DNS Firewall is primarily used by setting the following items:

Domain List
The types of domain lists include user-managed domain lists (Owned domain lists) where users add and manage domains, and AWS-managed domain lists (AWS managed domain lists).
You can register multiple domains in the owned domain list.
DNS Firewall Rules
DNS Firewall Rules are created by associating either the Owned domain lists or the AWS managed domain lists and selecting one of the actions: ALLOW, BLOCK, ALERT.
DNS Firewall Rule Group
This is a group of rules consisting of multiple DNS Firewall Rules.
If multiple DNS firewall rules are added, you can specify the priority of application.
The DNS Firewall Rule Group can be associated with multiple Amazon VPCs to apply rules.

DNS Firewall has continued to evolve since its launch: filtering by DNS query type (QTYPE) was added on 2024-01-10, automatic domain-redirection handling for CNAME/DNAME chains on 2024-05-01, and AWS Security Hub integration on 2025-01-13.
Amazon Route 53 Resolver DNS Firewall Advanced, introduced on 2024-11-15, adds real-time monitoring and blocking of DNS traffic based on anomalies in queried domain names, targeting advanced threats such as DNS tunneling and Domain Generation Algorithms (DGA), with protection against dictionary-based DGA attacks added on 2025-11-17 and a preview integration with Palo Alto Networks Advanced DNS Security started on 2026-06-15.

Amazon Route 53 Profiles

Amazon Route 53 Profiles, introduced on 2024-04-22, bundle DNS-related settings, such as private hosted zone associations, Resolver forwarding rules, and DNS Firewall rule groups, into a standard configuration that can be applied to multiple Amazon VPCs in a Region.
Profiles can be shared across AWS accounts via AWS Resource Access Manager, which eliminates per-VPC manual DNS configuration and provides a unified view of DNS settings across accounts in an organization.

Amazon Route 53 Global Resolver

Amazon Route 53 Global Resolver, announced in preview on 2025-11-30 and generally available since 2026-03-09, is an internet-reachable anycast DNS resolver that lets authorized clients anywhere resolve both public internet domains and private Route 53 hosted zone domains.
It provides DNS Firewall based query filtering for threat categories and web content, centralized query logging, and high availability through anycast resolution across multiple selected AWS Regions with automatic failover.
With this announcement, the original per-VPC Amazon Route 53 Resolver was renamed Amazon Route 53 VPC Resolver.

Query Log

The query log of Amazon Route 53 Resolver is used in association with Amazon VPC, and records the following.

DNS queries and their responses that occur within Amazon VPC (including name resolution of private hosted zones)
DNS queries using inbound and outbound endpoints
DNS queries evaluated by Amazon Route 53 Resolver DNS Firewall rules

The query log of Amazon Route 53 Resolver can be saved or delivered to the following services.

CloudWatch Logs log group
Amazon S3 bucket
Kinesis Data Firehose delivery stream

The following is an example of the items and format of the query log.

{
  "version": "[Log format version (example: 1.100000)]",
  "account_id": "[AWS account ID (example: 123456789012)]",
  "region": "[Region (example: ap-northeast-1)]", 
  "vpc_id": "[VPC ID (example: vpc-12345678901234567)]",
  "query_timestamp": "[Query timestamp (example: 2023-06-01T00:00:00Z)]",
  "query_name": "[Query name (example: private.hidekazu-konishi.com.)",
  "query_type": "[Query type (example: A)]",
  "query_class": "[Query class (example: IN)]",
  "rcode": "[Response code (NOERROR)]",
  "answers": [
    {
      "Rdata": "[Response data (example: 10.0.0.10)]",
      "Type": "[Response DNS record type (example: A)]",
      "Class": "[Response class (example: IN)]"
    }
  ],
  "srcaddr": "[Query source IP address (example: 172.31.0.10)]",
  "srcport": "[Query source port (example: 52400)]",
  "transport": "[Query transmission protocol (example: UDP)",
  "srcids": {
    "instance": "[Query source resource ID (example: i-12345678901234567)]"
    or
    "resolver_endpoint": "[Query source resource ID (example: rslvr-in-123456789012345678)]"
    "resolver_network_interface": "[Query source resource ID (example: rni-12345678901234567)]"
  },
  "firewall_rule_action": "[DNS Firewall rule action (example: ALERT)]",
  "firewall_rule_group_id": "[DNS Firewall rule group ID (example: rslvr-frg-1234567890123456)]",
  "firewall_domain_list_id": "[DNS Firewall domain list ID (example: rslvr-fdl-1234567890123456)]",
}

Amazon Route 53 Application Recovery Controller (Amazon Route 53 ARC)

Amazon Route 53 Application Recovery Controller (Amazon Route 53 ARC) primarily possesses two functions: Readiness Check and Routing Control.
In addition to these, Amazon Route 53 ARC now provides zonal shift and zonal autoshift: zonal autoshift, launched on 2023-11-30, automatically and safely shifts application traffic away from an Availability Zone when AWS identifies a potential failure, and shifts it back once the issue is resolved.

Readiness Check

The Readiness Check is a feature that verifies whether the settings, capacity, service limits of AWS resources that constitute an application are scaled to handle failover, and are prepared to avoid failure.
The components that make up the Readiness Check mainly include the following.

Cell
A Cell is a set grouping AWS resources that can run an application independently, representing a unit that can be the primary or replica for failover.
The boundaries between cells are typically separated by availability zones (AZ) or regions.
Recovery Group
A Recovery Group is a unit that groups cells with the same configuration in two or more functional aspects, and constitutes the primary and replicas for failover.
Resource Set
A Resource Set is a unit of the same function that groups multiple cells.
For example, you can make Application Load Balancers (ALB) created in both primary and replica environments configured in multiple regions into a Resource Set.
Readiness Rule
Readiness Rules are rules prepared for each AWS resource type supported by Amazon Route 53 ARC for auditing resources.
The readiness status of each AWS resource is determined based on evaluations according to the Readiness Rules.
Readiness Scope
Readiness Scope is a setting for the range to obtain information on the readiness status of recovery groups and cells within a Readiness Check (Recovery group, cell).
It can be associated with global resources of the entire Recovery Group or with specific cells within the Recovery Group.
Readiness Check
A Readiness Check is a setting for auditing AWS resources grouped by the Resource Set.
The AWS resources subject to the Readiness Check are evaluated based on the Readiness Rules.
By associating the Readiness Scope with the resources of the Recovery Group in the Readiness Check, you can obtain an overview of the readiness status of the Recovery Group and Cells.

Routing Control

Routing control is a feature that provides failover and traffic routing using Amazon Route 53 health checks and DNS resolution, with more detailed conditions than the conventional type.
Amazon Route 53 ARC's routing control mainly has the following features.

It allows for failover based on flexible conditions, such as detailed metrics and logic.
There are safety rules to prevent the drawbacks of automated routing processing, such as failover to unprepared replicas, settings with no routing destination, and route flapping.
It allows for manual overrides of safety rules to deal with recovery from maintenance or sudden condition changes.

The components that configure routing control include the following.

Cluster
The cluster used in Amazon Route 53 ARC's routing control provides endpoints for performing API executions to retrieve and update the state of routing control.
The cluster prepares endpoints redundantly in five regions. In addition, you can operate multiple control panels and routing controls in one cluster.
Be careful, as billing occurs by the hour for the cluster.
Routing controls
Routing controls regulate the traffic flow into cells ON/OFF based on the state of the routing controls, using the routing control health check for Amazon Route 53 ARC.
The state of the routing controls can be retrieved and updated using the Amazon Route 53 Application Recovery Controller API (Route 53 ARC API) or AWS CLI.
This allows for automatic control of traffic routing based on flexible conditions by program code logic, and manual control during maintenance.
Although the state of the routing controls can be retrieved and changed from the AWS Management Console, the method using the Route 53 ARC API is recommended.
Routing control health check
The routing control health check is a health check for Amazon Route 53 ARC associated with the routing control.
The routing control health check is set on the DNS record set (such as failover records) of AWS resources (such as ALB) at the front of the cell.
However, unlike traditional health checks, the status of the health check is not changed based on the state of the endpoint set, but rather, the health check's state is changed by the routing control.
In other words, DNS records with a failover policy associated with the routing control health check failover based on the state of the routing control.
Control panel
The control panel groups multiple routing controls and sets the application of safety rules mentioned later.
For example, you can set routing controls for each ALB in multiple AZs, group them in the control panel, and apply safety rules.
Default control panel
The default control panel is automatically created when creating a cluster, and it is a control panel to add all routing controls created in the cluster.
Safety rule
A safety rule is a rule to prevent accidental decrease in availability due to the recovery action of routing control.
For example, it prevents the drawbacks of automated routing processing, such as failover to unprepared replicas, settings with no routing destination, and route flapping.

Overview of Readiness Check and Routing Control

I will summarize the relationship of terms of Amazon Route 53 ARC's Readiness Check and Routing Control in an overview diagram, based on an example of a configuration consisting of ALB+Auto Scaling (Amazon EC2)+Amazon Dynamo DB (Global Table) in multi-region.

References:
Tech Blog with curated related content
AWS Documentation(Amazon Route 53)
AWS Documentation(Document history - Amazon Route 53)
AWS Documentation(Amazon Route 53 Application Recovery Controller)
Amazon Route 53
What's New with AWS?
AWS News Blog

Frequently Asked Questions about Amazon Route 53 History

When did Amazon Route 53 launch?: Amazon Route 53 was announced on December 5, 2010, and became generally available on May 24, 2011, together with ELB integration (alias records) and Weighted Round Robin routing.
When did Amazon Route 53 add domain registration?: Domain registration became available on Amazon Route 53 on July 31, 2014, together with the Geolocation routing policy. Amazon Registrar became an ICANN-accredited registrar for the .com and .net top-level domains on October 19, 2015.
How have Amazon Route 53 routing policies evolved?: Weighted Round Robin arrived with GA on May 24, 2011, Latency-based routing on March 21, 2012, Failover routing (with health checks) on February 11, 2013, Geolocation routing on July 31, 2014, Geoproximity routing within Traffic Flow on September 1, 2017 (standalone since January 10, 2024), Multivalue Answer routing on June 21, 2017, and IP-based routing in June 2022.
When did Amazon Route 53 Resolver launch, and what is Route 53 VPC Resolver?: Amazon Route 53 Resolver, which provides recursive DNS for VPCs and hybrid name resolution through inbound and outbound endpoints, became available on November 19, 2018. On November 30, 2025, it was renamed Amazon Route 53 VPC Resolver when the internet-reachable anycast resolver Amazon Route 53 Global Resolver was announced in preview; Global Resolver became generally available on March 9, 2026.
When did Amazon Route 53 support DNSSEC?: DNSSEC for domain registration (when using other DNS services) was supported on August 9, 2016, and DNSSEC signing for public hosted zones together with DNSSEC validation in Route 53 Resolver became available on December 17, 2020.
When did Amazon Route 53 Resolver DNS Firewall launch and how has it evolved?: Amazon Route 53 Resolver DNS Firewall launched on March 31, 2021. Query-type filtering was added on January 10, 2024, domain-redirection handling on May 1, 2024, DNS Firewall Advanced (detecting DNS tunneling and DGA anomalies) on November 15, 2024, AWS Security Hub integration on January 13, 2025, and dictionary-based DGA protection on November 17, 2025.
What are Amazon Route 53 Profiles?: Amazon Route 53 Profiles, introduced on April 22, 2024, bundle DNS settings such as private hosted zone associations, Resolver rules, and DNS Firewall rule groups into a standard configuration that can be applied to many VPCs and shared across accounts with AWS Resource Access Manager.
When did Amazon Route 53 Application Recovery Controller and zonal autoshift launch?: Amazon Route 53 Application Recovery Controller became available on July 27, 2021, providing readiness checks and routing controls. Zonal autoshift, which automatically shifts traffic away from an impaired Availability Zone, launched on November 30, 2023.

All dates above follow the primary AWS sources referenced in this article (AWS What's New, AWS News Blog, and the Amazon Route 53 document history). This article is reviewed regularly to incorporate new Amazon Route 53 launches.

Summary

In this article, I created a timeline of Amazon Route 53's history and looked at a list of Amazon Route 53's features and an overview.

Amazon Route 53 offers a wide range of features that have high affinity with AWS, in addition to covering basic DNS service features such as domain registration and hosting of public and private websites.
The ability to configure routing policies and failover features in various patterns, and the health check feature that allows for detailed settings under various conditions can be said to be major advantages of using Amazon Route 53.
In recent years, features that improve the convenience and security of DNS operation in AWS have been introduced one after another, such as Amazon Route 53 Resolver DNS Firewall (and DNS Firewall Advanced), Amazon Route 53 Application Recovery Controller with zonal autoshift, Amazon Route 53 Profiles, new record types (HTTPS, SVCB, SSHFP, TLSA), and Amazon Route 53 Global Resolver.
I would like to continue to watch how Amazon Route 53 will provide what kind of features in the future.

Please note that there is also a timeline of the entire AWS service history, including services other than Amazon Route 53. If you are interested, please check it out.

AWS History and Timeline - Almost All AWS Services List, Announcements, General Availability(GA)

I have also written related historical timelines for the services that Amazon Route 53 works most closely with:

This timeline will be updated as Amazon Route 53 continues to evolve.

Written by Hidekazu Konishi