Private Hosted Zones in AWS Route 53 Explained

Simple explanation

When an EC2 instance asks “where is db.internal.example.com?”, it asks the VPC’s built-in DNS resolver. That resolver checks the private hosted zone and returns the answer. No one outside the VPC gets the same answer, or any answer at all.

This is different from public DNS, which is how browsers on the internet find your website. Private hosted zones are for internal AWS workloads only: application servers finding their database, microservices finding each other, internal load balancers, and private endpoints for AWS services like S3 or Secrets Manager.

Why private hosted zones exist

Without private DNS, services inside a VPC reference each other by private IP address or by the AWS-assigned endpoint string like my-db.cluster-xyz.us-east-1.rds.amazonaws.com. Both approaches break in practice.

Private IP addresses change every time you recreate a resource. AWS endpoint strings are long, hard to read, tied to a specific resource, and embedded in configuration files across every service that uses them. When you replace an RDS instance or swap a load balancer, you update every caller.

Private hosted zones give you a stable layer of indirection. You point db.internal.example.com at your current RDS endpoint. When you replace the database, you update one DNS record. Every application using the DNS name picks up the change automatically without touching its own configuration. The same pattern applies to microservices discovering internal APIs, internal ALBs in private subnets, and any service-to-service communication that should stay off the public internet.

Private hosted zones also enable environment consistency. You can use the same internal DNS names across dev, staging, and production by giving each environment its own private hosted zone with the same structure but different record values. Promoting from dev to staging becomes a VPC association change, not a configuration rollout.

How private hosted zones work

A private hosted zone is structurally identical to a public hosted zone: same record types (A, CNAME, Alias, TXT, and so on), same TTL settings, same routing policies. The difference is that when you create it, you mark it private and associate it with one or more VPCs.

Every VPC has a built-in DNS resolver called the Route 53 VPC Resolver, reachable at the VPC’s base CIDR address plus two. For a VPC with the CIDR 10.0.0.0/16, the resolver is at 10.0.0.2. EC2 instances use this address for DNS by default (it is set automatically in the VPC’s DHCP options). You do not configure this manually.

When the VPC Resolver receives a query for a name in a private hosted zone associated with that VPC, it returns the record from the private zone. Queries from VPCs that are not associated with the zone get no response from the private zone.

When to use this

Use a private hosted zone whenever internal services need stable DNS names that should not be visible on the public internet.

Internal database names: Point db.internal.example.com at your RDS cluster endpoint. Applications use the DNS name. When you replace the database, you update one record.

Internal load balancers and microservices: Register each microservice under a readable name in the private zone (payments.internal.example.com, orders.internal.example.com). Services find each other by name, not by ALB DNS string.

Multi-VPC internal naming: Associate the private hosted zone with multiple VPCs so all your environments can resolve the same internal names. Useful when you have separate VPCs for dev, staging, and production.

Hybrid and on-premises connectivity: If you have on-premises servers connected via Site-to-Site VPN or Direct Connect, you can configure Route 53 Resolver Inbound Endpoints so those servers can resolve names in your private hosted zone. See the hybrid connectivity overview for the broader picture.

Private endpoints for AWS services: When you create Interface VPC Endpoints for services like S3, Secrets Manager, or SSM using AWS PrivateLink, those endpoints come with private DNS options. Traffic to the service stays on the AWS network and is resolved through the private hosted zone. See VPC endpoint policies for how to control access to these endpoints.

When not to use this

Do not create a private hosted zone for domains that only need public resolution. If your website or API is purely public-facing, a standard Route 53 public hosted zone is the right tool.

Avoid using private hosted zones for the same domain apex as your public zone unless you fully understand split-horizon DNS. If you create example.com as a private zone but forget to add a record for www.example.com, resources inside your VPC will get NXDOMAIN for www.example.com, even though the public zone has that record. There is no fallback.

If your goal is to forward DNS queries from on-premises to AWS without managing a full private hosted zone, consider Route 53 Resolver forwarding rules instead. They let you forward specific domains to custom DNS servers without duplicating zone management. Forwarding rules take precedence over private hosted zones for the same domain, so if you use both, understand the precedence order.

How it works step by step

Here is what happens when an EC2 instance queries a name in a private hosted zone:

1. The EC2 instance queries db.internal.example.com.
2. The query goes to the VPC Resolver at 10.0.0.2 (base CIDR + 2).
3. The Resolver checks whether a private hosted zone associated with this VPC is authoritative for internal.example.com.
4. It finds the private zone and looks up the db.internal.example.com record.
5. The record exists: a CNAME pointing to the RDS cluster endpoint.
6. The Resolver returns the answer. The EC2 instance connects to the database.

If the private zone is associated but the record is missing, step 5 fails. The Resolver returns NXDOMAIN. It does not fall through to check a public hosted zone with the same name. The private zone’s authority over that domain is absolute inside the VPC.

Creating a private hosted zone

You create a private hosted zone with the Route 53 console or CLI. The key difference from a public zone is the PrivateZone=true flag and the VPC association at creation time.

# Create a private hosted zone associated with a VPC
aws route53 create-hosted-zone \
  --name internal.example.com \
  --caller-reference "private-hz-$(date +%s)" \
  --hosted-zone-config PrivateZone=true \
  --vpc VPCRegion=us-east-1,VPCId=vpc-0abc123def456789a

# Save the hosted zone ID from the output
# "Id": "/hostedzone/Z9876543210ZYXWV9876"

Once the zone exists, add records for the internal services you want reachable by name:

# Add a CNAME pointing db.internal.example.com to an RDS endpoint
aws route53 change-resource-record-sets \
  --hosted-zone-id Z9876543210ZYXWV9876 \
  --change-batch '{
    "Changes": [{
      "Action": "CREATE",
      "ResourceRecordSet": {
        "Name": "db.internal.example.com",
        "Type": "CNAME",
        "TTL": 300,
        "ResourceRecords": [{
          "Value": "my-db.cluster-xyz.us-east-1.rds.amazonaws.com"
        }]
      }
    }]
  }'

# Add an Alias A record pointing api.internal.example.com to an internal ALB
aws route53 change-resource-record-sets \
  --hosted-zone-id Z9876543210ZYXWV9876 \
  --change-batch '{
    "Changes": [{
      "Action": "CREATE",
      "ResourceRecordSet": {
        "Name": "api.internal.example.com",
        "Type": "A",
        "AliasTarget": {
          "HostedZoneId": "Z35SXDOTRQ7X7K",
          "DNSName": "internal-alb-123456.us-east-1.elb.amazonaws.com",
          "EvaluateTargetHealth": true
        }
      }
    }]
  }'

Associating multiple VPCs

A private hosted zone can be associated with any number of VPCs. Records resolve correctly inside any associated VPC. This is useful for multi-VPC architectures: separate VPCs for different environments or teams that all need to resolve the same internal DNS names.

# Associate an additional VPC in the same account
aws route53 associate-vpc-with-hosted-zone \
  --hosted-zone-id Z9876543210ZYXWV9876 \
  --vpc VPCRegion=us-east-1,VPCId=vpc-0def456abc123789b

For cross-account associations, the process takes two steps: the hosted zone owner creates an authorization for the other account’s VPC, and the VPC owner completes the association from their account.

# Step 1: Hosted zone owner account: authorize the cross-account VPC
aws route53 create-vpc-association-authorization \
  --hosted-zone-id Z9876543210ZYXWV9876 \
  --vpc VPCRegion=us-east-1,VPCId=vpc-crossaccount

# Step 2: VPC owner account: complete the association
aws route53 associate-vpc-with-hosted-zone \
  --hosted-zone-id Z9876543210ZYXWV9876 \
  --vpc VPCRegion=us-east-1,VPCId=vpc-crossaccount

Split-horizon DNS

Split-horizon (or split-view) DNS means the same domain name resolves to different answers depending on where the query originates. Private hosted zones make this straightforward: create a private zone and a public zone with the same name, put different records in each, and Route 53 serves the right answer based on whether the query comes from inside or outside an associated VPC.

A common use case: api.example.com should resolve to a public ALB for internet users, but to an internal ALB for services running inside your VPC. This avoids the unnecessary public internet round-trip. The public hosted zone has an A record pointing to the public ALB. The private hosted zone has an Alias record pointing to the internal ALB. Inside the VPC, the private answer wins every time.

Private hosted zones vs public hosted zones vs Resolver forwarding

Resolving private DNS from on-premises

On-premises servers cannot query Route 53 private hosted zones directly. The Route 53 VPC Resolver at base+2 is only reachable from inside the VPC, so it is not accessible to traffic coming in over a VPN or Direct Connect link.

To allow on-premises servers to resolve names in a private hosted zone, you create a Route 53 Resolver Inbound Endpoint. The endpoint deploys a pair of DNS resolver IPs inside your VPC as Elastic Network Interfaces in subnets you specify. You then configure your on-premises DNS server to forward queries for your internal domain to those IP addresses. The endpoint receives the queries, resolves them using the VPC Resolver (which can see private hosted zones), and returns the answers back to the on-premises server through your hybrid connectivity link.

# Create a Route 53 Resolver Inbound Endpoint
aws route53resolver create-resolver-endpoint \
  --creator-request-id "inbound-$(date +%s)" \
  --direction INBOUND \
  --security-group-ids sg-resolver-endpoint \
  --ip-addresses \
    SubnetId=subnet-private-az1,Ip=10.0.1.100 \
    SubnetId=subnet-private-az2,Ip=10.0.2.100
# Then configure your on-premises DNS server to forward
# queries for internal.example.com to 10.0.1.100 and 10.0.2.100

Always use two IPs in two different Availability Zones. If one AZ has an issue, DNS forwarding continues through the other endpoint IP. Ensure your security group allows UDP and TCP on port 53 from your on-premises IP range.

Troubleshooting checklist

When a private hosted zone record is not resolving from inside your VPC, work through these checks in order:

1. Does the record exist? Open Route 53 and confirm the record is in the correct hosted zone with the correct name and type.
2. Is the hosted zone associated with the correct VPC? Check the hosted zone’s VPC associations. The VPC must be explicitly listed; there is no default association.
3. Are VPC DNS settings enabled? Run describe-vpc-attribute for both enableDnsSupport and enableDnsHostnames. Both must return true.
4. Is the instance using the VPC Resolver? On a Linux instance, check /etc/resolv.conf. It should list the base+2 address. A custom DHCP option set may have overridden it with a different DNS server.
5. Is a custom DNS server intercepting the query? If so, confirm it forwards to the VPC Resolver for AWS-internal names. It should not attempt to resolve private hosted zone names externally.
6. Are there Resolver forwarding rules for the same domain? Check Route 53 Resolver rules. A forwarding rule for the same domain takes precedence over the private hosted zone.
7. Are you testing from the right network context? Private zone records only resolve from inside an associated VPC. Testing from your laptop will correctly return no result, which is expected behavior.
8. For cross-account associations: Confirm the authorization exists in the hosted zone owner account and the association was completed from the VPC owner account.

For a deeper look at VPC DNS failures and their fixes, see the DNS resolution problems guide.