AVD deployment when your other core infra are in a region that doesn't have AVD

Question

Greetings we recently created a new tenant in a different region to support a portion of the business that is located in that part of the world. The tenant has been built out with virtual machines and the sql and app environment that will be consumed by employees in this other region. Unfortunately we didn't catch this beforehand but when we went to deploy the Azure Virtual Desktop environment we discovered that the deployment template is not offered where our existing infrastructure is located. What I mean by this is if I choose to deploy a host pool in the Azure Virtual Desktop blade, I am not given the option to choose SE Asia. I can choose Japan and then have everything except App Group, Host Pool and Workspace live in the same region (SE Asia) while the aforementioned reside in Japan West. Is it a bad practice to set it up this way with App Group, Host Pool and Workspace in a separate but close region than the Hosts, Profile Storage...?

Accepted Answer

Hello @mpls

It's great that you're setting up infrastructure to support your business in a different region! Deploying Azure Virtual Desktop (AVD) resources across regions is a common practice and can be done effectively with proper planning. You can deploy VMs in one region and have the AVD meta data stored in another region. This is documented and supported https://zcusa.951200.xyz/en-us/azure/virtual-desktop/data-locations

Best Practices for Multi-Region Deployment:

Data Residency and Compliance: Ensure that your deployment complies with data residency and compliance requirements for your organization.

Network Latency: Consider network latency between regions. While it's technically feasible to have resources in different regions, higher latency can impact user experience.

High Availability and Disaster Recovery: Deploying resources across regions can improve high availability and disaster recovery capabilities. This setup can help mitigate the impact of regional outages1.

Resource Management: Use Azure Resource Manager templates to manage and deploy resources consistently across regions.

Monitoring and Maintenance: Implement robust monitoring and maintenance practices to ensure the health and performance of your AVD environment.

Steps to Deploy AVD Across Regions:

Create Host Pool in Japan West: Start by creating the host pool in the Japan West region.

Create Workspace and Application Group: Set up the workspace and application group in the SE Asia region.

Configure Network Connectivity: Ensure proper network connectivity between the regions to minimize latency and ensure seamless access.

Deploy Session Hosts: Deploy session host VMs in the Japan West region.

Assign Users: Assign users or groups to the application group for access to desktops and applications.

Additional Considerations:

Template Export and Modification: If you need to move resources between regions, export a template, modify it, and redeploy it in the new region.

Azure Service Tags: Use Azure service tags to simplify network security rules and allow traffic between regions.

If I have answered your question, please accept this as answer as a token of appreciation and don't forget to thumbs up for "Was it helpful"!

Answer

So I think I found my answer to my own question on another site. It is okay to have the Metadata components that consist of the Host Pool, Application Group, and WorkSpace in a separate region then your hosts. For our situation since our other hosts all live in SEA, it makes sense to place the AVD hosts there as well, and then the Metadata components of AVD can live in say Japan West. If someone else wants to correct me on this that would be great, but this is my current understanding that the above statement is considered a viable and supported solution.

Share via

AVD deployment when your other core infra are in a region that doesn't have AVD

1 additional answer

Your answer