AWS Certified Advanced Networking Prep – Route 53
This post is part of a multi-series blog to help folks prepare to take the AWS Certified Advanced Networking Exam. This section is dedicated to Route 53 and other DNS-related topics. These are important topics to know for the exam. The previous posts can be found here:
Route 53 is an AWS service that provides managed DNS for customers requiring external and/or internal DNS services. Rather than spending time and effort configuring and managing your own DNS infrastructure, customers can simply configure Route 53 to act as the authoritative servers for any domains they own. Route 53 can be used for external DNS for publicly available services, regardless if the application servers are hosted on AWS infrastructure. Route 53 can also be used internally within your VPC as well using private hosted zones. The combination of both external and internal DNS services is generally referred to as split-brain DNS, or split-horizon (I like split-brain, it sounds cooler).
Beyond a simple DNS service, Route 53 offers many integrations with native AWS services. Providing a wide variety of DNS record types and aliases, Route 53 has many options to design disaster recovery efforts, assist with blue/green deployments, and can even be used to provide localized content for users. When creating a new record set in Route 53, you select the record type (i.e., A, CNAME, MX, etc) and select a routing policy to be used which instructs Route 53 how to handle queries.
When creating a new record set in Route 53, you select the record type (i.e., A, CNAME, MX, etc) and select a routing policy to be used which instructs Route 53 how to handle queries. Policies can be as simple as returning a single value for a query, or they can be configured as a decision tree to ensure the requester receives a value based upon things such as server health or a local host to serve content based upon the requester’s location.
Simple routing is exactly what it sounds like and is the traditional sense of routing that you likely already know. Basically, simple routing consists of a record which is queried and returned. Nothing special, no decision making, no determinations made, just a simple query and answer. It is generally a single record. You can, however, have multiple values for the record set and Route 53 will response to requesters in a round robin fashion. Keep in mind though that Route 53 doesn’t take host health into consideration when responding, so it’s possible Route 53 will send requesters an IP address of a host that is not functioning as intended.
Weighted routing is similar to using round robin, but this time there are multiple IP addresses (records) within the record set. The weight of each record will determine how often Route 53 responds to queries with that IP address. The chance of the record being sent to a requester is not only dependant on its own weight but the sum of all the weights within that record set, that is weight / sum value. For example, if a record set has 4 records in which the sum is 20, then a record with a weight of 10 will be sent 10/20 times. If a record has a weight of 5, then it will be sent 5/20 times.
But wait, there’s more…..
You can associate a health check with a record set. If the health check is determined to be unhealthy, it is removed from service. Even more, the weight of this record is no longer included in the total sum of weights within the record set, therefore records with a smaller weight could be sent more often. To demonstrate, let’s consider our example above and assume that the record with a weight of 10 is removed due to a health check. The sum of the weights is now 10 (rather than 20), which means that our record with a weight of 5 now has a 5/10 chance of being sent vs. 5/20 chance, as before. It just went from 25% to 50% chance of being sent to requesters. Here’s hoping you have a larger enough instance or autoscaling enabled for that destination.
One last fact about weights – if you set a record’s weight to 0, it essentially disables that record. But….if all the records within the record set are set to 0, they will be treated as equal and will be distributed as such.
Failover Routing Policies
Failover policies allow a user to create a primary and secondary record for your services, providing a simple solution for disaster recovery. For each health check, the user would apply a health check to ensure the target is up and running as intended. When the primary record is healthy, Route 53 will respond to queries with that record 100% of the time. If the health check fails, Route 53 will start responding to queries with the secondary record to 100% of the requests. If and when the primary record becomes healthy again, Route 53 will respond with the primary record for all requests.
Note: If both records are unhealthy, Route 53 will respond with the primary record.
Latency Based Routing
Latency-based routing allows a user to configure multiple record sets in Route 53, preferably with targets in different regions or even worldwide. When creating each record set, the user selects the specific region as the target. When a user queries Route 53 for a record, the response will be for the target with the least amount of latency to the requester with the idea that the request will be serviced from the fastest, and likely closest, region. To provide this service, AWS actually conducts latency tests across the globe, and depending on traffic and conditions, latency to regions can change quickly, possibly on a daily basis.
Note: If the ideal record is unavailable, due to a health check, the user is sent to the next best record based on latency.
Geolocation routing policies are similar to latency-based routing but they refer to an actual location rather than just the best choice to serve the request. Route 53 records the location of the requester, which is actually based on the DNS resolver the client is using and routes them to the IP of the record set which most closely matches their location. This is a perfect solution for when you want to create and serve local content to users, or even prevent them from accessing content they shouldn’t. For example, if I want to serve localized content for sections of the United States, I could create records, for example, that direct requests from the west coast to an application containing information specific to California. Maybe I want to serve up my application in a countries native language without having to create a separate domain for them.
Similar to routing, geolocation always prefers the most specific location when determining how to respond. The determination looks something like this: State –> Country –> Continent –> Default. For example, if a user from Florida makes a request, and there is a record set for Florida, it will be preferred over a US-based, North American, or the Default record, as it is a more specific location than a US-based location.
Speaking of the Default record, it’s well, the default response if a record set doesn’t match the requester’s location or if the location can’t be determined. Use the Default record to ensure they ultimately land somewhere, regardless of their location. If you want to lock users down to their location, do the opposite and don’t set a Default record, as you can’t default to a record that doesn’t exist 🙂
Health checks are an essential configuration for ensuring your application is running as intended and that users are able to access your applications without interruption. Health checks can be created to test the health of an endpoint, generally so you can configure an action to automatically take place in the event it becomes unhealthy. These checks can be done using HTTP, HTTPS, TCP (IP and port), or even using a domain name (itdiversified.com). Even cooler, then health checks associated with your Route 53 records don’t even have to be the same endpoint for which the record is configured. Once a health check is created, you can’t change the type of the health check (TCP, HTTP, HTTPS) so be sure to select the correct type, at a minimum.
For TCP health checks, Route 53 will simply try and establish a session with the intended host, nothing more. If the session can be established, the health check is considered healthy. This is risky as your web application could be responding with a 404 even though a TCP/80 session can be established. In short, make sure you’re using other types of health checks where possible.
HTTP and HTTPS health checks listen for HTTP response codes that are equal or greater than 200 and less than 400 within 2 seconds of a connection attempt. Even more powerful are the options to check for custom strings on the webpage and configuring the exact path that you want to health check. HTTP/HTTPS health checks can be performed by IP Address or domain name, both allowing you to select the protocol, port, and path to check.
Note: If you restrict access to your application using security groups or third-party solutions, health checks will likely fail as the Route 53 DNS servers won’t be able to access your application, and health checks will always fail. Also, it should go without saying, but IP addresses should change if you’re health checking your application using IP addresses.
If you’re looking to extend your infrastructure to the cloud, it’s highly likely you have some type of established DNS infrastructure on-premises that you’d like to use with your AWS infrastructure as well. As you’re well aware, DNS is a critical service that needs to be rock solid, otherwise, it wreaks havoc throughout your data center. There are a few ways to extend DNS out to AWS, and the most popular architecture that I’ve seen is to use EC2 instances for domain controllers/DNS servers. If you’re not willing to pay for long-term instances in EC2, you can use the “AWS recommended” solution of using Directory Service.
With all that said, there are a few important notes around DNS that you need to be aware of for the test.
The DNS server assigned in a VPC via DHCP cannot be queried outside of the VPC or a peered VPC. This means that on-premises servers cannot resolve records in the native ec2.internal domain. You can, however, set up some type of DNS forwarder or proxy in the VPC to relay those requests originating outside of the VPCs. You can also use Directory Service to do this and use conditional forwarders to send requests to the VPC DNS server. You also can’t create stub zones on Route 53 either, which would assist in delegating queries to your internal domain, using DNS servers on-prem or in EC2.
Last but not least, if you’re going to rely on your on-premises DNS servers for your applications in AWS, make sure that your network architecture is solid and is configured by multiple connectivity options. The last thing you want is for workloads in AWS to fail because of a connectivity issue between your data center and your VPCs.