migrating toBrowse playbooks
← All playbooks
DNS and CDN migration

Cloudflare DNS → Amazon Route 53

Move zones, record sets, names, and ttls, nameservers, delegation, and dnssec, traffic steering and health checks, proxy, cdn, origins, and host headers, tls certificates and security policy, caching, purge, and stale behavior, redirects, rewrites, edge logic, and headers, waf, bot, rate-limit, and access controls from Cloudflare DNS to Amazon Route 53 with a reversible cutover, explicit exception ledger, and evidence-backed verification.

Typical timeline15–45 business days70–180 hours active work
Statusneeds review
Source profileCloudflare DNS documentation reviewed 2026-07-20
Destination profileAmazon Route 53 documentation reviewed 2026-07-20
Documentation date
Review window
Evidence2 sources
This route needs review.Use it as a planning baseline, then verify the dated sources and test with representative data before production.
Before you migrate

Should you make this move?

Both platforms have a case. Compare what you gain with what you give up before scheduling the cutover.

Current platform

Cloudflare DNS

Reasons to stay
  • Fast authoritative DNS integrates with proxying, security, analytics, and a large global edge network
  • Declarative infrastructure makes environments reviewable, repeatable, and automatable
Reasons to leave
  • Proxied records, edge rules, and Cloudflare-specific security behavior extend far beyond portable zone data
  • State identity, provider behavior, secrets, and plans must remain aligned to avoid destructive changes
New platform

Amazon Route 53

What gets better
  • Highly available authoritative DNS integrates tightly with AWS health checks and routing policy
  • Declarative infrastructure makes environments reviewable, repeatable, and automatable
What gets worse
  • Advanced routing, resolver services, IAM, and per-query pricing create operational complexity
  • State identity, provider behavior, secrets, and plans must remain aligned to avoid destructive changes
Best of the move

Amazon Route 53: Highly available authoritative DNS integrates tightly with AWS health checks and routing policy. This removes a major source-side concern: Proxied records, edge rules, and Cloudflare-specific security behavior extend far beyond portable zone data.

Worst of the move

What you lose: Fast authoritative DNS integrates with proxying, security, analytics, and a large global edge network. What you inherit: Advanced routing, resolver services, IAM, and per-query pricing create operational complexity.

Connected catalog

2 destinations are documented from Cloudflare DNS. Compare nearby routes before committing.

Also from Cloudflare DNS
Also moving to Amazon Route 53
Jump to a section
01At a glance

Know the shape of the move.

Transfer outcome10 features audited
Transfer outcome distributionClean transfer: 0, Partial transfer: 1, Manual rebuild: 8, Not transferred: 1.
Clean0
Partial1
Manual8
Lost1
Mapping route8 of 9 fields have a destination path

This timeline assumes

  • Up to 1,000 zones, 100,000 records, 500 edge rules, and 10 Tbps of peak traffic
  • Administrators control both Cloudflare DNS and Amazon Route 53, including billing, identity, APIs, integrations, and export permissions.
  • Cloudflare DNS remains intact and recoverable until Amazon Route 53 completes one representative operating cycle.
  • A production-shaped pilot includes every object type, access class, edge case, and failure path.
  • The migration team preserves stable source identifiers and records durable evidence for every blocking check.
02What transfers

What survives the move.

“Partial” and “manual” are not footnotes. They are work that must be scheduled and verified.

