Skip to main content
On this page

​
Coverage by target cloud

​
How the backends compare

Each row compares a capability of Route 53 with its adaptation on each backend. A dash means this row is not stated for that backend.

​
Max adaptation

​
Infrastructure-only adaptation

​
On Google Cloud

​
How it works

Tensor9 translates Route 53 zones and records into Cloud DNS managed zones and record sets in your Google Cloud project, and Google’s authoritative servers answer queries. Your application uses the Route 53 API through the adapter for supported zone and record changes at runtime.
Your application sends Route 53 record changes to the Tensor9 adapter, which applies them to Cloud DNS with the provider credential it holds. DNS queries go straight to Cloud DNS.Your application sends Route 53 record changes to the Tensor9 adapter, which applies them to Cloud DNS with the provider credential it holds. DNS queries go straight to Cloud DNS.

Record changes go through the adapter; DNS queries go straight to the provider.

​
Zones and records

With Infrastructure-only adaptation, a declared zone becomes a managed zone, and an explicit lookup uses an existing Cloud DNS managed-zone name, which can differ from the DNS domain. Private zones attached to the target VPC network are supported at deployment. The runtime adapter manages its own public zones and reports the nameservers Google assigns. Looking up an existing zone does not transfer its ownership to the adapter. Do not let another controller write to the same zone; a previously seen zone that goes missing or is replaced needs explicit repair. The runtime adapter supports A, AAAA, CAA, CNAME, DS, HTTPS, MX, NAPTR, NS, PTR, SOA, SPF, SRV, SSHFP, SVCB, TLSA and TXT, keeping all values in an ordinary record set. Publishing DNSSEC-related records does not configure signing or key management. Infrastructure-only adaptation converts deprecated SPF declarations to TXT and defaults an unset TTL to 300 seconds.

​
Aliases and routing

An infrastructure alias resolves to the referenced resource’s address on the target cloud. Cloud DNS also offers an apex ALIAS type for public zones, but that is separate from resolving a resource reference at deployment. Route 53 target-health evaluation is not kept, and runtime AliasTarget requests are not supported. Weighted, latency, failover, geolocation and other Route 53 routing policies are not supported. Deployment can keep a record’s name, type and values while reporting the dropped policy. Cloud DNS has its own routing policies, but this mapping does not configure them. Multiple values in an ordinary record do not reproduce health-checked or weighted routing.

​
Runtime changes

Your application sends Route 53 API requests to the Tensor9 adapter, which records each change and applies it with the provider credential it holds. ChangeResourceRecordSets returns a change receipt; GetChange reports PENDING until the provider has applied the change, then INSYNC. INSYNC means the provider has applied the change. It does not guarantee that every authoritative server has observed the change or that recursive caches have expired, so keep polling for completion and allow for DNS caching during cutover. Google applies a change batch all at once, and the adapter still waits for Google to report completion before it finishes the receipt. Creating and deleting public zones, reading their nameservers and changing records all use the same managed zone; deployment support for private zones does not mean the runtime adapter manages private zones.

​
Limitations

Where Cloud DNS and Route 53 differ
  • Health checks are not supported. The Cloud DNS mapping leaves standalone Route 53 health checks out and reports them.
  • Delegation sets and Resolver resources are not supported. They are outside the zones-and-records mapping. The separate Resolver page describes hybrid DNS.
  • Very large zones are not supported by the runtime adapter. The native record inventory and change history must each fit in one response; paged native results are rejected. This is separate from paging in the Route 53 record-list API.
  • You must keep Google’s assigned apex nameservers. Supported apex TTL and SOA updates cannot reassign them, and deleting the apex NS or SOA records on their own is rejected. DS records at the zone apex and SOA records below it are rejected. Remove ordinary records before deleting the zone.

​
Other considerations

  • Private zones and consumers. Confirm DNS access from the network for a private zone, and update external consumers of AWS zone IDs or nameservers. A new public zone needs delegation to its Google nameservers.
  • Moving from AWS. Apply the records you need, check the authoritative answers, then update public nameserver delegation if the provider changes. Keep the previous zone available while cached records and delegation expire. Only declared records are applied; an existing zone and its query history are not copied.
  • When the appliance is down. Record changes need the appliance and its provider credentials. Records already applied keep answering from the provider.
  • Other DNS writers. Certificate-validation records are coordinated with certificate management. Review external DNS controllers and any credentials they used before.

​
Example monthly charges

This Tensor9 BYOC scenario estimates service charges for the named origin and target services. Adapter hosting and commercial Tensor9 fees need separate allocations. How Tensor9 estimates costs explains the method and what the estimates include.
Authoritative DNS zones and queries (Route 53) · Authoritative DNS queries per second
Feature: Authoritative DNS zones and queries (Route 53). Estimated monthly service charges by Authoritative DNS queries per second. Adapter hosting and Tensor9 fees are excluded. Source: us-east-1; target: us-central1; currency: USD.
Authoritative DNS zones and queries (Route 53) · Authoritative DNS queries per second: monthly service charges by Authoritative DNS queries per second. Exact values are in the following table.Authoritative DNS zones and queries (Route 53) · Authoritative DNS queries per second: monthly service charges by Authoritative DNS queries per second. Exact values are in the following table.
Comparison pills describe all sampled scale points; amounts beside each service are for the named workload. Costs The Same means within 20% at every point. Costs Depend includes mixed results and unpriced samples. Sampled monthly charges in USD, rounded to cents. Difference means target minus origin; a positive difference means the target costs more. Curve assumptions
  • Only this native meter varies; all other source usage and translation assumptions retain the displayed defaults. Other native meters and workload assumptions retain their explicitly displayed default quantities. Workload translation and capacity assumptions are not benchmark measurements.
  • Native monthly usage priced at the cited provider list prices; listed target allowances apply where present, excluding invoice credits, taxes and negotiated discounts. Rates as of 2026-10-22: us-east-1 → us-central1, USD/month.
  • Source prices are reference charges, not an invoice. Target lines cover selected service usage/configuration only; adapter hosting and Tensor9 fees are excluded.
  • Samples of explicit prices are not performance measurements or capacity qualification. No interpolation or break-even guarantee is implied.
  • Variant assumptions show the first axis sample; any axis-dependent configuration is described by this curve’s workload note.
  • Rates are cited provider list prices, editable for discounts, commitments or another region. Workload translation and capacity coefficients remain editable planning assumptions, not benchmark measurements or a commercial quote.
  • Default-zero rates are explicit assumptions, not evidence that the deployed service or resource is free.
  • Provisioned-unit minimums use an editable approximate allocation floor. Modeled target service cost is max(usage/allocation, minimum), with billable network, durable staging and dependent sinks added separately; actual RU/TU sizing, scaling increments and throughput remain unqualified.
  • Durable staging is priced once: provisioned targets include adapter state in their selected allocation; native targets add a separate staging allocation when required. Adapter hosting is a separate allocation and must exclude resources already priced as staging, workers or target capacity.
  • A declared adapter mapping and cost model do not establish implementation availability or service equivalence.
  • This is a declared directed mapping; a planning estimate does not establish deployment or request-serving support.
  • Origin unit prices are cited provider list prices; capacity coefficients and translation assumptions are editable authored planning guesses, not measured capacity or a provider quote.
  • Management requests do not reveal resource allocation or workload traffic. Provisioned resources and traffic are independent inputs.
  • This compares authoritative zones and query meters; resolver forwarding has a different allocation and price.
  • A cost scenario does not establish live-qualified runtime DNS propagation or public authority.
  • Zone-months and authoritative queries are billed independently; management calls are free. Cloud DNS managed zones and regular queries; zone prices step down at 25 and 10,000 zones, query prices after one billion. Routing policy queries cost more. Cloud DNS bills no data transfer.
  • AWS Price List API, AmazonRoute53 offer: https://pricing.us-east-1.amazonaws.com/offers/v1.0/aws/AmazonRoute53/current/aws-other/index.json
  • Amazon Route 53 pricing: https://aws.amazon.com/route53/pricing/
  • Cloud DNS pricing: https://cloud.google.com/dns/pricing
Cost scope: Modeled target native service and explicitly modeled state allocation; hosting and Tensor9 fees only when supplied. Excluded costs and workload features:
  • Health checks, DNSSEC premiums, resolver endpoints, query logs, domain registration and routing-policy premiums.
  • Taxes, discounts, credits and free-tier allowances not explicitly listed by this model.
  • Unmodeled dependent services, task execution and operations outside the selected workload family.
List prices read: 2026-10-22. Model: plan-bc96b4c81d9aeb673035e632cdbd5ab340d4a1cd / 2026-10-22.planning.2. Curve: workload-1. Sources: AWS Price List API, AmazonRoute53 offer, Amazon Route 53 pricing, Cloud DNS pricing. Authoritative DNS zones and queries (Route 53) → Cloud DNS: Authored native-usage planning example. Native monthly usage priced at the cited provider list prices; listed target allowances apply where present, excluding invoice credits, taxes and negotiated discounts. Scenario source region: us-east-1. Scenario target region: us-central1. Currency: USD. Unestimated components: Adapter hosting, Tensor9 fees. A modeled adapted total and savings require these costs. Cost scope: Modeled target native service and explicitly modeled state allocation; hosting and Tensor9 fees only when supplied. Excluded costs and workload features:
  • Health checks, DNSSEC premiums, resolver endpoints, query logs, domain registration and routing-policy premiums.
  • Taxes, discounts, credits and free-tier allowances not explicitly listed by this model.
  • Unmodeled dependent services, task execution and operations outside the selected workload family.
