As many of your employees or customers continue to embrace virtual desktop environments, Azure Virtual Desktop (short AVD) remains a crucial solution for delivering secure and scalable virtual desktops and applications. One key aspect of optimizing your AVD deployment is understanding where your data is stored and managed. Azure regions, grouped by geography, play a vital role in this.
In this blog post, we’ll work out the complexities of data locations in AVD, exploring how different types of data are stored and what it means for you as administrators.
Understanding Data Locations in Azure Virtual Desktop
When deploying AVD resources, you’ll need to specify the Azure region they’ll be created in. The region determines where the data associated with these resources will be stored. Although AVD is a non-regional service, the data related to its resources is stored according to the specified region’s geography.
AVD manages a variety of data for its service objects, such as host pool names, application group names, workspace names, and user principal names. This data falls into several categories, including customer input, customer data, diagnostic data, and service-generated data. Understanding these categories is paramount when navigating AVD’s data storage process.
Customer Input Data
Setting up Azure Virtual Desktop involves creating host pools and other service objects, requiring you to input details like host pool names and application group names. This customer input data is stored in the geography linked to the Azure region where the resource is created. It encompasses all data entered during the deployment process and any configuration changes made later. This data is sometime referred as “metadata” of the AVD service.
Customer Data
While the AVD service doesn’t store user data or application-related data directly, it does store customer data such as application names, virtual machine names, and user principal names. This data forms part of the resource deployment process and, like customer input data, is stored in the geography associated with the Azure region where the resource was created. This data is sometime referred as “metadata” of the AVD service.
Diagnostic Data
Diagnostic data is generated by the AVD service during user and administrator interactions. This data is crucial for troubleshooting, support, and monitoring the health of the service. Examples include information about VM registration to host pools and user session connections. Diagnostic data is stored in the geography of the Azure region where the host pool is created and is also sent to the location closest to the user for service infrastructure purposes.
Service-Generated Data
Service-generated data ensures Azure Virtual Desktop’s reliability and scalability. This type of data helps Azure analyse traffic patterns and service usage to manage infrastructure health and performance efficiently. For instance, Azure processes service usage logs to understand peak times and necessary regional infrastructure capacity increases.
Data Locations
AVD supports storing customer input data and service-generated data across various geographies, including:
- Asia Pacific
- Australia (AU)
- Canada (CA)
- Europe (EU)
- India (IN)
- Japan (JP)
- South Africa (ZA)
- United Kingdom (UK)
- United States (US)
Service-generated data from all locations is aggregated and sent to the US geography, albeit scrubbed of any identifiable information. Customer data, however, remains localized to the specific region it was created in.
Data Encryption and User-created / App-Related data
Data handled by AVD is encrypted at rest and mirrored geo-redundantly within the chosen geography for disaster recovery purposes. User-created or app-related information, such as app settings and user data (for example the session hosts itself or FSLogix profiles), resides in the Azure region selected by you and isn’t managed by the AVD service.
Conclusion
Solving the puzzle of data locations in AVD is essential for optimizing deployment and ensuring adherence to data residency regulations. For instance, if your organization is based in Switzerland, you should select Europe as the geographic region for your AVD “metadata”, due to performance and geographic considerations. While your session hosts and user-data can be stored within Switzerland, the metadata will be stored in Europe. As mentioned earlier, this does not pose a problem concerning regulatory standards since no app-related or customer-specific data is stored in the metadata.
However, it’s important to consider that if you include any kind of identification within the naming of your resources, an association with your customers could potentially be made even though only the metadata is stored. For example, using customer names or identifiable information in host pool names or application group names might result in identifiable traces in the metadata. This means that indirectly, customer associations could be made from the metadata, even if the actual app-related or customer-specific data remains protected.
Understanding where and how your data is stored allows you to leverage AVD effectively, creating a secure, efficient, and compliant virtual desktop environment tailored to your organization’s specific needs and regulatory standards.
For more detailed guidance, refer to Data locations – Microsoft Learn.