ItemOutcomeImpactWhat happensMitigation
Zones, record sets, names, and TTLspartialcriticalZone-file support, aliases, apex behavior, routing records, comments, and TTL limits differ. A successful bulk job therefore does not prove semantic parity between Cloudflare DNS and Amazon Route 53.Map zones, record sets, names, and ttls explicitly, pilot every feature class, and reconcile accepted, changed, rejected, and excluded items.
Nameservers, delegation, and DNSSECmanualcriticalRegistrar delegation, DS records, signing keys, propagation, and negative caching require staged change. A successful bulk job therefore does not prove semantic parity between Cloudflare DNS and Amazon Route 53.Inventory and rebuild nameservers, delegation, and dnssec, then test normal, edge, failure, and rollback behavior.
Traffic steering and health checksmanualcriticalWeighted, latency, geographic, failover, load-balancing, and health-check semantics differ. A successful bulk job therefore does not prove semantic parity between Cloudflare DNS and Amazon Route 53.Inventory and rebuild traffic steering and health checks, then test normal, edge, failure, and rollback behavior.
Proxy, CDN, origins, and host headersmanualcriticalProxy modes, shielding, origin selection, SNI, host headers, and connection policy require reconstruction. A successful bulk job therefore does not prove semantic parity between Cloudflare DNS and Amazon Route 53.Inventory and rebuild proxy, cdn, origins, and host headers, then test normal, edge, failure, and rollback behavior.
TLS certificates and security policymanualcriticalCertificate issuance, custom keys, cipher policy, minimum versions, mTLS, and renewal ownership change. A successful bulk job therefore does not prove semantic parity between Cloudflare DNS and Amazon Route 53.Inventory and rebuild tls certificates and security policy, then test normal, edge, failure, and rollback behavior.
Caching, purge, and stale behaviormanualcriticalCache keys, TTL precedence, stale controls, tags, surrogate keys, and purge APIs differ. A successful bulk job therefore does not prove semantic parity between Cloudflare DNS and Amazon Route 53.Inventory and rebuild caching, purge, and stale behavior, then test normal, edge, failure, and rollback behavior.
Redirects, rewrites, edge logic, and headersmanualcriticalRule languages, execution order, limits, header changes, and edge compute are provider-specific. A successful bulk job therefore does not prove semantic parity between Cloudflare DNS and Amazon Route 53.Inventory and rebuild redirects, rewrites, edge logic, and headers, then test normal, edge, failure, and rollback behavior.
WAF, bot, rate-limit, and access controlsmanualcriticalManaged rules, expressions, IP lists, challenges, rate windows, and allowlists do not translate directly. A successful bulk job therefore does not prove semantic parity between Cloudflare DNS and Amazon Route 53.Inventory and rebuild waf, bot, rate-limit, and access controls, then test normal, edge, failure, and rollback behavior.
Logs, analytics, and historical baselineslosthighDNS query, request, security, cache, and performance history remains provider-native. A successful bulk job therefore does not prove semantic parity between Cloudflare DNS and Amazon Route 53.Archive logs, analytics, and historical baselines as dated source evidence and define the new destination baseline.
APIs, credentials, automation, and billingmanualhighResource IDs, tokens, Terraform providers, quotas, contracts, and cost models change. A successful bulk job therefore does not prove semantic parity between Cloudflare DNS and Amazon Route 53.Inventory and rebuild apis, credentials, automation, and billing, then test normal, edge, failure, and rollback behavior.
03Field and feature mapping

Where each thing goes.

SourceDestinationMethodNotes
Cloudflare DNS: Zones, record sets, names, and TTLsAmazon Route 53: approved zones, record sets, names, and ttls representationtransformPreserve source IDs, ownership, timestamps, access intent, and an explicit exception status for zones, record sets, names, and ttls.
Cloudflare DNS: Nameservers, delegation, and DNSSECAmazon Route 53: approved nameservers, delegation, and dnssec representationmanualPreserve source IDs, ownership, timestamps, access intent, and an explicit exception status for nameservers, delegation, and dnssec.
Cloudflare DNS: Traffic steering and health checksAmazon Route 53: approved traffic steering and health checks representationmanualPreserve source IDs, ownership, timestamps, access intent, and an explicit exception status for traffic steering and health checks.
Cloudflare DNS: Proxy, CDN, origins, and host headersAmazon Route 53: approved proxy, cdn, origins, and host headers representationmanualPreserve source IDs, ownership, timestamps, access intent, and an explicit exception status for proxy, cdn, origins, and host headers.
Cloudflare DNS: TLS certificates and security policyAmazon Route 53: approved tls certificates and security policy representationmanualPreserve source IDs, ownership, timestamps, access intent, and an explicit exception status for tls certificates and security policy.
Cloudflare DNS: Caching, purge, and stale behaviorAmazon Route 53: approved caching, purge, and stale behavior representationmanualPreserve source IDs, ownership, timestamps, access intent, and an explicit exception status for caching, purge, and stale behavior.
Cloudflare DNS: Redirects, rewrites, edge logic, and headersAmazon Route 53: approved redirects, rewrites, edge logic, and headers representationmanualPreserve source IDs, ownership, timestamps, access intent, and an explicit exception status for redirects, rewrites, edge logic, and headers.
Cloudflare DNS: WAF, bot, rate-limit, and access controlsAmazon Route 53: approved waf, bot, rate-limit, and access controls representationmanualPreserve source IDs, ownership, timestamps, access intent, and an explicit exception status for waf, bot, rate-limit, and access controls.
Cloudflare DNS: Logs, analytics, and historical baselinesNo destinationunsupportedRetain immutable source evidence; do not manufacture destination-native history.
04Before you begin