Scenario assumptions
  • Translated reads: 100,000 operations.
  • Translated writes: 0 operations.
  • Translated resident physical data: 0 GiB-month.
  • Native provider operations: 100,000,000 operations.
  • Published payload: 0 GiB.
  • Delivered payload: 0 GiB.
  • Allocated execution CPU: 0 vCPU-hour.
  • Allocated execution RAM: 0 GiB-hour.
  • Independent resource allocation: 0 resource-hour.
  • Independent inventory: 1 resource-month.
  • Input tokens: 0 tokens.
  • Output tokens: 0 tokens.
  • Billable network: 0 GiB.
  • Dependent object sink retained data: 0 GiB-month.
  • Dependent object sink writes: 0 writes.
  • Rates are cited provider list prices, editable for discounts, commitments or another region. Workload translation and capacity coefficients remain editable planning assumptions, not benchmark measurements or a commercial quote.
  • Default-zero rates are explicit assumptions, not evidence that the deployed service or resource is free.
  • Provisioned-unit minimums use an editable approximate allocation floor. Modeled target service cost is max(usage/allocation, minimum), with billable network, durable staging and dependent sinks added separately; actual RU/TU sizing, scaling increments and throughput remain unqualified.
  • Durable staging is priced once: provisioned targets include adapter state in their selected allocation; native targets add a separate staging allocation when required. Adapter hosting is a separate allocation and must exclude resources already priced as staging, workers or target capacity.
  • A declared adapter mapping and cost model do not establish implementation availability or service equivalence.
  • This is a declared directed mapping; a planning estimate does not establish deployment or request-serving support.
  • Origin unit prices are cited provider list prices; capacity coefficients and translation assumptions are editable authored planning guesses, not measured capacity or a provider quote.
  • Management requests do not reveal resource allocation or workload traffic. Provisioned resources and traffic are independent inputs.
  • This compares authoritative zones and query meters; resolver forwarding has a different allocation and price.
  • A cost scenario does not establish live-qualified runtime DNS propagation or public authority.
  • Zone-months and authoritative queries are billed independently; management calls are free. Cloud DNS managed zones and regular queries; zone prices step down at 25 and 10,000 zones, query prices after one billion. Routing policy queries cost more. Cloud DNS bills no data transfer.
List prices read: 2026-10-22. Model: plan-bc96b4c81d9aeb673035e632cdbd5ab340d4a1cd / 2026-10-22.planning.2. Scenario: planning-example. Sources: AWS Price List API, AmazonRoute53 offer, Amazon Route 53 pricing, Cloud DNS pricing.

​
On Azure

​
How it works

Tensor9 applies Route 53 records to Azure DNS in your subscription and resource group, and Azure’s authoritative servers answer queries. The adapter also supports the Route 53 public hosted-zone lifecycle and record-change API, and returns the nameservers Azure assigns to your application.
Your application sends Route 53 record changes to the Tensor9 adapter, which applies them to Azure DNS with the provider credential it holds. DNS queries go straight to Azure DNS.Your application sends Route 53 record changes to the Tensor9 adapter, which applies them to Azure DNS with the provider credential it holds. DNS queries go straight to Azure DNS.

Record changes go through the adapter; DNS queries go straight to the provider.

​
Zones and record ownership

A deployment-time zone lookup needs an existing Azure DNS zone; it does not transfer that zone to runtime ownership. The runtime adapter can create and delete the public zone it manages, but its subscription and resource group must already exist. Do not let another controller write to that zone. An unrelated zone with the same name is not adopted automatically, and two logical zones with the same DNS name need separate Azure placement. The runtime adapter supports A, AAAA, CAA, CNAME, MX, NS, PTR, SOA, SRV and TXT. It retains Azure-assigned apex nameservers and the SOA primary; other supported SOA fields and the apex TTLs can change. Deleting the apex NS or SOA records on their own is rejected, so remove ordinary records before deleting the hosted zone. Other record types, private zones and Azure native aliases are outside the runtime adapter.

​
Aliases and routing

Azure native aliases point at supported Azure resources; they cannot alias an arbitrary hostname at a zone apex. This mapping does not reproduce Route 53 aliases or their target-health evaluation. A resolved infrastructure address can become an ordinary address record instead, which does not keep alias behaviour over time. Route 53 routing policies are not supported. Deployment can keep ordinary record values while reporting the dropped policy. Azure Traffic Manager has its own traffic routing, which you configure separately if you need it. Multiple values alone do not reproduce a weighted or health-checked answer.

​
Runtime changes

Your application sends Route 53 API requests to the Tensor9 adapter, which records each change and applies it with the provider credential it holds. ChangeResourceRecordSets returns a change receipt; GetChange reports PENDING until the provider has applied the change, then INSYNC. INSYNC means the provider has applied the change. It does not guarantee that every authoritative server has observed the change or that recursive caches have expired, so keep polling for completion and allow for DNS caching during cutover. The adapter records a change batch as one unit, but Azure applies individual record sets separately, so DNS answers can briefly show part of a multi-record change. Conditional writes detect changes made by another writer. Plan related record changes so that this in-between state is acceptable.

​
Limitations

Where Azure DNS and Route 53 differ
  • Health checks, delegation sets and Resolver resources are not supported. They are outside this zone-and-record mapping.
  • Private zones are not supported. Azure Private DNS is a separate service; this public-zone lifecycle does not create a private zone.
  • Unsupported record types are rejected. The runtime API rejects types outside its list instead of changing their meaning. Converting SPF to TXT at deployment does not mean the runtime API supports SPF.
  • Very large zones are not supported. Native record inventory must fit in one response. The adapter rejects an incomplete inventory rather than delete records based on it.
  • Escaped or binary record names are not supported. Runtime record names must be ASCII DNS labels within the usual length limits, and non-UTF-8 TXT or CAA data is not supported.
  • You must repair a missing zone yourself. If a zone the adapter has seen disappears, repair its association explicitly; the adapter does not automatically allocate new authority.
  • You must keep write access to the zone with the adapter. Ownership markers help detect unrelated zones and records, but another writer can copy those markers.

​
Other considerations

  • Moving from AWS. Apply the records you need, check the authoritative answers, then update public nameserver delegation if the provider changes. Keep the previous zone available while cached records and delegation expire. Only declared records are applied; an existing zone and its query history are not copied.
  • When the appliance is down. Record changes need the appliance and its provider credentials. Records already applied keep answering from the provider.
  • Other DNS writers. Certificate-validation records are coordinated with certificate management. Review external DNS controllers and any credentials they used before.

​
Example monthly charges

This Tensor9 BYOC scenario estimates service charges for the named origin and target services. Adapter hosting and commercial Tensor9 fees need separate allocations. How Tensor9 estimates costs explains the method and what the estimates include.
Authoritative DNS zones and queries (Route 53) · Authoritative DNS queries per second
Feature: Authoritative DNS zones and queries (Route 53). Estimated monthly service charges by Authoritative DNS queries per second. Adapter hosting and Tensor9 fees are excluded. Source: us-east-1; target: eastus; currency: USD.
Authoritative DNS zones and queries (Route 53) · Authoritative DNS queries per second: monthly service charges by Authoritative DNS queries per second. Exact values are in the following table.Authoritative DNS zones and queries (Route 53) · Authoritative DNS queries per second: monthly service charges by Authoritative DNS queries per second. Exact values are in the following table.
Comparison pills describe all sampled scale points; amounts beside each service are for the named workload. Costs The Same means within 20% at every point. Costs Depend includes mixed results and unpriced samples. Sampled monthly charges in USD, rounded to cents. Difference means target minus origin; a positive difference means the target costs more. Curve assumptions
  • Only this native meter varies; all other source usage and translation assumptions retain the displayed defaults. Other native meters and workload assumptions retain their explicitly displayed default quantities. Workload translation and capacity assumptions are not benchmark measurements.
  • Native monthly usage priced at the cited provider list prices; listed target allowances apply where present, excluding invoice credits, taxes and negotiated discounts. Rates as of 2026-10-22: us-east-1 → eastus, USD/month.
  • Source prices are reference charges, not an invoice. Target lines cover selected service usage/configuration only; adapter hosting and Tensor9 fees are excluded.
  • Samples of explicit prices are not performance measurements or capacity qualification. No interpolation or break-even guarantee is implied.
  • Variant assumptions show the first axis sample; any axis-dependent configuration is described by this curve’s workload note.
  • Rates are cited provider list prices, editable for discounts, commitments or another region. Workload translation and capacity coefficients remain editable planning assumptions, not benchmark measurements or a commercial quote.
  • Default-zero rates are explicit assumptions, not evidence that the deployed service or resource is free.
  • Provisioned-unit minimums use an editable approximate allocation floor. Modeled target service cost is max(usage/allocation, minimum), with billable network, durable staging and dependent sinks added separately; actual RU/TU sizing, scaling increments and throughput remain unqualified.
  • Durable staging is priced once: provisioned targets include adapter state in their selected allocation; native targets add a separate staging allocation when required. Adapter hosting is a separate allocation and must exclude resources already priced as staging, workers or target capacity.
  • A declared adapter mapping and cost model do not establish implementation availability or service equivalence.
  • This is a declared directed mapping; a planning estimate does not establish deployment or request-serving support.
  • Origin unit prices are cited provider list prices; capacity coefficients and translation assumptions are editable authored planning guesses, not measured capacity or a provider quote.
  • Management requests do not reveal resource allocation or workload traffic. Provisioned resources and traffic are independent inputs.
  • This compares authoritative zones and query meters; resolver forwarding has a different allocation and price.
  • A cost scenario does not establish live-qualified runtime DNS propagation or public authority.
  • Zone-months and authoritative queries are billed independently; management calls are free. Azure DNS public zones and queries; zone and query prices step down after 25 zones and one billion queries.
  • AWS Price List API, AmazonRoute53 offer: https://pricing.us-east-1.amazonaws.com/offers/v1.0/aws/AmazonRoute53/current/aws-other/index.json
  • Amazon Route 53 pricing: https://aws.amazon.com/route53/pricing/
  • Azure Retail Prices API: https://prices.azure.com/api/retail/prices
