Private hosted zones don't require Resolver endpoints

I create a Route 53 private hosted zone:

prod.aws.internal.bfstore.example

I associate it with the bfstore production VPC.

I add a record:

otel.prod.aws.internal.bfstore.example
    → 10.96.12.45

Then I notice Route 53 VPC Resolver has separate pages for:

• inbound endpoints
• outbound endpoints
• forwarding rules

The natural conclusion is:

Private hosted zone
        │
        ▼
Needs VPC Resolver endpoints
        │
        ▼
Otherwise no private DNS

That conclusion is wrong.

Every VPC already has access to Route 53 VPC Resolver, also called AmazonProvidedDNS. The resolver is available by default and answers queries for public records, AWS-provided VPC names and Route 53 private hosted zones associated with that VPC.

A workload inside the associated production VPC can therefore resolve the private record without bfstore creating a VPC Resolver inbound or outbound endpoint.

PRODUCTION WORKLOAD
        │
        ▼
AmazonProvidedDNS
        │
        ▼
ASSOCIATED PRIVATE HOSTED ZONE
        │
        ▼
PRIVATE RECORD

VPC Resolver endpoints do not make private hosted zones work inside VPCs that already receive the zone. They extend DNS resolution across boundaries that the built-in VPC resolver cannot cross by itself.

The private hosted zone provides the records.

The VPC association determines which resolver view receives them.

AmazonProvidedDNS answers the query.

That is already a complete private DNS path.

The resolver was already inside the VPC

A VPC can reach AmazonProvidedDNS through several addresses:

• the primary VPC IPv4 CIDR plus two
• 169.254.169.253
• fd00:ec2::253

For a VPC using:

10.80.0.0/16

the familiar resolver address is:

10.80.0.2

This is not an EC2-based DNS server that bfstore must deploy, patch or place in a subnet. Route 53 VPC Resolver is built into each Availability Zone and uses managed local and zonal resolver components behind those addresses.

The ordinary resolution path is:

APPLICATION
    │
    ▼
OPERATING-SYSTEM RESOLVER
    │
    ▼
AmazonProvidedDNS
    │
    ├── VPC-specific AWS names
    ├── associated private hosted zones
    └── public recursive DNS

The private hosted zone does not need to be connected to this resolver through an endpoint.

The private hosted-zone relationship with the VPC is the connection, whether it is created directly or supplied through a Route 53 Profile.

When Route 53 VPC Resolver receives a query, it evaluates the private hosted zones available to the source VPC through direct associations and Route 53 Profiles. If the most specific matching zone contains the requested record, it returns the private answer through AWS’s internal DNS infrastructure. It does not query the visible private-zone name servers over the public internet.

A VPC association is the ordinary requirement

A private hosted zone is useful to a VPC when the VPC receives that zone.

For a small environment, this is usually a direct hosted-zone-to-VPC association.

Suppose bfstore creates:

platform.aws.internal.bfstore.example

and associates it directly with:

• bfstore-dev
• bfstore-staging
• bfstore-prod
• bfstore-shared-services

Workloads in those VPCs can resolve records from the zone through their ordinary AmazonProvidedDNS path.

PRIVATE HOSTED ZONE
platform.aws.internal.bfstore.example
              │
              ├── dev VPC
              ├── staging VPC
              ├── production VPC
              └── shared-services VPC

At larger scale, Route 53 Profiles can carry private hosted zones, Resolver rules and related DNS configuration to associated VPCs.

PRIVATE HOSTED ZONE
        │
        ▼
ROUTE 53 PROFILE
        │
        ├── VPC A
        ├── VPC B
        └── VPC C

The relationship with the VPC is still what makes the private namespace visible.

The relationship is simply managed through a Profile rather than through an individual hosted-zone association.

The required VPC DNS attributes must also be enabled:

enable_dns_support: true
enable_dns_hostnames: true

AWS requires both attributes for private hosted-zone use.

No VPC Resolver inbound endpoint is needed because the query already originates inside a VPC that receives the zone.

No VPC Resolver outbound endpoint is needed because the answer already belongs to Route 53.

The minimum working design is:

