🍁 Route53: In brief 🍁

Pre-requisites
Understanding of DNS routing is necessary.Click here to have some picturesque. Route 53 is an Authoritative DNS and webserver i.e. ISP DNS finally contacts Rout53 which has IP address of the webserver.

Gotchas
🦋 Route53 just gives the reply (IP) doesn't route traffic
🦋 For every request(query) it process ...i.e. it is charged
🦋 Has option to balance queries in different regions.
🦋 Integrates with other AWS services
🦋 Register domain names

Routing policies in brief

1. Simple routing policy
   It is as simple as it sounds!
   EX:
   🍕 An application is running behind the Load balancer.
   🍕 Users need to connect to Load balancer. Therefore, make the entry of Load balancer into Route53
   🍕 Now when a user requests to ashwiniag.com, at first it goes through DNS resolving routine and it encounters Rout53 which in our case its Authoritative DNS. Rote53 will give the IP with TTL.
   🍕 User's system will then makes the direct connection with ashwiniag.com

2. Latency based routing
   It connects user's requests to the desired destination depending upon how close a user is i.e. considering the latency.
   Ex:
   🍕 An environment is set up in two different regions, same application is running in both regions. Let's say the Regions are:
   a. Mumbai
   b. Virginia
   🍕Now consider User is located somewhere near to Mumbai.
   🍕 User makes a request.
   🍕 Route53 knows the latency between User and the Regions, i.e. it is
   a. 10 ms (User to Mumbai)
   b. 50ms (User to Virginia)
   🍕 Hence, Route 53 will give Mumbai Regions' IP address.
   🍕 Remember Route53 doesn't route the traffic its job is it to give IP address. Based on the latency which is shorter for the user, so it can be faster for User to get connected Route53 will give that respective region IP address.

3. Weighted routing policy
   Distributing users among the regions based on the percentage provided by us.
   Ex-1:
   🍕 An application is running in three Regions. I configure Route53 saying only this percentage of requests should be coming to the respective regions. Let's say
   a. Mumbai [53%]
   b.Virginia[27%]
   c.London[20%]
   🍕 Route53 resolves by providing IP addresses depending on the percentages.
   Think as Route53 maintains a request list in sequence. So whoseever requests come first will receives IP of Mumbai until 53% is achieved and same with rest.
   EX-2:
   🍕 100 users make requests.
   🍕 Maybe for the first 53 requests it will give Mumbai's IP, for the next 27 Virginia of and to the rest give IP of London. It gives IP address such a way that this percentage of user will attend in the respective region.
   🍕 To broaden the understanding, consider a user X, its request was made which came under in first 53 requests which got the IP of Mumbai. User X finished its work. Later in some time user X will make the request again. It may receives IP of either Virginia/London...can also be Mumbai too depending on its requests position is in what sequence under Rout53.

This policy is good for rolling updates.

4. Geolocation routing policy
   Its more of like a static route... having the same IP.
   Allowing to control the content User will be accessing
   Ex:
   🍕 I have an application that has little different setup based on some parameters running in three different regions.
   🍕 Let's think of youtube..makes it easier to understand. Youtube content for India it's little different than for London/virginia...etc.
   🍕 So by default based on where User is located only that particular region's local content will be displayed until (s)he searches it explicitly.
   🍕 Think I have set up youtube in three regions having control over Users content. i.e.
   a. Mumbai
   b. London
   🍕 Now, whenever user makes a request who is located in Mumbai, will only get the IP of the mumbai region.
   🍕 Or user requests coming from London will get the IP of London region only.
   🍕 Hence, by default user will receive the local content generalized to their geological area. This way we can have control over user content.

5. Failover routing policy
   Extremely useful at disaster recovery
   Rout53 does health check at the backend and provides IP of healthy LB.
   Ex:

🍕 An instance running in Mumbai.
🍕 And I have kept some backup in London.
🍕 User makes requests.
🍕 Route53 checks if my Mumbai environment is working fine..is healthy?
If not the link to London gets active...It sends IP of London to user
now user's system will establish a connection with London where my backup environment is setup.
🍕 So this way even if my environment fails, I don't lose valuable customers, in fact I can route them to London displaying static page apologising for the inconvenience. You are valuable to us!
🙆🏻‍♀️ By the way, I forgot to tell that along with IP address TTL is also provided by ROute53. Which mean...TTL defines how long the IP address is supposed to live in user's cache whether its 2 sec or a day could be anything. Once that TTL time expires the entire process of resolving DNS and connection establishment happens. Do yourself a favor and go through DNS working.

🍀 My point here is, let's say I set the value for TTL as 2min. The first request of a user comes in, hits Route53, gets the IP, users get connected to webserver...doing its work. My Route53 has charged me for resolving that request query. Let's say after 10 min the same user makes second requests since the TTL time is exhausted it has to go through entire process and I'll be charged again for the query resolving.

🍀 Now Imagine 1000s of requests are coming from different users. In an hour if users are making requests again and again for whatsoever reason, I will be charged for all those queries again and again if in that hour once TTL is expired.

🍀 Meaning if a particular user is making 100+ requests in the time interval of every 5min for whatsoever and I have kept TTL as 2min...then ill be charged for all 100+ requests in that hour...I will have to pay so much. It ain't wise...certain things have to be lept in mind.
For each request processed by Rout53 it is charged.