How Private DNS Resolution Works in AWS Across Accounts

If you run AWS with multiple accounts, private DNS resolution becomes important very quickly.

Maybe you have a centralized shared services account where networking and DNS are managed for everyone. Or maybe you have a decentralized model where each account owns its own services and DNS. Both patterns are common, and both can work well, but the way private DNS resolution behaves in each design is often misunderstood.

The key to understanding this is simple:

AWS already provides a built-in DNS resolver inside every Virtual Private Cloud.

Once you understand how that resolver works, it becomes much easier to design cross-account private DNS the right way.

Two common multi-account DNS architectures

Let’s start with the two architectures most teams use.

1) Multi-account centralized architecture

In a centralized model, DNS is mostly managed from one shared services account or shared services VPC.

For example:

• Private Hosted Zones (PHZs) live in a shared services account
• Shared networking components also live there
• Other application accounts consume DNS from that central place

This is attractive because it gives you one place to manage private domains, records, and integrations with on-premises DNS.

A typical example looks like this:

• A shared services VPC owns the Private Hosted Zone, such as corp.internal
• That same zone is associated with the shared services VPC
• The zone is also associated with application VPCs in other AWS accounts
• On-premises DNS forwards AWS private domain queries to Route 53 Resolver inbound endpoints
• Route 53 Resolver outbound endpoints are used for forwarding on-premises domain queries back out when needed. You can learn more about Route 53 Failover here.

This model gives you central governance and consistent DNS management.

But it also raises a common question:

How do VPCs in other accounts resolve private names?

The answer is not “by forwarding queries to another VPC.”

The better answer is usually by associating the same Private Hosted Zone with those VPCs.

2) Multi-account decentralized architecture

In a decentralized model, each AWS account owns its own DNS.

That means:

• Each account can manage its own Private Hosted Zones
• Each team controls its own DNS records
• Failures and mistakes are isolated to that account
• Teams can move faster without depending on a central DNS owner

For example:

• Account A has its own PHZ
• Account B has its own PHZ
• Account C has its own PHZ
• A shared services VPC may still exist for hybrid DNS connectivity with on-premises
• PHZs can still be associated across accounts and even across Regions where needed

This model is useful when different teams need independence. It reduces the blast radius because one team’s DNS changes do not automatically affect everyone else.

The tradeoff is that you now have distributed ownership, so you need naming standards and governance to keep things organized.

Before cross-account DNS, understand DNS inside a VPC
This is the part many people skip, but it is the most important one.

Every VPC in AWS comes with an Amazon-provided DNS resolver.

This resolver is available at:

• 169.254.169.253
• fd00:ec2::253
• The base IP address of the VPC CIDR block plus 2

Examples:

• 10.0.0.0/16 → 10.0.0.2
• 172.31.0.0/16 → 172.31.0.2
• 192.168.100.0/24 → 192.168.100.2

That resolver is local to the VPC experience. Instances inside the VPC use it for DNS lookups.

So when an Amazon EC2 instance asks for:

efs.corp.internal

the flow is normally:

Instance → Amazon-provided Route 53 Resolver inside the VPC → DNS answer

That answer might come from:

• a Private Hosted Zone associated with that VPC
• public DNS
• forwarding rules if you configured hybrid DNS

The important idea is this:

Instances do not need to query a DNS server in another VPC just because the record is managed elsewhere.

If the right Private Hosted Zone is associated with the VPC, the query is resolved through the local Amazon-provided resolver.

Where designs go wrong

Historically, many teams tried to solve cross-account private DNS by doing one of these:

• Deploying DNS proxy servers on an Amazon EC2 instance
• Using Active Directory DNS servers as central forwarders
• Forwarding queries between VPCs through Route 53 Resolver endpoints

That works in some cases, especially for hybrid DNS with on-premises, but for AWS-to-AWS private name resolution, it often adds unnecessary complexity.

Why?

Because it turns a local DNS lookup into a network dependency.
Instead of resolving locally inside the VPC, the query has to travel somewhere else first.

That creates extra cost, more moving parts, and more failure scenarios.

The correct architecture for AWS-to-AWS private DNS

For private DNS resolution across AWS accounts, the better design is usually:

Share or associate the Private Hosted Zone with every VPC that needs to resolve it.

For example, imagine this setup:

• Private Hosted Zone: corp.internal
• VPC A in Account A
• VPC B in Account B
• VPC C in Account C
• Shared Services VPC in a networking account