Cost scope: Modeled target native service and explicitly modeled state allocation; hosting and Tensor9 fees only when supplied. Excluded costs and workload features:
  • Health checks, DNSSEC premiums, resolver endpoints, query logs, domain registration and routing-policy premiums.
  • Taxes, discounts, credits and free-tier allowances not explicitly listed by this model.
  • Unmodeled dependent services, task execution and operations outside the selected workload family.
List prices read: 2026-10-22. Model: plan-e814138b3589e4584681dfbb2713fa1ae4e3f7f5 / 2026-10-22.planning.2. Curve: workload-1. Sources: AWS Price List API, AmazonRoute53 offer, Amazon Route 53 pricing, Azure Retail Prices API. Authoritative DNS zones and queries (Route 53) → Azure DNS: Authored native-usage planning example. Native monthly usage priced at the cited provider list prices; listed target allowances apply where present, excluding invoice credits, taxes and negotiated discounts. Scenario source region: us-east-1. Scenario target region: eastus. Currency: USD. Unestimated components: Adapter hosting, Tensor9 fees. A modeled adapted total and savings require these costs. Cost scope: Modeled target native service and explicitly modeled state allocation; hosting and Tensor9 fees only when supplied. Excluded costs and workload features:
  • Health checks, DNSSEC premiums, resolver endpoints, query logs, domain registration and routing-policy premiums.
  • Taxes, discounts, credits and free-tier allowances not explicitly listed by this model.
  • Unmodeled dependent services, task execution and operations outside the selected workload family.
Scenario assumptions
  • Translated reads: 100,000 operations.
  • Translated writes: 0 operations.
  • Translated resident physical data: 0 GiB-month.
  • Native provider operations: 100,000,000 operations.
  • Published payload: 0 GiB.
  • Delivered payload: 0 GiB.
  • Allocated execution CPU: 0 vCPU-hour.
  • Allocated execution RAM: 0 GiB-hour.
  • Independent resource allocation: 0 resource-hour.
  • Independent inventory: 1 resource-month.
  • Input tokens: 0 tokens.
  • Output tokens: 0 tokens.
  • Billable network: 0 GiB.
  • Dependent object sink retained data: 0 GiB-month.
  • Dependent object sink writes: 0 writes.
  • Rates are cited provider list prices, editable for discounts, commitments or another region. Workload translation and capacity coefficients remain editable planning assumptions, not benchmark measurements or a commercial quote.
  • Default-zero rates are explicit assumptions, not evidence that the deployed service or resource is free.
  • Provisioned-unit minimums use an editable approximate allocation floor. Modeled target service cost is max(usage/allocation, minimum), with billable network, durable staging and dependent sinks added separately; actual RU/TU sizing, scaling increments and throughput remain unqualified.
  • Durable staging is priced once: provisioned targets include adapter state in their selected allocation; native targets add a separate staging allocation when required. Adapter hosting is a separate allocation and must exclude resources already priced as staging, workers or target capacity.
  • A declared adapter mapping and cost model do not establish implementation availability or service equivalence.
  • This is a declared directed mapping; a planning estimate does not establish deployment or request-serving support.
  • Origin unit prices are cited provider list prices; capacity coefficients and translation assumptions are editable authored planning guesses, not measured capacity or a provider quote.
  • Management requests do not reveal resource allocation or workload traffic. Provisioned resources and traffic are independent inputs.
  • This compares authoritative zones and query meters; resolver forwarding has a different allocation and price.
  • A cost scenario does not establish live-qualified runtime DNS propagation or public authority.
  • Zone-months and authoritative queries are billed independently; management calls are free. Azure DNS public zones and queries; zone and query prices step down after 25 zones and one billion queries.
List prices read: 2026-10-22. Model: plan-e814138b3589e4584681dfbb2713fa1ae4e3f7f5 / 2026-10-22.planning.2. Scenario: planning-example. Sources: AWS Price List API, AmazonRoute53 offer, Amazon Route 53 pricing, Azure Retail Prices API.

​
On OCI

​
How it works

Tensor9 applies the Route 53 records you declare to an existing OCI DNS zone in your compartment. The appliance holds the OCI credential. OCI’s authoritative servers answer public DNS queries directly.
Your application sends Route 53 record changes to the Tensor9 adapter, which applies them to OCI DNS with the provider credential it holds. DNS queries go straight to OCI DNS.Your application sends Route 53 record changes to the Tensor9 adapter, which applies them to OCI DNS with the provider credential it holds. DNS queries go straight to OCI DNS.

Record changes go through the adapter; DNS queries go straight to the provider.

​
Zones, records and aliases

The zone is looked up by domain name and must already exist. The documented record types are A, AAAA, CAA, CNAME, DS, MX, NAPTR, NS, PTR, SPF, SRV, SSHFP, TLSA and TXT. All values in an ordinary record set are kept, and an unset deployment TTL defaults to 300 seconds. OCI retains the deprecated SPF type and maintains the zone’s SOA and assigned apex nameservers. HTTPS and SVCB are not included in this documented OCI mapping. An infrastructure alias resolves a resource reference to its address on the target cloud. OCI also offers a native ALIAS pseudo-type at a public zone’s apex; that is separate from resolving a deployment reference. Route 53 alias target-health evaluation is dropped, and multiple address values do not by themselves give health-checked routing.

​
Runtime changes

Your application sends Route 53 API requests to the Tensor9 adapter, which records each change and applies it with the provider credential it holds. ChangeResourceRecordSets returns a change receipt; GetChange reports PENDING until the provider has applied the change, then INSYNC. INSYNC means the provider has applied the change. It does not guarantee that every authoritative server has observed the change or that recursive caches have expired, so keep polling for completion and allow for DNS caching during cutover.

​
Limitations

Where OCI DNS and Route 53 differ
  • Route 53 routing policies are not supported. They are left out and reported, while ordinary record data is still applied. OCI’s separate traffic-steering and health-check services are not configured by this mapping.
  • Route 53 health checks are not supported. A standalone health-check resource stops the build for this backend.
  • Private zones, delegation sets and Resolver resources are not supported. They are outside this zones-and-records mapping. OCI private DNS and the separate Resolver mapping have their own configuration; this does not mean OCI lacks private DNS.

​
Other considerations

  • Moving from AWS. Apply the records you need, check the authoritative answers, then update public nameserver delegation if the provider changes. Keep the previous zone available while cached records and delegation expire. Only declared records are applied; an existing zone and its query history are not copied.
  • When the appliance is down. Record changes need the appliance and its provider credentials. Records already applied keep answering from the provider.
  • Other DNS writers. Certificate-validation records are coordinated with certificate management. Review external DNS controllers and any credentials they used before.

​
Example monthly charges

This Tensor9 BYOC scenario estimates service charges for the named origin and target services. Adapter hosting and commercial Tensor9 fees need separate allocations. How Tensor9 estimates costs explains the method and what the estimates include.
Authoritative DNS zones and queries (Route 53) · Authoritative DNS queries per second
Feature: Authoritative DNS zones and queries (Route 53). Estimated monthly service charges by Authoritative DNS queries per second. Adapter hosting and Tensor9 fees are excluded. Source: us-east-1; target: us-ashburn-1; currency: USD.
Authoritative DNS zones and queries (Route 53) · Authoritative DNS queries per second: monthly service charges by Authoritative DNS queries per second. Exact values are in the following table.Authoritative DNS zones and queries (Route 53) · Authoritative DNS queries per second: monthly service charges by Authoritative DNS queries per second. Exact values are in the following table.
Comparison pills describe all sampled scale points; amounts beside each service are for the named workload. Costs The Same means within 20% at every point. Costs Depend includes mixed results and unpriced samples. Sampled monthly charges in USD, rounded to cents. Difference means target minus origin; a positive difference means the target costs more. Curve assumptions
  • Only this native meter varies; all other source usage and translation assumptions retain the displayed defaults. Other native meters and workload assumptions retain their explicitly displayed default quantities. Workload translation and capacity assumptions are not benchmark measurements.
  • Native monthly usage priced at the cited provider list prices; listed target allowances apply where present, excluding invoice credits, taxes and negotiated discounts. Rates as of 2026-10-22: us-east-1 → us-ashburn-1, USD/month.
  • Source prices are reference charges, not an invoice. Target lines cover selected service usage/configuration only; adapter hosting and Tensor9 fees are excluded.
  • Samples of explicit prices are not performance measurements or capacity qualification. No interpolation or break-even guarantee is implied.
  • Variant assumptions show the first axis sample; any axis-dependent configuration is described by this curve’s workload note.
  • Rates are cited provider list prices, editable for discounts, commitments or another region. Workload translation and capacity coefficients remain editable planning assumptions, not benchmark measurements or a commercial quote.
  • Default-zero rates are explicit assumptions, not evidence that the deployed service or resource is free.
  • Provisioned-unit minimums use an editable approximate allocation floor. Modeled target service cost is max(usage/allocation, minimum), with billable network, durable staging and dependent sinks added separately; actual RU/TU sizing, scaling increments and throughput remain unqualified.
  • Durable staging is priced once: provisioned targets include adapter state in their selected allocation; native targets add a separate staging allocation when required. Adapter hosting is a separate allocation and must exclude resources already priced as staging, workers or target capacity.
  • A declared adapter mapping and cost model do not establish implementation availability or service equivalence.
  • This is a declared directed mapping; a planning estimate does not establish deployment or request-serving support.
  • Origin unit prices are cited provider list prices; capacity coefficients and translation assumptions are editable authored planning guesses, not measured capacity or a provider quote.
  • Management requests do not reveal resource allocation or workload traffic. Provisioned resources and traffic are independent inputs.
  • This compares authoritative zones and query meters; resolver forwarding has a different allocation and price.
  • A cost scenario does not establish live-qualified runtime DNS propagation or public authority.
  • OCI DNS bills authoritative queries only; the price list has no per-zone charge. Traffic management queries cost more.
  • AWS Price List API, AmazonRoute53 offer: https://pricing.us-east-1.amazonaws.com/offers/v1.0/aws/AmazonRoute53/current/aws-other/index.json
  • Amazon Route 53 pricing: https://aws.amazon.com/route53/pricing/
  • OCI price list API: https://apexapps.oracle.com/pls/apex/cetools/api/v1/products/?currencyCode=USD
