Outbound endpoints allow DNS resolutions originating inside of your VPC to your on-premise DNS deployment or to another VPC. As with all DNS endpoint architectures, a direct connection is required and can be either the DX, Direct Connect, service or by using a VPN connection. Outbound DNS queries require forwarding rules to define the domains hosted on-premise, and the rules define what will be forwarded to the on-premise resolver when a query is made in your VPC.
Figure 3.29 shows the architecture of the outbound endpoint, and Figure 3.30 shows the basic configuration screen. You must give the endpoint a name, the VPC in the region, a security group, and the IP address information. When finished, click Create and validate the changes in the resolver VPC section of the Route 53 console.
FIGURE 3.29 Outbound resolver endpoints
FIGURE 3.30 Outbound endpoint configuration
Endpoints can be configured as inbound only for DNS resolutions originating outside of the VPC such as from another VPC or from your internal network. The Route 53 Resolver inbound endpoints terminate DNS queries from outside of the VPC to the internal Route 53 infrastructure. When connecting your on-premise DNS infrastructure to the VPC, the networks must share a direct connection using either a DX or VPN service that can route between the two networks. Figure 3.31 shows the architecture of the inbound endpoint, and Figure 3.32 shows the basic configuration screen. You must give the endpoint a name, the VPC in the region, a security group, and the IP address information. When finished, click Create and validate the changes in the resolver VPC section of the Route 53 console.
FIGURE 3.31 Inbound resolver endpoints
In this section, you will learn how to configure the many different options available to collect logging and metrics on Route 53 and how to use the collected data to ensure the availability, reliability, security, and performance of your Route 53 deployment.
Before implementing your monitoring strategy, it is valuable to analyze what your needs are. Questions to ask yourself include the following: What is it exactly you are looking to accomplish? Are there any corporate or regulatory requirements for data retention? What Route 53 resources are you intending to monitor? What is the data collection frequency you require? What AWS tools can you use to accomplish your monitoring and logging plan? Which internal groups will be responsible for the day-to-day monitoring and logging operations? Is it better to outsource to an external service company that specializes in this area and has special tools you can leverage? Do you have an escalation plan in place to notify individuals and automation services of critical events?
FIGURE 3.32 Inbound endpoint configuration
CloudTrail is the AWS service that logs activity from users, roles, or other services. If there are console, CLI, or application actions taken, it is an API call behind the scenes, and it gets logged in CloudTrail. Route 53 CloudTrail actions are stored in an S3 bucket that you define for long-term storage and are also cached for the short term in the CloudTrail service in its event history logs.
There is a great deal of event information collected, including the source IP of the request, who made the request, the date and time, and any other pertinent information including what the change was.
The event logging is in the Northern Virginia region since Route 53 is a global and not regional service. See Figure 3.33 for an example of the CloudTrail console for a Route 53 trail.
Acedexam Training Policies
Learning resources
Other resources
Our Training Providers
