Resource Groups and Subscriptions

Lesson: Resource Groups and Subscriptions in Azure Virtual Desktop

Introduction: The Foundation of AVD Architecture

When you begin architecting an Azure Virtual Desktop (AVD) environment, it is tempting to jump straight into creating session hosts and configuring application groups. However, the most critical decisions you make occur at the organizational layer: how you structure your subscriptions and resource groups. These logical containers are not merely administrative folders; they are the bedrock of your security, billing, networking, and governance strategy. If you get this structure wrong at the start, you will face significant friction when you need to scale, audit, or migrate resources later.

In the context of AVD, a "subscription" acts as your primary billing and quota boundary, while a "resource group" serves as a logical collection of related assets that share a common lifecycle. For an enterprise, an AVD deployment is rarely just a few virtual machines. It involves virtual networks, storage accounts for FSLogix profiles, Azure Key Vaults for secret management, and potentially complex identity configurations. Understanding how to distribute these across subscriptions and resource groups is the difference between a clean, manageable environment and a "spaghetti" infrastructure that is impossible to troubleshoot.

This lesson explores how to plan, organize, and implement these containers effectively. We will look at the trade-offs between centralized and decentralized management, the implications of Azure Policy on resource groups, and the real-world considerations for multi-region or multi-business-unit deployments.

Understanding Subscriptions: The Billing and Quota Boundary

A subscription is the highest level of hierarchy in your Azure environment. It defines your billing relationship with Microsoft and establishes the limits for how many resources you can deploy. When planning for AVD, you must decide whether to host your desktop infrastructure in a dedicated subscription or mix it with other services.

Why Subscription Planning Matters for AVD

AVD consumes a significant amount of resources, particularly in terms of virtual machine vCPU cores and network bandwidth. If you place your AVD session hosts in a subscription that already hosts your production database servers or web applications, you may hit regional core quotas unexpectedly. By segregating AVD into its own subscription, you protect your production workloads from "noisy neighbors" and simplify your billing reconciliation.

Subscription Design Strategies

There are three common patterns for organizing subscriptions in an AVD deployment:

1. The Monolithic Subscription: In this model, everything—networking, storage, and session hosts—resides in one subscription. This is easy to manage for small businesses with fewer than 50 users, but it becomes a management nightmare as the organization grows.
2. The Hub-and-Spoke Subscription Model: This is the industry standard for enterprise environments. You maintain a "Connectivity" subscription for shared networking (VPNs, ExpressRoute, Firewalls) and a "Workload" subscription specifically for AVD session hosts. This allows networking teams to manage the hub while AVD administrators manage the spoke.
3. The Business Unit/Geographic Model: Large organizations often split subscriptions by department or region. For example, the "North America AVD" subscription might be separate from the "Europe AVD" subscription to comply with data residency laws or to decentralize budget ownership.

Callout: Subscription vs. Management Group It is vital to distinguish between a subscription and a management group. A management group is a container that holds multiple subscriptions. You use management groups to apply Azure Policies and RBAC (Role-Based Access Control) at scale. Think of the management group as the "policy engine" and the subscription as the "billing and quota bucket."

Resource Groups: The Lifecycle Container

Once you have your subscriptions defined, you must organize your resources into groups. A resource group (RG) should contain resources that share the same lifecycle. If you delete the resource group, everything inside it is deleted. This is a crucial concept for AVD, where you might have "ephemeral" pools that you destroy and recreate frequently.

Best Practices for Organizing AVD Resource Groups

A common mistake is creating a single resource group called AVD_Resources and dumping everything into it. As your environment grows, this leads to confusion regarding which resources support which host pool. Instead, use a structured naming convention and functional grouping.

Recommended Resource Group Layout:

• Networking RG: Contains your Virtual Network, Subnets, and Network Security Groups (NSGs). These resources rarely change and should be kept separate from the volatile session hosts.
• Identity/Storage RG: Contains the storage account for FSLogix profiles and any Key Vaults used for automation secrets.
• Host Pool AVD RG: Contains the session host virtual machines, network interfaces, and OS disks for a specific host pool. By grouping these together, you can easily delete an entire host pool's infrastructure without impacting your shared storage or network config.

Practical Example: Implementing a Structured Layout

Imagine you are deploying a pooled host pool for the "Finance" department. Your deployment should look like this:

• rg-network-prod: Contains the VNET where the Finance pool connects.
• rg-storage-finance: Contains the Azure Files share for FSLogix profiles.
• rg-avd-finance-01: Contains the VMs for the Finance AVD pool.

If the Finance department decides to decommission their desktop environment, you simply delete rg-avd-finance-01. Your network and storage foundations remain intact, ready to be repurposed for another department.

Step-by-Step: Planning and Implementation

To implement a robust structure, follow this systematic workflow.

Step 1: Define the Network Topology

Before deploying the first virtual machine, define where your network resides. If you are using a hub-and-spoke model, ensure your AVD subscription has the necessary permissions to peer with the Hub VNET.

