What Is Route 53?

Amazon Route 53 is a highly available and scalable Domain Name System (DNS) service from AWS. It translates domain names such as example.com into DNS answers that help clients locate websites, APIs, mail servers, and other network services. Route 53 also supports domain registration, traffic routing policies, health checks, and private DNS resolution within Amazon VPC networks.

Route 53 plays an important role in production system architecture because DNS is often the first step in connecting a user to an application. It can direct users to CloudFront distributions, Application Load Balancers, regional endpoints, and failover destinations. However, DNS is not a load balancer or an HTTP proxy. It returns DNS answers, while clients and intermediate resolvers determine how and when those answers are reused. Designing reliable DNS requires understanding hosted zones, records, TTLs, caching, routing policies, and the limitations of DNS-based failover.

Table of Contents

• What Amazon Route 53 Provides
  • How DNS Resolution Works
  • Route 53 vs. CloudFront and Load Balancers
• Hosted Zones and DNS Records
  • Public vs. Private Hosted Zones
  • A, AAAA, CNAME, MX, TXT, NS, and CAA Records
  • Route 53 Alias Records
• Traffic Routing and DNS Failover
  • Simple, Weighted, Latency, and Geographic Routing
  • Health Checks and Failover
  • TTL, Caching, and DNS Changes
• Private DNS, Resolver, and Security
  • Route 53 Resolver and Hybrid DNS
  • DNSSEC, IAM, and DNS Security
• Production Design Example: Global SaaS Application
  • Public Website, Regional API, and Private Services
  • Failure Scenario: Regional API Outage
• Ready-to-Use Example: Route 53 with Terraform and Python
  • 1. Project Requirements
  • 2. Create Public and Private DNS Records
  • 3. Audit DNS with Python
  • 4. Deploy, Verify, and Troubleshoot
• Cost, Common Mistakes, and Production Checklist
  • Route 53 Pricing and Monitoring
  • Common Route 53 Mistakes
  • Production Checklist
• Frequently Asked Questions
  • What Is Amazon Route 53 Used For?
  • Why Is It Called Route 53?
  • Do I Need to Register My Domain with Route 53?
  • What Is the Difference Between Alias and CNAME?
  • Does Route 53 Provide Instant Failover?
  • Can Route 53 Resolve Private IP Addresses?
  • Is Amazon Route 53 Free?
• Conclusion
  • More Articles to Read

What Amazon Route 53 Provides

Route 53 provides a managed authoritative DNS service that answers queries for domains and hosted zones configured to use it. Instead of operating DNS servers, managing replication, and distributing changes across name servers, engineers configure DNS records through AWS APIs, the console, or infrastructure-as-code tools.

The service has several related capabilities: registering supported domain names, hosting DNS zones, applying routing policies, monitoring endpoints, and integrating private DNS with AWS networks.

How DNS Resolution Works

When someone opens https://www.example.com, the browser normally needs to determine where that domain points before establishing an HTTPS connection.

The simplified resolution process is:

1. The browser or operating system checks whether it already has a usable DNS answer.
2. If not, it asks a recursive DNS resolver, commonly supplied by the network provider or a DNS service.
3. The resolver locates the authoritative name servers responsible for the domain when the answer is not already cached.
4. Route 53, when authoritative for the relevant hosted zone, returns the applicable DNS record answer.
5. The resolver may cache the answer according to DNS caching rules and the record's TTL.
6. The client uses the DNS answer to establish a connection to the destination.

Route 53 does not necessarily receive a query from every end user. Recursive resolvers cache answers and can serve repeated lookups without contacting authoritative name servers again.

For example, a browser looking up api.example.com might receive an A record containing an IPv4 address or an alias response that resolves to an AWS resource's address. DNS resolution itself does not establish that the API is healthy or that the client's HTTPS request will succeed.

Route 53 vs. CloudFront and Load Balancers

DNS routing, content delivery, and application load balancing are separate concerns. In AWS, these services often work together.

A common request path is: the browser resolves a domain through Route 53, connects to CloudFront, and CloudFront contacts an application origin when necessary. Alternatively, Route 53 can return addresses associated with a regional load balancer, which then distributes requests among application targets.

Unlike CloudFront, Route 53 does not cache and deliver your HTML or JavaScript to users. It provides DNS answers used to locate those services.

