AWS Route 53 Pricing Guide: Hosted Zones, DNS Queries, Health Checks
Route 53-style costs are typically a combination of hosted zone fees plus DNS query charges and (optionally) health checks. The best cost model starts with measured query volume.
What to model (the 3 line items)
- Hosted zones: how many zones you maintain across environments/accounts
- Standard queries/month: your actual DNS query volume
- Health checks: if you use DNS-level health checks or endpoint monitoring
How to get the inputs (without guessing)
- Zones: list public and private zones separately. In multi-account setups, zones often get duplicated across environments.
- Queries: prefer a measured window from query logs. If you do not have logs, start from DNS QPS/RPS and convert to monthly.
- Health checks: count them, and confirm whether you have per-endpoint checks, multi-region checks, or checks per record.
A fast estimate (2 scenarios, not 1)
Use AWS Route 53 Cost Calculator for a simple zones + queries + health checks model. Then refine query volume using metrics/logs from a representative time window.
- Baseline scenario: a typical week (exclude outage windows and launch days).
- Peak scenario: incident retry storms, cache misses, or a short-lived traffic spike. This is what prevents a budget from failing in real life.
Query estimation methods
Method A: From query logs (best)
- Enable Route 53 query logging and sample at least 7 days.
- Compute: queries/day by hosted zone and top record names.
- Use the peak day as a sanity check for incident windows.
Fast DNS cost formula
- Total monthly Route 53 cost = hosted zone fees + DNS query charges + health checks.
- DNS query charges = queries/month x effective query unit rate.
- Peak protection: budget with both baseline and incident retry scenarios.
Method B: From request rate (good first pass)
- Convert RPS/QPS to monthly queries using RPS to monthly requests.
- Apply a multiplier for retries and cache misses (use a separate peak scenario rather than one inflated average).
What usually causes surprise bills (and how to prevent them)
- Very low TTLs: every resolver cache refresh becomes a paid query. Low TTLs have a purpose, but treat them as a cost decision.
- Service scale-out: more pods/instances often means more DNS lookups (especially with chatty clients or short DNS caches in runtimes).
- Retry storms: outages can multiply DNS queries as clients retry or fail over. Keep a peak scenario in your model.
- Health check sprawl: checks per endpoint and per environment add steady monthly cost and can be missed in budgets.
- CNAME chains: not always a cost problem, but they can increase lookup behavior and worsen incident sensitivity.
Worked estimate template (copy/paste)
- Hosted zones cost = public zones + private zones (as applicable)
- Query cost = standard queries/month (baseline) + standard queries/month (peak scenario)
- Health checks cost = health checks/month (baseline) + any extra checks used only for peak events
How to validate the estimate
- In Cost Explorer / CUR, confirm you see distinct line items for hosted zones, queries, and health checks.
- Compare baseline vs peak: if peak is not materially higher, you may be missing incident behavior in your model.
- Audit the top record names from query logs and look for noisy internal service discovery patterns.
TTL and query-volume decision guide
- Need fast failover: lower TTL only for critical records; keep default TTL higher elsewhere.
- Stable services: raise TTL to reduce resolver refresh frequency and query cost.
- Frequent deploys: use staged TTL changes during rollout windows, then restore normal values.
- Incident response: capture retry multipliers and include them in the peak scenario.
Failure patterns
- Applying one low TTL policy to every record type.
- Using traffic RPS as DNS query volume without resolver behavior checks.
- Ignoring health-check sprawl across environments.
- Estimating only baseline and skipping retry-storm budgets.
Related tools
Sources
Related guides
Estimate DNS queries per month (Route 53 query volume)
How to estimate DNS query volume for Route 53 cost models: from metrics and logs, and what drives query spikes (TTL, retries, resolver behavior).
AWS CloudTrail Pricing & Cost Guide
CloudTrail cost model for management vs data events, Lake vs S3 logs, and pricing drivers with estimation steps.
AWS CloudWatch Metrics Pricing & Cost Guide
CloudWatch metrics cost model: custom metrics, API requests, dashboards, and retention.
AWS ECS Pricing & Cost Guide (EC2 vs Fargate drivers)
ECS cost model for compute, storage, and networking. Compare EC2 vs Fargate and identify real cost drivers.
AWS network cost guide: NAT, VPC endpoints, PrivateLink, and data transfer (what to model)
A practical AWS network cost hub: how to model NAT Gateway, VPC endpoints/PrivateLink, and cross-AZ/cross-region data transfer. Includes formulas, break-even workflow, and a troubleshooting checklist.
CloudFront logs cost: estimate storage, retention, and queries
How to estimate CloudFront log costs: log volume (GB/day), retention (GB-month), and downstream query/scan costs (Athena/SIEM). Includes practical cost-control levers.
Related calculators
Data Egress Cost Calculator
Estimate monthly egress spend from GB transferred and $/GB pricing.
API Response Size Transfer Calculator
Estimate monthly transfer from request volume and average response size.
VPC Data Transfer Cost Calculator
Estimate data transfer spend from GB/month and $/GB assumptions.
Cross-region Transfer Cost Calculator
Estimate monthly cross-region transfer cost from GB transferred and $/GB pricing.
Log Cost Calculator
Estimate total log costs: ingestion, storage, and scan/search.
Log Ingestion Cost Calculator
Estimate monthly log ingestion cost from GB/day or from event rate and $/GB pricing.
FAQ
What usually drives Route 53 cost?
DNS query volume is the most common driver, followed by hosted zone count. Health checks can add a steady baseline if you use many of them.
Why do query charges grow over time?
Low TTLs, service growth (more pods/instances), and resolver behavior can increase query volume. Incident-driven retries can also create sudden spikes.
Should I estimate queries using RPS or from logs?
If you have query logs, use them. If not, RPS can be a good first pass. Convert RPS to monthly queries, then add a peak scenario for incidents and traffic spikes.
Do record types matter for pricing?
For first-pass budgets, query count is usually the key. But certain features (like health checks and advanced routing) can change the model, so treat them as separate line items.
Last updated: 2026-03-03