Cost-Effectively Using Amazon Route 53 Resolver Endpoints: Identifying and Eliminating Redundancy

DNS is the glue that holds distributed systems together, and in AWS, Amazon Route 53 Resolver endpoints are the building blocks that make hybrid and multi-account DNS possible. If you run hybrid workloads across multiple VPCs or accounts on-prem/office/branch networks, you’ve probably deployed inbound or outbound Resolver endpoints to get name resolution working.

But here’s the catch: Resolver endpoints come at a cost, and when they’re deployed without a strategy, the bill grows quickly. Working with customers as a Senior Cloud Architect at DoiT, I frequently find environments with dozens of Resolver endpoints where only a handful are truly necessary. Teams often assume that "one per VPC" is best practice, when in reality this pattern creates redundancy, sprawl, and unnecessary costs.

AWS documentation, such as the Best Practices for Route 53 Resolver and achieving DNS high availability with Resolver endpoints, provides excellent guidance on high availability and deployment patterns. This post complements that guidance by addressing a practical gap we see in the field: how to detect and remediate redundant endpoints that drive up cost without adding resilience.

How Resolver Endpoints Are Typically Deployed

Let’s start with the basics:

• Inbound endpoints allow external DNS queries (for example, from on-premises) to resolve private records inside AWS.
• Outbound endpoints allow DNS queries from inside a VPC to resolve external domains (often via conditional forwarding).

Each endpoint is deployed in one or more subnets and backed by ENIs. For high availability, AWS recommends placing endpoints across multiple Availability Zones, usually two.

That means that for a region, you need two inbound and two outbound endpoints (across two Availability Zones, AZs) to achieve high availability. Beyond that, adding more endpoints doesn’t improve resilience, it just adds cost.

In multi-account setups, I often see each account spinning up its own endpoints. Add a central networking team doing the same, and suddenly you’ve got 10, 20, or more endpoints per region. The difference between 4 endpoints and 20 endpoints in a region is over $1,400 per month, and that’s just one region.

Why Redundancy Happens

Why do redundant endpoints appear so often?

• Siloed account ownership: Teams are unaware that forwarding rules can be shared via AWS Resource Access Manager (RAM).
• Perceived simplicity: "Let’s just add an endpoint to this VPC" feels faster than coordinating with central IT.
• Lack of visibility: There is no built-in dashboard showing how many endpoints exist in each region and account.

Detecting Redundancy in Practice

Spotting redundancy starts with building a complete inventory. Because Resolver endpoints are regional and account-scoped, you’ll want to gather data across both accounts and regions. Once you know the count, anything beyond four per region (two inbound and two outbound) is a strong indicator of redundancy, and each adds about $90/month to your AWS bill.

1. Inventory Endpoints Per Account and Region

Start by listing Resolver endpoints using the AWS CLI. Include inbound vs outbound, status, and associated VPCs:

for id in $(aws route53resolver list-resolver-endpoints \
  --region eu-west-1 \
  --query "ResolverEndpoints[].Id" \
  --output text); do

  echo "Endpoint details for $id"

  # Show general endpoint information
  aws route53resolver get-resolver-endpoint \
    --region eu-west-1 \
    --resolver-endpoint-id $id \
    --query "ResolverEndpoint.{Id:Id,Name:Name,Direction:Direction,Status:Status,VpcId:HostVPCId,IpAddresses:IpAddressCount}" \
    --output table

  # Show subnet IDs of the endpoint's IP addresses
  aws route53resolver list-resolver-endpoint-ip-addresses \
    --region eu-west-1 \
    --resolver-endpoint-id $id \
    --query "IpAddresses[].{Ip:Ip,SubnetId:SubnetId,Status:Status}" \
    --output table
done

Example output:

This lets you distinguish inbound vs outbound, see which VPCs they belong to, and check if high availability is implemented (IpAddressCount shows how many ENIs are attached, and you can also see what subnets they are connected to).

Route 53 Resolver is a regional service. To get a complete picture, loop through all enabled regions. If you use AWS Organizations, you can combine the above with STS AssumeRole to gather inventories across member accounts. This way, you get a full inventory across your AWS estate.

