Route 53 Resolver endpoints: when you actually need them

bfstore has several Route 53 private hosted zones.

Production workloads can resolve:

otel.prod.aws.internal.bfstore.example

modules.platform.aws.internal.bfstore.example

orders.prod.aws.internal.bfstore.example

The VPCs use AmazonProvidedDNS. Their DNS attributes are enabled, and the appropriate private hosted zones are associated with them.

Private DNS already works.

BFSTORE WORKLOAD
       │
       ▼
AmazonProvidedDNS
       │
       ▼
ASSOCIATED PRIVATE HOSTED ZONE
       │
       ▼
PRIVATE ANSWER

No Resolver endpoint is required.

Then bfstore begins its Azure implementation.

An Azure-hosted platform component needs to resolve:

modules.platform.aws.internal.bfstore.example

AWS workloads also need to resolve:

registry.platform.azure.internal.bfstore.example

The DNS questions now cross between two resolver environments.

AZURE DNS
    │
    │ asks for an AWS-private name
    ▼
AWS DNS


AWS DNS
    │
    │ asks for an Azure-private name
    ▼
AZURE DNS

This is where Route 53 Resolver endpoints become useful.

Route 53 VPC Resolver is available by default in every VPC. It answers public records, VPC-specific names and associated private hosted zones. Resolver endpoints extend that service so DNS queries can cross between VPC Resolver and resolvers on another connected network.

Resolver endpoints are DNS bridges. They become necessary when the question or answer lives on the other side of a resolver boundary.

An inbound endpoint carries questions into AWS.

An outbound endpoint carries selected questions away from AWS.

A forwarding or delegation rule decides which names should take the outbound bridge.

That is the architecture in one paragraph.

The rest is deciding where the bridges belong, who may use them and how to stop them quietly forwarding questions in circles.

Start with the authority, not the endpoint

Before creating an endpoint, I need to know which DNS system owns each namespace.

Suppose bfstore eventually has:

AWS Route 53

aws.internal.bfstore.example

Azure private DNS

azure.internal.bfstore.example

GCP Cloud DNS

gcp.internal.bfstore.example

External identity platform

id.internal.bfstore.example

The DNS architecture should answer three questions:

Which resolver receives
the client query first?


Which DNS system is authoritative
for the requested namespace?


How does the first resolver
reach that authority?

A Resolver endpoint is useful only when the answer to the final question crosses an AWS network boundary.

If an AWS workload queries a private hosted zone associated with its VPC, Route 53 already owns and can answer the name.

AWS CLIENT
    │
    ▼
AmazonProvidedDNS
    │
    ▼
AWS PRIVATE HOSTED ZONE

No endpoint is needed.

If an external resolver needs the AWS answer:

EXTERNAL CLIENT
    │
    ▼
EXTERNAL RESOLVER
    │
    ▼
AWS INBOUND ENDPOINT
    │
    ▼
AWS PRIVATE HOSTED ZONE

An inbound endpoint is needed.

If an AWS client needs an externally owned answer:

AWS CLIENT
    │
    ▼
AmazonProvidedDNS
    │
    ▼
OUTBOUND RULE
    │
    ▼
AWS OUTBOUND ENDPOINT
    │
    ▼
EXTERNAL DNS AUTHORITY

An outbound endpoint is needed.

The endpoint follows the authority relationship.

It should not be deployed first and assigned a purpose afterwards.

Inbound: another network asks AWS

An inbound Resolver endpoint creates private IP addresses inside an AWS VPC. AWS creates a managed network interface for each endpoint address.

DNS resolvers on another connected network send queries to those addresses. VPC Resolver then answers using the DNS context available to the endpoint VPC, including private hosted zones associated with that VPC.

OTHER NETWORK
      │
      ▼
EXTERNAL DNS RESOLVER
      │
      │ conditional forward
      ▼
INBOUND ENDPOINT IP ADDRESSES
      │
      ▼
ROUTE 53 VPC RESOLVER
      │
      ▼
AWS-PRIVATE DNS ANSWER

A practical enterprise resolver configuration might be:

aws.internal.bfstore.example
    → 10.112.10.25
    → 10.112.11.25

Those two addresses belong to an inbound endpoint in two Availability Zones.

When the external resolver receives:

orders.prod.aws.internal.bfstore.example

it forwards the query to one of the endpoint addresses. VPC Resolver finds the matching private hosted zone and returns the record.