Cost scope: Modeled target native service and explicitly modeled state allocation; hosting and Tensor9 fees only when supplied. Excluded costs and workload features:
  • Health checks, DNSSEC premiums, resolver endpoints, query logs, domain registration and routing-policy premiums.
  • Taxes, discounts, credits and free-tier allowances not explicitly listed by this model.
  • Unmodeled dependent services, task execution and operations outside the selected workload family.
List prices read: 2026-10-22. Model: plan-ee40e35d319a19f9bbdbba556f2be4d11b13bd9e / 2026-10-22.planning.2. Curve: workload-1. Sources: AWS Price List API, AmazonRoute53 offer, Amazon Route 53 pricing, OCI price list API. Authoritative DNS zones and queries (Route 53) → OCI DNS: Authored native-usage planning example. Native monthly usage priced at the cited provider list prices; listed target allowances apply where present, excluding invoice credits, taxes and negotiated discounts. Scenario source region: us-east-1. Scenario target region: us-ashburn-1. Currency: USD. Unestimated components: Adapter hosting, Tensor9 fees. A modeled adapted total and savings require these costs. Cost scope: Modeled target native service and explicitly modeled state allocation; hosting and Tensor9 fees only when supplied. Excluded costs and workload features:
  • Health checks, DNSSEC premiums, resolver endpoints, query logs, domain registration and routing-policy premiums.
  • Taxes, discounts, credits and free-tier allowances not explicitly listed by this model.
  • Unmodeled dependent services, task execution and operations outside the selected workload family.
Scenario assumptions
  • Translated reads: 100,000 operations.
  • Translated writes: 0 operations.
  • Translated resident physical data: 0 GiB-month.
  • Native provider operations: 100,000,000 operations.
  • Published payload: 0 GiB.
  • Delivered payload: 0 GiB.
  • Allocated execution CPU: 0 vCPU-hour.
  • Allocated execution RAM: 0 GiB-hour.
  • Independent resource allocation: 0 resource-hour.
  • Independent inventory: 1 resource-month.
  • Input tokens: 0 tokens.
  • Output tokens: 0 tokens.
  • Billable network: 0 GiB.
  • Dependent object sink retained data: 0 GiB-month.
  • Dependent object sink writes: 0 writes.
  • Rates are cited provider list prices, editable for discounts, commitments or another region. Workload translation and capacity coefficients remain editable planning assumptions, not benchmark measurements or a commercial quote.
  • Default-zero rates are explicit assumptions, not evidence that the deployed service or resource is free.
  • Provisioned-unit minimums use an editable approximate allocation floor. Modeled target service cost is max(usage/allocation, minimum), with billable network, durable staging and dependent sinks added separately; actual RU/TU sizing, scaling increments and throughput remain unqualified.
  • Durable staging is priced once: provisioned targets include adapter state in their selected allocation; native targets add a separate staging allocation when required. Adapter hosting is a separate allocation and must exclude resources already priced as staging, workers or target capacity.
  • A declared adapter mapping and cost model do not establish implementation availability or service equivalence.
  • This is a declared directed mapping; a planning estimate does not establish deployment or request-serving support.
  • Origin unit prices are cited provider list prices; capacity coefficients and translation assumptions are editable authored planning guesses, not measured capacity or a provider quote.
  • Management requests do not reveal resource allocation or workload traffic. Provisioned resources and traffic are independent inputs.
  • This compares authoritative zones and query meters; resolver forwarding has a different allocation and price.
  • A cost scenario does not establish live-qualified runtime DNS propagation or public authority.
  • OCI DNS bills authoritative queries only; the price list has no per-zone charge. Traffic management queries cost more.
List prices read: 2026-10-22. Model: plan-ee40e35d319a19f9bbdbba556f2be4d11b13bd9e / 2026-10-22.planning.2. Scenario: planning-example. Sources: AWS Price List API, AmazonRoute53 offer, Amazon Route 53 pricing, OCI price list API.

​
On Private Kubernetes

​
Via Route 53 (any cloud)

​
How it works

Your workload can run in the customer’s Kubernetes environment while its public DNS zone stays in Route 53. Tensor9 writes the records your stack declares through the Route 53 API, using an AWS credential supplied to the appliance. AWS keeps answering DNS queries for the zone, and the nameserver delegation can stay as it is.
Your application sends Route 53 record changes to the Tensor9 adapter, which applies them in Route 53 with the AWS credential it holds. Route 53 keeps answering DNS queries for the zone.Your application sends Route 53 record changes to the Tensor9 adapter, which applies them in Route 53 with the AWS credential it holds. Route 53 keeps answering DNS queries for the zone.

Record changes go through the adapter; DNS queries still go to Route 53.

​
Zones and records

The hosted zone must already exist. Tensor9 finds it by domain name: first an explicitly specified zone, then the zone reference, then the deployment’s default domain. It writes the declared records into that zone. It does not create the zone or copy the whole zone. Standard record types, including native SPF, are kept, with every value in an ordinary record set. A record with no TTL gets 300 seconds. An alias to an infrastructure resource points at that resource’s address in the target cloud, but target health is not evaluated.

​
Changes at runtime

Your application sends Route 53 API requests to the configured adapter endpoint. The adapter records each requested change and applies it with the AWS credential it holds. ChangeResourceRecordSets returns a change ID, and GetChange reports PENDING until the change has been applied in Route 53, then INSYNC. Here, INSYNC means the change was applied in Route 53. It does not guarantee that every authoritative server has observed the change, or that cached answers in resolvers have expired. Keep polling for completion, and allow for DNS caching during cutover.

​
Limitations

Where this mapping differs from Route 53
  • Routing policies are not supported. Only ordinary records are applied. Weighted, latency, failover and health-checked routing policies are left out with a warning, and several address values in one record do not reproduce them.
  • Health checks, delegation sets and Resolver resources are not supported. A stack that declares any of them stops the build with an error.
  • Private hosted zones are not supported. A zone is found by domain name only, which cannot reliably tell a public zone from a private zone with the same name.
  • These limits behave differently from Route 53 itself. They are limits of this mapping, not of Route 53. Keeping Route 53 as the DNS provider does not mean every Route 53 configuration feature is supported.

​
Other considerations

Credentials. Scope the appliance’s AWS credential to the intended zone and protect the process that renews it. Your application calls the adapter endpoint and does not need that credential. Before cutover. Check the records against the new workload addresses. If the appliance is unavailable, Route 53 keeps answering for records already applied, but further changes need the appliance and a working credential. Other tools that manage records. Keep external DNS controllers and certificate-validation records only where they fit with which records this mapping manages.

​
Example monthly charges

This Tensor9 BYOC scenario estimates service charges for the named origin and target services. Adapter hosting and commercial Tensor9 fees need separate allocations. How Tensor9 estimates costs explains the method and what the estimates include.
Authoritative DNS zones and queries (Route 53) · Authoritative DNS queries per second
Feature: Authoritative DNS zones and queries (Route 53). Estimated monthly service charges by Authoritative DNS queries per second. Adapter hosting and Tensor9 fees are excluded. Source: us-east-1; target: us-east-1; currency: USD.
Authoritative DNS zones and queries (Route 53) · Authoritative DNS queries per second: monthly service charges by Authoritative DNS queries per second. Exact values are in the following table.Authoritative DNS zones and queries (Route 53) · Authoritative DNS queries per second: monthly service charges by Authoritative DNS queries per second. Exact values are in the following table.
Comparison pills describe all sampled scale points; amounts beside each service are for the named workload. Costs The Same means within 20% at every point. Costs Depend includes mixed results and unpriced samples. Sampled monthly charges in USD, rounded to cents. Difference means target minus origin; a positive difference means the target costs more. Curve assumptions
  • Only this native meter varies; all other source usage and translation assumptions retain the displayed defaults. Other native meters and workload assumptions retain their explicitly displayed default quantities. Workload translation and capacity assumptions are not benchmark measurements.
  • Native monthly usage priced at the cited provider list prices; listed target allowances apply where present, excluding invoice credits, taxes and negotiated discounts. Rates as of 2026-10-22: us-east-1 → us-east-1, USD/month.
  • Source prices are reference charges, not an invoice. Target lines cover selected service usage/configuration only; adapter hosting and Tensor9 fees are excluded.
  • Samples of explicit prices are not performance measurements or capacity qualification. No interpolation or break-even guarantee is implied.
  • Variant assumptions show the first axis sample; any axis-dependent configuration is described by this curve’s workload note.
  • Rates are cited provider list prices, editable for discounts, commitments or another region. Workload translation and capacity coefficients remain editable planning assumptions, not benchmark measurements or a commercial quote.
  • Default-zero rates are explicit assumptions, not evidence that the deployed service or resource is free.
  • Provisioned-unit minimums use an editable approximate allocation floor. Modeled target service cost is max(usage/allocation, minimum), with billable network, durable staging and dependent sinks added separately; actual RU/TU sizing, scaling increments and throughput remain unqualified.
  • Durable staging is priced once: provisioned targets include adapter state in their selected allocation; native targets add a separate staging allocation when required. Adapter hosting is a separate allocation and must exclude resources already priced as staging, workers or target capacity.
  • A declared adapter mapping and cost model do not establish implementation availability or service equivalence.
  • This is a declared directed mapping; a planning estimate does not establish deployment or request-serving support.
  • Origin unit prices are cited provider list prices; capacity coefficients and translation assumptions are editable authored planning guesses, not measured capacity or a provider quote.
  • Management requests do not reveal resource allocation or workload traffic. Provisioned resources and traffic are independent inputs.
  • This compares authoritative zones and query meters; resolver forwarding has a different allocation and price.
  • A cost scenario does not establish live-qualified runtime DNS propagation or public authority.
  • Zone-months and authoritative queries are billed independently; management calls are free. Route 53 public hosted zones and standard queries; zone and query prices step down after 25 zones and one billion queries. Alias queries to AWS resources are free, and latency, geo and weighted routing queries cost more.
  • AWS Price List API, AmazonRoute53 offer: https://pricing.us-east-1.amazonaws.com/offers/v1.0/aws/AmazonRoute53/current/aws-other/index.json
  • Amazon Route 53 pricing: https://aws.amazon.com/route53/pricing/
