Route 53 vs Cloudflare DNS: what actually changes when you move between them
Route 53 vs Cloudflare DNS compared on the things that break migrations: aliases, apex records, proxying, routing policies, TTLs, DNSSEC and API access.
10 min readDNSMigrator team
On this page
Route 53 and Cloudflare can both host an ordinary authoritative zone. The differences appear at the edges: what an apex alias can target, whether DNS also puts a proxy in the HTTP path, how traffic steering works, and which account permissions an automation tool receives. Those are the details to settle before changing nameservers.
Route 53 vs Cloudflare at a glance#
This comparison uses the record and TTL capabilities in DNSMigrator’s current provider catalog. The vendor links document the underlying services; the last column explains what matters during a move.
| Area | Amazon Route 53 | Cloudflare DNS | Migration consequence |
|---|---|---|---|
| Record types in the DNSMigrator catalog | A, AAAA, CNAME, MX, TXT, NS, SRV, CAA, PTR, DS, HTTPS, SVCB, TLSA, SSHFP, NAPTR, and legacy SPF | A, AAAA, CNAME, MX, TXT, NS, SRV, CAA, PTR, DS, HTTPS, SVCB, TLSA, SSHFP, NAPTR, LOC, CERT, URI, plus Cloudflare redirect and Worker-route features | Standard overlap is broad. Route 53 SPF becomes TXT; Cloudflare-only types or features can block a move to Route 53. SOA, DNSKEY, and apex NS are provider-managed rather than copied. See each vendor’s Route 53 record list and Cloudflare record reference. |
| Apex handling | Route 53 alias records can exist at the apex and target selected AWS resources or a compatible record in the same hosted zone | A CNAME can be stored at the apex; Cloudflare resolves the target and returns final addresses through CNAME flattening | An alias is intent, not a fixed IP. Preserve the hostname relationship where the destination can; otherwise a static address is a snapshot. |
| Proxying | No equivalent proxy flag in authoritative Route 53 records | Eligible A, AAAA, and CNAME records can be Proxied or DNS only | Moving a proxied name to Route 53 sends clients directly to the origin unless you put another edge service in front. |
| DNS routing | Simple, weighted, latency, geolocation, geoproximity, failover, multivalue, and IP-based policies | Ordinary Cloudflare DNS records do not carry those Route 53 policy objects | Cloudflare Load Balancing can provide health-aware and geographic steering, but Cloudflare documents it as a separate add-on product, not as metadata on an imported Route 53 RRset. |
| TTLs represented by DNSMigrator | 0 through 2,147,483,647 seconds; default 300. AWS aliases to resources do not expose a record TTL. DNSSEC signing enforces a one-week ceiling. | 60 through 86,400 seconds in the cross-plan catalog; 1 means Auto. Cloudflare documents 30 seconds for Enterprise DNS-only records and 60 seconds for non-Enterprise, while proxied Auto answers use 300 seconds. | Values outside the destination range are changed and shown in the preview. Route 53 values above one day are reduced for Cloudflare; Cloudflare Auto becomes Route 53’s 300-second default. |
| DNSSEC | API-managed signing; Route 53 uses a customer-managed AWS KMS key for the KSK and manages the ZSK | API-managed signing; Cloudflare generates the zone’s signing material and DS values | Keys are provider-specific. Follow a DNSSEC migration sequence, not a record copy. |
| API and auth | AWS API authorized through IAM; DNSMigrator uses a cross-account role with a workspace-specific external ID | Cloudflare API authorized with a token scoped to selected zones and DNS Read or DNS Edit | Both support least privilege, but the trust objects and revocation paths differ. |
| BIND zone files | Console import is supported; AWS says Route 53 does not export a zone file | Dashboard and API support both import and export | An API read avoids the limitations of either vendor’s file format. Use the zone-file migration guide when a file is the source. |
| Pricing model, checked September 27, 2026 | Route 53 pricing is pay-as-you-go: public hosted zones, query classes, health checks, and Traffic Flow have separate meters. DNSSEC signing itself has no Route 53 fee, but its KMS key and operations can incur KMS charges. | Cloudflare’s plans include authoritative DNS. Its DNS pricing FAQ says Free, Pro, and Business do not charge per DNS query; Enterprise query volume is an input to a custom quote. Load Balancing is priced as a separate add-on. | Compare the complete operating design, not only zone hosting. Route 53 routing/health checks and Cloudflare proxy/Load Balancing can change the bill independently. |
The catalog ranges are the values DNSMigrator plans against. A vendor may expose plan-specific choices that a portable migration cannot assume; Cloudflare’s 30-second Enterprise minimum is the obvious example.
Apex aliases: Route 53 alias records vs CNAME flattening#
AWS calls an alias a Route 53-specific extension. It can answer at the zone apex, where a literal CNAME is not valid, and it can follow selected resources such as CloudFront, Elastic Load Balancing, API Gateway, S3 website endpoints, and another compatible record in the same hosted zone. An AWS-resource alias needs the target DNS name and its hosted-zone ID. Route 53 follows resource address changes for you.
Cloudflare takes a different route. Its CNAME flattening lets you configure a CNAME at the apex. Cloudflare resolves the chain and returns A or AAAA answers rather than the CNAME. That can preserve an external hostname target that a Route 53 alias cannot accept.
Neither representation is a generic ALIAS record defined by the DNS standards. A provider export or API response must preserve the control-plane intent. Public dig output only shows the resulting A or AAAA answer and cannot tell you whether it came from a Route 53 alias, a flattened CNAME, or a literal address. The apex CNAME, ALIAS, and flattening guide covers the protocol constraint.
Cloudflare proxied records change the network path#
Cloudflare’s proxy status documentation says eligible A, AAAA, and CNAME records can be proxied. For a proxied name, public DNS returns Cloudflare addresses and HTTP or HTTPS traffic traverses Cloudflare. For DNS only, DNS returns the configured origin.
Route 53 authoritative DNS does not have a matching per-record proxy flag. If you migrate a proxied Cloudflare A record with origin 192.0.2.44, Route 53 can publish that address, but doing so removes Cloudflare from the request path. Before cutover, verify origin TLS, firewall allowlists, caching, redirects, WAF rules, rate limits, and client-IP handling. The detailed guide to migrating away from Cloudflare separates those concerns.
Routing policies are not portable record values#
Route 53’s routing policy reference includes weighted, latency, geolocation, geoproximity, failover, multivalue, and IP-based routing. A routed record carries identifiers and policy metadata in addition to its owner, type, TTL, and values. Health checks may decide whether an answer is eligible.
Cloudflare’s ordinary DNS-record API does not provide a destination for that Route 53 metadata. Cloudflare has Load Balancing, which supports pools, health monitors, failover, and traffic steering. Cloudflare labels it an add-on and links to separate pricing in the dashboard. Migrating into that product requires a new Load Balancing design; importing a zone does not create equivalent pools or monitors.
TTL limits and DNSSEC affect the change window#
Cloudflare’s current TTL documentation caps DNS-only records at one day and fixes proxied records to Auto, served at 300 seconds. DNSMigrator uses a 60-second portable minimum for Cloudflare because it cannot assume an Enterprise zone.
Route 53 accepts a much wider numeric TTL range in the catalog. AWS-resource aliases inherit the target’s TTL rather than exposing their own. When DNSSEC signing is enabled, AWS says Route 53 enforces a maximum TTL of one week even if a record was configured higher.
Both providers can sign public zones, but the chain of trust crosses the provider boundary. The parent DS must match a key served by the active child authority. If the two providers are not coordinating a multi-signer migration, remove the old DS, wait its full TTL, switch nameservers, enable destination signing, and then publish the new DS. Use the DNSSEC migration checker before and after the switch.
IAM roles and scoped tokens solve different trust problems#
Route 53 operations are AWS API actions governed by IAM. DNSMigrator’s Route 53 connection uses a cross-account IAM role and an external ID instead of asking for an access-key pair. Preview needs list and read actions; apply also needs record-change and, when necessary, hosted-zone creation actions. The Route 53 provider setup page gives the current policy and trust steps.
Cloudflare recommends scoped API tokens. A source-only connection can be limited to Zone → DNS → Read for the selected zone; apply needs Edit. Cloudflare also lets you restrict token resources, client IPs, and lifetime. See the Cloudflare API token setup page.
For files, AWS supports BIND import with documented limits and ignores apex NS and SOA, but does not export zone files. Cloudflare supports both zone-file import and export, including Cloudflare-specific comment tags. An API-based migration still gives a better account of aliases, proxy state, and routing than a plain BIND file.
What the translator does from Route 53 to Cloudflare#
The Route 53-to-Cloudflare migration page runs the same capability-aware translator used by the app. Its important decisions are:
- Ordinary shared record sets keep their names, values, and TTLs when Cloudflare accepts them.
- A Route 53 alias becomes a CNAME. At the apex, Cloudflare flattens that CNAME automatically, preserving the target relationship rather than freezing its current addresses.
- Weighted, latency, geolocation, geoproximity, multivalue, and IP-routed groups collapse into one simple set of unique answers. The preview warns that Cloudflare will serve them together as round-robin.
- Failover groups keep the primary answer and warn that automatic failover is gone.
- A source-account health-check ID is not recreated; it is discarded with the routing metadata, while the row’s routing-loss warning explains the simplified result.
- Legacy SPF record types become TXT with an informational note.
- TTLs below 60 seconds rise to 60; values above 86,400 fall to 86,400.
Routing and failover loss appear as Review rows, not blockers. Applying writes the simplified records shown in the preview, so decide whether to accept simple DNS or build the intended behavior in Cloudflare Load Balancing first.
What the translator does from Cloudflare to Route 53#
The reverse Cloudflare-to-Route 53 migration page handles a different set of gaps:
- Shared DNS records copy normally when Route 53 supports the type.
- A Cloudflare apex CNAME to CloudFront can become a Route 53 alias because the translator knows CloudFront’s hosted-zone ID. Other apex targets need supplied current A addresses; those are marked static because they will not follow later target changes. Without a safe alias or resolved addresses, the row is blocked.
- Auto TTL has no Route 53 sentinel, so it becomes Route 53’s 300-second default.
- Every proxied record gets a
proxy-lostwarning, and the proxy metadata is removed. The target is the configured origin, not Cloudflare’s public anycast answer. - Cloudflare redirects and Worker routes are classified as provider features and blocked for manual recreation. DNS cannot reproduce their HTTP behavior.
- LOC, CERT, and URI records are unsupported by the current Route 53 catalog and appear as blockers rather than disappearing.
Review these outcomes in the record-translation guide, then query Route 53’s assigned authorities before changing delegation. The DNS migration checker can compare what the Internet sees after cutover.
Which provider is the better fit?#
Choose Route 53 when your desired DNS behavior is tied to AWS resources, you need its native routing policies and health checks, or IAM roles are already your operational access model. It is also the more direct fit when DNS changes belong in the same Terraform or AWS deployment workflow as the resources they target.
Choose Cloudflare when you intentionally want Cloudflare in the HTTP path, need an external hostname at the apex through flattening, prefer zone-scoped tokens, or want authoritative DNS under Cloudflare’s plan model with BIND export. Cloudflare is a credible Route 53 alternative, but its Load Balancing and proxy are separate concepts that must be designed explicitly.
Neither answer should be based on a feature-count score. Inventory the zone, classify every alias, proxy, and routing policy, preview the actual translation, and keep both authorities answering through the parent NS TTL.