The external client can use the returned address only if a separate network route and security policy allow it.

INBOUND ENDPOINT

external DNS
    → AWS DNS


VPN, DIRECT CONNECT
OR OTHER NETWORK PATH

external client
    → returned AWS address

The endpoint provides DNS reachability.

It does not provide application reachability.

The endpoint is a narrow service boundary

An inbound endpoint accepts DNS queries. It is not a router into the endpoint VPC and does not grant access to:

application subnets;
Kubernetes Pods;
databases;
arbitrary VPC addresses;
AWS control-plane APIs.

EXTERNAL RESOLVER
        │
        ▼
DNS QUERY ONLY
        │
        ▼
INBOUND ENDPOINT
        │
        ▼
ROUTE 53 RESOLVER

The endpoint security group determines which source resolvers and protocols may reach it.

The associated private hosted zones determine which private answers VPC Resolver can provide.

The returned destination is governed separately.

This is a service-shaped boundary:

The external network may ask
approved DNS questions.

It does not join the AWS VPC
because those questions receive answers.

The inbound endpoint sees its VPC’s DNS view

An inbound endpoint does not automatically see every private hosted zone in every AWS account.

Suppose the endpoint lives in:

bfstore-dns-hub VPC

but the production zone is associated only with:

bfstore-prod VPC

An external query entering through the DNS hub does not inherit the production VPC’s zone association. The DNS hub also needs an appropriate association or shared DNS configuration.

PRIVATE HOSTED ZONE
prod.aws.internal.bfstore.example
          │
          ├── bfstore-prod VPC
          └── bfstore-dns-hub VPC

That association is also an audience decision. External resolver populations reaching the hub may be able to resolve records from the associated zone, subject to the forwarding and access design.

Zone associations should therefore express intended visibility, not merely make troubleshooting easier.

Outbound: AWS asks another authority

An outbound Resolver endpoint handles the opposite direction.

An AWS workload sends its normal query to AmazonProvidedDNS. VPC Resolver compares the queried name with its rules. When a matching forwarding rule exists, Resolver sends the query through the outbound endpoint to the configured target DNS servers.

AWS WORKLOAD
      │
      ▼
AmazonProvidedDNS
      │
      ▼
MATCHING RESOLVER RULE
      │
      ▼
OUTBOUND ENDPOINT
      │
      ▼
EXTERNAL DNS SERVER
      │
      ▼
EXTERNAL PRIVATE ZONE

Suppose bfstore’s Azure DNS environment owns:

azure.internal.bfstore.example

The AWS network account creates a forwarding rule:

rule:
  name: azure-private-dns
  type: FORWARD
  domain: azure.internal.bfstore.example

  targets:
    - ip: 10.160.10.53
      port: 53

    - ip: 10.160.11.53
      port: 53

The rule is associated with the VPCs whose workloads need that namespace.

A production Pod asks AmazonProvidedDNS for:

registry.platform.azure.internal.bfstore.example

Resolver finds the matching rule and sends the query through the outbound endpoint. The Azure-side resolver answers, and the result returns through VPC Resolver to the Pod.

The Pod continues using the resolver it always used. It does not need to know the addresses of the Azure DNS servers.

APPLICATION

asks for a name

ROUTE 53 RESOLVER

chooses the authority

OUTBOUND ENDPOINT

carries the question

Outbound rules decide which authority wins

An outbound endpoint does not forward every DNS query automatically.

Resolver rules determine which namespaces use it.

A rule can forward:

id.internal.bfstore.example

without forwarding:

aws.internal.bfstore.example

or ordinary public DNS.

QUERY

login.id.internal.bfstore.example
        │
        ▼
MATCHING RULE
        │
        ▼
OUTBOUND ENDPOINT


QUERY

orders.prod.aws.internal.bfstore.example
        │
        ▼
NO EXTERNAL RULE
        │
        ▼
ROUTE 53 PRIVATE HOSTED ZONE

When several rules match, Route 53 uses the rule containing the most-specific domain name. A rule for:

platform.azure.internal.bfstore.example

therefore takes precedence over:

azure.internal.bfstore.example

That resembles longest-prefix routing, except DNS labels rather than address bits determine the most-specific match.

The rule set should be reviewed as a routing table for names.

Forwarding rules can shadow private hosted zones

Suppose a VPC has:

a private hosted zone for corp.example;
a forwarding rule for corp.example.

