What is Route 53?

Amazon Route 53 is AWS's DNS service. It translates a domain name, such as www.example.com, into the IP address or destination needed to reach your application.

Think of DNS as the internet's phonebook. Users remember domain names, while computers use IP addresses to communicate.

For example, instead of asking users to remember an EC2 public IP address, you give them a domain name such as app.example.com. 2. How does Route 53 work?

1. User's browser

Opens app.example.com

2. DNS resolver

Looks up the domain's DNS record

3. Amazon Route 53

Returns the appropriate DNS answer

4. Load balancer

Receives the user's application request

5. Application

EC2, ECS, or EKS workloads serve the request

Here is the flow in simple steps:

1. The user enters app.example.com in the browser.
2. The browser's DNS resolver looks for the domain's DNS record.
3. Route 53 returns the configured destination, such as an Application Load Balancer.
4. The browser connects to that destination.
5. The load balancer forwards the request to the appropriate backend application. Important interview point: Route 53 resolves the domain name. It does not normally carry the application's HTTP traffic itself.
6. What are Route 53 routing policies? A routing policy tells Route 53 which DNS answer to return when a user requests your domain.

These are the main policies to know for interviews.

1. Simple routing

Routes a domain to one or more configured values without policy-based traffic distribution or health-based failover.

Example: Route app.example.com to one application load balancer.

Use when: You have a basic application with a straightforward DNS setup.

2. Weighted routing

Distributes DNS responses according to configured weights.

Example: Send 90% of DNS responses to the stable environment and 10% to the new version.

Use when: Canary releases, gradual traffic shifts, or splitting traffic between environments.

3. Latency-based routing

Routes users to a configured endpoint in the AWS Region expected to provide the lowest network latency.

Example: Your application runs in Mumbai and Singapore. Route 53 selects the region expected to give a user the lower latency.

Use when: You want better response times for a globally distributed application.

4. Failover routing

Uses primary and secondary records for active-passive disaster recovery. Health checks can help Route 53 return the secondary destination when the primary is unhealthy.

Example: Primary application in Mumbai, disaster recovery application in Singapore.

Use when: You need a disaster recovery strategy.

5. Geolocation routing

Routes users based on their geographic location, such as their country or continent.

Example: Send Indian users to an India-specific application and UK users to a UK-specific application.

Use when: You need location-specific content or regional requirements.

6. Geoproximity routing

Routes traffic based on the geographic location of users and resources. You can use a bias value to expand or shrink the geographic area served by an endpoint.

Example: Shift more users toward one region by increasing its geographic coverage.

Use when: You need geographic traffic distribution with adjustable regional boundaries.

7. Multivalue answer routing

Returns multiple healthy record values in a DNS response, where applicable, rather than relying on one value.

Example: Return several healthy server IP addresses for a domain.

Use when: You want DNS responses to include multiple healthy endpoints. It is not a replacement for a full load balancer.

8. IP-based routing

Routes requests based on the source IP address or CIDR ranges configured in Route 53.

Example: Route requests from specified corporate IP ranges to a particular endpoint.

Use when: You need DNS routing based on known client networks.

4. Quick interview revision Requirement Routing policy
   1. Basic DNS setup <=>Simple
   2. 90/10 traffic split <=>Weighted
   3. Lowest expected network latency <=>Latency-based
   4. Primary and disaster recovery endpoint <=>Failover
   5. Route by country <=> Geolocation
   6. Adjust geographic coverage with bias <=>.Geoproximity
   7. Return multiple healthy DNS answers. <=>Multivalue answer
   8. Route by client IP range <=> IP-based
5. Model interview answer You can say this in your interview:

“Amazon Route 53 is a highly available and scalable DNS service that translates domain names into the appropriate destinations. When a user accesses my application, Route 53 resolves the domain and returns a configured DNS answer, such as an Application Load Balancer.

Route 53 supports several routing policies. I use simple routing for basic applications, weighted routing for canary releases, latency-based routing for globally distributed applications, and failover routing for disaster recovery. I use geolocation when routing depends on the user's location, geoproximity when geographic traffic distribution needs adjustment, multivalue answers to return multiple healthy endpoints, and IP-based routing for specific client networks.

