Migrating DNS to the Cloud: Route 53, Azure DNS, and Cloud DNS Compared

Why DNS Migration Is Scarier Than It Should Be

DNS is one of those infrastructure components that works silently until it does not. When it breaks, everything breaks. Users cannot reach your application. APIs return connection errors. Email stops flowing. Certificate validation fails. The blast radius of a DNS misconfiguration is your entire public-facing infrastructure.

This is why DNS migrations make experienced engineers nervous. Moving from an on-premises DNS provider or a traditional registrar to a cloud-managed DNS service involves coordinating name server changes, record migration, TTL management, and validation -- all while keeping production traffic flowing without interruption. The good news is that DNS migrations are well-understood, and with proper planning, they can be executed with zero downtime. The bad news is that "proper planning" involves more steps than most teams expect.

This guide covers the three major cloud DNS services -- AWS Route 53, Azure DNS, and Google Cloud DNS -- compares their capabilities, and provides a step-by-step migration checklist that I have refined across multiple production migrations.

The Cloud DNS Services Compared

AWS Route 53

Route 53 is the most feature-rich cloud DNS service. It handles public and private hosted zones, supports all standard record types (A, AAAA, CNAME, MX, TXT, SRV, NS, SOA, CAA, NAPTR), and adds AWS-specific alias records that point directly to CloudFront distributions, ELB load balancers, S3 website endpoints, and API Gateway domains without the performance penalty of a CNAME lookup. Alias records are free -- there is no per-query charge -- which makes them the default choice for any AWS resource.

Route 53's routing policies are its strongest differentiator. Simple routing maps a domain to one or more IP addresses. Weighted routing distributes traffic across multiple endpoints by percentage. Latency-based routing sends users to the endpoint with the lowest network latency from their location. Geolocation routing maps users based on their geographic location, which is essential for data residency requirements. Failover routing switches to a standby endpoint when health checks detect an outage. Multivalue answer routing returns up to eight healthy IP addresses for client-side load distribution.

Health checks are integrated directly. You can configure HTTP, HTTPS, or TCP health checks against any endpoint, including endpoints outside AWS. Health checks run from multiple global locations and trigger routing changes within 10 to 30 seconds of failure detection. This makes Route 53 not just a DNS service but a global traffic management layer.

Pricing: $0.50 per hosted zone per month (first 25 zones), then $0.10 per zone. Query pricing starts at $0.40 per million queries for standard records and $0.60 per million for latency-based and geolocation queries. Health checks are $0.50 to $0.75 per month each.

Azure DNS

Azure DNS supports public and private zones with standard record types. It integrates with Azure resources through alias record sets, which work similarly to Route 53 alias records for Traffic Manager profiles, Azure CDN endpoints, and public IP resources. Azure DNS runs on Azure's name server infrastructure, with servers in every Azure region providing low-latency resolution globally.

Azure DNS does not include built-in health checks or traffic routing policies at the DNS level. For those capabilities, you need Azure Traffic Manager, which is a separate service. Traffic Manager provides priority-based failover, weighted distribution, performance-based routing (similar to Route 53 latency-based routing), geographic routing, and multivalue routing. The combination of Azure DNS plus Traffic Manager provides equivalent functionality to Route 53, but it is two services to manage and two billing line items instead of one.

One area where Azure DNS excels is private DNS zone integration with Virtual Networks. Azure Private DNS zones automatically register DNS records for VMs in linked VNets, enabling DNS resolution for private endpoints without manual record management. This is particularly useful for Azure Private Link -- when you create a private endpoint, Azure can automatically create the DNS record in a private zone.

Pricing: $0.50 per zone per month (first 25 zones). Query pricing is $0.40 per million queries for the first billion, then $0.20 per million. Traffic Manager profiles cost $0.36 per million queries plus $0.54 per month per endpoint with health checks.

Google Cloud DNS

Cloud DNS is Google's managed authoritative DNS service, running on the same infrastructure that serves Google's own domains. It supports public and private managed zones, all standard record types, and response policies that let you override DNS resolution for specific domains. Response policies are useful for split-horizon DNS, internal service discovery, and blocking access to specific domains.

Cloud DNS does not have built-in traffic routing policies comparable to Route 53. For traffic management, you use Cloud Load Balancing, which provides global anycast IP addresses with automatic failover and latency-based routing at the load balancer level rather than the DNS level. This is architecturally different -- traffic hits the nearest Google edge node and is routed to the optimal backend, rather than DNS resolving to the nearest backend's IP address. For most use cases, the load balancer approach is actually superior because it avoids DNS TTL propagation delays during failover.

