Complete Guide to Amazon Route 53: Learning “DNS and Traffic Control” Design Through Comparisons with Google Cloud DNS and Azure DNS / Traffic Manager
Introduction
Amazon Route 53 is a service that centers on AWS’s authoritative DNS, while also handling domain registration, health checks, DNS failover, and various routing policies. AWS’s official documentation explains that Route 53 provides not only DNS services but also functions such as health checks and VPC Resolver, and that its routing policies can distribute traffic based on user location, resource location, latency, IP address, and health checks.
In GCP, the closest core service is Cloud DNS, while in Azure, Azure DNS is the equivalent. However, functions in Route 53 such as “DNS failover” and “latency/performance-based routing” are more naturally compared in Azure not with Azure DNS alone, but in combination with Azure Traffic Manager. Cloud DNS uses a simple pricing model based on zones and queries, Azure DNS is also mainly charged by zones and queries, and Traffic Manager is mainly charged by DNS queries and health checks.
In this article, I will organize Route 53 not as “just a service for name resolution,” but as a design target that includes public DNS, internal DNS, availability design, multi-region switching, and cost optimization.
1. What is Route 53?
Route 53 is AWS’s fully managed DNS service. It can be used not only as a foundation for name resolution, but also to handle domain registration, public hosted zones, private hosted zones, health checks, and various routing policies together. The official guide also shows that Route 53 provides DNS services in addition to health checks, DNS failover, and VPC Resolver.
Put simply, Route 53 is strong because it can take care of the following three things together:
- Internet-facing DNS
- Internal DNS for VPCs
- Traffic control designed around availability, geography, and latency
In particular, once you begin using multiple regions, multiple Availability Zones, and multiple endpoints on AWS, it becomes important to design not just DNS management but also where traffic should be sent. That is where the value of Route 53 rises sharply.
2. Mapping to Equivalent Services in GCP and Azure
GCP: Cloud DNS
Cloud DNS is Google Cloud’s managed DNS service. According to the official pricing page, billing is mainly based on the number of zones and the number of queries, and there is no free tier. Its role is quite close to the authoritative DNS part of Route 53, but functions such as the health-check-linked failover and rich routing policies of Route 53 do not map directly into a single service in the same way.
Azure: Azure DNS + Traffic Manager
Azure DNS is the service responsible for authoritative DNS hosting. Traffic Manager, on the other hand, is a DNS-based traffic distribution service that provides routing such as performance-based routing, failover, and round robin, along with health checks. In other words, in Azure, it is easiest to understand Route 53 as having some of its functions split between Azure DNS and Traffic Manager.
This difference affects design.
In AWS, it is easy to place both “DNS and routing” into Route 53. In Azure, by contrast, it is easier to think in terms of role separation: “names in Azure DNS, routing in Traffic Manager.” GCP tends to keep DNS itself relatively simple, with higher-level distribution often handled by other services or architecture choices.
3. The Basic Structure of Route 53
Hosted Zones
The central concept in Route 53 is the hosted zone.
- A public hosted zone is for Internet-facing use
- A private hosted zone is for internal name resolution inside a VPC
This separation becomes the first branch in operational design. It is easier to manage permissions and reduce the risk of accidents when names visible from the Internet and names meant to resolve only inside the company or VPC are not mixed together. Some Route 53 routing policies can also be used with private hosted zones.
Records
The DNS records themselves use common concepts such as A, AAAA, and CNAME, but a major feature of Route 53 is that when creating a record, you choose which routing policy to use. This is where the difference between a simple DNS service and Route 53 becomes most apparent.
Health Checks
Route 53 health checks can monitor a specified endpoint, another health check, or the state of a CloudWatch alarm. Because health check results can be incorporated into DNS failover, it becomes easy to design a system that does not return dead endpoints.
4. Routing Policies Are the Real Core of Route 53
The true value of Route 53 lies not so much in the fact that it can hold DNS records, but in the fact that it can control how answers are returned. The official documentation explains that when you create a record, you choose a routing policy and determine how responses should be handled. Major policies include simple, failover, geolocation, and latency-based routing.
4.1 Simple Routing
This is for a single resource or basic name resolution. It is often enough for an initial environment, but once you start thinking about availability or geographic distribution, its limits appear quickly.
4.2 Failover Routing
This is aimed at active/passive configurations. It enables the clearest kind of high-availability design at the DNS level: if the primary fails, switch to the secondary. When combined with health checks, automatic switching at endpoint failure becomes possible.
4.3 Latency-Based Routing
This returns the region with the lowest latency for the user. It is useful in multi-region architectures when you want to guide users to the nearest site. It is especially effective for global services.
4.4 Geolocation Routing
This changes the response destination based on the user’s geographic location. It is easy to use for regulations, region-specific content, and overseas switching.
4.5 Weighted Routing
This is well suited for production cutovers, A/B tests, and gradual rollouts. For example, it is easy to use it to send 90% of traffic to the old environment and 10% to the new environment.
In practice, rather than memorizing all of these in detail, it becomes much easier to organize them into four categories:
- Simple name resolution
- Switching/failover
- Geography/latency
- Gradual rollout
5. Health Checks and DNS Failover
Route 53 health checks are the feature that turns DNS from “static name resolution” into “traffic management based on current conditions.” AWS officially explains that health checks can monitor resources such as web servers, other health checks, or CloudWatch alarms, and that they can be used for DNS failover.
Typical examples where this is useful are:
- If the frontend in the Tokyo region fails, switch to Osaka
- If the primary API fails, move traffic to the DR site
- Pick up abnormal application metrics through a CloudWatch alarm and reflect that state in DNS
Because this operates at the DNS layer, it does not offer the same fine-grained control as an L7 load balancer, but that simplicity makes it a good fit for large-scale switching across regions.
6. How to Think About Pricing
Route 53 pricing is mainly divided into:
- Hosted zones
- DNS queries
- Health checks
- Domain registration
The official pricing page also shows that health checks are billed monthly, and that there is a free tier for basic health checks against AWS endpoints.
GCP Cloud DNS charges by zone plus query count, with no free tier. Azure DNS is also based on zones and queries. Traffic Manager is mainly charged by DNS queries and per-endpoint health checks.
This makes it easier to estimate costs if you think about it roughly as follows:
- Route 53 / Cloud DNS / Azure DNS
- Costs grow with “how many names you have” and “how often they are queried”
- Route 53 health checks / Azure Traffic Manager
- Costs grow with “how many things you monitor” and “whether high-frequency monitoring is used”
In other words, if you are doing simple DNS hosting, pricing is relatively straightforward. But once you bring high-availability design into DNS, additional health-check-related costs appear. The decision point is whether you can justify that as “insurance for high availability.”
7. Practical Design Patterns
7.1 A Simple Website
- Public hosted zone
- Point
www.example.comto a CDN or load balancer - Start with simple routing
For a small-scale site, this is often enough. It is important not to make things too complicated from the beginning.
7.2 Multi-Region API
- Use latency-based or failover routing for
api.example.com - Distribute traffic to APIs in each region
- Use health checks for failover in the event of a problem
This is suitable when you have a global API or DR requirements. Because switching happens at the DNS level, the key is to understand that this is not perfectly real time.
7.3 Internal DNS for Company Use
- Private hosted zone
- Internal names such as
db.internal.example.local - Resolution per VPC
Simply avoiding hard-coded IP addresses in application settings can greatly increase flexibility during configuration changes and DR. Route 53 is strong as this kind of “internal DNS foundation” as well.
7.4 Gradual Rollout
- Keep old and new environments side by side with weighted routing
- Increase traffic to the new environment from 5% → 20% → 50% → 100%
This is better suited to infrastructure cutovers and large-scale migrations than to application-layer A/B testing.
8. Summary of the Comparison with GCP and Azure
AWS Route 53
Route 53 is characterized by the fact that it can bring together authoritative DNS, health checks, failover, and various routing policies into one service. It works very well with AWS-native multi-region design.
GCP Cloud DNS
Cloud DNS is a simple and easy-to-understand authoritative DNS service. Pricing is also easy to read, based on zones and queries, but it is not designed to complete rich DNS failover and routing functions like Route 53 within a single service.
Azure DNS + Traffic Manager
In Azure, DNS and traffic distribution are split.
- Azure DNS: authoritative DNS
- Traffic Manager: DNS-based distribution, health checks, and failover
At first glance this split may look more complex, but it can also make role separation clearer.
9. Common Pitfalls
9.1 Confusing the Roles of DNS and Load Balancers
Route 53 controls traffic at the DNS level. Fine-grained request-by-request routing or control based on application headers belongs to a different layer. Confusing these roles makes architecture unnecessarily complicated.
9.2 Adding Too Many Routing Policies from the Start
If you include everything, you end up with a DNS setup that only the operator understands.
It is safer to start with simple routing, then move to failover, and only then add latency or geolocation if needed.
9.3 Leaving the Meaning of Health Checks Unclear
If you add health checks without deciding what “healthy” actually means, you risk false positives or switching too often.
Decide first whether a simple HTTP 200 response is enough, whether you want to check full application connectivity, or whether you want to use CloudWatch alarm integration.
10. Conclusion
Amazon Route 53 is both a DNS management service and a service that supports the “entry-point design” of availability and global delivery. The official documentation clearly organizes features that go beyond simple DNS, such as routing policies, health checks, and VPC Resolver.
If you understand GCP Cloud DNS as a simple and straightforward authoritative DNS service, and Azure as creating a world similar to Route 53 through the combination of Azure DNS and Traffic Manager, then your architecture decisions are less likely to drift even in a multi-cloud environment.
As a practical first step, I recommend:
- Consolidate external-facing DNS into Route 53
- Attach health checks to important endpoints
- Try just one failover configuration
DNS is understated, but if you design it carefully, incident response, multi-region architecture, migrations, and gradual rollouts all become a little easier.