Health checking for Route 53 is used to test that the endpoints are reachable and responding to application requests before returning the IP address in response to a query. Route 53 will send a test connection at regular intervals to either an IP address or domain name that you specify. If a resource does not respond, it is considered to be unhealthy. Route 53 will failover to a backup device by changing the IP address that is returned in a query.
In addition to the DNS record monitoring, CloudWatch metrics can be configured using the large number of metrics that are collected by any AWS service. This allows for application-level monitoring as well as the underlying infrastructure such as EC2 instances or microservices. Other CloudWatch metrics that are used with Route 53 health checking include elastic load balancing metrics, a minimum number of servers that are responding, and backend applications such as RDS databases. These metrics are monitored at the streaming level so they are near real time and do not need to wait for CloudWatch to generate an alarm. Figures 3.12 and 3.13 show the basic health checking configuration in the Route 53 console. There are a lot of additional configuration options because of the flexibility of this feature, and the online documentation covers the details.
FIGURE 3.12 Health check configuration step 1
FIGURE 3.13 Health check configuration step 2
Most large organizations do not configure all of their DNS records, policies, and features from a central point of administration. By dividing the domain up into multiple subdomains such as production.tipofthehat.com and development.tipofthehat.com, the configuration duties can be delegated to the individual groups by designating authority of part of a namespace to one or more other DNS servers. This is a common scenario, and Route 53 allows you to delegate with a few simple configuration steps.
Delegating records involves updating the DNS parent domain with the addition of NS (name server) records for the subdomain.
The steps to configure a subdomain delegation start with creating a new hosted zone in a secondary account such as production.tipofthehat.com. Also select if it is a public or private zone in the drop-down box. Click Create and copy the NS records that are assigned to it.
In the main account, create a NS record set from the new delegated zone by selecting the type of name server and enter in the NS records you copied from the new delegated account; click Create to activate the new hosted zone.
Use a tool such as dig production.tipofthehat.com to verify the configuration.
You can now create A records or any other parameters in the new subdomain.
The following shows the basic dig command response for a domain in AWS:
[ec2-user@ip-10-100-1-140 ˜]$ dig tipofthehat.com
; <<>> DiG 9.11.4-P2-RedHat-9.11.4-26.P2.amzn2.5.2 <<>> tipofthehat.com
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 2897
;; flags: qr rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 0, ADDITIONAL: 1
;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 4096
;; QUESTION SECTION:
;tipofthehat.com. IN A
;; ANSWER SECTION:
tipofthehat.com. 60 IN A 54.201.176.99
;; Query time: 18 msec
;; SERVER: 10.100.0.2#53(10.100.0.2)
;; WHEN: Fri Aug 26 21:01:30 UTC 2022
;; MSG SIZE rcvd: 60
Acedexam Training Policies
Learning resources
Other resources
Our Training Providers