Cloud DNS supports DNSSEC natively, with automatic key generation and rotation. Enabling DNSSEC is a single API call. GCP also offers DNS peering between VPC networks, which lets private zones in one project resolve names in another project without zone replication.

Pricing: $0.20 per zone per month (first 25 zones), then $0.10. Query pricing is $0.40 per million queries for the first billion. This makes Cloud DNS the cheapest option for high-volume DNS.

Feature Comparison Matrix

When evaluating which cloud DNS service to use, the decision usually hinges on a few key capabilities.

• Alias/ANAME records: Route 53 and Azure DNS support alias records to their respective cloud resources. Cloud DNS does not have an equivalent -- you use standard A records or CNAME records.
• Built-in health checks: Route 53 includes health checks natively. Azure DNS requires Traffic Manager. Cloud DNS relies on Cloud Load Balancing.
• Traffic routing: Route 53 offers the widest selection of routing policies directly in DNS. Azure requires Traffic Manager. GCP handles this at the load balancer layer.
• DNSSEC: All three support DNSSEC. Route 53 added DNSSEC for hosted zones in 2021. Azure DNS supports DNSSEC signing. Cloud DNS has the most automated DNSSEC implementation.
• Private DNS: All three support private zones. Azure has the best integration with private endpoints through automatic DNS registration.

The Migration Process

Here is the step-by-step process for migrating DNS to any cloud provider. The steps are provider-agnostic -- the details of record creation differ, but the overall process is the same.

Phase 1: Preparation (1 to 2 weeks before migration)

Step 1: Audit your existing DNS records

Export a complete list of all DNS records from your current provider. Every record type, every subdomain, every TTL value. Use your current provider's export tool if available, or use dig/nslookup to query each known record. Cross-reference with your application inventory -- are there subdomains you forgot about? Old marketing landing pages? Partner CNAME records? MX records for email routing? SPF, DKIM, and DMARC records for email authentication?

The most common migration mistake is missing records. A forgotten CNAME for a partner integration or an old TXT record for domain verification can cause outages days after the migration when the cached records expire and the new zone does not have them.

Step 2: Lower TTL values

At least 48 hours before the migration, lower the TTL on all records to 60 to 300 seconds (1 to 5 minutes). The current TTL might be 3600 seconds (1 hour) or even 86400 seconds (24 hours). If you change name servers while the old TTL is cached, some resolvers will continue querying the old name servers for up to 24 hours. With a low TTL, the transition happens in minutes.

Lower the TTL at your current provider, not the new one. The TTL that matters is the one currently cached by resolvers around the world. Wait at least the duration of the old TTL before proceeding -- if the old TTL was 3600 seconds, wait at least an hour after lowering it to ensure the old cached values have expired.

Step 3: Create the hosted zone in the target cloud

Create a public hosted zone (or DNS zone) for your domain in the target cloud provider. The provider will assign name servers. Do not change your domain's name server delegation yet -- that comes later.

Step 4: Recreate all DNS records

Recreate every record from your audit in the new hosted zone. Match record types, values, and TTLs exactly. For CNAME records, verify the target hostname is correct. For MX records, verify the priority values. For TXT records, watch for character escaping differences between providers.

Pay special attention to:

• SPF records: These are critical for email deliverability. A missing or incorrect SPF record can cause your outbound email to be rejected as spam.
• DKIM records: These TXT records can be very long. Verify they are correctly split and reassembled if your provider has record length limits.
• CAA records: These control which certificate authorities can issue certificates for your domain. Missing CAA records can block certificate issuance or renewal.
• Apex CNAME equivalents: Some providers allow CNAME-like behavior at the zone apex (Route 53 alias, Azure alias, ANAME). If your current provider uses a non-standard mechanism, you need to replicate the equivalent.

Phase 2: Validation (day of migration)

Step 5: Validate records against the new name servers

Before changing the delegation, query the new name servers directly to verify every record resolves correctly. Use dig with the @ flag to query a specific name server:

Query each critical record against the new name servers and compare the response to the current production DNS. Any discrepancy must be resolved before proceeding. This step catches typos, missing records, and configuration errors before they affect production traffic.

Step 6: Update name server delegation

At your domain registrar, update the name server records to point to the new cloud provider's name servers. This is the point of no return -- once resolvers pick up the new delegation, they will query the new name servers. With the reduced TTL from Step 2, the transition should complete within 5 to 15 minutes for most resolvers.

Keep the old hosted zone active for at least 48 hours. Some resolvers (particularly enterprise DNS servers) may have cached the old delegation longer than expected. Having both the old and new zones serving correct records during the transition eliminates any gap in resolution.