Make the move recoverable.

Backup procedure

Create the source-of-truth backup

Preserve Cloudflare DNS data, configuration, access, and operating evidence before any destination write.

  1. Export every available Cloudflare DNS object and binary in scope, including zones, record sets, names, and ttls, nameservers, delegation, and dnssec, traffic steering and health checks, proxy, cdn, origins, and host headers.
  2. Capture configuration and runtime dependencies for tls certificates and security policy, caching, purge, and stale behavior, redirects, rewrites, edge logic, and headers, waf, bot, rate-limit, and access controls.
  3. Record counts, sizes, owners, timestamps, access classes, financial totals where applicable, and known exceptions.
  4. Hash immutable exports, record tool versions and commands, and transform working copies only.

Proof to capture: A signed manifest accounts for every scoped record class, configuration object, binary, count, total, exception, and hash.

Transformation · Version-controlled migration workbook, SQL, or typed transformation code

Identity, schema, and disposition registry

Preserve stable identity and make every mapping or exclusion reviewable.

  1. Inventory source types, identifiers, owners, states, and access.
  2. Define one approved destination representation or explicit archive decision.
  3. Reject unmapped critical items and produce an exception ledger.

Proof to capture: Save the input, output, command or tool settings, warnings, and final item counts.

Transformation · Official APIs, provider importers, checksums, and reconciliation scripts

Dependency-ordered migration package

Load prerequisite identities and configuration before dependent records and runtime actions.

  1. Normalize encoding, timestamps, identifiers, nulls, and destination limits.
  2. Run a representative pilot and retain request, response, and rejection evidence.
  3. Reconcile the final delta before enabling destination production writers.

Proof to capture: Save the input, output, command or tool settings, warnings, and final item counts.

05Handle with care

The things most likely to hurt.

These are operating limits. Treat every “Stop if” condition as a blocked migration, not a suggestion.

Import

A completed migration hides missing or altered zones, record sets, names, and ttls

criticalpossible likelihood

Headline counts look plausible while semantic, access, or relationship checks fail.

Consequence
The destination becomes authoritative with incomplete or misleading business data.
Mitigation
Reconcile by type, state, owner, access class, and representative record rather than total count alone.

Stop if: Any critical item lacks a verified destination, approved transformation, explicit exclusion, or recoverable archive.

Cutover

Cloudflare DNS and Amazon Route 53 both perform production actions

criticalpossible likelihood

Users, schedules, webhooks, integrations, or traffic continue changing both systems.

Consequence
State diverges or customers receive duplicate, contradictory, or unsafe actions.
Mitigation
Freeze source writers and transfer one production owner at a time with an approved rollback.

Stop if: An unapproved source writer or destination duplicate action appears after the freeze.

Verification

Destination access or security is broader than approved

criticalpossible likelihood

A representative restricted user can read, change, export, or trigger an unauthorized item.

Consequence
Confidential, regulated, financial, or security-sensitive data is exposed or changed.
Mitigation
Apply least privilege before bulk loading and test every access class using ordinary identities.

Stop if: Any unauthorized read, write, export, administrative action, or secret access succeeds.

06Precise timeline

Do the work in this order.