Step 2: Configure Role-Based Access Control (RBAC) at the RG Level

Do not assign permissions at the subscription level if you can avoid it. Assigning "Contributor" rights at the subscription level gives users control over your entire infrastructure. Instead, assign the "Desktop Virtualization Contributor" role at the resource group level.

# Example: Assigning AVD Contributor role to a specific Resource Group using Azure CLI
az role assignment create \
    --assignee "user@example.com" \
    --role "Desktop Virtualization Contributor" \
    --resource-group "rg-avd-finance-01"

Step 3: Deploying Resources with Consistency

Use Infrastructure as Code (IaC) to ensure your resource groups are created with the same tags and locks every time. Tags are essential for billing—if you don't tag your resource groups, you will never know which department is costing you the most in compute hours.

Tip: Use Resource Locks Always apply a ReadOnly or CanNotDelete lock to your core networking resource group. This prevents a junior administrator from accidentally deleting the VNET that connects your AVD environment to your on-premises domain controllers.

Managing Quotas and Scaling Limits

One of the most overlooked aspects of subscription planning is the "vCPU quota." Azure limits the number of vCPU cores you can provision in a specific region. When you create a host pool, you might need 50 VMs of the D4s_v3 series. If each VM has 4 cores, that is 200 cores. If your subscription is capped at 100 cores, your deployment will fail.

Handling Quota Issues

1. Check your current usage: Go to the "Usage + Quotas" blade in your subscription.
2. Request an increase: Do this before the project kickoff. Microsoft usually takes 24-48 hours to process quota increases.
3. Plan for "Bursting": If you use auto-scaling, your host pool might expand during peak hours. Ensure your quota covers the maximum possible number of VMs, not the average.

Networking and Resource Groups: The "Split-Brain" Problem

A common architectural trap is separating the AVD session hosts from their virtual network by too many layers of abstraction. While you want to keep networking in its own resource group, ensure that the AVD resource group has the correct permissions to interact with that network.

Specifically, the "Network Contributor" role is often required for the service principal or the user deploying the host pool so that they can attach the virtual machines to the existing subnet. If you try to deploy a host pool into a VNET that resides in a different resource group without proper delegation, the deployment will time out during the network interface creation phase.

Best Practice: Service Principal Delegation

Instead of granting human users broad network permissions, use a service principal for your AVD automation. Grant this service principal Network Contributor access only to the specific subnet within the network resource group.

{
  "roleDefinitionName": "Network Contributor",
  "principalId": "your-service-principal-id",
  "scope": "/subscriptions/sub-id/resourceGroups/rg-network-prod/providers/Microsoft.Network/virtualNetworks/vnet-main/subnets/avd-subnet"
}

Security and Governance: Azure Policy

Resource groups are the target for Azure Policies. You can enforce rules such as:

• "All resources in the AVD resource group must have a 'CostCenter' tag."
• "Virtual machines in this resource group must use Managed Disks."
• "Public IP addresses are forbidden in this resource group."

By using these policies, you ensure that even if a new administrator creates a resource, it complies with your corporate security standards. Applying these at the resource group level is much safer than applying them globally, as it allows for exceptions where they might be needed for testing or development.

Callout: The "Ephemeral" Resource Group For testing purposes, always create a dedicated "Sandbox" resource group. Apply a policy that automatically deletes resources in this group after 7 days. This prevents "zombie" resources—unused virtual machines that continue to accrue costs long after a proof-of-concept project has ended.

Common Pitfalls and How to Avoid Them

1. The "Default Resource Group" Trap

When you deploy AVD via the Azure Portal, it often prompts you to create a new resource group. Many admins accept the default naming convention. This leads to a fragmented environment where you have resource groups named rg-12345 that offer no context about what they contain. Always define your own naming convention (e.g., rg-[environment]-[service]-[location]) before clicking "Create."

2. Ignoring Regional Latency

If your users are in Europe but you create your resource group and host pool in the US, the latency will make the desktop experience unusable. Always create your resource group in the region closest to your users. Remember that while your storage (FSLogix) can be in a different region, the session host VMs must be physically close to the user's connection point.

3. Mixing Production and Development

Never put your "Production" host pools and your "UAT" (User Acceptance Testing) host pools in the same resource group. If you need to apply a restrictive network security group to your production environment, you might inadvertently block your UAT environment. Keep them in separate resource groups, even if they share the same subscription.

4. Over-complicating RBAC

Avoid creating custom roles unless absolutely necessary. The built-in roles like "Desktop Virtualization Contributor" and "Desktop Virtualization Operator" cover 95% of use cases. Custom roles are harder to maintain and often break during Azure API updates.

Comparison: Subscription and Resource Group Strategies

Troubleshooting Deployment Failures

When a host pool deployment fails, the error message often points to the resource group or subscription. Here is how to interpret the most common errors:

