Route 53 Deep Dive

Reducing latency for your web application

  • You need a domain and hosted zone for your web app for minimum. Then you need a Load Balancer in front of your web server
  • Register vs Host Domains: You can either register a domain natively within Route 53 or transfer a domain from another registrar. You can either just register a domain within Route 53 but then leave the hosting of the domain to another provider or you can go fully Route 53 native. You need to configure name servers to point to Route 53 for 3rd party domain providers.
  • Hosted zone is the actual data. You provide 4 name servers registered to the hosted zone.
  • Hosted zone can be public or private. Private ones are only VPC specific.
  • TTL value: means any other name servers which become aware of the certain record would cache the record sets based on TTL.

Route 53 Record Sets use cases

  • Use an A record if you manage what IP addresses are assigned to a particular machine or if the IP are fixed (this is the most common case)
  • Use a CNAME record if you want to alias a name to another name, and you don’t need other records (such as MX records for emails) for the same name. You can only use CNAME for subdomains.
  • Use an ALIAS record if you are trying to alias the root domain (apex zone) or if you need other records for the same name or you can refer to an AWS logical resource (ELB, CloudFront, S3).
  • Use the URL record if you want the name to redirect (change address) instead of resolving to a destination.
  • You can use S3 as a backup of an EC2 instance web hosting and use an Alias to serve the contents.

DNS Failover

  • Use health checks and associate them with resource record sets
  • DNS server propagates health check notifications globally
  • Set up Fail Whale if both health checks from 2 different path are evaluated as failure
  • Within failover set up, Primary record needs to be associated with the healtcheck on Route53.
  • Geolocation: able to specify a location when you have multiple regions and a specific bucket as well.

Deployment Strategies

  • DNS Wave Deployments: Every Edge Location servers consist of 1 stripe where 1 stripe consists of 4 name servers. Your name servers correspond to many Edge Locations. 1 stripe is supported by many Edge Locations but 1 Edge Location supports 1 stripe only.
  • API Deployments: 3 different fleets: Batch fleet (manages metrics, config etc small things), Operations fleet (used to process change proc but not directly to the customer) and Customer fleet (served API requests, client faced) in Staging Environment. You introduce a mixed mode architecture, old version of the software and new version of the software in two different waves. Then you take it to the production in the same way
  • Conditional Routing Trees: The idea is to utilize Alias Record Sets with health checks and combine them into the decision trees. For your web browser access, it would return more than one name. You can also check depending on the load on each address. If prod1 is less than %50, check prod2 as well and then if both true, return both prod1 and 2 addresses. This is basically shifting the return server depending on the load.

Going Global with Route 53

  • People then started to complain about latency issues within DNS. You would put a CloudFront in front but that might not be enough all the time. Let’s say you spin up 3 stacks in 3 different region. You can associate same private zone that you associated with your VPC with every single VPCs in those regions. Afterwards, you would apply Latency Based Routing among all those three regions. It does not always relate to the geographical region but also ISP details etc.
  • Geo Based Routing for places where AWS don’t have regions, let’s say Africa. Always uses the most specific routing possible. Fail Whale of course works with all these deployments.
  • Reducing failover latency via cache busting: This is in the context of DDoS. Typically used in a DDoS to make it hurdle for the server to respond by giving it more work because it is uncached and it will cause server to perform more work. In this case, we will ensure that our queries are not cached by the DNS failover, thus reducing our failover time.
  • Route 53 Weighted Round Robin: Allowing developers to specify the frequency (weight) with which different DNS responses are returned to end users. You can use WRR to bring servers into production, perform A/B testing, or balance your traffic across regions or data centres of varying size.
  • An alternative to using Auto Scaling groups and elastic load balancing is using Elastic IP addresses with Route 53 record sets. You might consider this solution when you use third-party load balancers, you need to support custom

Healthchecks within Route 53

  • Healthchecks are used for global resiliency, it cannot detect an individual EC2 instance’s health but only the endpoints such as ELB.
  • Utilising HTTP/HTTPS/TCP to configure and Route 53 will monitor the endpoint targets.
  • Here’s what happens when you omit a health check on a non-alias resource record set in this configuration: Amazon Route 53 receives a query for example.com. Based on the latency for the user making the request, Amazon Route 53 selects the latency alias resource record set for the us-east-1 region. Amazon Route 53 looks up the alias target for the latency alias resource record set, and checks the status of the corresponding health checks. The health check for one weighted resource record set failed, so that resource record set is omitted from consideration. The other weighted resource record set in the alias target for the us-east-1 region has no health check. The corresponding resource might or might not be healthy, but without a health check, Amazon Route 53 has no way to know. Amazon Route 53 assumes that the resource is healthy and returns the applicable value in response to the query.

Inbound and Outbound Endpoints

  • Helps you to create private IP addresses so you can access from outside.