The forwarding rule takes precedence. Resolver sends the query to the external DNS servers instead of answering it from the private hosted zone.

PRIVATE HOSTED ZONE

corp.example

OUTBOUND FORWARDING RULE

corp.example
    → external DNS

WINNER

outbound forwarding rule

This can be intentional. The external DNS environment may be the authoritative source while the private hosted zone is being retired.

It can also produce a baffling incident:

The record is clearly present
in Route 53.

The client still receives
the external answer.

The record is present. It is simply not on the winning resolution path.

Before creating a forwarding rule, I now ask:

Does a private hosted zone use the same name?
Does an AWS-defined system rule already own part of the namespace?
Will a more-specific subdomain need to remain inside Route 53?
Which VPCs should inherit the external authority?

A DNS forwarding rule is an authority decision. It should receive the same care as a network route.

System rules create deliberate exceptions

A forwarding rule normally applies to its domain and subdomains.

Suppose bfstore forwards:

example.com
    → external DNS

but wants VPC Resolver to use its normal resolution behaviour for:

aws.example.com

A more-specific SYSTEM rule can create that exception.

FORWARD RULE

example.com
    → external DNS


SYSTEM RULE

aws.example.com
    → Route 53 Resolver

This can preserve:

a Route 53 private hosted zone;
AWS-provided private naming;
ordinary recursive behaviour for one branch.

The final answer may therefore depend on:

private hosted zones;
custom forwarding rules;
delegation rules;
custom system rules;
AWS-defined system rules;
the most-specific domain match.

DNS troubleshooting should inspect the complete rule set, not only the record the engineer expected to win.

Forwarding and delegation are different relationships

Conditional forwarding says:

For names beneath this domain,
send the query to these resolver IPs.

DNS delegation says:

These name servers are authoritative
for this child namespace.

Route 53 Resolver supports both models, but they are not interchangeable.

A FORWARD rule redirects matching queries to configured target resolver addresses.

A DELEGATE rule follows the DNS delegation chain. Resolver uses the outbound endpoint only when the delegation configuration matches the NS records returned during resolution. For private-hosted-zone-to-outbound delegation, the private hosted zone must contain the relevant NS records.

FORWARD

domain match
    → configured target resolvers


DELEGATE

DNS response contains matching NS records
    → reach those delegated name servers
      through the outbound endpoint

Inbound delegation is also distinct from ordinary inbound forwarding. It uses a delegation-category inbound endpoint, and the parent DNS environment needs glue NS records pointing at the endpoint addresses. Delegation inbound endpoints currently support Do53 only.

Forwarding is often simpler when integrating existing resolvers whose authority cannot be changed easily.

Delegation can create a cleaner authority model when parent and child namespaces are deliberately divided between teams or environments.

The architectural question is:

Are we telling the resolver
where to forward a question?


Or are we declaring
who owns the child zone?

Both can involve Resolver endpoints.

They express different governance and require different DNS records.

A shared Regional DNS hub

A central DNS design does not normally need one inbound endpoint per private hosted zone or one outbound endpoint per rule.

Within a Region, one inbound endpoint and one outbound endpoint are typically sufficient for their respective directions. Multiple rules can use the same outbound endpoint, and additional capacity can usually be added by adding endpoint addresses rather than creating another endpoint.

ONE INBOUND ENDPOINT
        │
        ├── queries for aws.internal...
        ├── queries for platform.internal...
        └── queries for other approved AWS-private names


ONE OUTBOUND ENDPOINT
        │
        ├── rule for azure.internal...
        ├── rule for gcp.internal...
        └── rule for id.internal...

Separate endpoints may still be justified by different:

security boundaries;
source networks;
protocols;
owning teams;
routing paths;
availability requirements;
Regions.

The default should not be one endpoint per domain.

The endpoint is shared DNS transport. The rules provide namespace-specific routing.

The endpoint VPC becomes an audience and routing boundary

For bfstore, I would evaluate central Resolver endpoints in the bfstore-network account.

A dedicated DNS VPC or carefully designed network-services VPC could host:

BFSTORE-NETWORK ACCOUNT

DNS SERVICES VPC
│
├── inbound endpoint
│   ├── subnet-a
│   └── subnet-b
│
├── outbound endpoint
│   ├── subnet-a
│   └── subnet-b
│
└── external connectivity
    ├── Transit Gateway
    ├── VPN
    └── future cloud connections