For global content delivery, see What Is a CDN?.

Hosted Zones and DNS Records

A hosted zone is a collection of DNS records managed together for a domain name or a portion of a DNS namespace. The hosted zone is where engineers define how names such as www.example.com, api.example.com, and mail.example.com should resolve.

Creating a hosted zone is not sufficient to make it authoritative for public internet queries. The appropriate name server delegation must also point to it.

Public vs. Private Hosted Zones

Route 53 supports public and private hosted zones.

• Public hosted zones: Provide DNS records intended to be resolved through the public DNS system after appropriate delegation.
• Private hosted zones: Provide DNS records resolved through Route 53 Resolver for associated VPCs and supported connected network configurations.

For example, a public hosted zone for example.com might contain an A alias record for www.example.com that points to CloudFront.

A private hosted zone for internal.example.com might contain an A record for database.internal.example.com that points to a private application endpoint.

Private hosted zones are not automatically reachable from every AWS account or VPC. They must be associated with the relevant VPCs, and DNS resolution needs appropriate networking and Resolver configuration.

For standard private hosted zone operation, the VPC should have both enableDnsSupport and enableDnsHostnames enabled.

Private DNS can also use split-view DNS, where a name or namespace has different answers inside a VPC than it does through public DNS. This is useful but requires care: private zone matching and negative answers can prevent the expected fallback to public DNS.

A, AAAA, CNAME, MX, TXT, NS, and CAA Records

DNS supports several record types, each with a different purpose. Route 53 provides these records through its hosted zone configuration.

DNS records are part of the application's infrastructure. Changing an MX record can break email delivery, while an incorrect TXT record can prevent domain verification or authentication policies from working.

A zone apex, such as example.com, cannot use a standard CNAME record because the apex must coexist with records such as SOA and NS. Route 53 alias records provide an AWS-specific way to support many apex routing requirements.

Route 53 Alias Records

A Route 53 alias record is an AWS extension to DNS that points to supported AWS resources or another record in the same hosted zone. It is commonly used with CloudFront, Elastic Load Balancing, API Gateway, and other compatible endpoints.

Unlike CNAME, an alias A or AAAA record can exist at the domain apex.

For example, example.com can have an A alias pointing to a CloudFront distribution. Route 53 returns appropriate address records to DNS clients rather than requiring a CNAME at the apex.

Important details include:

• Alias records are not a general substitute for CNAMEs pointing to arbitrary external services.
• Supported alias targets have their own target hosted zone identifiers.
• For CloudFront aliases, EvaluateTargetHealth must be false.
• CloudFront must also be configured to recognize the custom domain and provide appropriate HTTPS certificates.
• For supported AWS alias destinations, Route 53 does not charge the ordinary alias DNS queries described in its pricing documentation.

For web applications, Route 53 typically provides the DNS name, while CloudFront or an ALB performs the actual HTTP routing.

Traffic Routing and DNS Failover

Route 53 supports routing policies that affect which DNS answer is returned when multiple eligible endpoints exist. This is useful for regional applications, controlled traffic distribution, and recovery from infrastructure failures.

DNS routing should not be confused with request-by-request load balancing. A resolver can reuse a cached answer for many clients or requests, so the actual traffic distribution may differ from the configured DNS answer distribution.

Simple, Weighted, Latency, and Geographic Routing

The main routing policies are:

Weighted routing can support gradual migration. For example, a team might configure two regional endpoints with weights of 90 and 10, then adjust the values while monitoring performance.

This does not guarantee that exactly 10% of individual user requests reach the second endpoint. DNS resolvers cache responses, and their clients may generate different amounts of traffic.

Latency-based routing selects DNS answers according to measured latency relationships, not necessarily the geographically closest Region. A nearby Region can be slower than a more distant one because of network conditions.

For a deeper introduction to regional distribution and target routing, see What Is a Load Balancer?.

Health Checks and Failover

Route 53 health checks can test supported public endpoints through HTTP, HTTPS, or TCP and can also monitor selected CloudWatch alarm states or calculated health-check conditions.

When connected to suitable routing policies, health-check results help Route 53 avoid returning records that represent unhealthy endpoints.

For example, a failover configuration may have:

