Live tool

Azure DNS Resolver Sizing Calculator

Size Azure DNS Private Resolver endpoints from a workload QPS mix. Combine standard VMs, AVD users, AKS clusters, and custom sources to see endpoint count, Pattern B vs Pattern C recommendation, monthly cost, warnings, and a copy-ready Bicep skeleton. Pricing is illustrative — verify against the Azure Pricing Calculator before committing.

Live Cloud Calculator Azure DNS Private Resolver Private Endpoint Network Architecture Sizing
Open tool
Pricing note: Endpoint and query costs are illustrative values for East US public Azure. Verify against the Azure Pricing Calculator before committing budgets. Sizing logic uses Microsoft-documented service limits (10,000 QPS per endpoint, 5 endpoints per direction per resolver).

Workload inputs

Add one row per workload group. Endpoint sizing and cost update live.

Name Type Count Sust. QPS Peak QPS
Multiplier applied to peak QPS when sizing endpoints. 1.2 covers typical bursts; 1.5+ for environments with sharp login storms or batch jobs.

Sizing result

Endpoint count, pattern recommendation, and monthly cost.

Sized QPS 0 peak × headroom
Inbound endpoints 0 / 5 max
Outbound endpoints 0 / 5 max
Monthly cost (USD) $0 endpoint + query

Bicep skeleton

Copy-paste-ready starting point for the recommended topology. Replace placeholder parameters with your resource IDs. 


                    

                

            

        


        

            

                

                    

                        

                            
Pattern reference

                            

                                Which topology and when.
                            

                        

                    

                    

                        

                            

                                Pattern A — Custom DNS VMs
                                Legacy. Two VMs running BIND or Windows DNS with conditional forwarders. Works, but you patch and monitor it. No reason to build new in 2026.
                            

                            

                                Pattern B — Centralized Private Resolver (recommended default)
                                Single resolver in the hub. Inbound + outbound endpoints, one ruleset, all spokes linked. Default for most enterprises.
                            

                            

                                Pattern C — Direct ruleset link to spoke
                                For high-QPS workloads (AVD with thousands of users, AKS clusters saturating CoreDNS). Links the DNS Forwarding Ruleset directly to the spoke VNet, bypassing the inbound endpoint.
                            

                            

                                Sharding / multi-resolver
                                Above ~50,000 sized QPS, or across Entra tenants. Multiple resolvers, ownership-boundary sharding.
                            

                        

                    

                

            


            

                

                    

                        

                            
Common sizing mistakes

                            

                                What teams get wrong in production.
                            

                        

                    

                    

                        

                            

                                1. Sizing on sustained QPS only
                                VDI login storms and AKS pod churn produce 5–10× peaks lasting minutes. Always size with peak × headroom, not steady-state.
                            

                            

                                2. Ignoring AKS CoreDNS upstream forwarding
                                A single misconfigured CoreDNS forwards every pod's external lookups through the resolver. One cluster can saturate an endpoint on its own.
                            

                            

                                3. Adding endpoints instead of sharding
                                5 endpoints per direction is the hard cap. If you're at 4 and still growing, plan the second resolver — not the fifth endpoint.
                            

                            

                                4. Assuming cross-tenant works
                                It doesn't. Ruleset linking is single-tenant. Plan per-tenant resolvers from day one if you're multi-tenant.
                            

                            

                                5. Forgetting the dedicated subnet
                                Inbound and outbound endpoints each need a dedicated /28 or larger, delegated to Microsoft.Network/dnsResolvers, with no other resources. Carve subnets early.