Traffic Manager in Azure App services

Traffic Manager

  • Traffic Manager is used for applications that need to scale beyond the capacity of a single deployment or whose users are globally dispersed.
  • Deploying your web app to multiple regions (or data-centers) is a scale-out strategy that can be used to achieve massive sociability for your web app.
  • Assume, for example, that you have a web app deployment in the Central US region. If your users are dispersed around the world, then you may choose to deploy to the West US, East US, and North Europe regions as well. Doing so will significantly increase capacity of your web app.
  • The challenge of routing users to one of many web app deployments can be met by using Azure Traffic Manager. This is a networking service that can be used to achieve global scale for your web apps by allowing you to control how user traffic is routed to multiple deployments of your application

To use Traffic Manager, you first must create a Traffic Manager profile, which identifies a unique DNS name for the profile in the domain, a list of (web app deployments) that you specify, and which can be one of the following:

  1. Performance: Select this method if your end points are deployed in different geographical locations and you want to use the one with lowest latency (closer to the user).
  2. Priority: Select this when you want to select an endpoint which has highest priority and is available.
  3. Weighted: Select this method when you want to distribute traffic across a set of endpoints as per the weight provided

How Traffic Manager works:

When you configure a Traffic Manager profile, the settings that you specify provide Traffic Manager with the information needed to determine which endpoint should service the request based on a DNS query. No actual endpoint traffic routes through Traffic Manager.

  1. User traffic to company domain name: The client requests information using the company domain name. The goal is to resolve a DNS name to an IP address. Company domains must be reserved through normal Internet domain name registrations that are maintained outside of Traffic Manager. In Figure 1, the example company domain is
  2. Company domain name to Traffic Manager domain name: The DNS resource record for the company domain points to a Traffic Manager domain name maintained in Azure Traffic Manager. This is achieved by using a CNAME resource record that maps the company domain name to the Traffic Manager domain name. In the example, the Traffic Manager domain name is
  3. Traffic Manager Domain name and profile: The Traffic Manager domain name is part of the Traffic Manager profile. The user’s DNS server sends a new DNS query for the Traffic Manager domain name (in our example,, which is received by the Traffic Manager DNS name servers.
  4. Traffic Manager Profile rules processed: Traffic Manager uses the specified traffic routing method and monitoring status to determine which Azure or other endpoint should service the request.
  5. Endpoint domain name sent to user: Traffic Manager returns a CNAME record that maps the Traffic Manager domain name to the domain name of the endpoint. The user’s DNS server resolves the endpoint domain name to its IP address and sends it to the user.
  6. User calls the endpoint: The user calls the returned endpoint directly using its IP address.

Note: Since the company domain and resolved IP address are cached on the client machine, the user continues to interact with the chosen endpoint until its local DNS cache entry expires. It is important to note that the DNS client caches DNS host entries for the duration of their Time-to-Live (TTL). Retrieving host entries from the DNS client cache bypasses the Traffic Manager profile and you could experience connection delays if the endpoint becomes unavailable before the TTL expires.

To implement Traffic Manager

  1. Deploy the Web Apps in different Geographical locations
  2. Browse à Traffic Manager profiles –> Add
  3. Set Name=Demo, Routing Method = Weighted –> Create
  4. Go to Traffic Manger –> Settings –> End Points –> Add
  5. Type = Azure EndPoint, Name=WebApp1EP, Target Resource Type = App Service, Choose an App Service, Weight = 1 –> OK
  6. Repeat step 5 for every Web App deployment.

Scaling a Web App in Azure Web App

Scaling a Web App

  • Whether your application needs to handle a few hundred requests per day or a few million requests per day,
    the Azure Web Apps scalability features provide ways for you to deliver the right level of scale in a robust,
    cost-effective manner.
  • When you consider the scalability requirements of an application, you should look at its resource requirements
    vertically (scaling up) horizontally (scaling out).
  • You typically choose to scale up when any single request demands more memory and processing power to complete,
    and the bottleneck / latency in the system is the intensive number of software objects created in the computer’s
    memory or the intensive algorithms and business logic that is performed. When you scale up a web app, you increase
    the resource capacity, such as RAM and CPU cores, of the virtual machine on which your web app is running.
  • You typically scale out when any single request requires less memory and processing power to complete, but
    the real bottleneck / latency is in network communication, disk access, etc. In this case, the key to completing
    each request more efficiently is to run it in parallel to other requests as each wait on external components to
    complete. To scale out a web app, you increase the number of virtual machine instances on which your web app is
    running. For the properly architected app, this means your web app can handle more load and therefore service
    more user requests.

Scale Up the Azure Web App:

  • The ability to scale up a web app exists only for web apps configured for Basic, Standard, or Premium pricing
  • The scale settings take only seconds to apply and affect all web apps in your App Service plan.
    They do not require your code to be changed or your applications to be redeployed.

To Scale Up:

  1. App Services –> Select App Service –> Settings –> Change App Service Plan
    (In App Service Plan) –> Select / Create New Plan
  2. Select the Pricing tier based on following options:
    1. Number of Cores
    2. RAM
    3. Storage
    4. Slots (Number of CPU Instances)
    5. Backup frequency
    6. Traffic Manager facility

To Scale Out:

The number of Virtual Machine Instances you can scale out is limited by the pricing tier configured for your web app.

  1. App Services –> Select App Service –> Settings –> App Service Plan
  2. Select Scale Out (App Service Plan) to configure settings
    1. Scale by: Manual – Manual setup means that the number of instances you choose won’t change,
      even if there are changes in load.
    2. Scale by: CPU percentage: Automatically scale based on CPU Percentage used. You can choose
      an average value you want to target.
    3. Scale by: Schedule and Performance Rules – Create your own set of rules. Create a schedule
      that adjusts your instance counts based on time and performance metrics.

Auto scale based on CPU percentage:

  • The Target range setting defines the minimum and maximum CPU percentage to target.
  • As long as the CPU percentage is within this range, Autoscale will not increase or decrease the number
    of instances.
  • When the CPU percentage exceeds the maximum CPU percentage you specify, Autoscale will add an instance.
    If CPU percentage continues to exceed the maximum CPU specified, then Autoscale will add another instance.
  • At no point will you have more than the maximum number of instances specified in the Instances setting.
  • Similarly, when CPU percentage falls below the minimum CPU percentage you specify, Autoscale will remove
    an instance. If CPU percentage continues to all below the minimum CPU percentage specified, then Autoscale
    will remove another instance. At no point will you have fewer than the minimum number of instances specified
    in the Instances setting

Note: The CPU percentage is measured as an average across all instances. For
example, if you have two instances, one of which is running at 50 percent CPU and the other of which is running
at 100 percent CPU, then the CPU percentage would be 75 percent for all the instances at that point in time

Auto scale based on a recurring schedule:

This can be particularly useful when demand for your web app is predictable. For example, if your web app provides
services for an industry where most work is done Monday through Friday, then you could configure Autoscale to
increase the number of instances during the week to support peak demand and decrease the number of instances
on weekends when demand is very light.

Azure Scaling Web App

Microsoft Azure App Services – Part 3

Automate deployment from Dropbox and One Drive

Dropbox is not a source control system, but if you store your source code in Dropbox you can automate deployment
from your Dropbox account.

  1. Create a drop box account @
  2. Go to
  3. Select the App Service –> Settings –> Publishing –> Deployment Source –> Configure required Settings –> Dropbox
  4. Authorize Azure to access your drop box
  5. Go to and go to folder Apps –> Azure –> App Service Name
  6. Upload the files to the above folder
  7. Go to Azure Portal
  8. Select the App Service –> Settings –> Publishing –> Deployment Source –> Sync the App Service
  9. View the page in browser.

Note: Similar steps are required even for One Drive.

Continuous delivery using Visual Studio Team Service

Continuous Integration – Set up continuous integration and deployment workflows with VSTS, GitHub, TeamCity, Hudson or BitBucket – enabling you to automatically build, test and deploy your web app on each successful code check-in or integration tests.

Visual Studio Team Services(VSTS) – (formerly Team Foundation Service- TFS) is Microsoft’s cloud-based solution for source control and team collaboration. The service is free for a team of up to 5 developers. You can do continuous delivery to a web app in App Services, and your repository can use either Git Or TFVC (Team Foundation Version Control).

  1. Create your FREE account of VSTS
  2. Check in a project to source control.
    1. If you’re not signed in to your Visual Studio Team Services account,
      visit http://{youraccount}, sign in now.
    2. In VS.NET, Right Click on Solution and Chose “Add Solution to Source Control”
    3. In VS.NET, Right Click on Solution –> Source Control –> Check In
  3. Connect the project to Azure
    1. Go to (Azure Classic Portal)
    2. Select Web App –> Choose the Set up deployment from source control link.
    3. In the wizard, type the name of your Visual Studio Team Services account in the textbox and click the Authorize Now link. You might be asked to sign in.
    4. In the Connection Request pop-up dialog, choose the Accept button to authorize Azure to configure your team project in VSTS.
    5. When authorization succeeds, you see a dropdown containing a list of your Visual Studio Team Services team projects. Choose the name of team project that you created in the previous steps, and then choose the wizard’s checkmark button.
  4. Trigger a rebuild and redeploy your project
    1. In Visual Studio’s Team Explorer, choose the Source Control Explorer link
    2. Navigate to your any of your project file and open it.
    3. In Solution Explorer, open up a file and change it. For example, change the file _Layout.cshtml
      under the Views\Shared folder in an MVC web role.
    4. Check In pending changes
    5. Choose the Home button to return to the Team Explorer home page
    6. Choose the Builds link to view the builds in progress. Team Explorer shows that a build has been
      triggered for your check-in.
    7. Double-click the name of the build in progress to view a detailed log as the build progresses.

    Note: While the build is in-progress, take a look at the build definition that was created when you linked
    TFS to Azure by using the wizard. Open the shortcut menu for the build definition and choose Edit Build Definition.

      1. In the Trigger tab, you will see that the build definition is set to build on every check-in by default.
      2. In the Process tab, you can see the deployment environment is set to the name of your App Service