• Primary endpoint: Application Load Balancer in the main AWS Region.
• Secondary endpoint: Standby application endpoint in another Region.
• Health check: Tests a dedicated primary-region readiness endpoint.
• Failover records: Select the secondary destination when the primary is considered unhealthy.

The health-check endpoint should represent meaningful application readiness. A server returning HTTP 200 while its critical database is inaccessible may not be useful as a failover target.

For an ELB alias record, EvaluateTargetHealth = true can use the load balancer's target-health state without requiring an independent Route 53 endpoint health check.

However, this option does not work identically for every alias target. For example, CloudFront aliases require target health evaluation to be disabled.

DNS failover is not instantaneous. Resolver caches, client connection reuse, and existing sessions can delay the movement of real traffic even after Route 53 changes its authoritative answers.

TTL, Caching, and DNS Changes

DNS records commonly have a Time to Live (TTL), expressed in seconds. The TTL tells caching resolvers how long the answer can normally be reused before it should be refreshed.

For example, an ordinary A record with a 300-second TTL can remain cached by a resolver for up to five minutes under typical behavior.

Changing the authoritative record does not invalidate cached responses already stored elsewhere. Some clients and resolvers can also apply their own caching or retry behavior.

For planned migrations, a common procedure is:

1. Reduce the TTL before the migration, allowing the previous longer TTL time to elapse.
2. Confirm the replacement endpoint is healthy and ready.
3. Update the relevant Route 53 record or routing weights.
4. Monitor both old and new endpoints during the transition.
5. Keep the previous endpoint available during the expected cache transition window.

Not all alias targets allow the TTL to be configured directly. Route 53 uses the target resource's applicable TTL behavior for those aliases.

DNS caching is also different from CloudFront HTTP caching. Updating a DNS record does not invalidate HTML, JavaScript, or images already stored in an edge or browser cache.

Private DNS, Resolver, and Security

Route 53 is not limited to public internet DNS. It also provides DNS resolution capabilities for private VPC workloads and supported connections to corporate or data center networks.

These capabilities become important in architectures with internal APIs, multiple AWS accounts, hybrid infrastructure, and requirements for centralized DNS controls.

Route 53 Resolver and Hybrid DNS

Route 53 Resolver is the DNS resolution component associated with Amazon VPC networking. It resolves supported public and private DNS names for resources in the VPC.

For hybrid DNS, Resolver inbound and outbound endpoints can connect DNS resolution between AWS VPCs and external networks.

• Inbound Resolver endpoints: Allow permitted DNS resolvers outside the VPC to send relevant queries into AWS.
• Outbound Resolver endpoints: Allow VPC-originated queries to be forwarded to designated external DNS servers using configured rules.
• Resolver forwarding rules: Specify which DNS namespaces are forwarded to selected targets.
• Private hosted zones: Provide authoritative private answers for associated VPCs.

For example, an AWS application might need to resolve database.corp.example through a company-managed DNS server while resolving orders.internal.example.com through a Route 53 private hosted zone.

A correct hybrid DNS design must also provide network connectivity and allow the DNS traffic, commonly UDP or TCP port 53 as required.

Route 53 Resolver supports additional features such as DNS query logging and DNS Firewall, which can help teams investigate and restrict selected DNS activity within VPC environments.

For the underlying subnet and VPC networking model, see What Is Amazon VPC?.

DNSSEC, IAM, and DNS Security

DNS is a critical infrastructure dependency. A compromised DNS configuration can redirect application traffic, interrupt email, or prevent clients from reaching a legitimate service.

Important protections include:

• IAM least privilege: Restrict who can change hosted zones and records.
• Change auditing: Record supported DNS administration activity through CloudTrail.
• Domain protection: Protect registrar access and domain transfer controls.
• DNSSEC: Support cryptographic validation of DNS data for suitable public hosted zones.
• CAA records: Limit which certificate authorities may issue certificates for a domain.
• Resolver query logging: Investigate DNS behavior in supported VPC environments.

DNSSEC adds signatures so validating DNS resolvers can verify the authenticity of supported DNS responses. Correct setup requires signing the hosted zone and establishing the appropriate chain of trust through a Delegation Signer (DS) record at the parent zone.

