Network topology considerations when using Azure AD Application Proxy

Hi folks,

Over the past few weeks we've had a number of customers ask us about network considerations to take into account when deploying the Azure AD app proxy. Where should the connectors be deployed? What usage characteristics determine the best option?

This has come up often enough that I decided it was time to write this down in a post.

First some basics:

Traffic flow:

When an application is published through Azure AD app proxy, all traffic from the users to the target backend applications flows through 3 hops.

  1. Hop 1: User to Azure AD App Proxy service's public endpoint on Azure
  2. Hop 2: App proxy service to the connector
  3. Hop 3: Connector to target application

Tenant location and App proxy service location:

When you sign up for an Azure AD tenant, the region of your tenant (US, EMEA, APAC etc) is determined based on the country you specify. When you enable App proxy, the App proxy service instances for your tenant are lit up in the same region as your Azure AD tenant (or the closest region to it).

Note: currently, as of this post date, the app proxy instances are available in EMEA, Australia and US.

E.g – If your Azure AD Tenant's region is EU, all your Azure AD Application Proxy connectors will be connected to the App proxy service instances in Azure data centers in EU. This also means that all your users will go through the app proxy service instances in this location, when trying to access published applications.

Before you ask J, there currently isn't any way to change your AAD tenant's region or App Proxy server instance region, once it has been established

Considerations for reducing latency

First off, remember that any proxy solution introduces latency into the connection.

No matter which proxy or VPN offering you may choose as your remote access solution, it will always include a set of servers enabling the connection to inside your corporate network. Traditionally these have been server endpoints in your DMZ, but of course, in the case of the Azure AD App proxy, no DMZ is needed. When using the Azure AD App proxy, as covered above, traffic flows thru the proxy service in the cloud and the connector in the corporate network.

Connector Placement:

While the App proxy service instances' location is chosen for you (based on your tenant location), you get to decide where to install the Connector. And that can have a great influence on the end-to-end latency characteristics of the traffic.

As you evaluate the options, here are some of the questions to ask:

  1. Where is the app located?
  2. Where are the majority of the users accessing the app from?
  3. Where is the app proxy instance located? <remember this follows your tenant>
  4. Do you already have a dedicated network connection to Azure Data Centers (like Express Route or similar VPN set up)?

The placement of the connector will determine the latency of hop #2 and hop #3. When evaluating the placement of the Connector you should consider the following:

  • The connector will need line of sight to a DC to perform KCD operations, when u want SSO to backend applications.
  • The connector is typically installed closer to the app to reduce time from the connector to the application.

General approach:

You can try and minimize the latency of the end to end traffic, by optimizing each of the network hops that the traffic flows over.

Each hop can be optimized by:

  1. Reducing the 'distance' that between the two ends of the hop
  2. Choosing the right 'network' to traverse. For example, traversing a private network <when available> rather than the public internet may be faster due to dedicated links.

    For example, if you have a dedicated VPN/Express Route link between Azure and your corporate network, you may want to leverage that.

Focusing your optimizing strategy

Since your users are accessing the app remotely over the internet anyways, it makes sense to focus on optimizing hops 2 and 3. Below are some of the common patterns to follow.

Pattern #1: Prioritize optimizing hop #3:

In this pattern, the connector is placed close to the target application in the customer network. The advantage with doing this, as called out above, is that the connector is likely to need line of sight to the Domain Controller anyways. This approach optimizes hop #3 and is usually enough for most customers and scenarios. Most of our customers follow this pattern.

Optimizing hop #2 and #3:

There are some scenarios where you will need to optimize both hop #2 and hop #3 to get the latency characteristics you want. If you have a VPN or ExpressRoute setup between your network and the Azure datacenter, that allows you to optimize hop #2 in addition to hop #3.

Pattern #2: Taking advantage ExpressRoute with public peering

If you have an ExpressRoute setup with public peering, then we will leverage the faster ExpressRoute connection for hop#2. Hop #3 is already optimized by placing the connector close to the app in the customer network.

Pattern #3: Taking advantage ExpressRoute with private peering

