This chapter covers AWS Route 53 Private Hosted Zones (PHZs), a critical networking feature for internal DNS resolution within Amazon Virtual Private Cloud (VPC). For the SOA-C02 exam, understanding PHZs is essential because they appear in multiple question scenarios involving hybrid networking, VPC peering, and DNS-based service discovery. Approximately 5-8% of exam questions directly test your knowledge of private hosted zones, their configuration, and their interaction with other AWS services like VPC endpoints, Direct Connect, and VPN connections.
Jump to a section
Imagine a large company with multiple buildings (VPCs) on its campus. Each building has its own internal phone system, but the company also has a main switchboard that connects to the public telephone network. The company's internal phone directory is a private phone book that lists every employee by their extension number, but only within the company's own network. This directory is not accessible from outside the company—callers from the public network cannot look up an employee's extension; they must dial the main company number and be transferred. Similarly, AWS Route 53 Private Hosted Zones (PHZs) are DNS zones that are only resolvable from within your VPCs. They contain resource records that map private IP addresses to internal domain names, such as db.internal.example.com pointing to 10.0.1.5. Just as the company's internal directory allows employees to call each other by extension without going through the public network, a PHZ enables instances in your VPC to resolve private DNS names without exposing them to the internet. If the company later merges with another company and connects their networks via VPN (like a VPC peering connection), the internal directory can be shared so that employees in both networks can look up each other's extensions. However, by default, a PHZ is only associated with the VPCs you explicitly specify—just as only certain buildings are given access to the internal directory. The directory itself is managed by the company's IT department (Route 53 service), and updates are automatically distributed to all connected buildings, similar to how DNS records in a PHZ are automatically propagated to the DNS resolvers within the associated VPCs.
What is a Route 53 Private Hosted Zone?
A Route 53 Private Hosted Zone (PHZ) is a DNS namespace that is resolvable only from within one or more Amazon VPCs that you specify. Unlike public hosted zones, which are accessible from the internet, PHZs are not queryable from outside the associated VPCs. They allow you to use custom domain names for internal resources, such as db.internal.example.com for an RDS instance, without exposing those names publicly.
PHZs are commonly used for:
Internal service discovery (e.g., microservices communicating via DNS)
Hybrid architectures where on-premises resources need to resolve private DNS names
Multi-account or multi-VPC environments where centralized DNS management is required
How Private Hosted Zones Work Internally
When you create a PHZ, Route 53 automatically creates a delegation record (NS record) set for the zone. However, unlike public zones, the zone apex (SOA and NS records) is not publicly visible. Instead, the DNS resolvers within the associated VPCs are configured to forward queries for the zone's domain to Route 53's private DNS infrastructure.
Here is the step-by-step mechanism:
1. An EC2 instance in a VPC performs a DNS lookup for web.internal.example.com.
2. The VPC's DNS resolver (the Amazon-provided DNS server at the VPC+2 IP address, typically 10.0.0.2) receives the query.
3. If the VPC is associated with a PHZ for internal.example.com, the resolver knows to forward the query to Route 53 for that zone.
4. Route 53 checks its resource records and returns the answer (e.g., A record mapping web.internal.example.com to 10.0.1.10).
5. The resolver caches the answer and returns it to the instance.
If the VPC is not associated with the PHZ, the resolver treats the domain as a public domain and attempts to query the internet root servers, which will fail because the domain is not public. This is why association is mandatory.
Key Components, Values, Defaults, and Timers
Zone ID: A unique identifier for the PHZ, used in AWS CLI and SDK operations.
Domain name: The name of the hosted zone (e.g., example.internal). Must end with a trailing dot in Route 53.
Resource record sets: The DNS records you define, such as A, AAAA, CNAME, MX, TXT, etc.
VPC association: You must associate one or more VPCs with the PHZ. The VPC must be in the same AWS account or a different account (with appropriate authorization).
Default TTL: 300 seconds (5 minutes) for most record types unless overridden.
Maximum number of records per zone: 10,000 by default, but can be increased via service quota increase.
Maximum number of VPC associations per zone: 100 by default.
SOA record TTL: 900 seconds (15 minutes) by default.
NS record TTL: 172800 seconds (2 days) by default.
Configuration and Verification Commands
Creating a PHZ using AWS CLI:
aws route53 create-hosted-zone \
--name example.internal \
--caller-reference my-unique-string \
--vpc VPCRegion=us-east-1,VPCId=vpc-12345678Associating an additional VPC:
aws route53 associate-vpc-with-hosted-zone \
--hosted-zone-id Z1234567890ABCDEF \
--vpc VPCRegion=us-east-1,VPCId=vpc-87654321Creating a resource record:
aws route53 change-resource-record-sets \
--hosted-zone-id Z1234567890ABCDEF \
--change-batch '{
"Changes": [
{
"Action": "CREATE",
"ResourceRecordSet": {
"Name": "db.example.internal.",
"Type": "A",
"TTL": 300,
"ResourceRecords": [
{"Value": "10.0.1.5"}
]
}
}
]
}'Verifying DNS resolution from an EC2 instance:
dig db.example.internal @169.254.169.253Or using the instance's default resolver (VPC+2):
nslookup db.example.internalInteraction with Related Technologies
VPC Peering: PHZs are not automatically shared across peered VPCs. You must explicitly associate the PHZ with each VPC. However, if both VPCs are associated with the same PHZ, instances in one VPC can resolve DNS names for instances in the other VPC, provided the security groups allow traffic.
AWS Direct Connect and VPN: On-premises resources can resolve private DNS names if you configure Route 53 Resolver inbound endpoints. This allows on-premises DNS servers to forward queries to Route 53.
VPC Endpoints: For gateway endpoints (S3, DynamoDB), DNS resolution via PHZ is not applicable because those services use public DNS names. For interface endpoints, you can use private DNS names (enabled by default) that resolve to private IPs within the VPC.
Route 53 Resolver: This service enables hybrid DNS resolution. You can forward queries from your VPC to on-premises DNS servers (outbound endpoint) and vice versa (inbound endpoint). PHZs work with Route 53 Resolver to provide seamless DNS across environments.
Limitations
PHZs cannot be used to resolve DNS names across accounts without explicit authorization and association.
You cannot create a PHZ for a public domain (e.g., example.com) unless you also own the public zone and understand the implications (split-brain DNS).
The domain name must end with a trailing dot in Route 53, but you specify it without the dot in the console.
A VPC can be associated with multiple PHZs, but if there are overlapping names, the most specific match wins (longest prefix match).
Exam Tips
Remember that PHZs are not automatically resolvable across VPCs; association is required.
The VPC must have DNS resolution and DNS hostnames enabled.
You can use a PHZ to override public DNS resolution for a domain within your VPC (split-brain scenario).
When using CLI, the --vpc parameter is required at creation if you want immediate association; otherwise, you can associate later.
Deleting a PHZ requires that all resource record sets except the default SOA and NS records are deleted first.
Create the Private Hosted Zone
In the Route 53 console, navigate to Hosted zones and click 'Create hosted zone'. Enter the domain name (e.g., 'internal.example.com') and select 'Private hosted zone' as the type. You must specify at least one VPC to associate. The VPC must have both DNS resolution and DNS hostnames enabled. Under the hood, Route 53 creates the zone and automatically generates SOA and NS records. The NS records are not publicly visible; they are used internally by the VPC resolvers. The caller reference parameter ensures idempotency—if the request is retried, it won't create duplicate zones.
Associate VPCs with the Zone
If you did not associate a VPC during creation, you can do so later by editing the zone. You can associate multiple VPCs, even from different AWS accounts, provided you have authorization (via cross-account association). The VPC association tells Route 53 which VPCs' DNS resolvers should forward queries for this domain to Route 53. Without association, the zone exists but is not resolvable from any VPC. The maximum number of VPC associations per zone is 100 by default. Each VPC can be associated with up to 100 PHZs.
Add Resource Record Sets
Within the PHZ, you create resource records (A, AAAA, CNAME, MX, TXT, etc.) that map names to values. For example, an A record for 'db.internal.example.com' pointing to 10.0.1.5. You can also use alias records to point to AWS resources like ELB, CloudFront, or S3 buckets (but note that alias records in a private zone can only point to resources that have private IP addresses, such as internal load balancers). TTL values can be set per record; default is 300 seconds. Changes propagate quickly within the zone's associated VPCs.
Configure VPC DNS Settings
For the PHZ to work, the VPC must have the 'enableDnsSupport' and 'enableDnsHostnames' attributes set to true. 'enableDnsSupport' enables the VPC's DNS resolver (the Amazon-provided DNS server at VPC+2). 'enableDnsHostnames' assigns public DNS hostnames to instances with public IPs (not directly related to PHZ but often required). You can verify these settings in the VPC console or via AWS CLI: `aws ec2 describe-vpc-attribute --vpc-id vpc-xxx --attribute enableDnsSupport`. If these are disabled, DNS queries for the PHZ domain will not be forwarded to Route 53.
Test DNS Resolution from an Instance
Launch an EC2 instance in the associated VPC. Use the dig or nslookup command to query the private domain. For example: `dig db.internal.example.com` or `nslookup db.internal.example.com`. The resolver should return the private IP address. If the instance is in a different VPC that is not associated, the query will fail (NXDOMAIN or no answer). You can also test from on-premises if you have set up Route 53 Resolver inbound endpoints. The response time is typically under 100ms due to caching.
Scenario 1: Multi-Tier Application with Internal Service Discovery
A company runs a microservices-based application across multiple VPCs in the same AWS account. Each service needs to discover other services by name, e.g., api.internal.example.com resolves to an internal ALB. They create a single PHZ for internal.example.com and associate all application VPCs. Each service's deployment script automatically creates or updates an A record pointing to the service's private IP or ALB DNS name. This eliminates the need for hardcoded IPs or a separate service registry. At scale, with hundreds of records, the default limit of 10,000 records per zone may be reached. The company then requests a service quota increase or splits services into multiple zones (e.g., us-east-1.internal.example.com). A common misconfiguration is forgetting to associate a new VPC, causing DNS failures for services in that VPC.
Scenario 2: Hybrid DNS with On-Premises Integration
An enterprise uses AWS Direct Connect to connect its on-premises data center to multiple VPCs. On-premises servers need to resolve DNS names for EC2 instances using private IPs. They set up a Route 53 Resolver inbound endpoint in a shared VPC and associate the PHZ with that VPC. On-premises DNS servers forward queries for internal.example.com to the inbound endpoint's IP addresses. This allows seamless name resolution across environments. However, if the PHZ is not associated with the VPC where the inbound endpoint resides, queries from on-premises will fail. Additionally, the on-premises DNS servers must have network connectivity to the inbound endpoint's IPs (which are in the VPC's CIDR). Performance considerations include DNS query latency over Direct Connect (typically 5-10ms) and caching TTLs.
Scenario 3: Split-Brain DNS for Active Directory
A company uses AWS Managed Microsoft AD and wants to use the same domain name (corp.example.com) both on-premises and in AWS. They create a PHZ for corp.example.com in AWS and associate it with their VPC. The on-premises AD DNS servers are authoritative for the same domain. To avoid conflicts, they configure Route 53 Resolver conditional forwarding: queries for corp.example.com from the VPC are forwarded to the on-premises DNS servers, while the PHZ handles records that only exist in AWS (e.g., EC2 instances). This split-brain setup requires careful management to ensure that records are not duplicated. Misconfiguration can lead to DNS loops or incorrect IP resolution. The exam tests understanding that a PHZ can override public DNS for a domain within the VPC, but it does not affect public DNS resolution outside the VPC.
The SOA-C02 exam tests Private Hosted Zones under Objective 5.2 (Implement and manage DNS services). Expect 2-3 questions directly on PHZs, plus hybrid scenarios involving Route 53 Resolver. Key areas:
Objective codes: 5.2.1 (Configure private hosted zones), 5.2.2 (Manage DNS resolution across VPCs and on-premises).
Common wrong answers: 1. "Private hosted zones are automatically resolvable from all VPCs in the same account." — Wrong. Association is required per VPC. 2. "You can use a private hosted zone to resolve public domain names from the internet." — Wrong. PHZs are not publicly resolvable. 3. "Associating a VPC with a private hosted zone automatically enables DNS resolution for all instances in that VPC." — Partially true, but the VPC must also have DNS support enabled. 4. "You can associate a private hosted zone with a VPC in a different region without any additional configuration." — True, but candidates often think it's region-restricted.
Specific values to memorize:
Default TTL: 300 seconds for records, 900 seconds for SOA, 172800 seconds for NS.
Maximum records per zone: 10,000 (default quota).
Maximum VPC associations per zone: 100.
VPC DNS attributes: enableDnsSupport and enableDnsHostnames must be true.
Edge cases:
Overlapping names: If multiple PHZs have the same domain and are associated with the same VPC, the most specific (longest prefix) wins. If equal, Route 53 returns records from one of them (non-deterministic).
Split-brain DNS: Using a PHZ for a public domain overrides public DNS only within associated VPCs. The exam may ask about the impact on public resolution.
Deleting a PHZ: Must delete all records except SOA and NS first.
Elimination strategy: If an answer says "automatically" regarding cross-VPC resolution, it's likely wrong. Look for "explicit association" language. If the question involves on-premises, look for Route 53 Resolver endpoints.
A Private Hosted Zone (PHZ) is a DNS namespace resolvable only from specified VPCs.
Each VPC must be explicitly associated with the PHZ; association is not automatic.
The VPC must have enableDnsSupport and enableDnsHostnames set to true.
Default TTL for records is 300 seconds; SOA TTL is 900 seconds; NS TTL is 172800 seconds.
Maximum records per zone: 10,000; maximum VPC associations per zone: 100.
Alias records in a PHZ can only point to resources with private IP addresses.
To delete a PHZ, you must first delete all resource record sets except SOA and NS.
PHZs support split-brain DNS: they can override public DNS for the same domain within the VPC.
These come up on the exam all the time. Here's how to tell them apart.
Public Hosted Zone
Resolvable from the internet by anyone.
Used for publicly accessible services like websites.
Requires a registered domain name.
NS and SOA records are publicly visible.
Cannot be associated with VPCs for internal resolution.
Private Hosted Zone
Resolvable only from associated VPCs.
Used for internal services like databases, microservices.
Can use any domain name, including unregistered ones.
NS and SOA records are not publicly visible.
Must be associated with at least one VPC to be functional.
Mistake
Private hosted zones are automatically accessible from all VPCs in the same AWS account.
Correct
False. Each VPC must be explicitly associated with the private hosted zone. Association does not happen automatically.
Mistake
You can use a private hosted zone to resolve domain names from the internet.
Correct
False. Private hosted zones are only resolvable from within the associated VPCs. They are not accessible from the internet.
Mistake
A VPC can be associated with only one private hosted zone.
Correct
False. A VPC can be associated with up to 100 private hosted zones. However, overlapping names can cause conflicts.
Mistake
Private hosted zones support alias records pointing to any AWS resource.
Correct
Alias records in private zones can only point to resources that have private IP addresses, such as internal load balancers. They cannot point to public resources like CloudFront or S3.
Mistake
Deleting a private hosted zone is straightforward and can be done anytime.
Correct
You must delete all resource record sets except the default SOA and NS records before you can delete the zone.
Reveal each answer, then mark whether you got it right. Score 60%+ to unlock the next chapter.
Yes, you can associate a private hosted zone with a VPC in a different account using cross-account association. The owner of the VPC must authorize the association, and you must specify the VPC ID and region when creating or updating the zone. This is commonly used in multi-account architectures where a central DNS zone is shared across accounts.
This creates a split-brain DNS scenario. Within the associated VPC, the private hosted zone takes precedence for the domain. Queries from inside the VPC will resolve using the private zone records. Outside the VPC, the public hosted zone is used. This allows you to use the same domain name internally and externally with different IP addresses.
Yes, you can use any domain name, including unregistered ones like 'internal.example.com', as long as it ends with a dot. However, if you use a domain that is publicly registered and you don't own it, you may cause conflicts if you also have a public hosted zone for that domain. AWS does not validate ownership for private zones.
You need to set up Route 53 Resolver inbound endpoints in your VPC. These endpoints provide DNS resolvers on the VPC network that on-premises DNS servers can forward queries to. The private hosted zone must be associated with that VPC. Then configure your on-premises DNS servers to forward queries for the private domain to the inbound endpoint IP addresses.
A private hosted zone is a DNS namespace that you manage directly in Route 53, containing resource records for your domain. A Resolver rule is a forwarding rule that tells the Route 53 Resolver to forward queries for a specific domain to another DNS resolver (e.g., on-premises). They serve different purposes: PHZs host your DNS data; Resolver rules control query routing.
Yes, you can use a private hosted zone for service discovery with ECS. ECS tasks can register their private IP addresses as A records in a PHZ. Other tasks can then resolve the service name to the IP. This is an alternative to AWS Cloud Map. You need to ensure the VPC is associated with the PHZ and that tasks have the necessary IAM permissions to update records.
AWS charges $0.50 per month per private hosted zone (for the first 25 zones). There is no charge for DNS queries within the VPC. However, if you use Route 53 Resolver endpoints, there are additional hourly and data processing charges. Cross-account associations are free.
You've just covered Route 53 Private Hosted Zones — now see how well it sticks with free SOA-C02 practice questions. Full explanations included, no account needed.
Done with this chapter?