Incorrect DS records or incomplete DNSSEC configuration can cause validating resolvers to reject otherwise legitimate DNS answers. Enable DNSSEC through a planned procedure with verification and rollback steps.

DNSSEC does not replace HTTPS. DNSSEC helps validate DNS data, while TLS protects the confidentiality and authenticity of the connection to the intended application endpoint.

Production Design Example: Global SaaS Application

Consider a SaaS platform with public documentation, a FastAPI API, private internal services, and a PostgreSQL database. Customers access the application globally, while the primary transactional system runs in one AWS Region with a standby environment in another.

Route 53 is responsible for public DNS resolution, selected regional failover behavior, and private naming for internal infrastructure.

Public Website, Regional API, and Private Services

A production architecture can use these DNS names:

• example.com: Alias to a CloudFront distribution serving the public application.
• www.example.com: Alias to CloudFront or a controlled redirect destination.
• api.example.com: Failover routing between primary and secondary regional API endpoints.
• assets.example.com: Alias to a suitable CloudFront distribution.
• orders.internal.example.com: Private DNS name for an internal application endpoint.
• db.internal.example.com: Private DNS name for a managed database endpoint when the additional abstraction is justified.

CloudFront distributes static content globally, while the regional API handles application requests through an Application Load Balancer or another suitable AWS entry point.

The primary API Region has ECS tasks distributed across multiple Availability Zones. The standby Region has compatible application infrastructure and a planned data recovery or replication strategy.

The public API DNS name can use failover alias records pointing to the two regional load balancers. A health signal determines when Route 53 should prefer the secondary endpoint.

Private names resolve only within the associated network environment, allowing internal services to avoid dependence on public application DNS.

Failure Scenario: Regional API Outage

Suppose the primary Region's API becomes unavailable because the application cannot connect to its database.

If the associated health check reports failure, Route 53 can begin returning the secondary region's endpoint to fresh DNS lookups.

But DNS failover alone does not solve the entire incident. The secondary application must have appropriate capacity, data availability, secrets, authorization configuration, and working external dependencies.

Existing client connections might continue targeting the previous endpoint, and cached DNS answers may delay adoption of the new destination.

The recovery strategy must also consider data consistency. If the primary Region accepted a transaction immediately before failing, the standby system may not have received that write yet, depending on the replication architecture.

A realistic disaster recovery test therefore measures both DNS convergence and business readiness. Switching to a reachable server that cannot safely process the customer's data is not a successful recovery.

Ready-to-Use Example: Route 53 with Terraform and Python

This example manages two types of DNS through Terraform: public DNS for an existing CloudFront distribution and private DNS for an existing Amazon VPC. A Python tool audits the hosted zones and verifies the relevant Route 53 records.

The example uses existing infrastructure because Route 53 DNS configuration is typically layered on top of a domain, CloudFront distribution, and application environment that already exist.

1. Project Requirements

You need an existing public Route 53 hosted zone that is authoritative for your domain, a CloudFront distribution configured for the intended custom hostname, and a VPC where the private hosted zone will be associated.

Before adding the CloudFront alias, confirm that the distribution includes the hostname under its alternate domain names and has a valid HTTPS certificate covering that hostname. For CloudFront, an ACM certificate used for viewer HTTPS must be in us-east-1.

Create this project structure:

route53-demo/
  main.tf
  outputs.tf
  terraform.tfvars
  requirements.txt
  audit_dns.py

This demonstration will create or manage DNS records named www and _route53-demo in the specified public zone. Do not point it at a production zone containing records with those names unless you intend Terraform to manage them.

Use a dedicated development domain or subdomain where possible.

2. Create Public and Private DNS Records

Create main.tf:

terraform {
  required_version = ">= 1.5.0"

  required_providers {
    aws = {
      source  = "hashicorp/aws"
      version = "~> 6.0"
    }
  }
}

provider "aws" {
  region = "us-west-2"
}

# -------------------------------------
# Existing AWS resources
# -------------------------------------

variable "domain_name" {
  description = "Domain with an existing public Route 53 hosted zone."
  type        = string
}

variable "cloudfront_domain_name" {
  description = "Existing CloudFront distribution domain name."
  type        = string
}

variable "vpc_id" {
  description = "Existing VPC for the private hosted zone."
  type        = string
}

