Before we started using Amazon’s Route 53 service, for every new sign up we had to manually go create a subdomain for each customer to provide search APIs. This required a longer sign-up and integration cycle as we had to go to our cPanel and manually add a subdomain name for each client. With Amazon Route 53, for every sign-up for Unbxd Search, we automatically create a sub-domain and published APIs for the user. Using Route 53 removed the manual intervention required for onboarding a customer. It also enabled our customers to begin testing searches soon than our earlier approach. Finally, once they are done tweaking the search configuration through the dashboard to meet their business rules, they can begin integration of Unbxd search into their e-commerce site search box. The below diagram explains how Unbxd Search is consumed by the end-user:

The ability to create a DNS record on the fly through your application automatically is extremely useful. Managing infrastructure using APIs within your application becomes a powerful feature as it takes out any manual intervention needed on our behalf for the end-user to use the service. I will describe briefly the advantages of going with Route 53 as a domain name service and how we utilize it. Route 53 lets you create a hosted zone that represents a collection of resource record sets under a domain name, in our case the domain name being unbxdapi.com. Route 53 supports a wide variety of DNS resource record types. We typically create A Records to point it to our search load balancer. The real power of Route 53 is in creating a record set where a Routing Policy can be defined.

Route 53 provides three routing policy options, namely:

• Simple
• Weighted Average
• Latency Based Routing

Typical scenarios where weighted resource record sets could be used are:

• DNS level load balancing
• Live A/B testing of newly deployed code. One could assign a really small weight to a record set entry and thereby see a small percentage of its users directed to the cluster.

Traffic vs performance could be monitored until one is sufficiently confident to migrate completely to the new version of code.

With latency-based routing, one actually can control scenarios. For instance, let’s say a request originates from India and we would like that request to be served from the AWS APAC region compute servers. This can be achieved by “configuring two or more latency-based record sets with matching names and types, then the Route 53 name servers will use network latency and DNS telemetry to choose the best record set to return for any given query.” If you want to dig deeper into Route 53 resource sets and their routing policies, here are the links to the official documentation: Resource Record Sets Weighted Resource Record Sets Latency What would really interest me is a combination of both policies. A scenario where I want all my Europe-based visitors to be redirected to the new version of the code. I’m not sure if this sort of use case could be supported by Route 53 or if Amazon is planning on implementing this feature. I’ll end by saying that Route 53 is a very good service for automating the creation of your infrastructure management through a simple API. I would be more than happy to hear your suggestions and comments on this post. You can also contact me at Varun [AT] unbxd.com or tweet me at @varunthacker.