private hosted zone
+
records
+
direct VPC association
or Route 53 Profile association
+
VPC DNS attributes
+
client using AmazonProvidedDNS

VPC Resolver endpoints enter when a query must move between VPC Resolver and another connected resolver environment.

Route 53 Global Resolver provides a separate authorised path for clients outside those VPCs.

Neither mechanism is required for ordinary private hosted-zone resolution inside a VPC that already receives the zone.

A matching private zone prevents public fallback

A private hosted-zone association creates an authoritative private view for that namespace.

Suppose a VPC receives:

example.com

as a private hosted zone.

A workload asks for:

missing.example.com

VPC Resolver selects the most specific matching private hosted zone.

Then it asks:

Does this zone contain
the requested name and record type?

PRIVATE ZONE MATCHES NAME
        │
        ▼
REQUESTED RECORD EXISTS?
        │
    ┌───┴───┐
    │       │
   YES      NO
    │       │
    ▼       ▼
 ANSWER   NXDOMAIN

If the record is missing, VPC Resolver returns NXDOMAIN.

It does not continue to a less-specific private zone or the public example.com zone in search of another answer.

The private zone is therefore not a partial overlay placed on top of public DNS.

Its association says:

For this resolver view,
Route 53 private DNS owns
this namespace.

That behaviour should be tested whenever bfstore creates private zones that overlap public names.

Inbound endpoints let connected-network resolvers ask VPC Resolver

A VPC Resolver inbound endpoint provides IP addresses inside a VPC to which a resolver on a connected network can send queries.

Typical callers include:

• an on-premises DNS server;
• a resolver in another privately connected environment;
• a central DNS service outside the VPC Resolver context;
• a future Azure or GCP DNS forwarding tier connected to AWS.

The flow becomes:

CONNECTED-NETWORK CLIENT
        │
        ▼
EXTERNAL DNS RESOLVER
        │
        ▼
VPC RESOLVER
INBOUND ENDPOINT
        │
        ▼
ROUTE 53 VPC RESOLVER
        │
        ▼
PRIVATE HOSTED ZONE

AWS describes inbound endpoints as a way for resolvers on another connected network to forward queries into Route 53 VPC Resolver.

Creating the endpoint does not change how VPC Resolver behaves for workloads inside the VPC.

It provides a supported entrance from outside the normal VPC resolver boundary.

For the inbound endpoint to answer using a private hosted zone, that hosted zone must be associated with the endpoint VPC directly or supplied through a Route 53 Profile associated with that VPC.

bfstore currently has no on-premises data centre.

A workload in bfstore-prod does not need an inbound endpoint to resolve a zone already available to bfstore-prod.

An inbound endpoint would become useful later if, for example:

Azure workload
      │
      ▼
Azure DNS forwarder
      │
      ▼
private network connection
      │
      ▼
AWS VPC Resolver
inbound endpoint
      │
      ▼
platform.aws.internal.bfstore.example

That is a cross-network DNS requirement.

It is not part of the basic private hosted-zone requirement.

Global Resolver provides a separate external path

Route 53 Global Resolver provides another way for authorised clients outside the associated VPCs to resolve configured DNS views.

It uses internet-reachable anycast resolver addresses and supports ordinary DNS, DNS over HTTPS and DNS over TLS.

Conceptually:

AUTHORISED EXTERNAL CLIENT
        │
        ▼
ROUTE 53 GLOBAL RESOLVER
        │
        ▼
CONFIGURED DNS VIEW
        │
        ▼
PRIVATE HOSTED ZONE

This is different from a VPC Resolver inbound endpoint.

VPC RESOLVER INBOUND ENDPOINT

private network path
resolver-to-resolver forwarding
endpoint IP addresses inside a VPC


GLOBAL RESOLVER

authorised client access
internet-reachable anycast service
configured external DNS view

The two models solve different access problems.

Neither is needed when the client already runs inside a VPC that receives the private hosted zone and uses AmazonProvidedDNS.

The updated principle is:

VPC Resolver endpoints bridge DNS between VPC Resolver and another connected resolver environment. Route 53 Global Resolver provides a separate authorised anycast path for clients outside those VPCs. Neither is a prerequisite for ordinary private DNS inside a VPC that already receives the zone.

Outbound endpoints let AWS ask another DNS system

A VPC Resolver outbound endpoint solves the opposite problem.

A workload in an AWS VPC asks for a name whose authority exists somewhere else.

Examples might include:

idp.external.internal

corp.example

services.azure.internal

legacy.partner.internal

A VPC Resolver forwarding rule identifies the namespace and the external DNS servers that should receive matching queries.

AWS WORKLOAD
     │
     ▼
AmazonProvidedDNS
     │
     ▼
VPC RESOLVER
FORWARDING RULE
     │
     ▼
VPC RESOLVER
OUTBOUND ENDPOINT
     │
     ▼
EXTERNAL DNS SERVER

The outbound endpoint is therefore needed when:

The question originates in AWS,
but another DNS system owns the answer.

It is not needed when Route 53 already owns the answer in a private hosted zone available to the source VPC.

This gives me a compact distinction:

An outbound endpoint cannot improve a private hosted zone by forwarding the query away from Route 53.

In fact, a forwarding rule for the same namespace takes precedence over the private hosted zone, causing the query to be sent to the configured external resolver instead.

That is less an enhancement and more a DNS plot twist.

Transit Gateway still does not make endpoints mandatory

Suppose bfstore-prod and bfstore-observability are connected through Transit Gateway.

The observability account owns:

observability.aws.internal.bfstore.example

The ordinary AWS-to-AWS design is to make that zone available to the production VPC.

Associate the production VPC directly

PRIVATE HOSTED ZONE
        │
        ├── observability VPC
        └── production VPC

The production workload queries its own AmazonProvidedDNS path.

No VPC Resolver endpoint is required.

Apply the zone through a Route 53 Profile

At larger scale, bfstore may place the private hosted zone in a Profile and associate that Profile with the production VPC.

PRIVATE HOSTED ZONE
        │
        ▼
ROUTE 53 PROFILE
        │
        ├── observability VPC
        └── production VPC

The workload still queries its own VPC Resolver.

The Profile centralises DNS configuration management without hairpinning the query through another VPC.

Use a central inbound endpoint for external resolvers

A central inbound endpoint remains useful when an on-premises or other connected external resolver needs to query AWS private names.

ON-PREMISES OR OTHER
CONNECTED DNS RESOLVER
        │
        ▼
CENTRAL VPC RESOLVER
INBOUND ENDPOINT
        │
        ▼
PRIVATE HOSTED ZONES
AVAILABLE TO ENDPOINT VPC

AWS spoke VPCs should not normally forward their Route 53 private-zone queries through an outbound endpoint and back into a central inbound endpoint merely to centralise resolution.

That pattern adds:

• endpoint cost;
• query-processing cost;
• additional latency;
• more routing and security dependencies;
• forwarding-loop risk.

Direct associations or Route 53 Profiles preserve the native VPC Resolver path.

Transit Gateway provides IP routing between VPCs.

It does not distribute private hosted-zone relationships automatically, and it does not make VPC Resolver endpoints mandatory.

The presence of Transit Gateway answers:

Can the packet reach another network?

It does not answer:

Which resolver view owns this name?

Custom DNS changes the first hop

A VPC may use custom DNS servers through its DHCP option set.

For example:

APPLICATION
    │
    ▼
BFSTORE-MANAGED DNS SERVER
    │
    ├── internal enterprise zones
    └── AWS private zones

The application now asks the custom server first rather than AmazonProvidedDNS directly.

To resolve private hosted-zone records, that custom DNS server must send those queries back to the Amazon-provided resolver for the VPC. AWS documents forwarding such private queries to the VPC CIDR-plus-two resolver address when the custom DNS server runs inside the VPC.

That still does not automatically require a VPC Resolver endpoint.

The location of the custom server matters.

Custom DNS server inside the VPC

It can forward appropriate queries to the VPC’s AmazonProvidedDNS address.

DNS server outside the VPC

It should use a VPC Resolver inbound endpoint rather than attempting to query the VPC-plus-two address directly.