If you have a dedicated VPN or Express Route setup with private peering between Azure and your corporate network where the app is installed, you have another option. In this configuration, the virtual network in Azure is typically considered as extension of the corporate network. So you can install the connector in the Azure datacenter and still satisfy the low latency requirements of the connector-to-app connection for Hop #3. Latency is not compromised because traffic is flowing over a dedicated connection. However, you get the added benefit of improving the latency characteristics of hop #2. This is because the Proxy service-to-connector connection (hop #2) is a shorter hop, as the connector is installed in an Azure datacenter close to your AAD tenant (and therefore App proxy) location

Other approaches:

While the focus above has been on the placement of the connector, I should point out that, if moving the application is an option (for example: to Azure or another hosted environment), then the application's placement can be changed to get better latency characteristics. Increasingly, organizations do have their networks stretch into a hosted environment. If so, this allows the app to be placed in the hosted environment that is part of the corporate network and still be 'within the domain'. In that case, the above patterns can be applied to this new application location.

If you're considering this option, do take a look at Azure AD Domain Services—which offers a ready AD like environment in the cloud, into which you can move apps that rely on LDAP.

Also, consider using connector groups to target apps that are in different locations/networks.

Common Scenarios:

In the section below I walk through a few use cases to make this clearer. For all the cases below, let's assume the Azure AD tenant (and therefore proxy service endpoint) is in the US. You can extrapolate to other regions and the same considerations will apply.

Use Case 1: App is in a customers' network in the US. And most users are in the same region. No express route or VPN between and Azure DC and the corporate network.

Recommendation: Follow pattern #1 above. For improved latency, consider leveraging ExpressRoute, if needed <see use case #3 and #4>

This is the simple case. The most common pattern is to optimize hop#3. The connector is placed near the app. This is also a natural choice, because the connector typically is installed with line of sight to the app and to the DC to perform KCD operations.

The picture below follows pattern #1 above.

Use Case 2: App is in a customers' network in the US. And users are spread globally. No express route or VPN between and Azure DC and the corporate network.

Recommendation: Follow pattern #1 above. For improved latency, consider leveraging ExpressRoute, if needed <see use case #3 and #4>

As covered above, the common pattern is to optimize hop#3. The connector is placed near the app for reasons covered above. Hop #3 is not too expensive as it is all within the same region. However, hop #1 can be expensive depending on where the user is, because all users will hit the app proxy instance in the US. <It's worth noting that any proxy solution will have similar characteristics here with respect to users being spread out globally>

Again this matches pattern #1 above.

Use Case 3: App is in a customers' network in the US. ExpressRoute with public peering exists between Azure and the corporate network.

Recommendation: Place the connector closest to the app. The system will automatically use ExpressRoute for hop #2. This follows pattern #2 described above.

If the ExpressRoute link is using public peering, then the traffic between the proxy and the Connector will flow over that link and hop#2 will have optimized latency.

Use Case 4: App is in a customers' network in the US. ExpressRoute with private peering exists between Azure and the corporate network.

Recommendation: Place the connector in the Azure DC that is connected to the corp network through ExpressRoute private peering. This follows pattern #3 described above.

The Connector can be placed in the Azure DC. Since it still has line of sight to the application and the DC through the private network hop #3 remains optimized. However, this setup additionally optimizes hop #2 further.

Use Case 5: App is in a customers' network in the EU. And most users are in the US.

Place the connector near the app. For the reasons covered above, this is the natural choice. Since the US users are hitting an app proxy instance that happens to be in the same region, Hop#1 is not too expensive. Hop #3 is optimized. However, Hop #2 is expensive in this story.

Consider leveraging ExpressRoute as called out in patterns #2 and #3 above. Below I show pattern #2 applied.

One other variant to this use-case that you can consider employing is below:

If most users in the organization are in the US, then chances are that your network 'extends' to the US as well. If that is the case, the connector can be placed in the US and can leverage the dedicated internal corporate network line to the application in the EU. This way hop #2 and hop#3 are optimized.

Future improvements:

We are looking into making proxy instances available in more datacenters around the globe and making the proxy instances more geo aware. This could help reduce the latency on hop #1 and hop #2 across many of the cases above.

As always, we'd love your feedback. Contact us at with any comments/questions that you might have.


Girish Chander

Principal PM Manger, Identity Division, Microsoft