variable "internal_service_ip" {
  description = "Private IPv4 address of a demo service."
  type        = string
}

# Read the existing authoritative hosted zone.
data "aws_route53_zone" "public" {
  name         = "${trimsuffix(var.domain_name, ".")}."
  private_zone = false
}

# -------------------------------------
# Public DNS records
# -------------------------------------

# Route the website hostname to CloudFront.
resource "aws_route53_record" "www" {
  zone_id = data.aws_route53_zone.public.zone_id

  name = "www.${trimsuffix(var.domain_name, ".")}"
  type = "A"

  alias {
    name = var.cloudfront_domain_name

    # Fixed Route 53 hosted zone ID for
    # standard CloudFront distribution aliases.
    zone_id = "Z2FDTNDATAQYW2"

    # CloudFront aliases require false.
    evaluate_target_health = false
  }
}

# Public TXT record for testing authoritative DNS.
resource "aws_route53_record" "verification" {
  zone_id = data.aws_route53_zone.public.zone_id

  name = "_route53-demo.${trimsuffix(var.domain_name, ".")}"
  type = "TXT"
  ttl  = 300

  records = [
    "managed-by-terraform"
  ]
}

# -------------------------------------
# Private DNS for an existing VPC
# -------------------------------------

resource "aws_route53_zone" "private" {
  name = "internal.${trimsuffix(var.domain_name, ".")}"

  vpc {
    vpc_id = var.vpc_id
  }

  comment = "Internal DNS for the Route 53 demo"

  tags = {
    Environment = "development"
    ManagedBy   = "terraform"
  }
}

# Resolve an internal application hostname
# to its private IPv4 address.
resource "aws_route53_record" "orders" {
  zone_id = aws_route53_zone.private.zone_id

  name = "orders.internal.${trimsuffix(var.domain_name, ".")}"
  type = "A"
  ttl  = 60

  records = [
    var.internal_service_ip
  ]
}

# Verify that a private zone record can be
# looked up by resources in the associated VPC.
resource "aws_route53_record" "internal_txt" {
  zone_id = aws_route53_zone.private.zone_id

  name = "info.internal.${trimsuffix(var.domain_name, ".")}"
  type = "TXT"
  ttl  = 60

  records = [
    "private-dns-enabled"
  ]
}

The public zone is retrieved rather than recreated, avoiding accidental changes to the domain's authoritative name servers.

The CloudFront A alias uses the target hosted zone ID Z2FDTNDATAQYW2, which is the standard hosted zone identifier for CloudFront distribution aliases. For other target types, such as an Application Load Balancer, use the target's own hosted zone ID rather than reusing this value.

The private hosted zone becomes associated with the specified VPC. Its records are available through the VPC's supported Route 53 Resolver configuration, not automatically through public DNS.

Create outputs.tf:

output "public_zone_id" {
  value = data.aws_route53_zone.public.zone_id
}

output "public_name_servers" {
  value = data.aws_route53_zone.public.name_servers
}

output "website_hostname" {
  value = aws_route53_record.www.fqdn
}

output "private_zone_id" {
  value = aws_route53_zone.private.zone_id
}

output "internal_hostname" {
  value = aws_route53_record.orders.fqdn
}

Configure your own values in terraform.tfvars:

# Replace with a domain whose public zone
# already exists in your AWS account.
domain_name = "example.com"

# Replace with your actual CloudFront domain.
cloudfront_domain_name = "d111111abcdef8.cloudfront.net"

# Replace with an existing VPC ID.
vpc_id = "vpc-0123456789abcdef0"

# Replace with the private IP of a suitable
# application endpoint in that VPC.
internal_service_ip = "10.40.10.25"

All values in this file are examples. The infrastructure will not be valid for your environment until you supply an actual domain, distribution, VPC, and private endpoint address.

Also note that DNS does not track the lifecycle of arbitrary private IP addresses. An A record pointing directly to an ephemeral ECS task or EC2 address can become stale when the workload is replaced. Production service discovery should use stable endpoints or suitable AWS service discovery capabilities.

3. Audit DNS with Python

Create requirements.txt:

boto3
dnspython

Create audit_dns.py:

import os

import boto3
import dns.exception
import dns.message
import dns.query
import dns.rdatatype


