Private Hosted Zones for VPC-Internal DNS

A private hosted zone is a Route 53 zone that answers only inside the VPCs you associate with it. It is how you give internal services stable names - db.internal, cache.svc.internal - without exposing anything to the public internet. Instances resolve those names to private IPs; the outside world gets nothing.

This is the one place Route 53's global model becomes region-aware: a private zone is bound to specific VPCs in specific regions, because a private name only means something inside a network.

Recipe

Create a private zone by passing a VPC block (VPCId + VPCRegion) and setting PrivateZone: true in the HostedZoneConfig. The zone is live inside that VPC immediately - no registrar delegation, since it never touches public DNS.

# --- Python (boto3) ---
import boto3, time
 
r53 = boto3.client("route53")
resp = r53.create_hosted_zone(
    Name="internal.example",
    CallerReference=f"private-{int(time.time())}",
    HostedZoneConfig={"Comment": "internal svc discovery", "PrivateZone": True},
    VPC={"VPCRegion": "us-east-1", "VPCId": "vpc-0abc123"},
)
zone_id = resp["HostedZone"]["Id"].split("/")[-1]
print(zone_id)

// --- TypeScript (AWS SDK v3) ---
import { Route53Client, CreateHostedZoneCommand } from "@aws-sdk/client-route-53";
 
const r53 = new Route53Client({ region: "us-east-1" });
const resp = await r53.send(new CreateHostedZoneCommand({
  Name: "internal.example",
  CallerReference: `private-${Date.now()}`,
  HostedZoneConfig: { Comment: "internal svc discovery", PrivateZone: true },
  VPC: { VPCRegion: "us-east-1", VPCId: "vpc-0abc123" },
}));
const zoneId = resp.HostedZone?.Id?.split("/").pop();
console.log(zoneId);

You must include exactly one VPC when creating a private zone; you associate additional VPCs afterward. The VPCRegion is the region the VPC lives in, and it can differ from anything else in your setup - this is the region-scoping the global service otherwise lacks.

Working Example

With the zone created, add records the same way as a public zone - a change batch of A records pointing at private IPs. Nothing about the record write changes; only who can resolve it does.

# --- Python (boto3) ---
r53.change_resource_record_sets(
    HostedZoneId=zone_id,
    ChangeBatch={"Changes": [
        {"Action": "UPSERT", "ResourceRecordSet": {
            "Name": "db.internal.example", "Type": "A", "TTL": 60,
            "ResourceRecords": [{"Value": "10.0.1.20"}]}},
        {"Action": "UPSERT", "ResourceRecordSet": {
            "Name": "cache.internal.example", "Type": "A", "TTL": 60,
            "ResourceRecords": [{"Value": "10.0.1.35"}]}},
    ]},
)

// --- TypeScript (AWS SDK v3) ---
import { ChangeResourceRecordSetsCommand } from "@aws-sdk/client-route-53";
 
await r53.send(new ChangeResourceRecordSetsCommand({
  HostedZoneId: zoneId,
  ChangeBatch: { Changes: [
    { Action: "UPSERT", ResourceRecordSet: {
        Name: "db.internal.example", Type: "A", TTL: 60,
        ResourceRecords: [{ Value: "10.0.1.20" }] } },
    { Action: "UPSERT", ResourceRecordSet: {
        Name: "cache.internal.example", Type: "A", TTL: 60,
        ResourceRecords: [{ Value: "10.0.1.35" }] } },
  ]},
}));

An EC2 instance in vpc-0abc123 now resolves db.internal.example to 10.0.1.20. An instance in an unassociated VPC, or anyone on the internet, gets NXDOMAIN. The private IPs never leak into public DNS.

Deep Dive

The VPC DNS Prerequisites

Private DNS only works if the VPC has two attributes enabled: enableDnsSupport (the VPC provides the .2 Route 53 Resolver) and enableDnsHostnames. Without both, instances cannot resolve the private zone even though it exists. Check and set them with the EC2 client - this is the single most common reason a private zone "does not work."