Comments (15)

  1. Tony says:

    Good and detailed explanation.

    The Azure Application Proxy is a great service that offloads a lot of responsibilities to Azure (DDoS protection, no inbound firewall rules needed etc.) but I think the product is still too immature to allow for serious production usage.

    I think the value of the Azure Application Proxy is diminished by the fact that you can’t pick the region that the endpoint is installed in. Not only it defaults to the general region where Azure AD is based on (for us is the US) but you can’t even pick the specific Datacenter. For example, what if I have users and servers in the West coast and I want them to access an endpoint to a US West region? I don’t currently have that option. The endpoint could very well be created in the East Coast causing users to travel the country twice before they get to the service.

    The latency experience is too unpredictable the way the endpoints are provisioned right now, making product unsuitable for important production workloads.

    Also, I have not been able to locate any guidelines in terms of performance for the endpoints running in Azure (how much load can each endpoint endure etc.) Is there a document that explains this?

    1. @Tony: thanks for the feedback. As I mentioned above, we are looking to improve the offering in this regard and will take this feedback into consideration for sure. If you are having specific latency concerns send us a note and we’d love to help you. On the last point you made, our goal is to make it so you don’t have to worry about the load on the service end. We will scale out/up to handle the load you throw at us, so you don’t have to worry about it.

      1. Tony says:

        Thanks for the reply, Girish.

        I realize I might have been a bit harsh with my comments. To set the record straight, I think AAD Application Proxy is a fantastic idea. Especially because of the fact that I don’t have to involve my network team anymore to publish apps.

        Understood about the performance scale. Are there any service limits, though? For example, can I host an HTTP file repository behind where people download large files from? What kind of speeds should I expect? Also, will I incure any bandwidth costs?

        Very much looking forward to the geo-awareness of the solution. I think that will make the offering unbeatable.

        Thanks for your work,

        1. @Tony. Thanks for the note Tony. Am glad you like the service and it’s our endeavor to continue to improve it. We have no published service limits. And unlike an IAAS like solution, we don’t charge for bandwidth through the service. We do require that users accessing the service have a valid AAD-P license.

  2. trang says:

    can i manage about bandwith of each session access to application i publish by azure application proxy guys, thanks you

    1. @trang: not sure I got the question. can u elaborate please?

      1. trang says:

        because international bandwith internet of my company is so low, so i want manager bandwith for each session user connect to web app, which publish through application proxy.
        with my situation, i from vietnam, and i want publish web app, its used to download or upload file from user, size of file about 2->5 MB and with my knowledge, application proxy will locate on singapore, so with my low bandwith internet connect from vietnam to singapore, what should i do for user can use this web applicaion normal?

        1. @trang: Hey can you send an email to We can dive in deeper into this and guide you there.

  3. Jason says:

    I wikl imediately snatch youhr rrss ass I caan noot finhd your
    email subsceiption hyperlknk orr e-newsletter service.
    Do you’ve any? Kindly permitt mme recognhise in order tgat I
    may justt subscribe. Thanks. Itss like yyou read myy
    thoughts! You seesm too knmow a llot about this,
    likie yyou wrkte tthe e-book inn itt oor something.
    I bbelieve that you just can doo with a feww p.c. too poweer the message hoyse a little bit,
    bbut instead oof that, his iss fanbtastic blog. A great
    read. I’ll defiunitely be back. I’ve ben browsinng online more than 4 houes today, yeet I nevrr foundd aany interesting aeticle likee yours.
    It iis ptetty wrth enough forr me. Personally, iif aall website owqners andd bloggers mqde good
    cointent aas youu did, thhe iinternet wkll bbe much mode usefl
    thn ver before.

  4. Further, when ignored low testosterone could be a gateway to Alzheimers, diabetes,
    osteoporosis and plenty of other serious circumstances.

  5. Hi there colleagues, how is the whole thing, and what you want
    to say regarding this post, in my view its actually remarkable in favor of me.

  6. fran ms says:

    Thanks for this clear information.
    What if my onpremise app is an azure VM with azure AD domain services ?
    Should I need an site to site VPN to connect the application?
    Does hop #2 travels internally and I dont need a VPN to Connect?
    Could you give some information about this or redirect to where I can find it?
    RThanks in advance

    1. fran ms says:

      Thank you for your answer in private message.
      I understand, I don´t need VPN between app proxy service and app proxy connector if I place all the parts in the same azureVNET

      1. fran ms says:

        This is only to confirm I´ve been answered.
        Thank you

Skip to main content