PUBLIC_ZONE_ID = os.environ["PUBLIC_ZONE_ID"]
PRIVATE_ZONE_ID = os.environ["PRIVATE_ZONE_ID"]
DOMAIN = os.environ["DOMAIN_NAME"].rstrip(".")

route53 = boto3.client("route53")


def list_records(zone_id: str) -> list[dict]:
    records = []

    paginator = route53.get_paginator(
        "list_resource_record_sets"
    )

    for page in paginator.paginate(
        HostedZoneId=zone_id
    ):
        records.extend(
            page["ResourceRecordSets"]
        )

    return records


def print_records(
    zone_name: str,
    records: list[dict],
) -> None:
    print(f"\n{zone_name} records:")

    for record in records:
        name = record["Name"]
        record_type = record["Type"]

        if "AliasTarget" in record:
            value = record["AliasTarget"]["DNSName"]
        else:
            value = ", ".join(
                entry["Value"]
                for entry in record.get(
                    "ResourceRecords", []
                )
            )

        print(
            f"{name:50} "
            f"{record_type:6} "
            f"{value}"
        )


def query_authoritative_txt(
    server: str,
    hostname: str,
) -> None:
    query = dns.message.make_query(
        hostname,
        dns.rdatatype.TXT,
    )

    response = dns.query.udp(
        query,
        server,
        timeout=4,
    )

    if response.flags & 0x0400:
        print(
            f"\nAuthoritative response from {server}:"
        )
    else:
        print(
            f"\nNon-authoritative response from {server}:"
        )

    print(response)


def resolve_public_nameservers(
    records: list[dict],
) -> list[str]:
    servers = []

    for record in records:
        if (
            record["Type"] == "NS"
            and record["Name"].rstrip(".") == DOMAIN
        ):
            servers.extend(
                item["Value"].rstrip(".")
                for item in record.get(
                    "ResourceRecords", []
                )
            )

    return servers


def main() -> None:
    public_records = list_records(
        PUBLIC_ZONE_ID
    )

    private_records = list_records(
        PRIVATE_ZONE_ID
    )

    print_records(
        "Public zone",
        public_records,
    )

    print_records(
        "Private zone",
        private_records,
    )

    nameservers = resolve_public_nameservers(
        public_records
    )

    if not nameservers:
        raise RuntimeError(
            "No public zone NS records found"
        )

    hostname = f"_route53-demo.{DOMAIN}"

    # An authoritative lookup works even if
    # the domain is not publicly delegated.
    import dns.resolver

    addresses = dns.resolver.resolve(
        nameservers[0],
        "A",
    )

    server_ip = str(addresses[0])

    try:
        query_authoritative_txt(
            server_ip,
            hostname,
        )
    except dns.exception.DNSException as exc:
        print(
            f"Authoritative query failed: {exc}"
        )

    print(
        "\nPrivate DNS records were inspected via AWS API."
    )
    print(
        "To test private resolution, run a resolver"
        " query from a resource inside the associated VPC."
    )


if __name__ == "__main__":
    main()

The script uses boto3 to enumerate DNS records from both hosted zones, then uses dnspython to query one of the public zone's authoritative name servers for the demonstration TXT record.

This is different from querying the operating system's recursive resolver. An authoritative query helps confirm that Route 53 is serving the intended data, even if registrar delegation has not yet been updated.

The script does not attempt to resolve private VPC records from a workstation outside AWS. Private hosted zone names require the appropriate VPC-associated Resolver path, so their lookup should be tested from an EC2 instance, container, or supported connected network environment.

4. Deploy, Verify, and Troubleshoot

Initialize and validate the Terraform configuration:

export AWS_REGION="us-west-2"

terraform init
terraform fmt
terraform validate
terraform plan

# Review DNS record names and resource changes
# before applying against an existing zone.
terraform apply

# Export values for the Python audit.
export PUBLIC_ZONE_ID="$(
  terraform output -raw public_zone_id
)"

export PRIVATE_ZONE_ID="$(
  terraform output -raw private_zone_id
)"

export DOMAIN_NAME="example.com"

# Install the auditing dependencies.
python3 -m venv .venv
source .venv/bin/activate

pip install -r requirements.txt

# Inspect hosted zone records.
python audit_dns.py