The endpoint is required because the external resolver needs a supported entrance into VPC Resolver.

The private hosted zone itself did not suddenly develop an endpoint dependency.

The client’s resolver path crossed a network boundary.

Endpoints introduce infrastructure of their own

A VPC Resolver endpoint is not a free logical switch.

AWS creates endpoint network interfaces in selected subnets.

An endpoint requires at least two IP addresses in different Availability Zones, and security groups must permit the required DNS traffic.

An endpoint therefore introduces:

• subnet addresses;
• network interfaces;
• security groups;
• routing requirements;
• endpoint IP capacity;
• per-IP query capacity;
• zonal placement;
• monitoring;
• hourly and query-processing cost;
• forwarding-rule lifecycle;
• possible DNS loops.

Each endpoint IP address contributes to the hourly charge.

AWS specifically warns against configurations in which an outbound rule forwards queries towards an inbound endpoint in a way that continually passes the query between the endpoints.

Hairpinning ordinary AWS spoke-VPC private-zone queries through outbound and inbound endpoints can create a similar collection of cost, latency and operational risk without improving the native association model.

Deploying endpoints before they have a real forwarding purpose creates infrastructure that can fail, cost money and confuse future engineers while changing nothing about ordinary private hosted-zone resolution.

The preferred rule is wonderfully plain:

Do not create a VPC Resolver endpoint until a DNS query genuinely needs to cross between VPC Resolver and another connected resolver environment.

The bfstore design today

For bfstore’s current AWS-only stage, I would begin with direct private hosted-zone associations.

private_dns:
  resolver:
    type: AmazonProvidedDNS

  hosted_zones:
    - name: prod.aws.internal.bfstore.example
      associated_vpcs:
        - bfstore-prod
        - bfstore-observability

    - name: nonprod.aws.internal.bfstore.example
      associated_vpcs:
        - bfstore-dev
        - bfstore-staging

    - name: platform.aws.internal.bfstore.example
      associated_vpcs:
        - bfstore-dev
        - bfstore-staging
        - bfstore-prod
        - bfstore-shared-services

  route53_profiles:
    current_use: none
    revisit_when:
      - repeated-cross-account-associations
      - shared-resolver-rules
      - many-vpc-dns-baselines

  vpc_resolver_endpoints:
    inbound: none
    outbound: none

  global_resolver:
    enabled: false

  query_logging:
    enabled: true

This provides:

• private service names;
• environment-specific namespace views;
• no unnecessary hybrid DNS infrastructure;
• normal resolution through AmazonProvidedDNS;
• a clear path to Profiles when association management becomes repetitive.

Because bfstore’s zones and VPCs may belong to different AWS accounts, direct association requires a two-step process.

HOSTED-ZONE OWNER

authorises the VPC association
        │
        ▼
VPC OWNER

creates the association
through API, SDK or CLI

The console does not complete the direct cross-account association workflow.

A Route 53 Profile may become simpler when the same zones, rules and DNS configuration must be applied repeatedly across many member accounts.

VPC Resolver query logging should also be enabled.

Those logs provide evidence about queries that reach VPC Resolver, but they do not record every lookup performed by every application. Repeated queries answered from resolver cache are not logged as repeated upstream queries.

I would introduce external-resolution mechanisms only when a concrete requirement appears.

Add a VPC Resolver inbound endpoint when

• an on-premises resolver must query AWS private names over private connectivity;
• another cloud’s DNS forwarding tier must resolve bfstore AWS services through a connected network;
• a central resolver outside the associated VPCs must ask VPC Resolver for private records.

Add a VPC Resolver outbound endpoint when

• AWS workloads must resolve private names owned by an external DNS system;
• bfstore needs conditional forwarding to an identity, partner or another-cloud namespace.

Add both when

bfstore develops a genuine bidirectional hybrid DNS architecture.

AWS PRIVATE NAMES
        ▲
        │ inbound
        │
EXTERNAL DNS ENVIRONMENT
        │
        │ outbound
        ▼
EXTERNAL PRIVATE NAMES

Add Global Resolver when

