I'm trying to understand the common architecture for hosting many public-facing applications in Azure across multiple regions. My current understanding is that an organization registers a domain with a DNS provider, then creates subdomain records pointing to public IP addresses or Azure endpoints for services such as compute, application gateways, load balancers, or other managed platforms. How are these applications typically routed regionally or globally, especially when there are many public IPs and company-specific subdomains? I'd also like to understand where TLS certificates are installed, how certificate renewal is handled, and whether managed certificates are commonly used. Our organization uses a third-party DNS provider, and the applications may be deployed in several regional zones.
4 Answers
The exact design depends on the availability, latency, and scale requirements. Alternatives include Front Door, Application Gateway, Traffic Manager, or combinations of those services. Traffic Manager is DNS-based, while Front Door operates at the edge and can terminate HTTPS before forwarding traffic to the application. For extremely large global platforms, organizations may use several layers, such as a CDN or edge service in front of regional gateways and application deployments.
TLS is normally terminated at the public edge service or load balancer rather than separately on every application server. With Front Door and some other Azure services, you can use a managed certificate tied to each custom hostname. The DNS provider usually remains authoritative for the domain, but you add the required CNAME or validation records there. If you bring your own certificate, it must be stored and renewed securely, often through a certificate-management service, and then associated with the relevant gateway or edge endpoint.
A typical pattern is one public hostname per application, such as app1.example.com, with DNS pointing to a shared edge endpoint. The edge service uses the requested hostname to select the correct routing rule and backend, so you do not necessarily need a separate public IP for every application. Regional deployments can sit behind private or regional endpoints, while the edge layer handles internet access, HTTPS, health checks, and failover.
For public applications, a common approach is to put Azure Front Door at the edge. DNS records point the application hostnames to Front Door, which then routes requests to the appropriate regional origin. You can configure a primary region and a secondary region for failover, or use routing rules based on latency, geography, health, or priority. Front Door can also provide managed TLS certificates and handle renewal, so certificates do not need to be manually installed on every backend.
That helps. The goal is to host many regional applications, each with its own company subdomain, while continuing to use our existing third-party DNS provider. I’m mainly comparing the available routing and certificate-management options.