# Verify authoritative DNS with AWS.
aws route53 test-dns-answer \
  --hosted-zone-id "$PUBLIC_ZONE_ID" \
  --record-name "_route53-demo.$DOMAIN_NAME" \
  --record-type TXT

# Inspect the configured website alias.
aws route53 list-resource-record-sets \
  --hosted-zone-id "$PUBLIC_ZONE_ID" \
  --query "ResourceRecordSets[?Type=='A']"

# Remove the demo's Terraform-managed resources
# only when they are no longer required.
terraform plan -destroy
terraform destroy

Replace the DOMAIN_NAME environment variable with your actual domain before running the audit.

From a system with DNS utilities installed, you can also inspect public delegation and resolution:

# Query the current public delegation.
dig NS example.com +short

# Query one authoritative server directly.
dig @ns-123.awsdns-45.com \
  _route53-demo.example.com TXT

# Resolve the public website hostname.
dig www.example.com A +short

# Inspect DNS resolution timing.
dig www.example.com A +stats

# Run this inside the associated VPC
# to validate private DNS.
dig orders.internal.example.com A +short

The name server in the second command is an illustrative placeholder. Use one of the actual Route 53 hosted zone's NS values.

If the public authoritative query succeeds but ordinary recursive DNS queries still return older data, check registrar delegation, cached responses, and any negative caching effects.

If the private DNS query fails, check VPC association, DNS support settings, resolver forwarding rules, and whether the querying workload actually uses the expected VPC Resolver.

Terraform destruction removes the demo-managed records and private hosted zone. It does not delete the existing public hosted zone, CloudFront distribution, or VPC retrieved through data sources and input variables.

Cost, Common Mistakes, and Production Checklist

Route 53 is usually inexpensive compared with application compute, databases, and data transfer, but DNS mistakes can make an entire application unavailable regardless of how much redundancy exists behind it.

Operational controls should therefore emphasize safe record changes, clear ownership, correct delegation, and tested recovery procedures.

Route 53 Pricing and Monitoring

Route 53 pricing depends on the capabilities used, including hosted zones, public DNS queries, health checks, domain registration, and some Resolver-related features.

Typical cost considerations include:

• Public hosted zones: Recurring hosted-zone charges.
• DNS queries: Public query volume and applicable query type.
• Domain registration: Registration and renewal fees that depend on the top-level domain.
• Health checks: Charges based on configured checks and features.
• Resolver endpoints: Hourly and query-processing charges where applicable.
• Resolver query logging: Possible log destination and processing charges.
• Alias queries: Eligible alias queries to supported AWS targets can be free under Route 53's documented rules.

Monitoring can include Route 53 health-check status through CloudWatch, DNS query logging where available, and CloudTrail audit events for changes to DNS infrastructure.

For a critical public domain, monitor more than the DNS record itself. Synthetic tests should validate that DNS resolves to a usable destination and that the application responds correctly through HTTPS.

Common Route 53 Mistakes

Frequent production mistakes include:

• Creating a hosted zone without updating delegation: Public users continue querying a different DNS provider.
• Confusing Route 53 with a load balancer: DNS answers are mistaken for per-request traffic routing.
• Using a CNAME at the domain apex: The record conflicts with DNS zone requirements.
• Using the wrong alias target hosted zone ID: Route 53 cannot correctly associate the intended AWS endpoint.
• Enabling target health evaluation for CloudFront: CloudFront aliases require the setting to be false.
• Assuming DNS failover is instantaneous: Cached answers and existing client connections delay traffic movement.
• Making DNS changes with an excessively long TTL: Rollback and migration become slow.
• Routing to an unhealthy standby Region: DNS failover moves traffic to infrastructure that cannot safely serve users.
• Forgetting private hosted zone associations: Internal names fail to resolve in the intended VPC.
• Creating overlapping private DNS namespaces without understanding precedence: Queries return unexpected or negative answers.
• Changing NS or MX records without reviewing dependencies: Public websites or email delivery become unavailable.
• Misconfiguring DNSSEC DS records: Validating resolvers reject otherwise legitimate DNS responses.

Production Checklist

Before relying on Route 53 for a production application, verify that:

