Application availability can be increased by using the Application Recovery Controller, which is a feature of Route 53 that monitors your endpoints and is used to determine if they have availability and are ready for recovery. You can use the routing control and readiness checking to manage failover using DNS responses to queries. The feature can be used in all regions and availability zones as well as your on-premise applications. It acts as a single control point in the AWS console to manage Route 53’s recovery features. Recoveries can be either active-active and/or active standby. Recoveries can be automated or manually executed.
With built-in intelligence that enhances the Route 53 services beyond basic DNS, it monitors your resource quotas, routing policies, and defined capacity. It will suggest options on how to improve your configurations and when making changes during recovery operations. policies can be configured to prevent premature recovery from happening either manually or with automation. You can configure safety rules to ensure that defined policies are enforced during a failover that prevents automated recovery actions impacting application availability.
Hybrid DNS with Route 53 allows you to interconnect DNS systems from your corporate on-premise servers with Route 53 running in the AWS cloud for end-to-end name resolution. DNS queries originating from AWS can be sent to your corporate DNS for resolution, and corporate DNS requests can be sent to a Route 53 Resolver to access your AWS VPC resources. This allows DNS to work across your entire network. The Route 53 Resolver allows for seamless interconnection of your Route 53 and on-premise systems, as shown in Figure 2.20.
FIGURE 2.20 Hybrid DNS architecture
The Route 53 Resolver is a fully managed AWS service that supports 10,000 queries per second both inbound and outbound. Query metrics are displayed in CloudWatch. The on-premise and AWS cloud are required to be directly connected either by Direct Connect or by a VPN service.
Route 53 is supported when using multiple AWS accounts. It is common for organizations to set up a master AWS account and then create separate accounts for different environments such as production, development, and test, as shown in Figure 2.21. These can all share the same primary domain with subdomains delegated to each account such as prod.tipofthehat.com, dev.tipofthehat.com, and test.tipofthehat.com. Each account can own and manage its own subdomain records and not the others. With the root domain hosted in the master AWS account, the subdomains will be owned by each unique environment’s account.
When you create the subdomains in each account, an NS record will be created. Copy these NS records and add them to the master account’s Route 53 zone. The master account will then reference the NS records for each of the subdomains. What this accomplishes is that the ownership and administration of its hosted zoned is delegated to each specific account so the accounts own the subdomains and do not require administration from the master account. With multi-account Route 53 configured, different teams can now make changes to their individual records, and access is restricted at the account level.
When a DNS request is made for a host in the test.tipofthehat.com domain, a query is made to the tipofthehat.com domain, and its name server will respond with the addresses of the delegated name server for test.tipofthehat.com. The test.tipofthehat.com domain receives a query from the resolver and will then resolve the hostname to an IP address since test.tipofthehat.com contains the host A records are contained. This name server will reply with the requested IP address. This process is shown in Figure 2.22.
Acedexam Training Policies
Learning resources
Other resources
Our Training Providers