• "AuthorizationFailed": This almost always means the user or service principal lacks the correct role on the resource group. Check if you have Contributor or Desktop Virtualization Contributor rights.
• "QuotaExceeded": Your subscription has hit its core limit. You need to request a quota increase via the Azure Portal.
• "SubnetNotFound": You are attempting to deploy the host pool into a resource group that doesn't have visibility into the VNET. Ensure the VNET resource group and the AVD resource group are in the same subscription or peered correctly.

Practical Checklist for New Deployments

Before clicking "Deploy" on any AVD component, verify:

1. Naming Convention: Does the RG name follow the company standard?
2. Region: Is the RG in the same region as the VNET?
3. Tags: Are the mandatory cost-center tags applied?
4. Locks: Are the appropriate resource locks enabled to prevent accidental deletion?
5. Permissions: Does the deployment identity have access to the target subnet?

The Role of Tags in Resource Management

Tags are key-value pairs that help you categorize your resources. In a large AVD environment, you might have hundreds of virtual machines. Without tags, you cannot answer basic business questions like, "How much did the Marketing department's AVD usage cost this month?"

Recommended Tagging Schema:

• Department: (e.g., Finance, HR, IT)
• Environment: (e.g., Prod, Dev, Test)
• Owner: (e.g., The person responsible for the host pool)
• CostCenter: (e.g., 100234)
• Project: (e.g., AVD-Migration-2024)

By applying these tags at the resource group level, you can ensure that all resources created within that group inherit the tags, provided you configure the policy correctly.

Handling Multi-Region Deployments

If your organization has offices in London, New York, and Tokyo, you cannot use a single resource group for all session hosts. You must create regional resource groups.

Why?

• Latency: The session host must be in the same region as the user.
• Data Residency: Some countries require that data (like user profiles in FSLogix storage) remains within their borders.
• Disaster Recovery: If one region goes down, you want your infrastructure isolated so that a failure in the US doesn't cascade into the UK.

When deploying multi-region, use a single subscription (if the billing model allows) but create distinct resource groups for each region. This keeps your management plane unified while keeping the data plane localized.

Managing Lifecycle with Azure Resource Graph

Once you have a large number of resource groups, finding resources becomes difficult. Use the Azure Resource Graph Explorer to query your environment. This is a powerful tool for administrators to maintain order.

For example, to find all resource groups that do not have a "CostCenter" tag, run the following Kusto Query Language (KQL) command:

resourcecontainers
| where type == 'microsoft.resources/subscriptions/resourcegroups'
| where not(tags has 'CostCenter')
| project name, tags

This allows you to proactively identify "orphaned" or improperly configured resource groups before they become a billing or compliance issue.

Advanced: Scaling and Automation

As your AVD environment matures, you will likely automate the creation of host pools. When using tools like Azure DevOps or GitHub Actions, the pipeline itself needs to be scoped to the correct resource group.

Pipeline Best Practices:

1. Scope the Service Connection: Do not give your CI/CD service principal access to the entire subscription. Scope it down to the specific resource group where the deployment happens.
2. Use Parameterized Templates: Use Bicep or ARM templates that accept the resource group name as a parameter. This allows you to reuse the same code for rg-avd-prod and rg-avd-dev.
3. Validate before Deploy: Use the "What-If" operation in your pipeline. This tells you exactly what resources will be created or deleted before you commit to the deployment.

# Example: Running a What-If analysis on a Bicep template
az deployment group what-if \
    --resource-group rg-avd-finance-01 \
    --template-file main.bicep \
    --parameters hostPoolName=finance-pool

Summary and Key Takeaways

Planning your subscriptions and resource groups is not a one-time task; it is a continuous process of aligning your technical infrastructure with your business needs. By following the principles outlined in this lesson, you can build an AVD environment that is secure, scalable, and easy to manage.

Key Takeaways for Success:

1. Subscription as a Boundary: Always use subscriptions to define your billing and quota limits. Isolate AVD workloads from other production services to avoid resource contention.
2. Lifecycle-Based Grouping: Organize your resource groups by lifecycle. Keep volatile resources (session hosts) separate from stable resources (networking, storage).
3. Naming and Tagging: Implement a strict naming convention and a mandatory tagging policy. This is the only way to manage costs and auditability as your environment grows.
4. Use Infrastructure as Code: Avoid manual portal deployments for production environments. Use templates to ensure consistency and repeatability across different resource groups.
5. Principle of Least Privilege: Never assign permissions at the subscription level if you can achieve the same result at the resource group level. Use built-in AVD roles to minimize security risks.
6. Proactive Quota Management: Monitor your regional vCPU usage and request quota increases before your deployment starts.
7. Policy Enforcement: Use Azure Policy to enforce compliance (tags, locations, resource types) across your resource groups, ensuring that your environment remains secure and cost-efficient by design.

By treating these logical containers as critical infrastructure components rather than just administrative folders, you position your AVD environment for long-term stability and success. Always remember that the effort you put into the planning phase pays dividends when you need to scale, troubleshoot, or audit your environment in the future.