• The intended public hosted zone is authoritative through correct registrar delegation.
• Domain registration renewal and ownership are protected.
• Public records use suitable A, AAAA, alias, CNAME, MX, TXT, and CAA types.
• CloudFront aliases match configured alternate domains and HTTPS certificates.
• TTL settings support planned migrations and realistic recovery times.
• Weighted routing is not mistaken for precise per-request traffic splitting.
• Primary and secondary failover endpoints have working health signals.
• Disaster recovery procedures include data availability and application readiness.
• Private hosted zones are associated with the intended VPCs.
• VPC DNS support and hostname settings are configured correctly.
• Resolver rules and endpoint networking are documented for hybrid DNS.
• DNS infrastructure changes are version-controlled and reviewed.
• IAM limits who can modify hosted zones or domain registration.
• CloudTrail and suitable DNS or health-check monitoring are enabled.
• DNSSEC changes are tested and coordinated with domain delegation.

Frequently Asked Questions

Route 53 combines familiar DNS functions with AWS-specific routing and private networking integrations, so engineers commonly need to distinguish authoritative DNS from application connectivity and traffic distribution.

What Is Amazon Route 53 Used For?

Amazon Route 53 provides authoritative DNS hosting, domain registration, health checks, DNS routing policies, and private DNS resolution. Applications use it to map domain names to supported AWS and external endpoints.

Why Is It Called Route 53?

The name refers to DNS using port 53 for its standard network communications. DNS commonly uses UDP port 53 and uses TCP port 53 for supported query and transfer scenarios.

Do I Need to Register My Domain with Route 53?

No. A domain can remain registered with another registrar while Route 53 provides authoritative DNS hosting. You configure the appropriate name server delegation at the registrar to use your Route 53 hosted zone.

Route 53 can also register or transfer supported domain names when desired.

What Is the Difference Between Alias and CNAME?

A CNAME is a standard DNS record that maps one name to another. A Route 53 alias is an AWS-specific record configuration that can route queries to supported AWS resources or other records in the same hosted zone.

Alias A and AAAA records can work at the zone apex for supported targets, while ordinary CNAME records cannot be used at the zone apex.

Does Route 53 Provide Instant Failover?

No. Route 53 can change authoritative DNS responses after detecting an unhealthy primary endpoint, but recursive resolver caching, client behavior, and existing connections affect how quickly real users move to the alternate destination.

Reliable recovery also requires the secondary application and its data dependencies to be ready for production traffic.

Can Route 53 Resolve Private IP Addresses?

Yes. Route 53 private hosted zones can return private IP addresses or other supported DNS answers through the Resolver environment of associated VPCs and appropriately connected networks.

Private hosted zone answers are not automatically available to arbitrary users on the public internet.

Is Amazon Route 53 Free?

Amazon Route 53 is generally a paid service. Hosted zones, eligible DNS queries, health checks, domain registration, and optional Resolver features can incur charges.

Some supported alias queries to AWS resources have no separate Route 53 query charge, but this does not make the entire service free.

Conclusion

Amazon Route 53 is AWS's managed DNS and traffic routing service. It connects domain names to application infrastructure, supports public and private hosted zones, offers advanced routing policies, and can help direct new DNS lookups away from unhealthy endpoints.

Its most important architectural characteristic is that DNS operates before the application connection. Route 53 can influence which endpoint a client discovers, but it does not distribute every HTTP request, invalidate every cached answer, or guarantee that a selected backend is ready to process business transactions.

Production DNS design requires correct delegation, sensible TTLs, secure access to records, reliable health signals, working standby infrastructure, and careful handling of private DNS namespaces. These decisions can have a larger availability impact than the number of application instances running behind the DNS name.

Key Takeaway: Use Amazon Route 53 to manage domain resolution, route traffic to suitable infrastructure, and support public or private DNS. Treat DNS as critical infrastructure, and test routing changes and recovery procedures against the behavior of real resolvers, clients, and applications.

More Articles to Read

Explore these related topics for guidance on AWS infrastructure, application routing, security, deployment automation, and reliability.

• What Is a Reverse Proxy?
• What Is an API Gateway?
• What Is Terraform?
• What Is Infrastructure as Code?
• What Is CloudFront?
• What Is IAM?
• What Is Auto Scaling?
• What Is Zero-Downtime Deployment?