The endpoint VPC is not selected merely because it is central. It needs:

private hosted-zone associations for inbound answers;
routes towards external resolvers;
return routes from those resolvers;
suitable subnets in multiple Availability Zones;
security groups permitting the selected protocols;
operational ownership.

A subnet labelled dns does not create connectivity through the force of nominative optimism.

The complete query and response route must exist.

Shared rules centralise outbound behaviour

A central networking account can create outbound Resolver rules and share them with other AWS accounts using AWS Resource Access Manager.

Consuming accounts associate the shared rules with their VPCs. Queries from those VPCs then use the centrally owned outbound endpoint named by the rule.

BFSTORE-NETWORK

outbound endpoint

shared rules:
    azure.internal...
    gcp.internal...
    id.internal...
          │
          ▼
AWS RAM
          │
          ├── bfstore-dev
          ├── bfstore-staging
          ├── bfstore-prod
          └── bfstore-shared-services

This creates a useful platform boundary.

The network team controls:

external target resolvers;
endpoint security;
DNS transport;
common namespace rules.

Workload accounts control:

which shared rules are associated with their VPCs;
which applications use the resulting names;
application access to the resolved services.

A shared rule remains centrally owned. Deleting or unsharing it changes how associated VPCs process matching queries, so its lifecycle is a cross-account production concern.

Resolver endpoints and rules are Regional

A rule created in one Region is not automatically available in another.

EU-WEST-2

inbound endpoint
outbound endpoint
regional rules


EU-CENTRAL-1

inbound endpoint
outbound endpoint
regional rules

A multi-Region design should decide whether:

each Region forwards directly to external resolvers;
one Region acts as a DNS hub;
a hub failure affects other Regions;
authorities and private zones exist in both Regions;
rules and target addresses are kept consistent.

Forwarding every Region through one distant DNS hub may reduce infrastructure while adding latency and a central dependency.

A Regional service should not be made global through wishful arrows.

Operating Resolver endpoints

Availability starts with endpoint addresses

Each endpoint requires at least two IP addresses. AWS recommends placing them in at least two Availability Zones. Each address creates a Resolver-managed network interface.

DNS SERVICES VPC

Availability Zone A
    inbound endpoint ENI
    outbound endpoint ENI


Availability Zone B
    inbound endpoint ENI
    outbound endpoint ENI

External resolvers using an inbound endpoint should be configured with every endpoint address.

The target DNS environment behind an outbound endpoint should also provide multiple healthy resolvers where availability requires it.

AWS OUTBOUND ENDPOINT
        │
        ├── external DNS server A
        └── external DNS server B

Two AWS interfaces forwarding towards one fragile external DNS server still produce one very carefully approached failure domain.

Match security groups to the endpoint protocol

Do53 uses DNS over UDP or TCP. A Do53 endpoint policy should normally account for both transports on port 53 because DNS can fall back to TCP for large or truncated responses and other protocol behaviours.

DO53 INBOUND ENDPOINT

allow UDP/53 and TCP/53
from approved external resolver ranges


DO53 OUTBOUND ENDPOINT

allow UDP/53 and TCP/53
to approved target resolver addresses

DoH uses HTTPS over TCP port 443. DoH-FIPS is supported for inbound endpoints only. Delegation inbound endpoints currently support Do53 only.

DOH INBOUND ENDPOINT

allow TCP/443
from approved external resolver ranges

The exact policy should follow the protocols enabled on the endpoint and supported by the connected resolver.

Encryption does not replace DNS access control. It protects the query in transit. Security groups and resolver configuration still decide who may submit it.

Overly broad rules increase the number of clients capable of using the bridge. Restrictive, connection-tracked security-group paths can also reduce effective endpoint throughput, so security and scaling should be reviewed together.

Address family and DNS transport are separate from the answer

Resolver endpoints can use IPv4, IPv6 or dual-stack addressing. Inbound endpoints can also support DNS64 for IPv6-only clients that need synthesized AAAA answers for IPv4-only destinations, when paired with NAT64.

The design should ask:

Are external resolvers reachable over IPv4, IPv6 or both?
Which address family does the endpoint expose?
Does the network path carry that family?
Do security groups permit it?
Does the returned application path support the address family advertised by DNS?

A dual-stack DNS endpoint does not make an application dual-stack.

It only allows the DNS transport to use both address families.

Prevent forwarding loops

Consider:

VPC Resolver
      │
      ▼
