DNS in the Cloud: Amazon Route 53

When we think about DNS, the first thing that usually comes to mind is converting domain names into IP addresses. That’s its job, right? But in the world of AWS, DNS becomes much more than that. Amazon Route 53 is a fully managed service that takes traditional DNS, adds reliability, scalability, and intelligence, and integrates it with the entire AWS ecosystem.

In this blog, we’ll explore how Route 53 works, its role in cloud architecture, and how it can enhance performance and availability for your applications. Later, I’ll also walk you through how to set up DNS failover, so your app continues to run even if one endpoint fails.

What is Amazon Route 53?

Amazon Route 53 is AWS’s Domain Name System (DNS) web service. It’s called “53” after the port DNS uses, but beyond the name, it’s a powerful service that connects user requests to infrastructure running inside or outside AWS. You can use it to route traffic to EC2 instances, load balancers, S3 buckets, or even non-AWS endpoints.

It supports domain registration, DNS record management, health checks, traffic routing based on different strategies, and integrates seamlessly with AWS services like ELB, CloudFront, and more.

One of the things that makes Route 53 stand out is its ability to route traffic intelligently based on health, geography, latency, and weights. This opens up possibilities for high availability, disaster recovery, performance optimization, and multi-region deployments.

Route 53 also offers:

• Health checks and monitoring: Route 53 supports health checks that monitor the status of your endpoints. These checks can run against HTTP, HTTPS, or TCP endpoints and be used as conditions in routing rules. If a check fails, Route 53 can stop including the failed endpoint in DNS responses. Combined with failover or multivalue routing, this helps keep your application available even if something breaks. You can also integrate Route 53 with CloudWatch for monitoring, alerts, and automated remediation if needed.
• Traffic flow control: Route 53 supports multiple routing policies, including failover, geolocation, latency-based, and weighted routing. We will explore these in the next section.
• Domain registration: Route 53 can also act as your domain registrar. You can register new domain names directly from the AWS console and manage DNS records all in one place. This is useful when building a new project or migrating an existing DNS to AWS.

AWS Regions and Availability Zones — where DNS comes into play

Before diving deeper, it’s worth understanding how AWS is structured. An AWS Region is a physical location in the world where AWS has multiple data centers. Each Region contains multiple Availability Zones (AZs), which are isolated locations that offer redundancy. Route 53 operates globally but can be used to direct traffic intelligently across these zones and regions. You could, for example, route users to the closest Region with the lowest latency or automatically failover to another Region if the primary one goes down.

How Routing Works in Route 53?

At the heart of Route 53 are routing policies. These are strategies you can apply to DNS records to control how requests are handled. Let’s look at them:

Simple routing

This is the basic one: you create a record that maps a domain name to a single resource, like an IP address or ELB.

Weighted routing

This lets you split traffic between multiple resources based on assigned weights. For example, you could send 80% of traffic to one server and 20% to another. This is useful for gradual rollouts or A/B testing.

Latency-based routing

With this, Route 53 directs users to the AWS Region that gives the best latency, improving response time for globally distributed users.

Failover routing

One of the most practical features. You set up a primary and secondary resource. Route 53 monitors the primary, and if it fails a health check, traffic is automatically redirected to the backup.

Geolocation and Geoproximity

These help you serve content or route traffic based on where users are located. Geolocation uses country/region, while geoproximity allows more fine-tuned biasing using AWS Regions and IPs.

Multivalue answer routing

You can return multiple healthy IP addresses to clients, adding some redundancy without a full-blown load balancer.

Practical — Amazon Route 53 Failover Routing

In this section, we will follow a scenario of a Cafe Online Order system and set up DNS failover for a simple web application using Amazon Route 53. The goal is to route traffic to a backup web server if the primary one becomes unavailable. This is done by combining health checks, failover routing policies, and Route 53 DNS records.

We’re working with two EC2 instances, running a LAMP stack, and hosting the same café website. Each one is placed in a different Availability Zone inside the same region. This ensures high availability across multiple zones.

The final setup will look like this:

Route 53 will serve the domain name that maps to the primary server. It will continuously check the health of that server. If it goes down, traffic will be automatically rerouted to the secondary instance, and an email alert will be sent. This is a simple and effective way to achieve failover using DNS.

Let’s get started!

Confirming the café websites

First, we check that both EC2 instances are up and the café application is running on each.

1. In the AWS Management Console, we will go to the EC2 Instances section. Here, we will see two instances already deployed, one in us-west-2a and the other in us-west-2b. Both are named appropriately: CafeInstance1 and CafeInstance2. We will copy the IP addresses of both instances and keep them in our notes.

These instances are pre-configured with the full LAMP stack and have the café website already deployed. Each instance acts as a web server serving the same application.

2. Next, we will open a browser and visit the website on the primary instance. The café homepage should load and display server information, including the Availability Zone and instance metadata. The URL in this case will be: http://44.250.104.85/cafe/