Estimate forUp to 1,000 zones, 100,000 records, 500 edge rules, and 10 Tbps of peak traffic
Total elapsed15–45 business days
Active work70–180 hours
BufferAdd time for large Cloudflare DNS exports, destination rate limits, unsupported features, identity exceptions, regulated data, or a strict downtime objective.
01
Days 1–4Inventory and decisions2–4 days
02
Days 3–8Backup and reconcile2–5 days
03
Days 6–20Map, transform, and pilot5–12 days
04
Days 18–35Bulk load, final delta, and switch2–8 days
05
Days 25–45Observe and close7–14 days
  1. Days 1–4 · inventory

    Inventory and decisions

    8–16 hours active2–4 days elapsedOwner, legal, security, and finance review waiting
    • Inventory Cloudflare DNS data, configuration, identities, integrations, limits, and billing.
    • Approve scope, owners, mappings, exclusions, acceptance thresholds, and rollback authority.

    Depends on: Cloudflare DNS and Amazon Route 53 administrator access

    Stop / go checkpoint

    Export?

    Go when: Every critical item and production action has an owner and disposition.

    Stop when: Authority, retention, billing, access, or system ownership is unclear.

  2. Days 3–8 · backup

    Backup and reconcile

    8–20 hours active2–5 days elapsedProvider export processing waiting
    • Create immutable data, configuration, binary, and audit exports.
    • Reconcile source counts, totals, sizes, access classes, and hashes.

    Depends on: Approved inventory and retention location

    Stop / go checkpoint

    Transform?

    Go when: The signed source manifest and exports agree.

    Stop when: Any critical dataset, binary, configuration, or recovery path is absent.

  3. Days 6–20 · pilot

    Map, transform, and pilot

    25–70 hours active5–12 days elapsedDestination processing and owner review waiting
    • Configure Amazon Route 53 and transform a production-shaped pilot.
    • Test normal records, every feature class, edge cases, permissions, failures, and rollback.

    Depends on: Verified source backup and approved mapping registry

    Stop / go checkpoint

    Scale?

    Go when: Every pilot mapping and blocking verification check passes.

    Stop when: Any critical invariant, access boundary, or production action lacks a safe destination.

  4. Days 18–35 · cutover

    Bulk load, final delta, and switch

    20–55 hours active2–8 days elapsedImports, propagation, indexing, or synchronization waiting
    • Freeze production writes and automated actions in Cloudflare DNS.
    • Apply and reconcile the final delta, switch ownership to Amazon Route 53, and run all blocking checks.

    Depends on: Passed pilot, stakeholder go decision, and rehearsed rollback

    Stop / go checkpoint

    Open production?

    Go when: Amazon Route 53 is the sole production owner and every critical exception is resolved.

    Stop when: A source writer remains active, a blocking check fails, or rollback is unavailable.

  5. Days 25–45 · observe

    Observe and close

    9–19 hours active7–14 days elapsedRepresentative operating-cycle evidence waiting
    • Monitor correctness, access, failures, latency, delivery, cost, and user outcomes.
    • Sign the verification report and close rollback only after stable evidence.

    Depends on: Verified cutover

    Stop / go checkpoint

    Close rollback?

    Go when: No trigger occurs during the approved observation period.

    Stop when: Data, access, delivery, routing, cost, or business results regress.

07The point of change

Cut over with a way back.

Go live

Cutover

Make Amazon Route 53 the only production system without losing the final Cloudflare DNS delta.

Recommended window: A low-volume weekday morning with platform, data, security, networking, finance, and business owners available.

  1. Freeze user, integration, schedule, and API writes in Cloudflare DNS.
  2. Capture and reconcile the final source delta against the last verified checkpoint.
  3. Apply the approved delta and configuration changes to Amazon Route 53.
  4. Switch traffic, domains, integrations, credentials, automation, and user entry points in dependency order.
  5. Run every blocking verification check and keep the source intact.

Proof to capture: Amazon Route 53 alone owns production, totals reconcile, exceptions are signed, and every blocking check has durable evidence.

Return to safety

Rollback

Return production ownership to Cloudflare DNS without losing destination-era changes.

Deadline: Within seven days and before source data, plans, credentials, domains, keys, or retention settings are changed.

  1. Stop new user, integration, schedule, and API writes in Amazon Route 53.
  2. Restore prior Cloudflare DNS traffic, domains, credentials, automation, and integration ownership.
  3. Export and classify the Amazon Route 53 post-cutover delta.
  4. Apply safe destination-era changes back to Cloudflare DNS without duplicating actions.
  5. Run the same blocking checks against the restored source.

Proof to capture: Cloudflare DNS again owns production with current data and no duplicate destination action.

Rollback immediately when
  • Unexplained critical count, value, relationship, or checksum variance
  • Missing, corrupted, or exposed critical data
  • Duplicate production action or unresolved split-brain state
  • Failed access, security, delivery, routing, performance, or integration check
  • A critical feature has no safe destination replacement or rollback path
08Verification report

Prove the migration worked.

Every blocking check must pass. Capture the evidence before cleanup begins.