• authorised clients outside the associated VPCs need a managed anycast DNS path;
• internet-reachable Do53, DoH or DoT access fits the security and client model;
• a VPC-based inbound endpoint and private network forwarding path are not the intended design.

The endpoints and Global Resolver follow the external DNS relationship.

They do not precede it.

The mental model I am keeping

My earlier model was:

PRIVATE HOSTED ZONE
        │
        ▼
RESOLVER ENDPOINTS
        │
        ▼
PRIVATE DNS WORKS

The stronger model is:

                 PRIVATE HOSTED ZONE
                           │
                           ▼
               DIRECT VPC ASSOCIATION
                 OR ROUTE 53 PROFILE
                           │
                           ▼
                   AmazonProvidedDNS
                           │
                           ▼
                     VPC WORKLOAD
                           │
              PRIVATE DNS ALREADY WORKS
                           │
                           ▼
              DOES THE QUERY ORIGINATE
              IN A VPC THAT RECEIVES
                  THE PRIVATE ZONE?
                           │
                     ┌─────┴─────┐
                     │           │
                    YES          NO
                     │           │
                     ▼           ▼
              VPC RESOLVER    WHICH EXTERNAL
              NO ENDPOINT     ACCESS MODEL?
              REQUIRED             │
                           ┌────────┴────────┐
                           │                 │
                           ▼                 ▼
                    CONNECTED DNS       AUTHORISED
                       NETWORK         GLOBAL CLIENT
                           │                 │
                           ▼                 ▼
                    INBOUND ENDPOINT   GLOBAL RESOLVER

The private hosted zone answers:

Which private records
does Route 53 own?

A direct association or Route 53 Profile answers:

Which VPCs receive
that private namespace?

AmazonProvidedDNS answers:

How do workloads inside
those VPCs resolve it?

A VPC Resolver inbound endpoint answers:

How can a resolver on
a connected network ask VPC Resolver?

A VPC Resolver outbound endpoint answers:

How can VPC Resolver forward
a question to another DNS authority?

Route 53 Global Resolver answers:

How can an authorised external client
use a managed anycast resolver path?

And the absence of all three external mechanisms answers:

Are all current questions already
being asked and answered inside
VPCs that receive the zone?

For bfstore today, the answer is yes.

The private hosted zones can be associated directly with the VPCs that consume them.

Those VPCs already have AmazonProvidedDNS.

The records will resolve without inbound endpoints, outbound endpoints or a small ceremonial DNS estate waiting for an on-premises network that does not exist.

Private hosted zones are native VPC DNS. VPC Resolver endpoints and Global Resolver are different bridges for clients outside that native resolver view.

Build the private namespace now.

Associate it deliberately, directly or through a Profile.

Enable VPC Resolver query logging while accounting for resolver caching.

Add the bridges when another shore finally appears.

References and further reading

• Route 53 VPC Resolver Describes the built-in VPC Resolver and distinguishes it from Route 53 Global Resolver.

• Working with private hosted zones Explains how private hosted zones, records, VPC relationships and VPC Resolver work together.

• Private hosted-zone considerations Covers VPC DNS attributes, private-zone precedence, NXDOMAIN behaviour and forwarding-rule precedence.

• Associating private hosted zones with VPCs Documents direct and cross-account VPC association workflows.

• Associating private hosted zones with Route 53 Profiles Explains how Profiles can distribute private hosted zones and related DNS configuration across VPCs.

• Route 53 Global Resolver announcement Introduces the authorised anycast resolver path for clients outside associated VPCs.

• Forwarding queries from another network into AWS Explains VPC Resolver inbound endpoints and connected-network forwarding.

• Choosing a VPC for Resolver endpoints Covers endpoint placement, private hosted-zone availability and the multi-AZ IP requirement.

• Scaling DNS management across accounts and VPCs Explains why private hosted zones should normally be associated with consuming VPCs rather than hairpinned through outbound and inbound endpoints.

• VPC Resolver query logging Documents query evidence and the effect of resolver caching on logged queries.

• Avoiding Resolver endpoint loops Describes forwarding configurations that can circulate queries between endpoints.