The following case study is an example deployment scenario of a fictitious company to help illustrate how values such as Region Name and External Domain Name are used.
Contoso wants to deploy Azure Stack Hub and already owns the DNS name Contoso.com. They want to leverage this existing DNS name because their customers are already familiar with their name and brand. Consequently, they want to use an external domain name for Azure Stack Hub that is a subdomain of Contoso.com. They are going to start with a single region in their Chicago data center, and they plan to add more regions in the future. They have chosen to call this Azure cloud “MAST” because it is simple and they like the way that it sounds.
Contoso chooses the following values for their deployment:
Company name: Contoso
Region name: CHI
External domain name: mast.contoso.com
Using this combination of values, the Azure Stack Hub Tenant Portal URL for this deployment would be:
What if a tenant wants to create a load balancer with a public IP address for their web application and give it a DNS name label? It is for a teamwork application, so the tenant uses the DNS name label “Teams.” The resulting URL for the web application would be:
Contoso chooses an external domain name that was a subdomain of an existing DNS domain name. Contoso can set up a DNS delegation for that zone down to the Azure Stack Hub DNS so that tenants can resolve these names from outside of the Azure Stack Hub instance. Contoso could also, for example, set up a CNAME or alias for Azure Stack Hub to point to portal.mast.contoso.com that in turn points to portal.chi.mast.contoso.com.
In the future, depending on proximity, availability, or other business rules, when Contoso wants to add another region in Seattle, they can set load-balancing rules to route the portal.mast.contoso.com name to either:
Organizations can set this up differently, according to their business needs. This example illustrates the factors to consider during your namespace planning.