![\"Potential](\"https://tailscale.com/_next/image?url=%2F_next%2Fstatic%2Fmedia%2Fazure-reference-architecture.98492d65.png&w=3840&q=75\")
Last validated: Jan 5, 2026
\nThis document details best practices and a reference architecture for Tailscale deployments on Microsoft Azure. The following guidance applies for all Tailscale modes of operation—such as devices, exit nodes, and subnet routers.
\nTailscale device—for the purposes of this document Tailscale device can refer to a Tailscale node, exit node, subnet router, and the like. Refer to Terminology and concepts for additional terms.
\n
Tailscale provides a few options for connecting to resources within Azure. At a high-level they are:
\nWe recommend installing the Tailscale agent wherever possible—for example, setting up servers on Azure VMs. This generally provides the best and most scalable connectivity while enabling Tailscale agent-based functionality such as Tailscale SSH.
\nRefer to Access Azure Linux VMs privately using Tailscale and Access Azure Windows VMs privately using Tailscale for general guides.
\nFor managed resources where you cannot install the Tailscale agent, such as Azure SQL or Azure Cosmos DB, you can run a subnet router within your virtual network to access these resources from Tailscale.
\nApp connectors let you route traffic bound for SaaS applications or managed services by proxying DNS for the target domains and advertising the subnet routes for the observed DNS results. This is useful for cases where the application has an allowlist of IP addresses which can connect to it; the IP addresses of the nodes running an app connector can be added to the allowlist, and all nodes in the tailnet will use that IP address for their traffic egress.
\nThe Tailscale Kubernetes Operator lets you expose services in your Kubernetes cluster to your Tailscale network, and use an API server proxy for secure connectivity to the Kubernetes control plane.
\nTailscale supports userspace networking where processes in the container can connect to other resources on your Tailscale network by using a SOCKS5 or HTTP proxy. This lets Azure Functions, Azure App Service, and other container-based solutions to connect to the Tailscale network with minimal configuration needed.
\nRefer to Using Tailscale on Azure App Service for a general guide.
\nBelow are general recommendations and best practices for running Tailscale in production environments. Much of what is listed below is explained in greater detail throughout this document:
\nRefer to Performance best practices for general recommendations.
\nDeploy multiple overlapping connectors within a DERP region to take advantage of in-region load balancing to evenly spread load across the connectors and provide in-region redundancy.
\nWhen installing Tailscale on an Azure VM as a \"normal\" Tailscale device (for example, not a subnet router, exit node, and the like), you likely have already sized that VM to a suitable type for its workload and running Tailscale on it will likely add negligible resource usage.
\nThere are many variables that affect performance and workloads vary widely so we do not have specific size recommendations, but we do have general guidance for selecting a VM size for an Azure VM running as a subnet router, exit node, or app connector:
\nTailscale uses various NAT traversal techniques to safely connect to other Tailscale nodes without manual intervention. Nearly all the time, you do not need to open any firewall ports for Tailscale. However, if your virtual network and network security groups are overly restrictive about internet-bound egress traffic, refer to What firewall ports should I open to use Tailscale.
\nTailscale devices deployed to a public subnet with a public IP address will benefit from direct connections between nodes for the best performance.
\nTailscale uses both direct and relayed connections, opting for direct connections where possible. Azure NAT Gateway is a Hard NAT and will prevent direct connections causing connections to use DERP relay servers. This can lead to lower throughput and performance than direct connections.
\nTailscale Peer Relays let you use devices in your tailnet as high-throughput relay servers when direct connections aren't possible due to network conditions such as being in a private subnet behind an Azure NAT Gateway. To bypass Azure NAT Gateway, follow the steps to deploy and configure a peer relay to a public subnet in your virtual network, with a public IP address, and allow incoming UDP traffic to the relay port.
\nTo allow non-Azure devices in your tailnet to query Azure DNS private zones, create a Azure DNS private resolver for your virtual network and configure split DNS to forward queries for your virtual network's internal domain name suffix to the IP address of the DNS private resolver's inbound endpoint.
\nVirtual network peering is a common strategy for connecting multiple virtual networks together. You can deploy a subnet router (or a set for high availability) within a virtual network to allow access to multiple virtual networks.
\nIf you have virtual networks or subnets with overlapping IPv4 addresses, use 4via6 subnet routers to access resources with unique IPv6 addresses for each overlapping subnet.
\nOftentimes organizations are using Tailscale to connect to and administer their Azure AKS clusters. While Tailscale can run within a container and be deployed to AKS, we recommend running your subnet routers externally to these clusters to ensure connectivity is available in the event your cluster is having issues. In other words, run your subnet router on dedicated VMs or an AKS cluster separate from than the cluster you're administering.
\nDeploy multiple session recorder instances across multiple availability zones to improve resiliency against zone failures. If your organization operates across multiple regions, consider deploying SSH session recording nodes in each region you operate and configure SSH access rules to send recording information to the local region for your nodes.
\nAsk AI
\nreCAPTCHA
\nRecaptcha requires verification.
\nprotected by reCAPTCHA
\n"}![\"Project](\"https://cdn.brandfetch.io/tailscale.com/fallback/lettermark/theme/dark/h/256/w/256/icon?c=1bfwsmEH20zzEfSNTed\")