I select the policy based on the application's availability, performance, traffic distribution, and disaster recovery requirements.”

One important senior-level detail: DNS answers can be cached according to their TTL, so a routing-policy change does not guarantee that every user switches destinations immediately. Also, Route 53 health checks and routing policies do not replace application-level monitoring or load-balancer health checks.

“Amazon Route 53 is a highly available and scalable DNS service that resolves domain names to application endpoints. When a user accesses my application, Route 53 evaluates the DNS records and routing policy, then returns the appropriate destination, such as an Application Load Balancer.

In production, I use simple routing for basic applications, weighted routing for canary deployments, latency-based routing for multi-Region performance, and failover routing for disaster recovery. I use geolocation for location-specific routing, geoproximity for adjustable geographic distribution, multivalue answers to return multiple healthy endpoints, and IP-based routing for specific client networks.

I select the policy based on performance, availability, disaster recovery, and business requirements. I also account for DNS caching and TTL because routing changes may not take effect for every user immediately.”

One important distinction: latency-based routing and geolocation routing are not the same. Latency-based routing aims to select the Region with the lowest expected network latency. Geolocation routes according to where the user is located, even if that location is not the lowest-latency option.

Amazon Web Services+1

Your next mock interview question

Your application runs in Mumbai and Singapore. Mumbai is the primary Region, and Singapore is the disaster recovery Region. If Mumbai becomes unhealthy, you want users to be directed to Singapore.

Which Route 53 routing policy would you choose, and how would you configure it?

Answer in your own words, and I'll evaluate it at the 7 to 8 years of DevOps experience level before moving to a new question.

Thanks for waiting. Route 53 is AWS's DNS service. It translates your domain name into the right destination, like a load balancer. Routing policies control which DNS answer based on rules you set, not proxying the HTTP the HTTP traffic itself. DNS requests, checks the domain's DNS records, applies the routing policy you configure, and returns the right answer, like a load balancer address. In production I would use simple routing for basic apps, weighted for canary releases, latency-based for multi-region performance, and failover for disaster recovery, like making Singapore the backup if Mumbai fails. And I'd remember that latency-based routing is about network speed, while geolocation is based purely on where the user is. Quick follow-up, if Mumbai is the primary region, Singapore is the disaster recovery region, what routing policy would you choose to send users to Singapore if Mumbai becomes unhealthy?

=======================================

Sure, just a second. Let's do this in simple language. Imagine you previously used an EC2 public IP, then moved to a public load balancer in front of your private instances. You'd update the Route 53 record to an alias A record pointing to the load balancer, not the EC2. So users still type your domain, but traffic goes to the ALB, which forwards it to your private service. That's the clean and standard way. Now the last one. What happens if the target group shows unhealthy, even though your CPU is 70%?

Let's understand it in simple language. 😊 How would you handle DNS with Route 53 after moving to a load balancer? Imagine your application was previously accessed using an EC2 public IP address. Now you've moved the application to private subnets and placed a public Application Load Balancer (ALB) in front of it.

You want users to continue accessing the application using the same domain, for example, www.myapp.com. Architecture and traffic flow User's browser

www.myapp.com

Amazon Route 53

Alias record points to the ALB

Public Application Load Balancer

Receives the HTTP/HTTPS request

Private EC2 instances or EKS pods

Process the request and return the response

What would you configure?

1. Open Amazon Route 53 and select your hosted zone.
2. Create or update the DNS record for www.myapp.com.
3. Choose an A record with Alias enabled and select your Application Load Balancer as the target.
4. Verify that the ALB listener and target group are healthy.
5. Test the domain and monitor traffic after the change. The important point is that you map the domain to the load balancer's DNS name, not directly to the private EC2 instance. Route 53 resolves the domain to the load balancer, which forwards requests to healthy application targets. Interview-ready answer "I would update the Route 53 hosted zone and configure an Alias A record pointing to the public Application Load Balancer. The ALB would forward incoming traffic to healthy EC2 instances or EKS services in private subnets. This allows users to access the application through the same domain without exposing the backend instances directly to the internet. I would validate DNS resolution, load balancer health checks, and application connectivity after the change."

Remember: Route 53 handles DNS resolution, the ALB handles incoming traffic distribution, and the private instances handle application processing.