Phase 3: Post-migration (24 to 72 hours after)

Step 7: Monitor DNS resolution

After changing name servers, monitor DNS resolution from multiple geographic locations. Use external DNS monitoring services that check resolution from dozens of global vantage points. Watch for:

• SERVFAIL responses (the name server is authoritative but cannot answer the query)
• NXDOMAIN responses for records that should exist (missing record in the new zone)
• Incorrect IP addresses (wrong A record values)
• Slow resolution times (new name servers are slower than expected)

Step 8: Restore normal TTL values

After 24 to 48 hours of stable operation, raise TTL values back to normal levels. For most records, 300 to 3600 seconds is appropriate. Higher TTLs reduce query volume (and costs) and improve resolution speed for end users. For records that might change during failover, keep TTLs at 60 seconds so routing changes take effect quickly.

Step 9: Configure health checks and routing policies

Once the basic migration is complete and stable, add advanced features: health checks for critical endpoints, failover routing for disaster recovery, latency-based routing for multi-region deployments, and geolocation routing for data residency compliance.

Step 10: Enable DNSSEC

If your domain uses DNSSEC (or you want to enable it), configure DNSSEC signing in the new zone and update the DS record at your registrar. DNSSEC adds cryptographic signatures to DNS responses, preventing DNS spoofing and cache poisoning attacks. All three cloud providers support DNSSEC, though the setup process differs:

• Route 53: Enable DNSSEC signing on the hosted zone. Route 53 generates KSK and ZSK keys. You create a DS record at your registrar using the information Route 53 provides.
• Azure DNS: Enable DNSSEC signing through the Azure portal or CLI. Azure manages key generation and rotation.
• Cloud DNS: Enable DNSSEC with a single API call. GCP automatically generates and rotates keys. Create the DS record at your registrar.

Advanced Patterns

Failover routing for disaster recovery

DNS failover is the simplest form of disaster recovery. Configure a primary and secondary endpoint with health checks. When the primary fails health checks, DNS automatically returns the secondary endpoint's IP address. Route 53 failover routing is the most straightforward implementation: create two record sets with the same name (one primary, one secondary) and associate health checks.

The limitation is DNS TTL. Even with a 60-second TTL, failover takes 60 to 90 seconds because clients must wait for cached records to expire. For sub-minute failover, use a global load balancer (AWS Global Accelerator, Azure Front Door, GCP Cloud Load Balancing) that reroutes at the network layer without waiting for DNS propagation.

Latency-based routing for global applications

For applications deployed in multiple regions, latency-based routing sends each user to the region with the lowest network latency from their location. Route 53 measures latency between the user's resolver location and each AWS region where you have configured an endpoint. This typically improves response times by 50 to 200 ms for users far from your primary region.

The challenge is maintaining health checks for each regional endpoint. If a region goes down and the health check fails, Route 53 removes it from the latency calculation and routes users to the next-best region. Test this failover regularly -- simulate a regional outage and verify that users are correctly rerouted.

Multi-cloud DNS architecture

For organizations running workloads across multiple clouds, DNS can serve as the traffic distribution layer. Use your primary cloud's DNS service for the parent zone, with delegation to other providers for specific subdomains. For example, use Route 53 for example.com, delegate app.example.com to Azure DNS for your Azure-hosted application, and delegate api.example.com to Cloud DNS for your GCP-hosted API.

Alternatively, use a single DNS provider for all zones and point records to endpoints in different clouds. This is operationally simpler but creates a single point of failure at the DNS layer. For critical domains, consider running secondary DNS with a different provider -- Route 53 and Cloud DNS both support secondary zone hosting where they pull records from a primary via zone transfer (AXFR/IXFR).

The Pre-Migration Checklist

Print this out and check off each item before, during, and after your DNS migration.

1. Complete audit of all existing DNS records exported to a spreadsheet or file.
2. All TTLs lowered to 60 to 300 seconds at least 48 hours before migration.
3. New hosted zone created in target cloud provider.
4. All records recreated in the new zone and verified against the audit.
5. Each record tested by querying the new name servers directly.
6. Rollback plan documented: original name servers and zone retained for 48+ hours.
7. Monitoring configured: external DNS checks from multiple global locations.
8. Team notified: on-call engineers aware of migration window.
9. Name server delegation updated at registrar.
10. Resolution verified from multiple locations within 15 minutes of delegation change.
11. Old zone kept active for 48 hours post-migration.
12. TTLs restored to normal values after 24 to 48 hours of stable operation.
13. Health checks and routing policies configured.
14. DNSSEC enabled and DS record updated at registrar (if applicable).
15. Old zone decommissioned after full confidence in new zone stability.