# --- Python (boto3) ---
ec2 = boto3.client("ec2", region_name="us-east-1")
ec2.modify_vpc_attribute(VpcId="vpc-0abc123",
                         EnableDnsSupport={"Value": True})
ec2.modify_vpc_attribute(VpcId="vpc-0abc123",
                         EnableDnsHostnames={"Value": True})

// --- TypeScript (AWS SDK v3) ---
import { EC2Client, ModifyVpcAttributeCommand } from "@aws-sdk/client-ec2";
 
const ec2 = new EC2Client({ region: "us-east-1" });
await ec2.send(new ModifyVpcAttributeCommand({
  VpcId: "vpc-0abc123", EnableDnsSupport: { Value: true } }));
await ec2.send(new ModifyVpcAttributeCommand({
  VpcId: "vpc-0abc123", EnableDnsHostnames: { Value: true } }));

Associating More VPCs

Add another VPC - in the same or a different region - with AssociateVPCWithHostedZone. All associated VPCs then resolve the same private names, which is how you share internal DNS across a multi-VPC or multi-region footprint.

# --- Python (boto3) ---
r53.associate_vpc_with_hosted_zone(
    HostedZoneId=zone_id,
    VPC={"VPCRegion": "eu-west-1", "VPCId": "vpc-0def456"},
    Comment="share internal DNS with the EU VPC",
)

// --- TypeScript (AWS SDK v3) ---
import { AssociateVPCWithHostedZoneCommand } from "@aws-sdk/client-route-53";
 
await r53.send(new AssociateVPCWithHostedZoneCommand({
  HostedZoneId: zoneId,
  VPC: { VPCRegion: "eu-west-1", VPCId: "vpc-0def456" },
  Comment: "share internal DNS with the EU VPC",
}));

Cross-account association is a two-step handshake: the zone owner calls CreateVPCAssociationAuthorization, then the VPC owner (in the other account) calls AssociateVPCWithHostedZone. Remove a network later with DisassociateVPCFromHostedZone - you cannot remove the last remaining VPC.

Split-Horizon DNS

You can create a private zone with the same name as a public one - say example.com both public and private. Inside an associated VPC, Route 53 answers from the private zone; outside, from the public zone. This split-horizon pattern lets api.example.com resolve to an internal IP for your services and a public IP for customers, with the same name.

Gotchas

• VPC DNS attributes off. enableDnsSupport and enableDnsHostnames must both be on, or instances cannot resolve the private zone even though it exists.
• Forgetting the required VPC on create. CreateHostedZone for a private zone must include exactly one VPC; omit it and the call fails.
• Overlapping private zones. Two private zones with the same name associated to the same VPC create ambiguity; Route 53 uses the most specific match, so avoid overlap.
• Cross-account single-step. Associating a VPC from another account needs CreateVPCAssociationAuthorization first; a direct associate call from the other account is denied.
• Removing the last VPC. You cannot disassociate the final VPC from a private zone; delete the zone instead.
• Expecting public resolution. A private zone never answers on the internet. If you need both, run split-horizon with a matching public zone.

Alternatives

• AWS Cloud Map for richer service discovery with health-aware service instances and API-based lookup, built on Route 53 under the hood.
• Route 53 Resolver endpoints and rules for hybrid DNS - forwarding between on-premises DNS and VPC-resolved private zones.
• /etc/hosts or a config service for a handful of static internal names where a full private zone is overkill.
• ECS/EKS service DNS (Cloud Map or CoreDNS) when discovery is scoped to a container orchestrator rather than the whole VPC.

Use a private hosted zone for VPC-wide internal names; reach for Cloud Map or Resolver rules when you need health-aware discovery or hybrid on-prem forwarding.

FAQs

Related

• Route 53 via SDK Basics - the zone and record calls that private zones reuse.
• Route 53's DNS & Traffic-Shaping Model - why private zones are the region-scoped exception.
• Record Types & Alias Records - the record types you put in a private zone.
• Route 53 via SDK Best Practices - safe change-batch habits for internal DNS.

Stack versions: This page was written for boto3 1.43.x (Python 3.10+) and the AWS SDK for JavaScript v3 (Node.js 18+).