Tutorial: Create a geo-distributed app solution with Azure and Azure Stack
Applies to: Azure Stack integrated systems and Azure Stack Development Kit
Learn how to direct traffic to specific endpoints based on various metrics using the geo-distributed apps pattern. Creating a Traffic Manager profile with geographic-based routing and endpoint configuration ensures information is routed to endpoints based on regional requirements, corporate and international regulation, and your data needs.
In this tutorial, you will build a sample environment to:
- Create a Geo-Distributed App.
- Use Traffic Manager to target your app.
Use the geo-distributed apps pattern
With the geo-distributed pattern, your app can spans regions. You can default to the public cloud, but some of users may require that their data remain in their region. You can direct users to the most suitable cloud based on their requirements.
Issues and considerations
The solution you will build with this tutorial is not to accommodate scalability. However, if used in combination with other Azure and On-Premises technologies and solutions you can accommodate scalability requirements. For information on creating a hybrid solution with auto-scaling via traffic manager, see Create cross-cloud scaling solutions with Azure.
As is the case with scalability considerations, this solution doesn't directly address availability. However, also similar to our scalability considerations, Azure, and on-premises technologies and solutions can be implemented within this solution to ensure high availability for all components involved.
When to use this pattern
Your organization has international branches requiring custom regional security and distribution policies.
Each of your organizations offices pulls employee, business, and facility data, requiring reporting activity per local regulations and time zone.
High scale requirements can be met by horizontally scaling out apps, with multiple app deployments being made within a single region, as well as across regions, to handle extreme load requirements.
Planning the topology
Before building out a distributed app footprint, it helps to have the following knowledge:
Custom domain for the app: What is the custom domain name that customers will use to access the app? For the sample app, the custom domain name is www.scalableasedemo.com.
Traffic Manager domain: A domain name needs to be chosen when creating an Azure Traffic Manager profile. This name will be combined with the trafficmanager.net suffix to register a domain entry that is managed by Traffic Manager. For the sample app, the name chosen is scalable-ase-demo. As a result, the full domain name that is managed by Traffic Manager is scalable-ase-demo.trafficmanager.net.
Strategy for scaling the app footprint: Will the application footprint be distributed across multiple App Service Environments in a single region? Multiple regions? A mix of both approaches? The decision should be based on expectations of where customer traffic will originate, as well as how well the rest of an app's supporting back-end infrastructure can scale. For example, with a 100% stateless application, an app can be massively scaled using a combination of multiple App Service Environments per Azure region, multiplied by App Service Environments deployed across multiple Azure regions. With 15+ global Azure regions available to choose from, customers can truly build a world-wide hyper-scale application footprint. For the sample app used for this article, three App Service Environments were created in a single Azure region (South Central US).
Naming convention for the App Service Environments: Each App Service Environment requires a unique name. Beyond one or two App Service Environments, it is helpful to have a naming convention to help identify each App Service Environment. For the sample app a simple naming convention was used. The names of the three App Service Environments are fe1ase, fe2ase, and fe3ase.
Naming convention for the apps: Since multiple instances of the app will be deployed, a name is needed for each instance of the deployed app. With App Service Environments the same app name can be used across multiple App Service Environments. Since each App Service Environment has a unique domain suffix, developers can choose to reuse the exact same app name in each environment. For example, a developer could have apps named as follows: myapp.foo1.p.azurewebsites.net, myapp.foo2.p.azurewebsites.net, myapp.foo3.p.azurewebsites.net, etc. For the app in this scenario, each app instance has a unique name. The app instance names used are webfrontend1, webfrontend2, and webfrontend3.
Microsoft Azure Stack is an extension of Azure. Azure Stack brings the agility and innovation of cloud computing to your on-premises environment and enabling the only hybrid cloud that allows you to build and deploy hybrid apps anywhere.
The whitepaper Design Considerations for Hybrid Applications reviews pillars of software quality (placement, scalability, availability, resiliency, manageability and security) for designing, deploying, and operating hybrid applications. The design considerations assist in optimizing hybrid application design, minimizing challenges in production environments.
Part 1: Create a geo-distributed app
In this part, you will create a web app.
- Create web apps and publish
- Add Code to Azure Repos
- Point the app build to multiple cloud targets.
- Manage and configure the CD process
An Azure subscription and Azure Stack installation are required.
Geo-distributed app steps
Obtain a custom domain and configure DNS
Update the DNS zone file for the domain. Azure AD can then verify ownership of the custom domain name. Use Azure DNS for Azure/Office 365/external DNS records within Azure, or add the DNS entry at a different DNS registrar.
Register a custom domain with a public Registrar.
Sign in to the domain name registrar for the domain. An approved admin may be required to make the DNS updates.
Update the DNS zone file for the domain by adding the DNS entry provided by Azure AD. The DNS entry doesn't change behaviors such as mail routing or web hosting.
Create web apps and publish
Set up hybrid CI/CD to deploy Web App to Azure and Azure Stack, and auto push changes to both clouds.
Azure Stack with proper images syndicated to run (Windows Server and SQL) and App Service deployment are required. Review the App Service documentation Before you get started with App Service on Azure Stack section for Azure Stack Operator.
Add Code to Azure Repos
Sign in to Visual Studio with an account that has project creation rights on Azure Repos.
Hybrid Continuous Integration/Continuous Delivery (CI/CD) can apply to both application code and infrastructure code. Use Azure Resource Manager templates for both private and hosted cloud development.
Clone the repository by creating and opening the default web app.
Create web app deployment in both clouds
Edit the WebApplication.csproj file: Select Runtimeidentifier and add win10-x64. (See Self-contained Deployment documentation.)
Check in the code to Azure Repos using Team Explorer.
Confirm that the application code has been checked into Azure Repos.
Create the build definition
Log into Azure Pipelines to confirm ability to create build definitions.
Add -r win10-x64 code. This is necessary to trigger a self-contained deployment with .NET Core.
Run the build. The self-contained deployment build process will publish artifacts that can run on Azure and Azure Stack.
Using an Azure Hosted Agent
Using a hosted agent in Azure Pipelines is a convenient option to build and deploy web apps. Maintenance and upgrades are automatically performed by Microsoft Azure, enabling continual, uninterrupted development, testing, and deployment.
Manage and configure the CD process
Azure DevOps and Azure DevOps Server provide a highly configurable and manageable pipeline for releases to multiple environments such as development, staging, QA, and production environments; including requiring approvals at specific stages.
Create release definition
Select the plus button to add a new Release under the Releases tab in the Build and Release page of Visual Studio Online (VSO).
Apply the Azure App Service Deployment template.
Under Add artifact pull-down menu, add the artifact for the Azure Cloud build app.
Under Pipeline tab, Select the Phase, Task link of the environment and set the Azure cloud environment values.
Set the environment name and select Azure Subscription for the Azure Cloud endpoint.
Under Environment name, set the required Azure app service name.
Enter Hosted VS2017 under Agent queue for Azure cloud hosted environment.
In Deploy Azure App Service menu, select the valid Package or Folder for the environment. Select OK to folder location.
Save all changes and go back to release pipeline.
Add a new artifact selecting the build for the Azure Stack app.
Add one more environment applying the Azure App Service Deployment.
Name the new environment Azure Stack.
Find the Azure Stack environment under Task tab.
Select the subscription for the Azure Stack endpoint.
Set the Azure Stack web app name as the App service name.
Select the Azure Stack agent.
Under the Deploy Azure App Service section select the valid Package or Folder for the environment. Select OK to folder location.
Under Variable tab add a variable named
VSTS\_ARM\_REST\_IGNORE\_SSL\_ERRORS, set its value as
true, and scope to
Select the Continuous deployment trigger icon in both artifacts and enable the Continues deployment trigger.
Select the Pre-deployment conditions icon in the Azure Stack environment and set the trigger to After release.
Save all changes.
Some settings for the tasks may have been automatically defined as environment variables when you created a release definition from a template. These settings cannot be modified in the task settings; instead you must select the parent environment item to edit these settings.
Part 2: Update web app options
Azure App Service provides a highly scalable, self-patching web hosting service.
- Map an existing custom DNS name to Azure Web Apps
- Use a **CNAME recorder an A record to map a custom DNS name to App Service.
Map an existing custom DNS name to Azure Web Apps
Use a CNAME for all custom DNS names except a root domain (for example,northwind.com).
To migrate a live site and its DNS domain name to App Service, see Migrate an active DNS name to Azure App Service.
To complete this tutorial:
Create an App Service app, or use an app created for another tutorial.
Purchase a domain name and ensure access to the DNS registry for the domain provider.
Update the DNS zone file for the domain. Azure AD will verify ownership of the custom domain name. Use Azure DNS for Azure/Office 365/external DNS records within Azure, or add the DNS entry at a different DNS registrar.
Register a custom domain with a public Registrar.
Sign in to the domain name registrar for the domain. (An approved admin may be required to make DNS updates.)
Update the DNS zone file for the domain by adding the DNS entry provided by Azure AD.
For example, to add DNS entries for northwindcloud.com and www.northwindcloud.com, configure DNS settings for the northwindcloud.com root domain.
Create and map CNAME and A records
Access DNS records with domain provider
Use Azure DNS to configure a custom DNS name for Azure Web Apps. For more information, see Use Azure DNS to provide custom domain settings for an Azure service.
Sign in to the website of the main provider.
Find the page for managing DNS records. Every domain provider has its own DNS records interface. Look for areas of the site labeled Domain Name, DNS, or Name Server Management.
DNS records page can be viewed in My domains. Find the link named Zone file, DNS Records, or Advanced configuration.
The following screenshot is an example of a DNS records page:
In Domain Name Registrar, select Add or Create to create a record. Some providers have different links to add different record types. Consult the provider's documentation.
Add a CNAME record to map a subdomain to the app's default hostname.
For the www.northwindcloud.com domain example, add a CNAME record that maps the name to <app_name>.azurewebsites.net.
After adding the CNAME, the DNS records page looks like the following example:
Enable the CNAME record mapping in Azure
In a new tab, sign in to the Azure portal,
Navigate to App Services.
Select web app.
In the left navigation of the app page in the Azure portal, select Custom domains.
Select the + icon next to Add hostname.
Type the fully qualified domain name, such as
If indicated, add additional records of other types (
TXT) to the domain name registrars DNS records. Azure will provide the values and types of these records:
a. An A record to map to the app's IP address.
b. A TXT record to map to the app's default hostname <app_name>.azurewebsites.net. App Service uses this record only at configuration time, to verify custom domain ownership. After verification, delete the TXT record.
Complete this task in the domain registrar tab and revalidate until the Add hostname button is activated.
Make sure that **Hostname record type is set to CNAME (www.example.com or any subdomain).
Select Add hostname.
Type the fully qualified domain name, such as
The Add is activated.
Make sure that **Hostname record type is set to A record (example.com).
It might take some time for the new hostnames to be reflected in the app's Custom domains page. Try refreshing the browser to update the data.
In the case of an error, a verification error notification will appear at the bottom of the page.
The above steps may be repeated to map a wildcard domain (*.northwindcloud.com).. This allows the addition of any additional subdomains to this app service without having to create a separate CNAME record for each one. Follow the registrar instructions to configure this setting.
Test in a browser
Browse to the DNS name(s) configured earlier (for example,
Part 3: Bind a custom SSL cert
In this part:
- Bind the custom SSL certificate to App Service
- Enforce HTTPS for the app
- Automate SSL certificate binding with scripts
If needed, obtain a customer SSL certificate in the Azure portal and bind it to the web app. Follow the App Service Certificates tutorial.
To complete this tutorial:
- Create an App Service app
- Map a custom DNS name to your web app
- Acquire an SSL certificate from a trusted certificate authority and use the key to sign the request
Requirements for your SSL certificate
To use a certificate in App Service, the certificate must meet all the following requirements:
Signed by a trusted certificate authority
Exported as a password-protected PFX file
Contains private key at least 2048 bits long
Contains all intermediate certificates in the certificate chain
Elliptic Curve Cryptography (ECC) certificates work with App Service but are not included in this guide. Consult a certificate authority for assistance in creating ECC certificates.
Prepare the web app
To bind a custom SSL certificate to the web app, the App Service plan must be in the Basic, Standard, or Premium tier.
Sign in to Azure
Open the Azure portal and navigate to the web app.
From the left menu, select App Services, and then select the web app name.
Check the pricing tier
In the left-hand navigation of the web app page, scroll to the Settings section and select Scale up (App Service plan).
Ensure the web app is not in the Free or Shared tier. The web app's current tier is highlighted in a dark blue box.
Custom SSL is not supported in the Free or Shared tier. To upscale, follow the steps in the next section, or Choose your pricing tier page and skip to Upload and bind your SSL certificate.
Scale up your App Service plan
Select one of the Basic, Standard, or Premium tiers.
The scale operation is complete when notification is displayed.
Bind your SSL certificate and merge intermediate certificates
Merge multiple certificates in the chain.
Open each certificate you received in a text editor.
Create a file for the merged certificate, called mergedcertificate.crt. In a text editor, copy the content of each certificate into this file. The order of your certificates should follow the order in the certificate chain, beginning with your certificate and ending with the root certificate. It looks like the following example:
-----BEGIN CERTIFICATE----- <your entire Base64 encoded SSL certificate> -----END CERTIFICATE----- -----BEGIN CERTIFICATE----- <The entire Base64 encoded intermediate certificate 1> -----END CERTIFICATE----- -----BEGIN CERTIFICATE----- <The entire Base64 encoded intermediate certificate 2> -----END CERTIFICATE----- -----BEGIN CERTIFICATE----- <The entire Base64 encoded root certificate> -----END CERTIFICATE-----
Export certificate to PFX
Export merged SSL certificate with the private key generated by the certificate.
A private key file is created via OpenSSL. To export the certificate to PFX, run the following command, replacing the placeholders <private-key-file> and <merged-certificate-file> with private key paths and merged certificate file.
openssl pkcs12 -export -out myserver.pfx -inkey <private-key-file> -in <merged-certificate-file>
When prompted, define an export password for uploading your SSL certificate to App Service later.
When IIS or Certreq.exe are used to generate the certificate request, install the certificate to a local machine and then export the certificate to PFX.
Upload the SSL certificate
Select SSL settings in the left navigation of the web app.
Select Upload Certificate.
In PFX Certificate File, select PFX file.
- In Certificate password, type the password created when exporting the PFX file.
When App Service finishes uploading the certificate, it appears in the SSL settings page.
Bind your SSL certificate
In the SSL bindings section, select Add binding.
If the certificate has been uploaded, but does not appear in domain name(s) in the Hostname dropdown, try refreshing the browser page.
In the Add SSL Binding page, use the drop downs to select the domain name to secure, and the certificate to use.
In SSL Type, select whether to use Server Name Indication (SNI)or IP-based SSL.
SNI-based SSL- Multiple SNI-based SSL bindings may be added. This option allows multiple SSL certificates to secure multiple domains on the same IP address. Most modern browsers (including Internet Explorer, Chrome, Firefox, and Opera) support SNI (find more comprehensive browser support information at Server Name Indication).
IP-based SSL- Only one IP-based SSL binding may be added. This option allows only one SSL certificate to secure a dedicated public IP address. To secure multiple domains, secure them all using the same SSL certificate. This is the traditional option for SSL binding.
- Select Add Binding.
When App Service finishes uploading the certificate, it appears in the SSL bindings sections.
Remap the A record for IP SSL
If IP-based SSL is not used in the web app, skip to Test HTTPS for your custom domain.
By default, the web app uses a shared public IP address. When the certificate is bound with IP-based SSL, App Service creates a new and dedicated IP address for the web app.
When an A record is mapped to the web app, the domain registry must be updated with the dedicated IP address.
In various browsers, browse to https://<your.custom.domain>to ensure the web app is served.
If certificate validation errors occur, a self-signed certificate may be the cause, or intermediate certificates may have been left off when exporting to the PFX file.
By default, anyone may access the web app using HTTP. all HTTP requests to the HTTPS port may be redirected.
In the web app page, select SL settings. Then, in HTTPS Only, select On.
When the operation is complete, navigate to any of the HTTP URLs that point to the app. For example:
Enforce TLS 1.1/1.2
In web app page, in the left navigation, select SSL settings.
In TLS version, select the minimum TLS version.
Create a Traffic Manager profile
Select Create a resource > Networking > Traffic Manager profile > Create.
In the Create Traffic Manager profile, complete as follows:
In Name, provide a name for the profile. This name needs to be unique within the traffic manager.net zone and results in the DNS name, traffic manager.net, which is used to access the Traffic Manager profile.
In Routing method, select the Geographicrouting method.
In Subscription, select the subscription under which to create this profile.
In Resource Group, create a new resource group to place this profile under.
In Resource group location, select the location of the resource group. This setting refers to the location of the resource group and has no impact on the Traffic Manager profile that will be deployed globally.
When the global deployment of the Traffic Manager profile is complete, it is listed in respective resource group as one of the resources.
Add Traffic Manager endpoints
In the portals search bar, search for the **Traffic Manager profile **name created in the preceding section and select the traffic manager profile in the results that the displayed.
In Traffic Manager profile, in the Settings section, select Endpoints.
Adding the Azure Stack Endpoint.
For Type, select External endpoint.
Provide a Name for this endpoint, ideally the name of the Azure Stack.
For fully qualified domain name (FQDN), the use external URL for the Azure Stack Web App.
Under Geo-mapping, select a region/continent where the resource is located, for example, Europe.
Under the Country/Region drop-down that appears, select the country that will apply to this endpoint, for example, Germany.
Keep Add as disabled unchecked.
Adding the Azure Endpoint:
For Type, select Azure endpoint.
Provide a Name for this endpoint.
For Target resource type, select App Service.
For Target resource, select Choose an app service to show the listing of the Web Apps under the same subscription. In Resource, pick the App service use as the first endpoint.
Under Geo-mapping select a region/continent where the resource is located, for example, North America/Central America/Caribbean.
Under the Country/Region drop-down that appears, leave this blank to select all of the above regional grouping.
Keep Add as disabled unchecked.
Create at least one endpoint with a geographic scope of All (World) to serve as the default endpoint for the resource.
When the addition of both endpoints is complete, they are displayed in Traffic Manager profile along with their monitoring status as Online.
Global Enterprise relies on Azure Geo-Distribution capabilities
Directing data traffic via Azure Traffic Manager and geography-specific endpoints enables global enterprises to adhere to regional regulations and keep data compliant and secure crucial to the success of local business and across remote locations.
- To learn more about Azure Cloud Patterns, see Cloud Design Patterns.