NOTE: Most organizations already have the default role OrganizationAccountAccessRole, which is created automatically when accounts are added to an Organization. This role has AdministratorAccess, so it can be used directly for inventory purposes. For stronger governance and least privilege, you may prefer to create a dedicated role (for example, OrgAccountAuditRole) with only the read-only permissions required for Route 53 Resolver and VPC discovery.

2. Use Metrics and Logs to Detect Redundancy

Inventory alone doesn’t show which endpoints are used. An easy first step is to check CloudWatch metrics for query volume per endpoint, which often highlights unused or underutilized endpoints.

For deeper analysis, enable Resolver query logging. By cross-referencing logs with your endpoint inventory, you can flag:

• Endpoints with no queries (likely unused).
• Endpoints with very low traffic (potentially consolidatable).
• Duplicated rules forwarding the same domain to the same targets.

This is often where hidden redundancy emerges, such as endpoints deployed for a project that was retired, or for accounts that could easily use the shared services VPC instead.

Best Practices to Avoid Redundancy

Once you have visibility, the path to optimization is straightforward:

1. Centralize in a Shared Services VPC
   • Deploy two inbound and two outbound endpoints per region in subnets across two AZs.
   • Share them across accounts via AWS RAM.
2. Consider Route 53 Profiles
   • Another option is to use Amazon Route 53 Profiles, which provide a scalable way to share DNS configurations across accounts. Profiles introduce additional costs, but for organizations that view operational complexity as an expense in itself, the simplified management can be worth the trade-off.
3. Apply Governance Controls
   • Use Service Control Policies (SCPs) to limit endpoint creation.
   • Require tagging to track ownership and costs.
4. Decommission Redundancy Safely
   • Update VPC rules to point to the shared endpoints first.
   • Validate DNS resolution using CloudWatch metrics or query logs.
   • Only then remove unused endpoints to avoid disruption.

A note on scaling, quotas and performance: consolidating endpoints into a Shared Services VPC is often more cost-effective, but there are service quotas and performance considerations to be aware of. AWS allows 4 resolver endpoints per account per Region by default, with up to 6 IP addresses per endpoint and 6 IP addresses per forwarding rule. Each account can have up to 1,000 forwarding rules per Region, and rules can be associated with up to 2,000 VPCs per Region. In high query volume scenarios, each IP address in an endpoint can handle up to about 10,000 UDP DNS queries per second, though actual throughput depends on response times, external dependencies, and network latency. If many VPCs point to a shared endpoint, you should monitor CloudWatch metrics for endpoint throughput, test under load, and ensure that performance remains acceptable. For large-scale environments, you may need to request quota increases or distribute DNS traffic appropriately. Review the Route 53 Resolver quotas and test performance as part of your design.

A Real-World Example

At DoiT, we worked with a customer who had over 50 Resolver endpoints across three regions. Each team had deployed its own, assuming it was required for their VPC.

When we inventoried endpoints and analyzed usage, we found:

• Dozens of endpoints with no queries at all.
• Multiple endpoints forwarding the exact same domains.
• No endpoint sharing via AWS RAM.

By consolidating to four endpoints per region in a Shared Services VPC, the customer reduced endpoint count from 50 to 12. The savings were substantial, more than $40,000 annually, but equally important was the operational clarity: a simpler DNS setup, easier governance, and less risk of inconsistent rules.

Conclusion

Amazon Route 53 Resolver endpoints are essential for hybrid and multi-account DNS in AWS. AWS guidance ensures you know how to deploy them for high availability, but in the field, we often see deployments go further than needed.

The missing step is visibility:

• Build an inventory across accounts and regions.
• Use CloudWatch metrics or query logs to understand actual usage.
• Consolidate where appropriate.

By combining AWS best practices with proactive detection, organizations can run leaner DNS infrastructures that are cost-efficient, easier to manage, and still highly available.

You can start by using the default OrganizationAccountAccessRole to build your inventory quickly, but for long-term governance, consider rolling out a least-privilege audit role that limits access to only the permissions required.

The lesson is simple: you don’t always need more Resolver endpoints. Often, you need fewer, and better visibility into the ones you already have.