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 aadapfeedback@microsoft.com with any comments/questions that you might have.

Girish Chander

Principal PM Manger, Identity Division, Microsoft

@chander_girish