outbound rule
      │
      ▼
external DNS server
      │
      ▼
inbound endpoint
      │
      ▼
VPC Resolver

If the external resolver sends the same namespace back into AWS, and the AWS rule sends it out again, the query begins a circular tour.

AWS asks external

external asks AWS

AWS asks external

external asks AWS

The solution begins with clear authority:

For each namespace,
one resolver path must terminate
at an authority capable of answering it.

The design record should state:

authoritative DNS system;
forwarding origin;
forwarding targets;
permitted return behaviour;
more-specific exceptions;
expected terminal response.

A diagram containing two arrows is not automatically resilient.

Sometimes it is a very tidy loop.

Scale per endpoint address, not per diagram

As of July 2026, AWS documents up to 10,000 UDP DNS queries per second per endpoint IP address under qualifying conditions. Actual capacity depends on query type, response size, latency, target health, protocol and connection tracking. AWS notes that tracked paths can reduce effective capacity substantially.

ENDPOINT

IP address A
    → DNS query capacity

IP address B
    → DNS query capacity

IP address C
    → additional capacity

DNS traffic can be bursty:

workloads restarting after an outage;
short-lived Kubernetes Jobs;
low TTLs on popular names;
an external resolver losing its cache;
repeated negative lookups during a migration;
search-suffix mistakes;
random-name traffic.

Scaling should consider peak query rate per endpoint address, not only average daily volume.

Observe the bridge and the authority behind it

Route 53 Resolver publishes CloudWatch metrics for inbound and outbound endpoints, including endpoint-interface health and query volume. Optional detailed metrics include latency and response outcomes such as SERVFAIL, NXDOMAIN, refusals and timeouts.

Outbound endpoints can also publish target name-server metrics, including request count, latency and timeouts for each target.

A useful bfstore dashboard would show:

INBOUND

queries by endpoint IP
healthy endpoint interfaces
response latency
SERVFAIL
NXDOMAIN
timeouts


OUTBOUND

queries by endpoint IP
target resolver request count
target resolver latency
target resolver timeouts
healthy endpoint interfaces

Resolver query logs can add:

queried name;
source VPC;
source address;
response code;
returned answer.

Application telemetry shows whether failed resolution affected a customer operation.

CLOUDWATCH ENDPOINT METRICS

Is the bridge operating?

QUERY LOGS

Which questions crossed it?

APPLICATION TELEMETRY

What did DNS failure do
to the customer journey?

A healthy endpoint with a misspelled forwarding rule is still a beautifully monitored wrong turn.

Cost and quotas favour shared infrastructure

Resolver endpoint pricing is based on provisioned endpoint addresses and processed DNS queries. Because each endpoint requires at least two addresses, even an idle endpoint has a baseline cost.

Related architecture may also cost money:

VPN;
Transit Gateway;
Direct Connect;
cross-Region traffic;
external resolver infrastructure;
optional detailed CloudWatch metrics;
log storage.

As of July 2026, AWS documents default quotas including:

four Resolver endpoints per account per Region;
six IP addresses per endpoint;
1,000 rules per account per Region;
2,000 associations between rules and VPCs per account per Region;
six target addresses per rule.

Several quotas can be increased.

The intended shape remains:

few shared endpoints

many namespace rules

many VPC associations

The endpoint is transport infrastructure.

The rule is the unit of DNS-routing policy.

The bfstore architecture now

bfstore currently has:

AWS VPCs;
Route 53 private hosted zones;
AmazonProvidedDNS;
no on-premises data centre;
no active Azure or GCP private network;
no external DNS authority requiring conditional forwarding.

The current design remains:

route53_resolver:
  inbound_endpoints: []
  outbound_endpoints: []
  forwarding_rules: []
  delegation_rules: []

Private hosted zones are associated directly with the VPCs that consume them.

That is enough.

BFSTORE AWS TODAY

workload
   → AmazonProvidedDNS
   → associated private hosted zone

Resolver endpoints should be introduced when an external DNS relationship becomes real.

Future AWS-to-Azure or AWS-to-GCP integration

AWS workloads need cloud-private names:

AWS Resolver
    → outbound rule
    → outbound endpoint
    → cloud-side resolver

Cloud workloads need AWS-private names:

cloud-side resolver
    → inbound endpoint
    → AWS Resolver

The design requires both directions only when the DNS relationship is genuinely bidirectional.

External identity platform