0%
Interactive report preview0 / 8 checks passed
PassIDCheckMethodExpected resultEvidence
V-01BlockingZones, record sets, names, and TTLs reconciliationCompare source inventory, transformed output, destination results, and a stratified sample for zones, record sets, names, and ttls.Every in-scope item is present, intentionally transformed, explicitly excluded, or retained in the signed source archive.Zones, record sets, names, and TTLs ledger with counts, exceptions, sample IDs, and owner sign-off.
V-02BlockingNameservers, delegation, and DNSSEC reconciliationCompare source inventory, transformed output, destination results, and a stratified sample for nameservers, delegation, and dnssec.Every in-scope item is present, intentionally transformed, explicitly excluded, or retained in the signed source archive.Nameservers, delegation, and DNSSEC ledger with counts, exceptions, sample IDs, and owner sign-off.
V-03BlockingTraffic steering and health checks reconciliationCompare source inventory, transformed output, destination results, and a stratified sample for traffic steering and health checks.Every in-scope item is present, intentionally transformed, explicitly excluded, or retained in the signed source archive.Traffic steering and health checks ledger with counts, exceptions, sample IDs, and owner sign-off.
V-04BlockingProxy, CDN, origins, and host headers reconciliationCompare source inventory, transformed output, destination results, and a stratified sample for proxy, cdn, origins, and host headers.Every in-scope item is present, intentionally transformed, explicitly excluded, or retained in the signed source archive.Proxy, CDN, origins, and host headers ledger with counts, exceptions, sample IDs, and owner sign-off.
V-05BlockingTLS certificates and security policy reconciliationCompare source inventory, transformed output, destination results, and a stratified sample for tls certificates and security policy.Every in-scope item is present, intentionally transformed, explicitly excluded, or retained in the signed source archive.TLS certificates and security policy ledger with counts, exceptions, sample IDs, and owner sign-off.
V-06BlockingCaching, purge, and stale behavior reconciliationCompare source inventory, transformed output, destination results, and a stratified sample for caching, purge, and stale behavior.Every in-scope item is present, intentionally transformed, explicitly excluded, or retained in the signed source archive.Caching, purge, and stale behavior ledger with counts, exceptions, sample IDs, and owner sign-off.
V-07BlockingRedirects, rewrites, edge logic, and headers reconciliationCompare source inventory, transformed output, destination results, and a stratified sample for redirects, rewrites, edge logic, and headers.Every in-scope item is present, intentionally transformed, explicitly excluded, or retained in the signed source archive.Redirects, rewrites, edge logic, and headers ledger with counts, exceptions, sample IDs, and owner sign-off.
V-08BlockingWAF, bot, rate-limit, and access controls reconciliationCompare source inventory, transformed output, destination results, and a stratified sample for waf, bot, rate-limit, and access controls.Every in-scope item is present, intentionally transformed, explicitly excluded, or retained in the signed source archive.WAF, bot, rate-limit, and access controls ledger with counts, exceptions, sample IDs, and owner sign-off.
09Post-migration cleanup

Remove the scaffolding safely.

Safe after: One complete operating cycle, at least seven stable days, and owner sign-off on every blocking check and exception.

  1. Create final Cloudflare DNS exports and archive verification, access, financial, and rollback evidence.
  2. Revoke temporary credentials, API keys, webhooks, elevated roles, and migration network access.
  3. Remove obsolete jobs, embeds, domains, integrations, collectors, routes, and DNS records.
  4. Keep the source intact and read-only through the approved legal and operational retention window.
  5. Cancel paid plans only after billing, legal, security, evidence, and recovery review.
  6. Schedule the next Amazon Route 53 backup, restore test, access review, and migration-playbook review.
10Experiences from the field

When the plan met reality.

First-hand accounts are preferred. Vendor case studies are labeled, and every note below is an editorial paraphrase—follow the link for the full context.

First-person accountNick Little · Nick Little

Migrate from CloudFlare and GitHub Pages to AWS for Static Web Hosting2022

AWS solutions architect Nick Little documents moving a personal domain and DNS from Cloudflare to Route 53 as part of a wider static-site migration. Cloudflare's BIND export imported only after removing SOA and NS records and replacing an apex CNAME that depended on Cloudflare flattening with Route 53's alias model. Because Cloudflare Registrar did not support third-party DNS, the project also required disabling DNSSEC, unlocking and transferring the domain, and debugging an unused DNSSEC key afterward.

What they recommend
  • Inspect apex CNAME flattening and translate it to a supported Route 53 alias or address strategy before importing the zone.
  • Lower TTLs early, disable DNSSEC in the correct sequence, and budget separately for a registrar transfer when required.
Worth noticing
  • A standards-based zone export still contained a Cloudflare-specific apex behavior that Route 53 rejected.
  • Changing DNS, registrar, hosting, and DNSSEC together made the final resolution fault harder to isolate.
Sources and evidence

Verify against the primary material.

Platform behavior changes. Check these sources and the review dates above before executing a production migration.

  1. Cloudflare DNS: official portability and migration documentationAccessed 2026-07-20
  2. Amazon Route 53: official portability and migration documentationAccessed 2026-07-20