Instead of forwarding corp.internal queries from VPC A to a central resolver endpoint, you associate the same PHZ with:

• VPC A
• VPC B
• VPC C
• Shared Services VPC

Now each VPC resolves the same private records locally.

Query flow now

From an instance in VPC A:

efs.corp.internal

The flow is:

Instance → Amazon DNS Resolver inside VPC A → Private Hosted Zone lookup → Answer returned

Key points of this design: 

• No forwarding.
• No DNS proxy server.
• No centralized DNS hop for AWS-to-AWS lookups.

Why is this better

1) Resolution stays local to the VPC

Each VPC uses its own built-in Route 53 Resolver path.

That means resolution is not dependent on a central DNS forwarding layer for internal AWS private names.

If one part of the environment has trouble, other VPCs are less likely to be affected.

For example:

• If VPC A has a local issue, VPC B can still resolve it using its own resolver path
• You avoid introducing a shared DNS choke point for every private lookup
• You reduce cross-VPC dependency for something as basic as name resolution

This is especially valuable in multi-account environments where resilience matters.

2) It is simpler

A lot of DNS pain comes from unnecessary forwarding chains.

When you use the PHZ association:

• There are fewer components
• There are fewer rules to debug
• There are fewer network paths involved

When something fails, troubleshooting is easier because the question becomes:

“Is the PHZ associated with this VPC, and is the record there?”

That is much easier than tracing forwarding rules across accounts and endpoints.

3) It is cheaper

Resolver endpoints cost money.

If you deploy inbound and outbound endpoints across multiple Availability Zones, the cost adds up fast.

By contrast, associating a Private Hosted Zone with VPCs does not require you to build a resolver-endpoint-based design just for AWS-to-AWS private resolution.

So for many internal AWS use cases, PHZ association is the more cost-effective design.

4) It scales better operationally

If you grow from 3 VPCs to 30, or from 10 accounts to 100, centralized forwarding becomes harder to manage.

You have more:

• rules
• dependencies
• endpoints
• failure domains

PHZ association keeps the design cleaner. The DNS data is shared where needed, and resolution remains local inside each VPC.

When Resolver endpoints still matter

This does not mean Resolver endpoints are useless.

They are still important for hybrid DNS, especially when you need DNS between AWS and on-premises environments.

Examples:

• On-premises DNS forwarding private AWS domain queries into AWS
• AWS forwarding on-premises domain queries back to the enterprise DNS
• Centralized hybrid name resolution patterns

So the rule of thumb is:

• AWS-to-AWS private DNS: prefer PHZ association
• AWS-to-on-premises DNS: Resolver inbound and outbound endpoints are often the right tool

That distinction clears up a lot of confusion.

Why the built-in VPC resolver matters so much

The Amazon-provided DNS resolver is the reason this architecture works so well.

Because every VPC already has a native resolver, AWS can let workloads in that VPC resolve records from any Private Hosted Zone associated with it.

That means you do not need to “send DNS traffic” to wherever the zone was created.

This is a big conceptual shift for beginners.

Many people assume:

“The hosted zone lives in another account, so my query must go there.”

But that is not how it works from the workload’s point of view.

What matters is not where the PHZ was created.

What matters is whether the PHZ is associated with the VPC that is making the query.

Once it is associated, workloads in that VPC can resolve the records using the built-in resolver.

That is why private DNS works smoothly in some designs and fails in others.

Centralized vs decentralized: which is better?

There is no single answer. It depends on how your organization works.

A centralized model is better when:

• You want strong governance
• A central networking team owns DNS
• You want one place to manage shared private namespaces

A decentralized model is better when:

• Teams need autonomy
• Accounts own their own services end-to-end
• You want to reduce blast radius and team dependencies

In both models, the same DNS principle still applies:

Do not force AWS-to-AWS private DNS through central forwarding if PHZ association can solve it more directly.

Final takeaway

The recommended approach in most cases :

Private DNS resolution in AWS works best when each VPC resolves names locally using its built-in Route 53 Resolver, with the required Private Hosted Zones associated directly to that VPC.

That design is usually simpler, cheaper, and more resilient than pushing every query through centralized DNS forwarders.

AWS already gives you a DNS resolver in every VPC. The smartest design is usually the one that takes advantage of it.

And in multi-account AWS, that often means sharing the zone, not forwarding the query.