Cost scope: Modeled target native service and explicitly modeled state allocation; hosting and Tensor9 fees only when supplied. Excluded costs and workload features:
  • Health checks, DNSSEC premiums, resolver endpoints, query logs, domain registration and routing-policy premiums.
  • Taxes, discounts, credits and free-tier allowances not explicitly listed by this model.
  • Unmodeled dependent services, task execution and operations outside the selected workload family.
List prices read: 2026-10-22. Model: plan-e390fc07b2c09ccd76f15f73b45d266273dc1a87 / 2026-10-22.planning.2. Curve: workload-1. Sources: AWS Price List API, AmazonRoute53 offer, Amazon Route 53 pricing. Authoritative DNS zones and queries (Route 53) → Route 53 (any cloud): Authored native-usage planning example. Native monthly usage priced at the cited provider list prices; listed target allowances apply where present, excluding invoice credits, taxes and negotiated discounts. Scenario source region: us-east-1. Scenario target region: us-east-1. Currency: USD. Unestimated components: Adapter hosting, Tensor9 fees. A modeled adapted total and savings require these costs. Cost scope: Modeled target native service and explicitly modeled state allocation; hosting and Tensor9 fees only when supplied. Excluded costs and workload features:
  • Health checks, DNSSEC premiums, resolver endpoints, query logs, domain registration and routing-policy premiums.
  • Taxes, discounts, credits and free-tier allowances not explicitly listed by this model.
  • Unmodeled dependent services, task execution and operations outside the selected workload family.
Scenario assumptions
  • Translated reads: 100,000 operations.
  • Translated writes: 0 operations.
  • Translated resident physical data: 0 GiB-month.
  • Native provider operations: 100,000,000 operations.
  • Published payload: 0 GiB.
  • Delivered payload: 0 GiB.
  • Allocated execution CPU: 0 vCPU-hour.
  • Allocated execution RAM: 0 GiB-hour.
  • Independent resource allocation: 0 resource-hour.
  • Independent inventory: 1 resource-month.
  • Input tokens: 0 tokens.
  • Output tokens: 0 tokens.
  • Billable network: 0 GiB.
  • Dependent object sink retained data: 0 GiB-month.
  • Dependent object sink writes: 0 writes.
  • Rates are cited provider list prices, editable for discounts, commitments or another region. Workload translation and capacity coefficients remain editable planning assumptions, not benchmark measurements or a commercial quote.
  • Default-zero rates are explicit assumptions, not evidence that the deployed service or resource is free.
  • Provisioned-unit minimums use an editable approximate allocation floor. Modeled target service cost is max(usage/allocation, minimum), with billable network, durable staging and dependent sinks added separately; actual RU/TU sizing, scaling increments and throughput remain unqualified.
  • Durable staging is priced once: provisioned targets include adapter state in their selected allocation; native targets add a separate staging allocation when required. Adapter hosting is a separate allocation and must exclude resources already priced as staging, workers or target capacity.
  • A declared adapter mapping and cost model do not establish implementation availability or service equivalence.
  • This is a declared directed mapping; a planning estimate does not establish deployment or request-serving support.
  • Origin unit prices are cited provider list prices; capacity coefficients and translation assumptions are editable authored planning guesses, not measured capacity or a provider quote.
  • Management requests do not reveal resource allocation or workload traffic. Provisioned resources and traffic are independent inputs.
  • This compares authoritative zones and query meters; resolver forwarding has a different allocation and price.
  • A cost scenario does not establish live-qualified runtime DNS propagation or public authority.
  • Zone-months and authoritative queries are billed independently; management calls are free. Route 53 public hosted zones and standard queries; zone and query prices step down after 25 zones and one billion queries. Alias queries to AWS resources are free, and latency, geo and weighted routing queries cost more.
List prices read: 2026-10-22. Model: plan-e390fc07b2c09ccd76f15f73b45d266273dc1a87 / 2026-10-22.planning.2. Scenario: planning-example. Sources: AWS Price List API, AmazonRoute53 offer, Amazon Route 53 pricing.

​
Via Cloudflare DNS

​
How it works

Tensor9 applies the Route 53 records you declare to an existing Cloudflare zone. The appliance holds the Cloudflare credential and handles supported record-change requests from your application. Cloudflare’s authoritative DNS servers answer public queries.
Your application sends Route 53 record changes to the Tensor9 adapter, which applies them to Cloudflare DNS with the provider credential it holds. DNS queries go straight to Cloudflare DNS.Your application sends Route 53 record changes to the Tensor9 adapter, which applies them to Cloudflare DNS with the provider credential it holds. DNS queries go straight to Cloudflare DNS.

Record changes go through the adapter; DNS queries go straight to the provider.

​
Zones and records

Onboard the domain to Cloudflare and create the zone before deployment; the mapping looks it up by domain name. Standard record types and all values in an ordinary record set are kept, and an unset deployment TTL defaults to 300 seconds. Deprecated SPF declarations become TXT. An infrastructure alias resolves to the referenced resource’s address on the target cloud, and Cloudflare CNAME flattening answers for the zone apex.

​
DNS-only and proxied records

Records are DNS-only by default. A Cloudflare proxied record sends supported application traffic through Cloudflare’s edge, where the CDN, WAF and DDoS features you configure apply. Turning on that proxy and choosing its protections are separate Cloudflare settings; creating an ordinary DNS record does not turn them on.

​
Runtime changes

Your application sends Route 53 API requests to the Tensor9 adapter, which records each change and applies it with the provider credential it holds. ChangeResourceRecordSets returns a change receipt; GetChange reports PENDING until the provider has applied the change, then INSYNC. INSYNC means the provider has applied the change. It does not guarantee that every authoritative server has observed the change or that recursive caches have expired, so keep polling for completion and allow for DNS caching during cutover. A Cloudflare API write can complete without a separate change operation to wait for. That does not shorten DNS cache lifetimes or prove the change has propagated worldwide.

​
Limitations

Where Cloudflare DNS and Route 53 differ
  • Route 53 routing policies are not supported. They are left out and reported, while the record’s ordinary data is still applied. Cloudflare Load Balancing has its own traffic routing, which this mapping does not configure.
  • Alias target health is not supported. Route 53 alias target-health evaluation is dropped, and multiple values in an ordinary record do not give health-checked routing.
  • Health checks, delegation sets, private zones and Resolver resources are not supported. This mapping uses Cloudflare public authoritative zones; Cloudflare’s private-DNS products are not used. A subdomain zone has its own Cloudflare plan requirements, separate from private DNS.

​
Other considerations

  • Moving from AWS. Apply the records you need, check the authoritative answers, then update public nameserver delegation if the provider changes. Keep the previous zone available while cached records and delegation expire. Only declared records are applied; an existing zone and its query history are not copied.
  • When the appliance is down. Record changes need the appliance and its provider credentials. Records already applied keep answering from the provider.
  • Other DNS writers. Certificate-validation records are coordinated with certificate management. Review external DNS controllers and any credentials they used before.

​
Example monthly charges