3. We will do the same with the secondary web server to confirm that both instances are running the same application in their respective zones. The URL will be: http://54.68.204.15/cafe/

This confirms that both EC2 instances are live, identical, and serving the café application across two different Availability Zones for high availability.

Configuring a Route 53 health check

Next, we will move on to configuring a Route 53 health check for the primary web server. This health check will continuously monitor the server’s `/cafe` path and notify us if it goes down.

1. We will begin by heading to the Route 53 console from the AWS Management Console. In the left sidebar, we will choose Health checks, then click Create health check.

2. In the setup form, we will enter the following:

• Name: Primary-Website-Health
• What to monitor: Endpoint
• Specify endpoint by: IP address
• IP address: This will be the public IPv4 address of CafeInstance1, which we can grab from the EC2 console or from our earlier notes.
• Path: /cafe

3. Next, we will expand the Advanced configuration and change the settings to make the health check more responsive:

• Request interval: Fast (10 seconds)
• Failure threshold: 2

This will ensure that Route 53 reacts quickly if the instance becomes unreachable.

4. In a real-world scenario, we could create a CloudWatch alarm tied to this health check and configure it to send out email alerts via Amazon SNS. This is especially useful for operational awareness. However, for this walkthrough, we’ll skip the email notification setup.

5. Once created, Route 53 will begin monitoring the health of the primary instance. It may take a minute or two for the status to show as Healthy. We can check this by selecting the health check and opening the Metrics tab. However, no data is available at the time of creation of this health check.

Configuring Route 53 Failover DNS Records

With the health check in place, we’ll now configure two A records in our Route 53 hosted zone, one for the primary web server and one for the secondary. This setup will let Route 53 route traffic to the primary instance when it’s healthy, and automatically fail over to the secondary when it’s not.

1. We begin by heading over to the Route 53 console and selecting Hosted zones from the left panel. A hosted zone has already been created for us. The domain name looks like XXXXXX_XXXXXXXXXX.vocareum.training, unique to this lab environment.

2. We open this domain to see the default records already present:

• The NS (Name Server) record, listing the four authoritative name servers.
• The SOA (Start of Authority) record, defining DNS metadata for the zone.

We leave both as-is.

Now we’ll add our first A record that will be for the primary instance.

3. Click Create record, and fill in the following:

• Record name: www
• Record type: A – Routes traffic to an IPv4 address
• Value: The public IP address of CafeInstance1 (44.250.104.85)
• TTL (seconds): 15
• Routing policy: Failover
• Failover record type: Primary
• Health check ID: Primary-Website-Health
• Record ID: FailoverPrimary

And then click Create records.

This will create the primary failover A record. It should now appear in the list of DNS records in the hosted zone.

3. Next, we’ll repeat the process to create the secondary failover record, which Route 53 will use if the primary instance goes down.

Click Create Record again, and enter the following:

• Record name: www
• Record type: A
• Value: The public IP address of CafeInstance2 (54.68.204.15)
• TTL (seconds): 15
• Routing policy: Failover
• Failover record type: Secondary
• Health check ID: (leave blank)
• Record ID: FailoverSecondary

With both records in place, we’ve completed the DNS routing setup. Requests to www.XXXXXX_XXXXXXXXXX.vocareum.training will now go to the primary instance when it's healthy, and automatically switch over to the secondary if the primary becomes unreachable.

5. To confirm that Route 53 is routing traffic to the primary server, open a new browser tab and visit the domain name, which in this case will be

The café web page should load, and the Server Information section should show the primary instance running in us-west-2a, indicating that DNS is resolving correctly.

Simulating Failover and Verifying

Now that we’ve configured everything, it’s time to test whether Route 53 correctly fails over to the secondary instance when the primary becomes unavailable.

1. Go to the EC2 console, select CafeInstance1, and from the Instance state dropdown, choose Stop instance. Confirm the prompt.

2. Head to the Route 53 console → Health checks → select Primary-Website-Health. Wait for the status to change to Unhealthy. This may take a minute or two. Refresh the page if needed.

2. Go back to your browser tab with the café website open and hit refresh. Once the DNS propagates, Route 53 will begin serving traffic from the secondary instance.

You’ll know the failover worked when the Server Information on the page shows the other Availability Zone (like us-west-2b instead of us-west-2a).

What’s Next?

Here are some ideas for what you can try next:

• Integrate CloudWatch Metrics: Trigger more complex failover scenarios based on performance thresholds instead of just availability.
• Test Multi-Region Failover: Extend the setup across regions instead of just Availability Zones for full regional disaster recovery.

Wrapping Up

In this blog, we explored Amazon Route 53 and how it helps implement fault-tolerant architectures using DNS-based failover. We walked through configuring health checks, setting up primary and secondary routing policies, and finally tested failover in action by simulating a failure. With this setup, traffic automatically shifts between instances across different Availability Zones, ensuring high availability even if one of the web servers goes down.

While our example used simple EC2 instances serving a café website, the same failover strategy can be applied to more complex production systems, especially when availability and reliability are key business requirements.