An externally hosted identity platform may need to resolve a private AWS service, or AWS may need to resolve a private identity namespace.

The product integration should determine whether private DNS is necessary. A public authenticated endpoint does not require a private Resolver bridge merely because bfstore enjoys network diagrams.

Hybrid enterprise network

An on-premises DNS environment may forward AWS-private names inbound while AWS forwards corporate domains outbound.

That is the classic bidirectional Resolver endpoint use case.

A practical implementation sequence

1. Document the authority

namespace: azure.internal.bfstore.example
authority: azure-private-dns
consumers:
  - bfstore-dev
  - bfstore-staging
  - bfstore-prod

2. Establish network connectivity

Prove that the endpoint VPC can reach each external resolver and receive the reply.

3. Create endpoint subnets

Use at least two Availability Zones and reserve addresses for growth.

4. Create protocol-specific security groups

Permit only the required Do53 or DoH traffic between intended resolver ranges.

5. Create the endpoint

Choose inbound or outbound according to where the query originates.

6. Create narrow rules

Begin with the smallest domain requiring external authority. Use delegation only when the DNS authority model and required NS records support it.

Associate only the VPCs that genuinely consume the namespace.

8. Configure the external resolver

For ordinary inbound use, configure conditional forwarding to every endpoint address. For inbound delegation, create the required parent-side NS and glue records.

9. Enable evidence

Add query logging, endpoint metrics and target name-server metrics where useful.

10. Test success, failure and isolation

Confirm:

the intended name resolves;
a child name uses the correct authority;
an unrelated name remains on its ordinary path;
an unapproved network cannot query the endpoint;
loss of one endpoint interface does not remove resolution;
loss of one target resolver is tolerated;
no forwarding loop exists.

The test is not complete when:

dig returned an address once.

It is complete when the authority, failure behaviour and isolation match the design.

The mental model I am keeping

                       DNS QUERY
                           │
                           ▼
                  WHERE DID IT ORIGINATE?
                           │
             ┌─────────────┴─────────────┐
             │                           │
             ▼                           ▼
          INSIDE AWS                 OUTSIDE AWS
             │                           │
             ▼                           ▼
      AmazonProvidedDNS          EXTERNAL RESOLVER
             │                           │
             ▼                           ▼
       WHO OWNS THE NAME?         WHO OWNS THE NAME?
             │                           │
    ┌────────┴────────┐          ┌───────┴────────┐
    │                 │          │                │
    ▼                 ▼          ▼                ▼
ROUTE 53         EXTERNAL DNS  AWS DNS       EXTERNAL DNS
    │                 │          │                │
    ▼                 ▼          ▼                ▼
ANSWER         OUTBOUND RULE  INBOUND         ANSWER
DIRECTLY            │         ENDPOINT        DIRECTLY
                    ▼             │
             OUTBOUND ENDPOINT    ▼
                    │        ROUTE 53 RESOLVER
                    ▼
              EXTERNAL RESOLVER

AmazonProvidedDNS answers:

Can AWS already resolve
this name locally?

The private hosted-zone association answers:

Does this VPC receive
the AWS-private namespace?

The inbound endpoint answers:

How can another DNS environment
ask Route 53 Resolver a question?

The outbound endpoint answers:

How can Route 53 Resolver
ask another authority a question?

The Resolver rule answers:

Which namespace should cross
the outbound bridge?

The system rule answers:

Which more-specific branch
should remain with Route 53?

Delegation answers:

Which DNS authority owns
this child namespace?

The endpoint security group answers:

Which resolvers may send
or receive these questions?

CloudWatch answers:

Is the bridge healthy,
and is the authority responding?

Query logging answers:

Which names actually crossed it?

And the lack of an endpoint answers:

Is every current DNS question
already being answered inside AWS?

For bfstore today, most of them are.

For bfstore’s future multi-cloud environment, that answer will change.

Create an inbound endpoint when another resolver needs AWS answers. Create an outbound endpoint when AWS needs another resolver’s answers. Create both when the DNS relationship is genuinely bidirectional.

Do not create either merely because the record is private.

Do not create one endpoint per hosted zone.

Do not forward a namespace before deciding who owns it.

Do not join two forwarding paths without checking whether they form a circle.

Resolver endpoints are not the foundation of VPC DNS.

AmazonProvidedDNS already holds that job.

The endpoints are the carefully guarded doors added when DNS must finally leave the room.