This Tensor9 BYOC scenario estimates service charges for the named origin and target services. Adapter hosting and commercial Tensor9 fees need separate allocations. How Tensor9 estimates costs explains the method and what the estimates include.
Authoritative DNS zones and queries (Route 53) · Authoritative DNS queries per second
Feature: Authoritative DNS zones and queries (Route 53). Estimated monthly service charges by Authoritative DNS queries per second. Adapter hosting and Tensor9 fees are excluded. Source: us-east-1; target: global; currency: USD.
Authoritative DNS zones and queries (Route 53) · Authoritative DNS queries per second: monthly service charges by Authoritative DNS queries per second. Exact values are in the following table.Authoritative DNS zones and queries (Route 53) · Authoritative DNS queries per second: monthly service charges by Authoritative DNS queries per second. Exact values are in the following table.
Comparison pills describe all sampled scale points; amounts beside each service are for the named workload. Costs The Same means within 20% at every point. Costs Depend includes mixed results and unpriced samples. Sampled monthly charges in USD, rounded to cents. Difference means target minus origin; a positive difference means the target costs more. Curve assumptions
  • Only this native meter varies; all other source usage and translation assumptions retain the displayed defaults. Other native meters and workload assumptions retain their explicitly displayed default quantities. Workload translation and capacity assumptions are not benchmark measurements.
  • Native monthly usage priced at the cited provider list prices; listed target allowances apply where present, excluding invoice credits, taxes and negotiated discounts. Rates as of 2026-10-22: us-east-1 → global, USD/month.
  • Source prices are reference charges, not an invoice. Target lines cover selected service usage/configuration only; adapter hosting and Tensor9 fees are excluded.
  • Samples of explicit prices are not performance measurements or capacity qualification. No interpolation or break-even guarantee is implied.
  • Variant assumptions show the first axis sample; any axis-dependent configuration is described by this curve’s workload note.
  • Rates are cited provider list prices, editable for discounts, commitments or another region. Workload translation and capacity coefficients remain editable planning assumptions, not benchmark measurements or a commercial quote.
  • Default-zero rates are explicit assumptions, not evidence that the deployed service or resource is free.
  • Provisioned-unit minimums use an editable approximate allocation floor. Modeled target service cost is max(usage/allocation, minimum), with billable network, durable staging and dependent sinks added separately; actual RU/TU sizing, scaling increments and throughput remain unqualified.
  • Durable staging is priced once: provisioned targets include adapter state in their selected allocation; native targets add a separate staging allocation when required. Adapter hosting is a separate allocation and must exclude resources already priced as staging, workers or target capacity.
  • A declared adapter mapping and cost model do not establish implementation availability or service equivalence.
  • This is a declared directed mapping; a planning estimate does not establish deployment or request-serving support.
  • Origin unit prices are cited provider list prices; capacity coefficients and translation assumptions are editable authored planning guesses, not measured capacity or a provider quote.
  • Management requests do not reveal resource allocation or workload traffic. Provisioned resources and traffic are independent inputs.
  • This compares authoritative zones and query meters; resolver forwarding has a different allocation and price.
  • A cost scenario does not establish live-qualified runtime DNS propagation or public authority.
  • Cloudflare authoritative DNS is free on the Free, Pro and Business plans: no zone fee and no query charge. Enterprise prices DNS by quote from query volume, which this model does not select.
  • AWS Price List API, AmazonRoute53 offer: https://pricing.us-east-1.amazonaws.com/offers/v1.0/aws/AmazonRoute53/current/aws-other/index.json
  • Amazon Route 53 pricing: https://aws.amazon.com/route53/pricing/
  • Cloudflare DNS FAQ: https://developers.cloudflare.com/dns/faq/
Cost scope: Modeled target native service and explicitly modeled state allocation; hosting and Tensor9 fees only when supplied. Excluded costs and workload features:
  • Health checks, DNSSEC premiums, resolver endpoints, query logs, domain registration and routing-policy premiums.
  • Taxes, discounts, credits and free-tier allowances not explicitly listed by this model.
  • Unmodeled dependent services, task execution and operations outside the selected workload family.
List prices read: 2026-10-22. Model: plan-a2b15e7e8b9d97cacc6d80c0dd48118358a26fab / 2026-10-22.planning.2. Curve: workload-1. Sources: AWS Price List API, AmazonRoute53 offer, Amazon Route 53 pricing, Cloudflare DNS FAQ. Authoritative DNS zones and queries (Route 53) → Cloudflare DNS: Authored native-usage planning example. Native monthly usage priced at the cited provider list prices; listed target allowances apply where present, excluding invoice credits, taxes and negotiated discounts. Scenario source region: us-east-1. Scenario target region: global. Currency: USD. Unestimated components: Adapter hosting, Tensor9 fees. A modeled adapted total and savings require these costs. Cost scope: Modeled target native service and explicitly modeled state allocation; hosting and Tensor9 fees only when supplied. Excluded costs and workload features:
  • Health checks, DNSSEC premiums, resolver endpoints, query logs, domain registration and routing-policy premiums.
  • Taxes, discounts, credits and free-tier allowances not explicitly listed by this model.
  • Unmodeled dependent services, task execution and operations outside the selected workload family.
Scenario assumptions
  • Translated reads: 100,000 operations.
  • Translated writes: 0 operations.
  • Translated resident physical data: 0 GiB-month.
  • Native provider operations: 100,000,000 operations.
  • Published payload: 0 GiB.
  • Delivered payload: 0 GiB.
  • Allocated execution CPU: 0 vCPU-hour.
  • Allocated execution RAM: 0 GiB-hour.
  • Independent resource allocation: 0 resource-hour.
  • Independent inventory: 1 resource-month.
  • Input tokens: 0 tokens.
  • Output tokens: 0 tokens.
  • Billable network: 0 GiB.
  • Dependent object sink retained data: 0 GiB-month.
  • Dependent object sink writes: 0 writes.
  • Rates are cited provider list prices, editable for discounts, commitments or another region. Workload translation and capacity coefficients remain editable planning assumptions, not benchmark measurements or a commercial quote.
  • Default-zero rates are explicit assumptions, not evidence that the deployed service or resource is free.
  • Provisioned-unit minimums use an editable approximate allocation floor. Modeled target service cost is max(usage/allocation, minimum), with billable network, durable staging and dependent sinks added separately; actual RU/TU sizing, scaling increments and throughput remain unqualified.
  • Durable staging is priced once: provisioned targets include adapter state in their selected allocation; native targets add a separate staging allocation when required. Adapter hosting is a separate allocation and must exclude resources already priced as staging, workers or target capacity.
  • A declared adapter mapping and cost model do not establish implementation availability or service equivalence.
  • This is a declared directed mapping; a planning estimate does not establish deployment or request-serving support.
  • Origin unit prices are cited provider list prices; capacity coefficients and translation assumptions are editable authored planning guesses, not measured capacity or a provider quote.
  • Management requests do not reveal resource allocation or workload traffic. Provisioned resources and traffic are independent inputs.
  • This compares authoritative zones and query meters; resolver forwarding has a different allocation and price.
  • A cost scenario does not establish live-qualified runtime DNS propagation or public authority.
  • Cloudflare authoritative DNS is free on the Free, Pro and Business plans: no zone fee and no query charge. Enterprise prices DNS by quote from query volume, which this model does not select.
List prices read: 2026-10-22. Model: plan-a2b15e7e8b9d97cacc6d80c0dd48118358a26fab / 2026-10-22.planning.2. Scenario: planning-example. Sources: AWS Price List API, AmazonRoute53 offer, Amazon Route 53 pricing, Cloudflare DNS FAQ.

​
Costs

Estimated monthly service charges for each backend with a published cost model, at one sampled workload from that model’s cost curve. Adapter hosting and Tensor9 fees are excluded. How Tensor9 estimates costs explains the method, what the estimates include and how to read their qualifications. Difference means backend minus origin; a positive difference means the backend costs more. Workloads and target configurations differ by model, so compare each row’s difference at its stated workload rather than charges across rows. Cost curves across workload sizes, with every assumption and exclusion: Route53 costs.

​
Service level agreements

These tables show Tensor9’s standard service levels and adapters whose standard terms are still being defined. Your signed agreement determines the SLAs, covered adapters and operations, limits, remedies and support terms that apply to your deployment.
Listed terms cover requests sent through this service adapter. They do not cover direct connections to the target service or replace the cloud provider’s own SLA. Each origin-to-target pair has its own terms or an explicit pending status. See the SLA tables, measurement rules, and scaling conditions.

​
Route53 to Route 53 (any cloud)

Adapter-added latency. A + prefix marks time added by the adapter, not the total time your application waits. Total request time includes adapter processing, backend service time and network time. The backend provider’s SLA applies independently. Only separately measured target-service wait may be subtracted, and only when your agreement permits it; internal metadata, coordination and retry processing still count. For one request, 12 ms of adapter processing plus 90 ms waiting for the backend means at least 102 ms total. This example does not add monthly p99 values. What Tensor9 covers. These service levels cover the adapter between the origin API and target API. They do not replace the target provider’s SLA. How latency is counted. Adapter work, including metadata and coordination, counts. Only separately measured permitted target waits are excluded. Which terms apply. Your signed agreement names the covered operations, workload limits, remedies, and final service levels for your deployment.

​
What this adapter does

The adapter validates Route 53-shaped zone, record, health-check and resolver-management calls, records the requested revision and translates it to aws::1.0.0::route53. Authoritative or recursive DNS query processing occurs in the selected DNS service and is deliberately outside these management-operation targets; no DNS query latency is claimed.

​
How the latency targets were chosen

DNS management reads: +8 ms monthly p99 (adapter-added). GetChange, GetHostedZone, ListHostedZones, ListResourceRecordSets. Bounded desired and observed management-state lookup; no DNS query execution. Bounded zone and record mutation: +20 ms monthly p99 (adapter-added). ChangeResourceRecordSets, CreateHostedZone, DeleteHostedZone. Whole-batch validation, atomic durable admission and reconciliation scheduling. Your signed agreement sets the terms for your deployment. A target does not add an operation or option that the compatibility tables mark unavailable.

​
What counts toward latency

For a request-response row, measure from the agreed ingress boundary to dispatch of the complete response. A row that explicitly names a first response chunk ends at that chunk; its number does not cover the rest of the stream. A long-poll row names the intentional wait and when adapter delay starts. Include parsing, authorization, admission, translation, serialization, adapter-owned storage and coordination, retries and response handling. Subtract only separately measured target-workload waits and external network segments allowed by the measurement rules. The adapter’s own response handling and dispatch remain covered. A database used for adapter metadata is still adapter work, even if a cloud provider hosts it. For concurrent calls, exclude the union of permitted wait intervals, not the sum of overlapping spans. Calculate each request’s adapter duration first, then the monthly p99. Do not subtract one service’s p99 from another’s. Known adapter timeouts are over-budget samples; failed or incomplete requests cannot disappear to improve the percentile. Missing measurements do not become zero latency. An SDK call span alone does not prove how much of its duration can be excluded.

​
Endpoint reachability and request failures

The endpoint-reachability target measures adapter health checks. Correctly forwarding a target quota or permission error is different from producing that error because the adapter sent the wrong request. Adapter-caused failures remain Tensor9’s responsibility even when the target is healthy. Correctness and data-integrity requirements apply to every supported request. Endpoint reachability does not measure request correctness or grant an allowance for incorrect results.

​
Scaling and target-service capacity

