How do medium and large organizations typically expose applications hosted in Azure VNets across multiple regions or globally? My understanding is that they purchase a domain and create subdomain records with a DNS provider, pointing those names toward public IP addresses or Azure service endpoints such as compute resources, application gateways, load balancers, or other frontend services. I'm trying to understand the common architecture when there are many regional applications and public endpoints, including how traffic is routed between regions and how failover is handled. I'm also unclear about TLS: where certificates are normally installed, whether organizations use certificates for every application subdomain, and how certificate renewal and rotation are managed. Our organization uses a third-party DNS provider, so I'd also like to understand how that typically integrates with Azure's global routing and certificate-management services.
4 Answers
There isn’t one universal design—it depends on the application, client locations, availability targets, and whether the traffic is HTTP-based. For regional services, options can include Front Door, Traffic Manager, Application Gateway, or a combination of these. TLS is normally terminated at the edge or load balancer, and many Azure services support managed certificates. If you use your own certificates, they’re uploaded to the relevant service and must be renewed and rotated through your certificate-management process.
A common Azure pattern is to put internet-facing applications behind Azure Front Door. It can provide global HTTP routing, health probes, failover between regional deployments, and TLS termination. Front Door can issue and renew managed certificates for custom domains, so you generally don’t have to manually rotate a certificate for every application. DNS records at your provider point the application hostname to the Front Door endpoint, usually through the required CNAME setup.
For applications that need regional redundancy, organizations commonly deploy the app in a primary region and a secondary region, then use health-based routing or priority routing to send traffic to the preferred region and fail over when it becomes unhealthy. Front Door is often enough for global HTTP or HTTPS applications. Traffic Manager can also provide DNS-based routing, while Application Gateway is typically used inside a region for layer-7 routing and features such as WAF. The DNS provider only needs to delegate or create the records required to reach the chosen Azure entry point.
For very large or highly available platforms, the edge layer may include multiple services—for example, a CDN or global gateway in front of regional gateways and application deployments. The important distinction is that DNS usually directs users to the global entry service, rather than maintaining a separate public IP for every backend instance. Certificates are then associated with the public hostnames at that edge layer, where TLS is terminated and traffic is forwarded securely to the regional application.
The scenario is an online environment with many regional applications and public endpoints. Each application may use a company-owned subdomain, and our organization manages DNS through a third-party provider. I’m mainly comparing the available patterns for routing and managing all those hostnames and certificates.