Independent zones, resolver endpoints and rules reconcile concurrently while changes to one zone or object remain generation ordered. Qualification fixes record count, change-batch bytes, routing-policy branches, endpoint addresses and returned page size; provider propagation and cache convergence are separate readiness measures. Tell Tensor9 the expected steady rate, bursts, concurrency, payload sizes and operation mix. Tensor9 sizes and scales the adapter for the agreed load; you choose and monitor the target service’s capacity with Tensor9’s help. A latency budget is not a requests-per-second rating. Larger requests and higher rates need explicit terms, not silent inheritance of a small-request SLA.

​
Data and behavior guarantees

A successful management response preserves owner name, type, TTL, values, routing-policy identity and private-zone association without broadening visibility. Change status cannot report INSYNC until target observation supports it, and unsupported alias, DNSSEC, health-check or resolver semantics fail explicitly rather than degrading DNS behavior.

​
Example and diagnosis

ChangeResourceRecordSets submits a bounded batch of 100 records. The 20 ms target covers validation, atomic durable admission and target-plan construction. Target publication, nameserver delegation, recursive caches and client query time remain separately observed; GetChange reports the durable revision and its observed propagation state. Use tensor9 explain and the documented explain headers to understand the selected adapter and its behavior. Correlate available request diagnostics with the target provider’s latency, throttling and capacity metrics. An explain report helps diagnose a request; it is not by itself a qualified SLA timing measurement. Share the operation, request shape, timestamps and request identifiers with support, with credentials and customer payloads removed.

​
Route53 to Azure DNS

Adapter-added latency. A + prefix marks time added by the adapter, not the total time your application waits. Total request time includes adapter processing, backend service time and network time. The backend provider’s SLA applies independently. Only separately measured target-service wait may be subtracted, and only when your agreement permits it; internal metadata, coordination and retry processing still count. For one request, 12 ms of adapter processing plus 90 ms waiting for the backend means at least 102 ms total. This example does not add monthly p99 values. What Tensor9 covers. These service levels cover the adapter between the origin API and target API. They do not replace the target provider’s SLA. How latency is counted. Adapter work, including metadata and coordination, counts. Only separately measured permitted target waits are excluded. Which terms apply. Your signed agreement names the covered operations, workload limits, remedies, and final service levels for your deployment.

​
What this adapter does

The adapter validates Route 53-shaped zone, record, health-check and resolver-management calls, records the requested revision and translates it to azure::1.0.0::dns. Authoritative or recursive DNS query processing occurs in the selected DNS service and is deliberately outside these management-operation targets; no DNS query latency is claimed.

​
How the latency targets were chosen

DNS management reads: +8 ms monthly p99 (adapter-added). GetChange, GetHostedZone, ListHostedZones, ListResourceRecordSets. Bounded desired and observed management-state lookup; no DNS query execution. Bounded zone and record mutation: +20 ms monthly p99 (adapter-added). ChangeResourceRecordSets, CreateHostedZone, DeleteHostedZone. Whole-batch validation, atomic durable admission and reconciliation scheduling. Your signed agreement sets the terms for your deployment. A target does not add an operation or option that the compatibility tables mark unavailable.

​
What counts toward latency

For a request-response row, measure from the agreed ingress boundary to dispatch of the complete response. A row that explicitly names a first response chunk ends at that chunk; its number does not cover the rest of the stream. A long-poll row names the intentional wait and when adapter delay starts. Include parsing, authorization, admission, translation, serialization, adapter-owned storage and coordination, retries and response handling. Subtract only separately measured target-workload waits and external network segments allowed by the measurement rules. The adapter’s own response handling and dispatch remain covered. A database used for adapter metadata is still adapter work, even if a cloud provider hosts it. For concurrent calls, exclude the union of permitted wait intervals, not the sum of overlapping spans. Calculate each request’s adapter duration first, then the monthly p99. Do not subtract one service’s p99 from another’s. Known adapter timeouts are over-budget samples; failed or incomplete requests cannot disappear to improve the percentile. Missing measurements do not become zero latency. An SDK call span alone does not prove how much of its duration can be excluded.

​
Endpoint reachability and request failures

The endpoint-reachability target measures adapter health checks. Correctly forwarding a target quota or permission error is different from producing that error because the adapter sent the wrong request. Adapter-caused failures remain Tensor9’s responsibility even when the target is healthy. Correctness and data-integrity requirements apply to every supported request. Endpoint reachability does not measure request correctness or grant an allowance for incorrect results.

​
Scaling and target-service capacity

Independent zones, resolver endpoints and rules reconcile concurrently while changes to one zone or object remain generation ordered. Qualification fixes record count, change-batch bytes, routing-policy branches, endpoint addresses and returned page size; provider propagation and cache convergence are separate readiness measures. Tell Tensor9 the expected steady rate, bursts, concurrency, payload sizes and operation mix. Tensor9 sizes and scales the adapter for the agreed load; you choose and monitor the target service’s capacity with Tensor9’s help. A latency budget is not a requests-per-second rating. Larger requests and higher rates need explicit terms, not silent inheritance of a small-request SLA.

​
Data and behavior guarantees

A successful management response preserves owner name, type, TTL, values, routing-policy identity and private-zone association without broadening visibility. Change status cannot report INSYNC until target observation supports it, and unsupported alias, DNSSEC, health-check or resolver semantics fail explicitly rather than degrading DNS behavior.

​
Example and diagnosis

ChangeResourceRecordSets submits a bounded batch of 100 records. The 20 ms target covers validation, atomic durable admission and target-plan construction. Target publication, nameserver delegation, recursive caches and client query time remain separately observed; GetChange reports the durable revision and its observed propagation state. Use tensor9 explain and the documented explain headers to understand the selected adapter and its behavior. Correlate available request diagnostics with the target provider’s latency, throttling and capacity metrics. An explain report helps diagnose a request; it is not by itself a qualified SLA timing measurement. Share the operation, request shape, timestamps and request identifiers with support, with credentials and customer payloads removed.

​
Route53 to Cloudflare DNS

Adapter-added latency. A + prefix marks time added by the adapter, not the total time your application waits. Total request time includes adapter processing, backend service time and network time. The backend provider’s SLA applies independently. Only separately measured target-service wait may be subtracted, and only when your agreement permits it; internal metadata, coordination and retry processing still count. For one request, 12 ms of adapter processing plus 90 ms waiting for the backend means at least 102 ms total. This example does not add monthly p99 values. What Tensor9 covers. These service levels cover the adapter between the origin API and target API. They do not replace the target provider’s SLA. How latency is counted. Adapter work, including metadata and coordination, counts. Only separately measured permitted target waits are excluded. Which terms apply. Your signed agreement names the covered operations, workload limits, remedies, and final service levels for your deployment.

​
What this adapter does

The adapter validates Route 53-shaped zone, record, health-check and resolver-management calls, records the requested revision and translates it to cloudflare::1.0.0::dns. Authoritative or recursive DNS query processing occurs in the selected DNS service and is deliberately outside these management-operation targets; no DNS query latency is claimed.

​
How the latency targets were chosen

DNS management reads: +8 ms monthly p99 (adapter-added). GetChange, GetHostedZone, ListHostedZones, ListResourceRecordSets. Bounded desired and observed management-state lookup; no DNS query execution. Bounded zone and record mutation: +20 ms monthly p99 (adapter-added). ChangeResourceRecordSets, CreateHostedZone, DeleteHostedZone. Whole-batch validation, atomic durable admission and reconciliation scheduling. Your signed agreement sets the terms for your deployment. A target does not add an operation or option that the compatibility tables mark unavailable.

​
What counts toward latency

For a request-response row, measure from the agreed ingress boundary to dispatch of the complete response. A row that explicitly names a first response chunk ends at that chunk; its number does not cover the rest of the stream. A long-poll row names the intentional wait and when adapter delay starts. Include parsing, authorization, admission, translation, serialization, adapter-owned storage and coordination, retries and response handling. Subtract only separately measured target-workload waits and external network segments allowed by the measurement rules. The adapter’s own response handling and dispatch remain covered. A database used for adapter metadata is still adapter work, even if a cloud provider hosts it. For concurrent calls, exclude the union of permitted wait intervals, not the sum of overlapping spans. Calculate each request’s adapter duration first, then the monthly p99. Do not subtract one service’s p99 from another’s. Known adapter timeouts are over-budget samples; failed or incomplete requests cannot disappear to improve the percentile. Missing measurements do not become zero latency. An SDK call span alone does not prove how much of its duration can be excluded.

​
Endpoint reachability and request failures

The endpoint-reachability target measures adapter health checks. Correctly forwarding a target quota or permission error is different from producing that error because the adapter sent the wrong request. Adapter-caused failures remain Tensor9’s responsibility even when the target is healthy. Correctness and data-integrity requirements apply to every supported request. Endpoint reachability does not measure request correctness or grant an allowance for incorrect results.

​
Scaling and target-service capacity

Independent zones, resolver endpoints and rules reconcile concurrently while changes to one zone or object remain generation ordered. Qualification fixes record count, change-batch bytes, routing-policy branches, endpoint addresses and returned page size; provider propagation and cache convergence are separate readiness measures. Tell Tensor9 the expected steady rate, bursts, concurrency, payload sizes and operation mix. Tensor9 sizes and scales the adapter for the agreed load; you choose and monitor the target service’s capacity with Tensor9’s help. A latency budget is not a requests-per-second rating. Larger requests and higher rates need explicit terms, not silent inheritance of a small-request SLA.

​
Data and behavior guarantees

A successful management response preserves owner name, type, TTL, values, routing-policy identity and private-zone association without broadening visibility. Change status cannot report INSYNC until target observation supports it, and unsupported alias, DNSSEC, health-check or resolver semantics fail explicitly rather than degrading DNS behavior.

​
Example and diagnosis

ChangeResourceRecordSets submits a bounded batch of 100 records. The 20 ms target covers validation, atomic durable admission and target-plan construction. Target publication, nameserver delegation, recursive caches and client query time remain separately observed; GetChange reports the durable revision and its observed propagation state. Use tensor9 explain and the documented explain headers to understand the selected adapter and its behavior. Correlate available request diagnostics with the target provider’s latency, throttling and capacity metrics. An explain report helps diagnose a request; it is not by itself a qualified SLA timing measurement. Share the operation, request shape, timestamps and request identifiers with support, with credentials and customer payloads removed.

​
Route53 to Cloud DNS

Adapter-added latency. A + prefix marks time added by the adapter, not the total time your application waits. Total request time includes adapter processing, backend service time and network time. The backend provider’s SLA applies independently. Only separately measured target-service wait may be subtracted, and only when your agreement permits it; internal metadata, coordination and retry processing still count. For one request, 12 ms of adapter processing plus 90 ms waiting for the backend means at least 102 ms total. This example does not add monthly p99 values. What Tensor9 covers. These service levels cover the adapter between the origin API and target API. They do not replace the target provider’s SLA. How latency is counted. Adapter work, including metadata and coordination, counts. Only separately measured permitted target waits are excluded. Which terms apply. Your signed agreement names the covered operations, workload limits, remedies, and final service levels for your deployment.

​
What this adapter does

The adapter validates Route 53-shaped zone, record, health-check and resolver-management calls, records the requested revision and translates it to google::1.0.0::dns. Authoritative or recursive DNS query processing occurs in the selected DNS service and is deliberately outside these management-operation targets; no DNS query latency is claimed.

​
How the latency targets were chosen

DNS management reads: +8 ms monthly p99 (adapter-added). GetChange, GetHostedZone, ListHostedZones, ListResourceRecordSets. Bounded desired and observed management-state lookup; no DNS query execution. Bounded zone and record mutation: +20 ms monthly p99 (adapter-added). ChangeResourceRecordSets, CreateHostedZone, DeleteHostedZone. Whole-batch validation, atomic durable admission and reconciliation scheduling. Your signed agreement sets the terms for your deployment. A target does not add an operation or option that the compatibility tables mark unavailable.

​
What counts toward latency

For a request-response row, measure from the agreed ingress boundary to dispatch of the complete response. A row that explicitly names a first response chunk ends at that chunk; its number does not cover the rest of the stream. A long-poll row names the intentional wait and when adapter delay starts. Include parsing, authorization, admission, translation, serialization, adapter-owned storage and coordination, retries and response handling. Subtract only separately measured target-workload waits and external network segments allowed by the measurement rules. The adapter’s own response handling and dispatch remain covered. A database used for adapter metadata is still adapter work, even if a cloud provider hosts it. For concurrent calls, exclude the union of permitted wait intervals, not the sum of overlapping spans. Calculate each request’s adapter duration first, then the monthly p99. Do not subtract one service’s p99 from another’s. Known adapter timeouts are over-budget samples; failed or incomplete requests cannot disappear to improve the percentile. Missing measurements do not become zero latency. An SDK call span alone does not prove how much of its duration can be excluded.

​
Endpoint reachability and request failures

The endpoint-reachability target measures adapter health checks. Correctly forwarding a target quota or permission error is different from producing that error because the adapter sent the wrong request. Adapter-caused failures remain Tensor9’s responsibility even when the target is healthy. Correctness and data-integrity requirements apply to every supported request. Endpoint reachability does not measure request correctness or grant an allowance for incorrect results.

​
Scaling and target-service capacity

Independent zones, resolver endpoints and rules reconcile concurrently while changes to one zone or object remain generation ordered. Qualification fixes record count, change-batch bytes, routing-policy branches, endpoint addresses and returned page size; provider propagation and cache convergence are separate readiness measures. Tell Tensor9 the expected steady rate, bursts, concurrency, payload sizes and operation mix. Tensor9 sizes and scales the adapter for the agreed load; you choose and monitor the target service’s capacity with Tensor9’s help. A latency budget is not a requests-per-second rating. Larger requests and higher rates need explicit terms, not silent inheritance of a small-request SLA.

​
Data and behavior guarantees

A successful management response preserves owner name, type, TTL, values, routing-policy identity and private-zone association without broadening visibility. Change status cannot report INSYNC until target observation supports it, and unsupported alias, DNSSEC, health-check or resolver semantics fail explicitly rather than degrading DNS behavior.

​
Example and diagnosis

ChangeResourceRecordSets submits a bounded batch of 100 records. The 20 ms target covers validation, atomic durable admission and target-plan construction. Target publication, nameserver delegation, recursive caches and client query time remain separately observed; GetChange reports the durable revision and its observed propagation state. Use tensor9 explain and the documented explain headers to understand the selected adapter and its behavior. Correlate available request diagnostics with the target provider’s latency, throttling and capacity metrics. An explain report helps diagnose a request; it is not by itself a qualified SLA timing measurement. Share the operation, request shape, timestamps and request identifiers with support, with credentials and customer payloads removed.

​
Route53 to OCI DNS

Adapter-added latency. A + prefix marks time added by the adapter, not the total time your application waits. Total request time includes adapter processing, backend service time and network time. The backend provider’s SLA applies independently. Only separately measured target-service wait may be subtracted, and only when your agreement permits it; internal metadata, coordination and retry processing still count. For one request, 12 ms of adapter processing plus 90 ms waiting for the backend means at least 102 ms total. This example does not add monthly p99 values. What Tensor9 covers. These service levels cover the adapter between the origin API and target API. They do not replace the target provider’s SLA. How latency is counted. Adapter work, including metadata and coordination, counts. Only separately measured permitted target waits are excluded. Which terms apply. Your signed agreement names the covered operations, workload limits, remedies, and final service levels for your deployment.

​
What this adapter does

The adapter validates Route 53-shaped zone, record, health-check and resolver-management calls, records the requested revision and translates it to oci::1.0.0::dns. Authoritative or recursive DNS query processing occurs in the selected DNS service and is deliberately outside these management-operation targets; no DNS query latency is claimed.

​
How the latency targets were chosen

DNS management reads: +8 ms monthly p99 (adapter-added). GetChange, GetHostedZone, ListHostedZones, ListResourceRecordSets. Bounded desired and observed management-state lookup; no DNS query execution. Bounded zone and record mutation: +20 ms monthly p99 (adapter-added). ChangeResourceRecordSets, CreateHostedZone, DeleteHostedZone. Whole-batch validation, atomic durable admission and reconciliation scheduling. Your signed agreement sets the terms for your deployment. A target does not add an operation or option that the compatibility tables mark unavailable.

​
What counts toward latency

For a request-response row, measure from the agreed ingress boundary to dispatch of the complete response. A row that explicitly names a first response chunk ends at that chunk; its number does not cover the rest of the stream. A long-poll row names the intentional wait and when adapter delay starts. Include parsing, authorization, admission, translation, serialization, adapter-owned storage and coordination, retries and response handling. Subtract only separately measured target-workload waits and external network segments allowed by the measurement rules. The adapter’s own response handling and dispatch remain covered. A database used for adapter metadata is still adapter work, even if a cloud provider hosts it. For concurrent calls, exclude the union of permitted wait intervals, not the sum of overlapping spans. Calculate each request’s adapter duration first, then the monthly p99. Do not subtract one service’s p99 from another’s. Known adapter timeouts are over-budget samples; failed or incomplete requests cannot disappear to improve the percentile. Missing measurements do not become zero latency. An SDK call span alone does not prove how much of its duration can be excluded.

​
Endpoint reachability and request failures

The endpoint-reachability target measures adapter health checks. Correctly forwarding a target quota or permission error is different from producing that error because the adapter sent the wrong request. Adapter-caused failures remain Tensor9’s responsibility even when the target is healthy. Correctness and data-integrity requirements apply to every supported request. Endpoint reachability does not measure request correctness or grant an allowance for incorrect results.

​
Scaling and target-service capacity

Independent zones, resolver endpoints and rules reconcile concurrently while changes to one zone or object remain generation ordered. Qualification fixes record count, change-batch bytes, routing-policy branches, endpoint addresses and returned page size; provider propagation and cache convergence are separate readiness measures. Tell Tensor9 the expected steady rate, bursts, concurrency, payload sizes and operation mix. Tensor9 sizes and scales the adapter for the agreed load; you choose and monitor the target service’s capacity with Tensor9’s help. A latency budget is not a requests-per-second rating. Larger requests and higher rates need explicit terms, not silent inheritance of a small-request SLA.

​
Data and behavior guarantees

A successful management response preserves owner name, type, TTL, values, routing-policy identity and private-zone association without broadening visibility. Change status cannot report INSYNC until target observation supports it, and unsupported alias, DNSSEC, health-check or resolver semantics fail explicitly rather than degrading DNS behavior.

​
Example and diagnosis

ChangeResourceRecordSets submits a bounded batch of 100 records. The 20 ms target covers validation, atomic durable admission and target-plan construction. Target publication, nameserver delegation, recursive caches and client query time remain separately observed; GetChange reports the durable revision and its observed propagation state. Use tensor9 explain and the documented explain headers to understand the selected adapter and its behavior. Correlate available request diagnostics with the target provider’s latency, throttling and capacity metrics. An explain report helps diagnose a request; it is not by itself a qualified SLA timing measurement. Share the operation, request shape, timestamps and request identifiers with support, with credentials and customer payloads removed.

​
Route53 to Scaleway Domains and DNS

SLA status: Not applicable DNS zones and records are provisioned through the target provider. This mapping has no Route 53 management adapter endpoint, and DNS lookups go directly to the provider’s name servers.

​
Debug this service

For requests through a service adapter, use Explain and request diagnostics to investigate the selected mapping. Follow the BYOC service-adapter debugging runbook to capture and interpret the diagnostic evidence. Service Catalog.