Skip to main content

Scenario: AVD — Dedicated Sovereign Tenant

Executive summary — what this architecture delivers​

Organizations that handle CUI but are not ready to re-platform every workstation and server want a single, well-bounded environment they can point to and say: CUI lives here, nowhere else. The architecture in this chapter — a dedicated sovereign GCC High tenant fronted by Azure Virtual Desktop and hardened with Azure Firewall, Conditional Access, dedicated accounts, and Intune policies — delivers exactly that.

What this gives you:

  • A CMMC attestation anchor. When a prospect or customer asks where the CUI they provide will live, the answer is this tenant and the AVD session hosts inside it. For Level 1 self-attestation, this is the environment being attested to. For a future Level 2 assessment, the same boundary is what a C3PAO walks through.
  • Workstation scope reduction. CUI work happens inside the AVD session host, not on the user's physical laptop. Physical endpoints remain out of CUI Asset scope — CRMAs at most — which takes BitLocker evidence, device-compliance reporting, and endpoint hardening off the daily-driver fleet and concentrates them on the session hosts.
  • Controlled access, end to end. Conditional Access gates who can sign in with phishing-resistant authentication. Azure Firewall constrains what session hosts can reach outbound to an explicit FQDN allow-list. Intune hardens the session host OS with the Open Intune Baseline. Dedicated enclave accounts prevent daily-driver identity commingling with the CUI environment.
  • Contained data. SharePoint and OneDrive in the sovereign tenant hold CUI; sensitivity labels tag it; DLP watches egress. Nothing leaves the tenant without passing the controls documented in the Data pillar.

What this is not:

  • Not a full company-wide GCC High migration. The primary tenant continues to run commercial workloads. Only the enclave is sovereign.
  • Not a substitute for MDM on daily-driver endpoints. Laptops still need basic hygiene; they are simply out of the CUI-assessment scope.
  • Not an automatic Level 2 pass. The enclave is the environment; Level 2 adds the documentation, monitoring, and evidence workstreams described in the rest of the book.

The smallest defensible CUI environment a DIB supplier can operate. The rest of this chapter is the engineering to build it.

Azure Virtual Desktop deploys session hosts as Entra Joined virtual machines, managed by Intune, authenticating through Entra ID—the same identity stack as physical devices.

Prerequisite

Complete Entra Join (The Cloud-Only Path) (DNS records + MDM User Scope) before starting this section. The AVD host pool join and Intune enrollment depend on that foundation being in place.

Step-by-step build procedure in Appendix C.1

This chapter is the architectural reference — what AVD looks like in GCC High, why the personal pool, why dedicated accounts, what each network and identity boundary defends. For the click-by-click deployment procedure (resource group → firewall policy → VNet → AVD workspace → host pool → session hosts → backup → validation), follow Appendix C.1: AVD Deployment Runbook. The runbook is ordered to respect Azure resource dependencies and assumes you've read this chapter for the rationale.

AVD Architecture​

AVD and Microsoft 365 GCC High as the Security Boundary​

In this model, organizations tightly control the identity, device, and data policies in their GCC High tenant. User identities accessing AVDs in this environment should be authenticated with phishing resistant authentication, but organizations may want to leave the machines and the systems that manage them out of the scope of their assessment. Depending on broadly you have enforced device-compliance, you may want to avoid bringing connecting devices and the systems that manage them into assessment scope by excluding from your equivalent of P006 Require compliant devices for O365, Azure, and Management:

  • Azure Virtual Desktop
  • Azure Virtual Desktop Client
  • Windows Sign In

Cross-tenant access settings allow your tenant to trust device claims from another tenant. From a security perspective, I always thought it better to restrict access to compliant devices, even if compliance for that device is managed by someone else. However, I've been told by not activating that control, the system governing that control does not come into assessment scope. Security is different than compliance.

Host Pool Model: Personal (Assigned)​

This deployment uses a personal (assigned) host pool — each user is assigned a dedicated VM that persists between sessions. Benefits:

  • Clean audit trail. All events on a VM map unambiguously to one assigned user, which supports NIST 800-171 account-management and audit-accountability requirements without additional mitigation work.
  • No FSLogix. Personal pools don't need FSLogix profile containers. The Azure Files storage dependency, SMB firewall rules, and profile-mount failure modes are all absent.
  • Predictable user experience. A user's session host retains their installed applications, browser profile, desktop layout, and local app state between sessions. No "fresh profile on every login" anomalies.
  • Simplified troubleshooting. When a user reports an issue, the session host is theirs alone — IT isn't debugging a shared environment where one user's actions affect others.

Authentication (Azure RBAC, No Domain Controllers)​

In the AVD model, authentication is handled by Azure RBAC policies rather than Domain Controller ACLs. Users authenticate using their Entra ID credentials directly. There are no group policy logins, no Kerberos ticket requests to a DC, and no VPN requirement for the authentication path.

Two RBAC roles govern access:

RoleAssigned ToEffect
Virtual Machine User LoginStandard users / AVD user groupAllows interactive sign-in to session hosts
Virtual Machine Administrator LoginIT adminsAllows sign-in with local admin rights

Without one of these roles, a user will receive an "Access Denied" error when connecting—even if the VM is running and healthy.

SSO via RDP Properties​

To prevent double authentication prompts (once at the gateway, once at the VM), SSO must be enabled at the Host Pool level using RDP properties:

PropertyValuePurpose
enablerdsaadauth:i:11Enables Entra ID authentication for the RDP session
targetisaadjoined:i:11Tells the RDP client the target VM is Entra Joined

PIV Cards and CBA with AVD​

For environments where users authenticate with NFC PIV cards (Path 2 in Phishing-Resistant Authentication), the AVD connection flow differs from both the traditional smart card experience and the Windows login screen behavior described in that article.

The key point: the PIV card authenticates the user once, at the Entra gate. It is not used again at the session host.

How the connection flow works​

User taps PIV card at their local workstation
    → Entra CBA validates the certificate
    → Conditional Access: PIV cert satisfies phishing-resistant auth strength
    → AVD Gateway brokers the connection
    → SSO (enablerdsaadauth:i:1) carries the authenticated Entra token to the session host
    → User sees the session host desktop — no second PIN prompt

The session host's Windows login screen is bypassed entirely by SSO. The enablerdsaadauth:i:1 RDP property tells the AVD client and gateway to pass the user's existing Entra token — obtained from the PIV card authentication — directly into the session host's credential provider. The user does not tap the card at the session host because the session host is not the authentication boundary. Entra is.

Operational implications​

  • Users tap their card once to unlock their workstation. That authentication session carries into AVD. The experience is seamless.
  • The PIV card and NFC reader are at the user's physical workstation — they never need to be present in or near the Azure datacenter.
  • If the AVD session times out and triggers re-authentication, the user will be prompted through Entra again, which may require a new card tap depending on your Conditional Access Sign-in frequency setting.
Match CA sign-in frequency to shift length

Set the Sign-in frequency on your PIV CA policy (CA policy → Session → Sign-in frequency) to 8–12 hours to avoid mid-session re-authentication prompts for a standard work shift.

If SSO RDP properties are missing, PIV card logon to the session host will fail

Without enablerdsaadauth:i:1 and targetisaadjoined:i:1, the AVD client issues a second Windows credential prompt at the session host. A PIV card cannot satisfy that prompt over RDP — the card is physically at the user's desk, not at the session host. The session will either fail or fall back to password authentication, breaking the PIV-only enforcement posture.

Network Architecture​

Azure Firewall Topology​

GCC High AVD session hosts must not have public IP addresses. All outbound internet traffic routes through an Azure Firewall deployed in a hub VNet, enforced via a User Defined Route (UDR) applied to the session host subnet.

Session Host Subnet (10.x.x.0/24)
  └─ UDR: 0.0.0.0/0 → Azure Firewall private IP
       └─ Azure Firewall (Hub VNet)
            ├─ Application Rule Collections (FQDN-based)
            └─ Network Rule Collections (port/protocol-based)
                 └─ Internet

The key architectural principle: session hosts have no direct internet path. The firewall is the only egress point, and every allowed destination is explicitly enumerated. A deny-all rule at the lowest priority (4096) catches and logs any traffic not matched by an explicit allow.

Accelerate Your AVD Secure Enclave Build

Architecting an Azure Virtual Desktop enclave for GCC High is a heavy lift. Configuring an Azure Firewall with a deny-all default posture, routing all outbound traffic explicitly, and managing the unique constraints of the sovereign cloud can easily stall an internal IT team for months. If you need hands-on engineering to deploy a high-performance, compliant AVD environment, this is our core competency. Mindline can accelerate your build and ensure your network boundary is defensible for your next compliance assessment. Connect with our architects at mindline.com.

Required Traffic Categories​

Azure Firewall rules for AVD GCC High fall into distinct categories, each with different ownership:

CategoryOwnerExamples
AVD Control PlaneMicrosoft (sovereign)*.wvd.microsoft.us, *.servicebus.usgovcloudapi.net
Identity & AuthMicrosoft (sovereign)login.microsoftonline.us, *.msftauth.net
M365 GCC HighMicrosoft (sovereign)*.mail.protection.office365.us, *.teams.microsoft.us
Windows ManagementMicrosoft (global CDN)*.update.microsoft.com, *.delivery.mp.microsoft.com
Defender for EndpointMicrosoft (sovereign)*.security.microsoft.us, *.winatp-gw-usw.microsoft.com
Customer ApplicationsCustomer-specificLine-of-business FQDNs, SaaS providers

For the full reference rule set with FQDN tables and network rules, see AVD Firewall Reference.

Device Join & Enrollment​

Azure Government compute capacity — plan ahead

Azure Government regions (USGov Virginia, USGov Texas) are currently experiencing significant compute oversubscription. VM provisioning requests for AVD session hosts may fail with a quota or capacity error even when your subscription has available quota on paper. If this happens:

  1. Submit an Azure support request to increase your VM family quota in the target region. Select Service and subscription limits (quotas) as the issue type, and specify the VM SKU family (e.g., Dsv5, Dasv5) and the number of vCPUs needed.
  2. Expect delay. Capacity fulfillment in Government regions can take days to weeks depending on the SKU and region. This is a Microsoft-side infrastructure constraint, not a configuration issue.
  3. Plan provisioning early. Do not wait until the deployment window to discover a quota shortfall. Submit the support request as soon as the Azure Government subscription is established and the target VM count and SKU are known — ideally during project kickoff, not during the deployment sprint.
  4. Consider both Government regions. If USGov Virginia is constrained, USGov Texas may have availability (or vice versa). Evaluate whether the alternate region meets your data-residency and latency requirements before committing.

Entra Join and Intune Enrollment: No User Interaction Required​

AVD session hosts join Entra ID and enroll in Intune entirely in system context during VM provisioning — before any user ever signs in. No user MFA challenge is triggered, and no per-user Intune license is validated at enrollment time.

The provisioning flow is:

  1. Azure deploys the VM and runs the AADLoginForWindows extension under the SYSTEM account
  2. The extension joins the VM to Entra ID using the tenant's device join configuration
  3. Intune MDM auto-enrollment fires automatically as a consequence of the Entra Join
  4. Intune delivers compliance policies and configuration profiles to the device

The Intune license check occurs later — when the first user signs in, Intune verifies that the user has an eligible license (M365 E3/E5). For a properly licensed deployment this is transparent. No interactive enrollment, no MFA prompt, and no per-VM manual step is required.

Common client concern: "Will provisioning 20 VMs trigger 20 MFA challenges?"

No. The join and enrollment happen at the system level. The only MFA challenge is the one the engineer authenticates with when deploying the host pool through the Azure portal.

Entra Join Constraint​

AVD session hosts join Entra ID using the AADLoginForWindows VM extension, which runs at the SYSTEM account level during VM provisioning. This mechanism is subject to the tenant-level "Users may join devices to Microsoft Entra ID" policy in Entra > Devices > Device settings.

This policy must be set to All. There is no mechanism to scope the AADLoginForWindows join to a service principal — the setting applies to user-initiated and extension-initiated joins alike. If the policy is restricted to a named group, the extension's join attempt will fail and session host provisioning will partially complete: the VM is created but it is not Entra Joined or Intune-enrolled.

"Users may join devices" must be All — mitigate with compensating controls, not by abandoning the requirement

Setting this to All creates a surface where any user in the tenant could potentially join a personal device to Entra ID. The compensating controls below close this gap without restricting AVD provisioning:

ControlHow It Mitigates
Enrollment restrictions (Intune)Block personally-owned device enrollment — even if a device joins Entra, it cannot enroll in MDM unless it is corporate-owned
Conditional Access: require compliant device (P006)Any device that joined Entra but bypassed Intune enrollment will fail compliance checks and cannot access M365 resources
B007: Block Non-Approved Device RegistrationBlocks device registration from non-US locations, preventing foreign-IP device joins

With these controls in place, the risk of "Users may join devices = All" is substantially mitigated. Document this as a known constraint with compensating controls in your SSP.

Data Protection​

Encryption​

AVD session hosts handle sensitive data in transit and at rest. The encryption posture has three layers:

LayerMechanismConfiguration
OS disk (at rest)BitLocker + Server-Side Encryption (SSE)Intune BitLocker policy applies automatically to Entra Joined session hosts; SSE uses platform-managed keys by default
Server-side encryptionAzure Storage Service Encryption (AES-256)Enabled by default on all managed disks — no additional configuration required
Customer-managed keys (optional)Azure Key Vault (GCC High) + Disk Encryption SetProvides key lifecycle control for higher-sensitivity environments; requires an Azure Key Vault in the same Azure Government subscription

For environments that require CMK: create a Disk Encryption Set referencing a Key Vault in Azure Government, and associate it with the AVD host pool's managed disk configuration at provisioning time. Keys must be stored in Key Vault instances within the US Gov regions to stay within the FedRAMP High boundary.

Data Storage Policy: AVD Is Near-Ephemeral; CUI Lives in SharePoint​

The architectural stance for this enclave is that CUI lives in governed SharePoint sites — never on the session host disk. SharePoint is the single CUI storage surface: sensitivity-labeled, DLP-monitored, audited at the file level. The session host is treated as near-ephemeral: it hosts the user's session, runs the applications, and preserves application provisioning state, but it is not a place where CUI is created, stored, or worked on outside the SharePoint-hosted document.

Practical implications:

  • No OneDrive Known Folder Move on session hosts. Desktop, Documents, and Pictures are not redirected. Auto-sync of those folders to OneDrive is not configured. If a user does sign in to OneDrive interactively during their session, that is permitted, but no policy encourages CUI to flow into OneDrive — the governed path is opening labeled documents directly from SharePoint and editing them in place.
  • CUI on the session host disk is a policy violation, not a tolerated edge case. If forensic review shows CUI saved to C:\Users\..., that is treated as the user not following process, and the response is procedural (training, label-enforced reminders, DLP) rather than architectural (no attempt to "protect" CUI that should not be there).
  • Azure VM Backup exists to protect the AVD investment, not CUI. The recommended Trusted Launch session host costs 25–45 minutes to reprovision and re-baseline, and users accumulate application configuration (browser profiles, signing certs, installed line-of-business tools, registry tweaks) over weeks that nothing in the provisioning pipeline captures. A failed VM without backup forces that user to rebuild their working environment by hand. Backup preserves the provisioning and configuration investment — it is not a CUI custody mechanism.

Backup​

ResourceBackup ApproachPolicy
Session host VMsAzure Backup for VMsRequired — enable at provisioning; loss of AVD provisioning state on VM failure or accidental deletion without it

Configuring backup: the Recovery Services Vault, daily backup policy, and per-VM enrollment are documented as Step 13 of Appendix C.1: AVD Deployment Runbook. The recommended baseline is daily backup with 30-day retention against the AVD device group; the runbook step covers vault creation, policy configuration, enabling backup on session hosts, and validating the first backup completes. The architectural rationale for backing up session hosts in a pool that looks stateless on paper — undefined application provisioning practices, CMMC IR.L2-3.6.1/3.6.2 forensics, recovery time objective, and the AppData gap (browser profiles, signing certificates, application caches) — is in the secure enclave variant at Scenario: AVD Secure Enclave § Session Host Backup and applies equally here.

Secure Enclave Pricing​

An AVD secure enclave is not just VM compute. The full monthly cost includes the Azure Firewall anchoring the network boundary, OS disks that run continuously regardless of VM power state, backup storage, and Log Analytics ingestion. Each component is priced independently in Azure Government — understanding the full picture prevents budget surprises after deployment.

All prices are approximate as of early 2026 (Azure Government — US Gov Virginia). Verify current rates at the Azure Government pricing calculator before budgeting.

AVD Control Plane​

The AVD service itself — host pools, workspaces, application groups, and the gateway that brokers connections — is free. Microsoft does not charge per session, per user, or per host pool. You pay only for the underlying Azure infrastructure resources listed below.

Session Host Compute​

For a personal (assigned) pool, select a VM size based on the workload profile of your users. Three tiers cover light, standard, and power-user scenarios — D8as_v6 is the recommended default for most deployments.

TierVM SizevCPURAMBest For
LightStandard_D4s_v5416 GBEmail, browser, light Office — no Teams video, no large files
StandardStandard_D8as_v6832 GBGeneral knowledge workers — Office, Teams, browser, line-of-business apps
Power UserStandard_D16as_v61664 GBData analysts, developers, users with large datasets or many concurrent applications
Windows Enterprise license is included in M365 E3/E5

For AVD personal pools running Windows 11 Enterprise single-session, the Windows license is covered by M365 E3 or E5 — there is no additional OS license cost on the VM. Pricing below reflects compute only.

The "8 hr/day" column assumes 176 active hours per month (8 hours × 22 business days) using Start VM on Connect to power down VMs outside active use.

Light — Standard_D4s_v5 (4 vCPU, 16 GB RAM)​

Hourly RateMonthly (24/7)Monthly (8 hr/day)
$0.192/hr$140/VM$34/VM

Standard — Standard_D8as_v6 (8 vCPU, 32 GB RAM)​

Hourly RateMonthly (24/7)Monthly (8 hr/day)
$0.384/hr$280/VM$68/VM

Power User — Standard_D16as_v6 (16 vCPU, 64 GB RAM)​

Hourly RateMonthly (24/7)Monthly (8 hr/day)
$0.768/hr$561/VM$135/VM

OS Disks​

OS disks are billed continuously regardless of VM power state. Stopping a VM saves compute cost but not disk cost.

Disk TypeSizeMonthly Cost/VMBest For
Standard SSD E10128 GB$8Light users — email, browser, light Office; acceptable performance
Premium SSD P10128 GB$20Default — best login performance, recommended baseline
Premium SSD P20512 GB$70Users with large local data (CAD files, datasets)
Start with Premium SSD P10; evaluate Standard SSD after first month

The Windows 11 OS and standard productivity applications consume 40–70 GB. A P10 128 GB disk provides comfortable headroom and the best login responsiveness. After the first month of use, users who run only browser, email, and light Office are candidates for Standard SSD E10 — saving $12/VM/month with a modest reduction in disk throughput. Do not use Standard SSD for users running data-heavy applications or frequent large file operations.

64 GB disks are not viable for personal pools

A 64 GB OS disk leaves only 4–14 GB of free space after Windows 11 and Office install. Windows Update staging alone can fill this within weeks. Always provision at least 128 GB regardless of disk tier.

Azure Firewall​

Azure Firewall is the most significant fixed infrastructure cost in a secure enclave. It is billed by the hour regardless of traffic volume, plus a per-GB data processing fee. A single Standard-tier instance covers a 20-user deployment comfortably.

SKUHourly RateMonthly (24/7)Data Processing
Azure Firewall Standard$1.25/hr$912$0.016/GB processed
Azure Firewall Premium$1.66/hr$1,212$0.016/GB processed

Standard vs. Premium for AVD: Standard tier is sufficient for the FQDN-based rules that govern AVD egress. Premium adds TLS inspection and IDPS signatures — warranted if the firewall is also inspecting general internet traffic from corporate workloads, but not required for the AVD firewall rule set described in this guide.

Data processing cost estimate: A 20-user team producing 300 GB/month of outbound traffic through the firewall adds approximately $5/month in data processing fees — not a meaningful budget variable compared to the fixed hourly cost.

Azure Firewall is a fixed cost regardless of user count

Unlike session host compute, Azure Firewall cost does not scale linearly with users. A single Standard-tier firewall serves 5 users and 50 users at the same $912/month. This makes the per-user firewall cost high for small deployments and negligible for larger ones.

Supporting networking resources (one-time, low cost):

ResourceApprox. Monthly Cost
Standard Public IP (Firewall SNAT egress)$4
AzureFirewallSubnet (required /26)No charge
Hub VNetNo charge
VNet peering (hub ↔ spoke, per GB)$0.01/GB transferred

VM Backup​

Azure VM Backup protects the OS disk (and any data disks) of each session host. Because this is a personal pool with user data persisting on the VM disk, backup is a required component of the architecture — not optional.

Backup cost has two components: the protected instance fee and backup storage consumed.

ComponentApprox. Monthly Cost
Protected instance fee (per VM, any size)$5/VM
Backup storage — LRS, 128 GB disk (P10)$3–6/VM
Backup storage — LRS, 512 GB disk (P20)$10–20/VM

Estimate for 20-user deployment with 128 GB disks: $160–220/month total backup cost.

Use GRS only if a secondary-region recovery requirement exists

Backup storage defaults to Locally Redundant Storage (LRS). Geo-Redundant Storage (GRS) doubles the backup storage cost and is only warranted if a regulatory or business continuity requirement mandates recovery from a region failure.

Log Analytics + Microsoft Sentinel​

CMMC Level 2 requires audit logging and continuous monitoring of systems that process CUI (AU.L2-3.3.1, AU.L2-3.3.2, SI.L2-3.14.6, SI.L2-3.14.7). For an AVD enclave where users access Exchange, SharePoint, OneDrive, and Teams, this means connecting the full set of M365 and Azure data sources to a Sentinel-enabled Log Analytics workspace.

Pricing stacks: Log Analytics charges for data storage, and Sentinel charges an equal rate on top for SIEM analytics, incident correlation, and built-in detections.

ComponentRate
Log Analytics data ingestion$2.76/GB (Pay-As-You-Go)
Sentinel analysis (on top of Log Analytics)$2.76/GB
Combined per-GB cost$5.52/GB
Data retention (first 31 days)Included
Data retention (beyond 31 days)$0.10/GB/month

Data source volume estimates (20-user enclave):

Data sourceEst. monthly volumeNotes
AVD session diagnostics3–5 GBSign-in events, connection logs, session host health
Azure Firewall logs2–5 GBRule evaluations, threat intelligence hits — scales with rule count and traffic
MDE device events3–8 GBEndpoint telemetry, alert data — scales with user activity
Entra ID sign-in and audit logs1–2 GBCA policy evaluations, admin actions, directory changes
Exchange Online audit logs5–15 GBMailbox access, send/receive, admin actions — highest volume M365 source
SharePoint / OneDrive audit logs3–10 GBFile access, sharing events, DLP matches
Teams activity logs2–5 GBChat, channel, meeting events
Defender XDR incidents and alerts2–5 GBCross-workload incident correlation
Total estimated ingestion21–55 GB/month

Cost estimate for a 20-user enclave:

ScenarioMonthly ingestionMonthly cost
Lower activity (25 GB)25 GB~$138
Moderate activity (40 GB)40 GB~$221
Higher activity (55 GB)55 GB~$304
Commitment tiers reduce ingestion cost significantly

If the workspace ingests more than 100 GB/day across all workloads (shared with other environments), Commitment Tier pricing reduces the per-GB rate substantially. Evaluate this once the workspace is established and ingestion volume is measurable. For a standalone 20-user enclave, volume is typically too low to benefit from commitment tiers.

Sentinel is a per-workspace cost, not per-user

Like Azure Firewall, Sentinel cost is driven by data volume, not user count. A 15-user enclave and a 20-user enclave on the same workspace produce similar costs — the difference is marginal. If the enclave shares a workspace with other organizational workloads, the Sentinel cost is amortized across all connected data sources.

Total Enclave Cost — 20-User Deployment​

The table below combines all resource categories for a 20-user personal pool using D8as_v6 (32 GB) session hosts with Start VM on Connect (176 active hours/month). Firewall and backup costs are fixed regardless of VM count.

ResourceMonthly CostNotes
Session host compute (20 × D8as_v6, 8 hr/day)$1,360Start VM on Connect, 176 hr/month
OS disks (20 × Premium SSD P10, 128 GB)$400Billed 24/7 regardless of power state
Azure Firewall Standard$912Fixed regardless of user count
Public IP$4One per firewall
VM Backup (20 VMs, 128 GB)$180Instance fee + LRS storage
Log Analytics + Sentinel$221Est. 40 GB/month ingestion (full M365 + Azure connectors)
Monthly Total$3,077
Annual Total$36,924

Nerdio Manager license not included. See Nerdio Manager for AVD below for impact on total cost.

Standard SSD downgrade opportunity: For light users (email, browser, light Office), replacing Premium SSD P10 with Standard SSD E10 reduces disk cost from $20 to $8/VM/month. Migrating all 20 users to E10 saves $240/month ($2,880/year); a realistic split of 10 light users on E10 saves $120/month ($1,440/year). This change is independent of Nerdio and requires only a disk SKU change per VM.

Azure Firewall dominates fixed cost for small deployments

For a 20-user deployment, Azure Firewall represents 30% of total monthly spend and does not decrease as the user count or compute footprint shrinks. Organizations evaluating AVD on a per-user compute cost basis alone are often surprised by this line item. It is the price of maintaining a defensible network security boundary.

Nerdio Manager for AVD​

Nerdio Manager for Enterprise is a third-party AVD management platform that adds cost optimization, automated image management, and operational tooling on top of the native Azure AVD control plane.

Power scheduling does not require Nerdio

8-hour/day VM scheduling is achievable with a free Azure Automation Runbook — a straightforward script that stops VMs on a schedule and pairs with Start VM on Connect for on-demand restarts. For organizations that want to manage this themselves, Nerdio is not required for power scheduling alone. Nerdio's value in a personal pool deployment is right-sizing based on actual utilization data and operational efficiency for image management and monitoring.

Business Benefits​

CapabilityDescriptionImpact
Power SchedulingPowers VMs off after business hours and on before shift start on a configurable scheduleAchievable without Nerdio via Azure Automation Runbook — Nerdio adds reliability, pre-stage warm-up, and a managed UI
Start VM on Connect integrationStarts the assigned VM when a user initiates a connection, even outside scheduled hoursNative Azure AVD feature — Nerdio surfaces this in its scheduling UI alongside power-off rules
Pre-stage schedulingStarts VMs 15–30 minutes before scheduled shift startEliminates cold-start wait time — VM is ready when the user connects; not easily replicated with a basic runbook
Right-sizing recommendationsMonitors per-VM CPU and RAM utilization and flags over-provisioned hostsPrimary Azure cost lever when power scheduling is already handled — enables targeted downgrades based on evidence
Cost attribution reportsPer-user, per-VM, per-resource-group cost reportingMakes AVD spend visible and attributable for budget reviews and chargeback
Multi-tenant MSP dashboardManage multiple client environments from a single paneOperational efficiency for managed service providers supporting multiple tenants

Projected Cost Savings — 20-User Personal Pool​

With 8hr/day power scheduling already handled by an Azure Automation Runbook, the remaining Azure cost savings Nerdio provides come from right-sizing — downsizing VMs whose actual CPU and RAM utilization is well below their provisioned tier.

The baseline assumes all 20 users on D8as_v6 (32 GB) at 8hr/day. After 30 days of utilization monitoring, Nerdio identifies users whose workloads fit a smaller VM:

  1. Review per-VM CPU and RAM utilization in Nerdio's dashboard after the first month.
  2. Downgrade users consistently below 40% RAM utilization to D4s_v5 (4 vCPU, 16 GB) — roughly half the compute cost.
  3. Upgrade users regularly exceeding 70% RAM to D16as_v6 (64 GB) if performance is impacted.

This produces a mixed fleet calibrated to actual usage rather than a uniform over-provisioned tier.

Right-Sizing Savings​

ResourceBaseline (8 hr/day, no Nerdio)Moderate Right-Sizing (10 × D4s_v5)Aggressive Right-Sizing (20 × D4s_v5)
Session host compute$1,360$1,020$680
OS disks (20 × P10 128 GB)$400$400$400
Azure Firewall Standard$912$912$912
Public IP$4$4$4
VM Backup (20 VMs, 128 GB)$180$180$180
Log Analytics + Sentinel$221$221$221
Nerdio license—$100$100
Monthly Total$3,077$2,837$2,497
Annual Total$36,924$34,044$29,964
Annual Savings vs. Baseline$2,880 (8%)$6,960 (19%)

Nerdio license estimate: $5/user/month × 20 users = $100/month. Actual pricing varies — contact Nerdio for current enterprise rates.

Right-sizing savings are utilization-dependent

The moderate scenario (10 of 20 users on D4s_v5) is a realistic outcome for a mixed knowledge-worker team. The aggressive scenario (all 20 on D4s_v5) applies only if the entire team has light workloads — primarily browser, email, and light Office use with no Teams video calls or data-heavy applications. Without Nerdio's per-VM utilization data, right-sizing is guesswork. That data is Nerdio's primary financial justification in a deployment where power scheduling is already handled natively.

Resilience and Failsafe Configuration​

Nerdio controls AVD costs through an Azure app registration (service principal) with delegated permissions on your subscription. This design creates a dependency: if Nerdio loses its Azure connection, all automated cost controls — power scheduling, auto-start, pre-stage timers — stop functioning. VMs that are running at the time of the disconnection continue running indefinitely until manually stopped. This is the scenario some organizations have experienced as an unexpected spike in cloud costs.

Root causes of Nerdio connection loss:

CauseDetails
Service principal secret expiryApp registration client secrets have a configurable expiry (default 1–2 years in Entra). When the secret expires, Nerdio can no longer authenticate to Azure.
App registration deleted or permissions revokedIf an administrator removes the Nerdio app registration or removes its subscription-level RBAC roles, Nerdio loses access.
Nerdio service disruptionNerdio is a SaaS platform — an outage on Nerdio's side prevents it from executing any Azure actions, even if the service principal is healthy.

Mitigations:

  1. Azure Cost Management budget alerts (independent of Nerdio). Create a budget in Azure Cost Management scoped to the AVD resource group. Set alert thresholds at 80% (warning) and 100% (critical) of the expected monthly compute cost. Budget alerts fire independently of Nerdio — they are evaluated directly against Azure billing data. This is the primary financial safety net if Nerdio stops functioning.

  2. Service principal expiry monitoring. In Entra > App registrations > [Nerdio app] > Certificates & secrets, note the client secret expiry date. Create a calendar reminder or an Entra Workbook alert 60 days before expiry to rotate the secret and update it in Nerdio before it expires. Nerdio's admin portal typically shows a warning when the credential is approaching expiry — verify this alert is configured and going to a monitored inbox.

  3. Azure Monitor alert on running VM count. Create a metric alert on the AVD resource group: if the count of VMs in a "running" state during off-hours (e.g., between 20:00 and 06:00) exceeds an expected baseline (e.g., more than 2 VMs running overnight), trigger an email to the IT admin. This catches the "Nerdio stopped scheduling shutdowns" scenario within hours rather than at billing review time.

    Example: for a 20-user deployment with Start VM on Connect, you would expect 0–2 VMs running at midnight on a weekday. An alert threshold of 5+ running VMs overnight is a reliable signal that power scheduling has stopped.

  4. Native AVD Scaling Plans as a documented fallback. Azure natively supports scaling plans for personal host pools (Start VM on Connect + scheduled deallocation). Important: Microsoft does not support running a native AVD scaling plan and a third-party management tool (Nerdio) on the same host pool simultaneously — they conflict. The native scaling plan is a fallback for if Nerdio is decommissioned or unavailable for an extended period, not a concurrent safety net.

    To enable native scaling as a fallback: in the Azure Government portal, navigate to Azure Virtual Desktop > Scaling Plans, create a plan for personal pools with scheduled deallocation, and assign it to the host pool after disabling Nerdio's power scheduling for that pool.

  5. Regular Nerdio health validation. At least monthly, verify in the Nerdio portal that the Azure connection status shows active and that the service principal last-authenticated timestamp is recent. Include this in any routine operational review.

Treat Azure Cost Management alerts as mandatory, not optional

Even with Nerdio functioning perfectly, Azure Cost Management budget alerts are a valuable independent check. They protect against misconfigured schedules, forgotten test VMs, and other cost anomalies that Nerdio would not flag. Configure them at deployment time, not after the first unexpected bill.

AVD Deployment Checklist​

This checklist is a phase-organized summary of the deployment to give you the shape of the work and the order things have to happen in. For the actual click-by-click steps — including resource naming, firewall policy deployment, RDP property values, the SSO PowerShell script, the Recovery Services Vault, and validation — follow Appendix C.1: AVD Deployment Runbook. Use this checklist for review and sign-off; use the runbook for execution.

Phase 1: Host Pool, Application Group, and Workspace​

A complete AVD deployment is three linked resources: a Host Pool (the VMs), an Application Group (the entitlement surface — what users can see and connect to), and a Workspace (the named container that appears in the Windows App client). All three are created through the Host Pool creation wizard in a standard deployment. All three remain required even for personal/assigned pools — the Host Pool holds the VM, but users reach that VM only through an Application Group inside a Workspace.

The Entra Join happens at the Host Pool level during VM provisioning.

  • [ ] Host Pool Settings:

    • When creating the Host Pool, ensure:
      • Host pool type: Personal (one VM per user)
      • Assignment type: Automatic — and pre-pin each user to a specific VM after provisioning per Appendix C.1 Step 11. This gives the audit determinism of Direct assignment (every event on a VM maps to a known user) without locking VMs to users before the pool is fully provisioned. Choose plain Direct only when bulk pre-assignment via the Assign user blade is operationally simpler than the runbook's PowerShell pattern.
      • Domain to join: Select Microsoft Entra ID
      • Enroll VM with Intune: Select Yes

  • [ ] Application Group:

    • The Host Pool wizard creates a default Desktop application group linked to the new pool. Keep it — this is the entitlement object Phase 2 assigns users to.
    • Note the Application Group name; you will reference it in Phase 2.

  • [ ] Workspace:

    • Attach the Application Group to a Workspace during the wizard, or create a Workspace after and register the Application Group to it. The Workspace is what users see as a named tile in their Windows App client.

  • [ ] RDP Properties (SSO):

    • In the Host Pool RDP Properties blade, add or set:
      • enablerdsaadauth:i:1
      • targetisaadjoined:i:1

Phase 2: RBAC Permissions (Entitlement and Logon)​

Users need two separate role assignments to connect successfully: Desktop Virtualization User on the Application Group (entitles them to see the workspace) and Virtual Machine User Login on the session host (authorizes the Windows sign-in). Either role alone produces a failed connection with a confusing symptom — empty workspace if only the Windows login is granted, "access denied at sign-in" if only the entitlement is granted.

  • [ ] Assign Desktop Virtualization User on the Application Group:

    • Navigate to the Application Group created in Phase 1.
    • Click Access control (IAM) > + Add > Add role assignment, or use the AVD-native Application groups → Assignments → Add blade (writes the same role under the hood).
    • Role: Desktop Virtualization User
    • Members: Your AVD user group — for CUI enclaves where the same group must also carry sensitivity-label decryption authority, this must be a mail-enabled security group (MESG), not a plain Entra security group. See Appendix C.1 Step 8 for the rationale and the Exchange admin center creation flow (the Entra "New group" UI cannot create mail-enabled groups).
    • This is the entitlement layer — without it, the user's Workspace appears empty in the Windows App client.

  • [ ] Assign Virtual Machine User Login:

    • Navigate to the Resource Group containing your AVD VMs.
    • Click Access control (IAM) > + Add > Add role assignment.
    • Role: Virtual Machine User Login
    • Members: Your AVD user group
    • This is the Windows login layer — without it, the connection reaches the VM and then fails at sign-in with "access denied."
    • Note: Assign at the Resource Group level to cover all session hosts in the pool, including newly provisioned VMs.

  • [ ] Assign Virtual Machine Administrator Login (Admins):

    • Repeat the above for IT admin accounts using the Virtual Machine Administrator Login role.

  • [ ] Pre-pin each user to their VM (recommended for CMMC enclaves):

    • With Automatic assignment plus pre-pinning, you get the audit determinism of Direct assignment without locking VMs to users before provisioning completes.
    • Host Pool → Session hosts → select the VM → Assign user. See Appendix C.1 Step 11 for the portal and bulk-PowerShell paths.
    • Skip this only if your operational model accepts first-come-first-served VM assignment — the first user to connect after provisioning claims the next available VM and the mapping is recorded from that moment.

Phase 3: Personal Pool Profile & Data Persistence​

In a personal (assigned) pool, each user has a dedicated VM. Their Windows profile and application settings persist on the VM's OS disk between sessions — but per the Data Storage Policy, CUI itself lives in governed SharePoint sites, not on the VM disk. FSLogix, Shared PC Mode, and OneDrive Known Folder Move are not deployed to personal pool VMs.

Do not deploy FSLogix or Shared PC Mode to personal pool VMs

Shared PC Mode deletes user profiles on logout — on a personal pool where profile persistence is the goal, this destroys the user's work. FSLogix profile container policies targeting Azure Files blob storage add cost and complexity with no benefit when each VM has a single dedicated user.

Do not deploy OneDrive Known Folder Move on session hosts

This architecture intentionally keeps the AVD session host near-ephemeral. CUI lives in governed SharePoint sites only. KFM (silently redirecting Desktop / Documents / Pictures to OneDrive for Business) would create a second cloud storage surface for user-generated content and encourage CUI to accumulate in the user's OneDrive — a policy violation in this architecture. Users may still sign in to OneDrive interactively if they have legitimate non-CUI use, but no policy automates or rewards that flow. Application provisioning state on the VM disk is preserved by Azure VM Backup (Phase 1 / Step 13); the working CUI document path is SharePoint → in-place edit → save back to SharePoint.

Phase 4: Verification & Success Indicators​

  • [ ] Connect to a session host as an administrator.

  • [ ] Run dsregcmd /status and verify:

    • AzureAdJoined : YES — Host is natively cloud joined
    • DomainJoined : NO — Correct for cloud-only AVD. If YES, the host was accidentally Hybrid Joined
    • AzureAdPrt : YES — Valid cloud token present

  • [ ] Verify GCC High Discovery:

    • MdmUrl: Must point to https://enrollment.manage.microsoft.us/enrollmentserver/discovery.svc
    • MdmTouUrl: Must point to https://portal.manage.microsoft.us/TermsofUse.aspx
    Critical Sovereign Check

    If MdmUrl points to a .com address, the session host is attempting to enroll in Commercial. Check the Host Pool region and DNS records.

  • [ ] Visual Verification:

    • Open Settings > Accounts > Access work or school on the session host.
    • You should see the Entra ID connection with an Info button.
    • If the Info button is missing: The host is joined but not enrolled. Check MDM User Scope in Entra.

Architecture Validation (AVD-Specific)​

These validation questions are specific to AVD. For general Entra Join validation, see Entra Join (The Cloud-Only Path).

Data Protection: Validation Checklist​

  • "Are we restricting Clipboard and Drive Redirection?"

    The Boundary: If users can copy/paste sensitive content from the secure AVD session to their unmanaged home PC, or redirect local drives into the session, your data boundary is broken. These are RDP Properties, not Intune settings. Set them in the Host Pool RDP Properties blade:

    • drivestoredirect:s: (empty string = no drive redirection)
    • redirectclipboard:i:0 (disable clipboard)

  • "Is Azure VM Backup enabled on all session hosts, and is the Recovery Services vault in a US Gov region?"

    The Sovereign Check: In a personal pool, user data persists on the VM OS disk. Confirm that Azure Backup is enabled on every session host and that the Recovery Services vault is in US Gov Virginia or US Gov Arizona. A vault in a commercial Azure region moves backup data outside the FedRAMP High boundary.

Sovereignty​

  • "Do global support staff have console access to these session hosts?"

    The Law: A login to an AVD session host from a non-US IP address by a non-US national may violate ITAR/EAR, regardless of the host's location. Enforce a Conditional Access Policy restricting AVD access to US-based IPs or named locations.

  • "Is the AVD control plane in GCC High?"

    The Check: Confirm the Host Pool is deployed in US Gov Virginia or US Gov Arizona in the Azure Government portal (portal.azure.us). Session hosts deployed in the wrong portal will not benefit from the FedRAMP High boundary.

Network​

  • "Is all session host egress going through Azure Firewall?"

    The Check: Verify the UDR on the session host subnet has a 0.0.0.0/0 route pointing to the Azure Firewall private IP — not to the VNet gateway or internet directly. In the Azure portal, select the session host NIC > Effective routes and confirm the default route next hop is VirtualAppliance.

  • "Are any session hosts running with a public IP address?"

    The Boundary: AVD session hosts should have no public IPs. Users connect through the AVD Gateway (Microsoft-managed), not directly to the VM. A public IP on a session host creates a direct attack surface outside the firewall.

AVD Client Configuration​

Users connect to their session hosts using either the Windows App (current client) or the legacy Remote Desktop client. In GCC High, the feed subscription URL is sovereign — this is the most common first-connection misconfiguration.

Feed Subscription URL​

ClientFeed URL
Windows App (recommended)https://rdweb.wvd.azure.us/api/arm/feeddiscovery
Remote Desktop client (legacy)https://rdweb.wvd.azure.us/api/arm/feeddiscovery
AVD Web Clienthttps://client.wvd.microsoft.us
Using the commercial feed URL blocks all GCC High workspaces

The commercial feed (rdweb.wvd.microsoft.com) does not display GCC High host pools. Users will see an empty workspace or an auth error. The sovereign cloud uses the wvd.azure.us namespace; see Microsoft Learn: Windows App connection guide for the canonical "Azure for US Government" feed URL.

Supported Clients by Platform​

PlatformClientGCC High Support
Windows 10/11Windows App (Microsoft Store)Full support
macOSWindows App (Mac App Store)Full support
iOS / iPadOSWindows App (App Store)Full support
AndroidRemote Desktop (Play Store)Supported; Windows App not yet on Android
Web browserAVD Web Client (client.wvd.microsoft.us)Full support — sovereign URL required
Windows App replaces the Remote Desktop client

Microsoft is transitioning from the Remote Desktop client to Windows App as the primary AVD client. Windows App handles GCC High feed discovery automatically and receives updates through the Microsoft Store. Use Windows App for all new deployments; the legacy client remains functional but is not receiving feature investment.

Connecting with Windows App​

Install​

PlatformSource
Windows 10/11Microsoft Store — Windows App
macOSMac App Store — search "Windows App"
iOS / iPadOSApp Store — search "Windows App"

Subscribe to the Feed​

  1. Open Windows App
  2. Click the + icon (top right) → Add Work or School account (for Commercial) or Add Workspace (for GCC High and other sovereign clouds, per Microsoft Learn: Get started with Windows App)
  3. Sign in with the user's Entra account — this triggers MFA
  4. If the workspace does not appear after sign-in, select + Add → Workspace and enter the feed URL manually from the Feed Subscription URL table above (rdweb.wvd.azure.us for GCC High, rdweb.wvd.microsoft.com for Commercial)
  5. The assigned session host will appear as a desktop tile in the workspace
Feed auto-discovery

Windows App attempts feed discovery automatically on sign-in using the account's tenant home region. For GCC High tenants, Add Workspace with the explicit rdweb.wvd.azure.us URL is the documented path — Microsoft's Windows App guidance routes sovereign-cloud users through Add Workspace rather than the Add Work or School account flow. If the workspace appears empty after using the latter, fall back to manual URL entry per step 4.

Connect and Verify​

  1. Click the session host tile — Windows App launches the RDP session through the AVD Gateway
  2. If prompted for credentials at the Windows login screen, SSO is not configured — verify enablerdsaadauth:i:1 is set in the host pool RDP properties
  3. Once connected, open a browser inside the session and navigate to https://myip.microsoft.com — confirm the egress IP matches the Azure Firewall public IP
  4. In the AVD session, open Settings → About (or run whoami /upn in a terminal) to confirm you are signed in with the correct Entra identity

Validate the Connection in CA Sign-In Logs​

After a successful connection, verify E001 fired correctly:

  1. Entra admin center → Monitoring → Sign-in logs
  2. Filter by the user's UPN and the last 30 minutes
  3. Look for a sign-in to Azure Virtual Desktop — Status should be Success, CA policy E001 should show Grant — Phishing-resistant MFA satisfied

Monitoring & AVD Insights​

AVD Insights is a native monitoring workbook built on Azure Monitor and Log Analytics. It provides session host health, connection metrics, user experience data, and alert history — and reuses the Log Analytics workspace already deployed in Phase 1 for Azure Firewall diagnostics.

Enabling AVD Insights​

  1. In the Azure Government portal, navigate to Azure Virtual Desktop > Host Pools > [your host pool] > Insights.
  2. Enable diagnostic settings for the host pool — send Checkpoint, Error, Management, and Feed log categories to the Log Analytics workspace.
  3. Enable data collection rules on session host VMs to forward Windows event logs and performance counters:
    • Event channels: System, Application, Microsoft-Windows-TerminalServices-LocalSessionManager/Operational
    • Performance counters: CPU (% Processor Time), Memory (Available MBytes), Disk (% Free Space) at 60-second intervals

Key Monitoring Views​

ViewWhat to WatchAction Threshold
Session Host HealthHosts in Unavailable stateAlert on any single Unavailable host — personal pool, so 1 unavailable = 1 user impacted
Connection ReliabilityConnection failure rateAlert if > 5% failures in a 1-hour window
User ExperienceRound-trip timeRTT > 150ms sustained indicates connectivity issue between user and Azure region
Resource UtilizationCPU and RAM per VM> 85% sustained triggers right-sizing review in Nerdio
MDE Sensor HealthActive sensor count (Defender portal)Alert if sensor count drops below total VM count — indicates VM missed onboarding
// Alert: Session host entered Unavailable state
WVDAgentHealthStatus
| where Status == "Unavailable"
| summarize count() by SessionHostName, TimeGenerated
// Alert: High connection failure rate — last 1 hour
WVDConnections
| where TimeGenerated > ago(1h)
| summarize Total = count(), Failed = countif(State == "Failed") by bin(TimeGenerated, 5m)
| extend FailureRate = todouble(Failed) / todouble(Total)
| where FailureRate > 0.05

Control Mapping​

AVD Sovereign Tenant — CMMC Control Mapping​

The AVD secure enclave architecture directly implements the following NIST SP 800-171 Rev 2 controls through mechanisms specific to the AVD deployment model. For the complete control matrix across all technologies, see Appendix A: Compliance Controls.

CMMC PracticeNIST 800-171 ControlAVD Implementation
AC.L2-3.1.1Limit system access to authorized usersVirtual Machine User Login RBAC role is required for session host interactive sign-in — Entra group membership alone grants nothing. Users without explicit role assignment receive Access Denied at connection time regardless of license or group state.
AC.L2-3.1.3Control the flow of CUI in accordance with approved authorizationsRDP Properties redirectclipboard:i:0 and drivestoredirect:s: prevent clipboard paste and drive mapping out of the session. CUI cannot be transferred to an unmanaged endpoint at the protocol level.
AC.L2-3.1.14Route remote access via managed access control pointsAll user sessions are brokered through the AVD Gateway (Microsoft-managed sovereign service). Direct RDP to session hosts is not possible — session hosts have no public IPs and the UDR routes all traffic through Azure Firewall. The gateway is the single managed ingress point.
AC.L2-3.1.15Monitor and control remote access sessionsVirtual Machine Administrator Login is restricted to named IT admin accounts. Privileged console sessions are logged in Entra sign-in logs, separate from user sessions, and subject to the same phishing-resistant CA requirements.
MA.L2-3.7.5Require MFA for remote maintenance sessionsAdministrative access via Virtual Machine Administrator Login is gated by Conditional Access policy A002 (phishing-resistant auth required). FIDO2 or WHfB is enforced before any privileged session is established.
PE.L2-3.10.1Limit physical access to CUI to authorized individualsSession hosts run in Azure Government datacenters (US Gov Virginia / US Gov Arizona). No CUI touches end-user hardware — users see only a rendered screen. Physical access to CUI is scoped to Microsoft's FedRAMP High certified facilities.
SC.L2-3.13.1Monitor, control, and protect communications at external boundariesAzure Firewall with deny-all default (Priority 4096) and explicit FQDN allow rules enforces boundary control at all session host egress. All denied traffic is logged to Log Analytics.
SC.L2-3.13.5Implement subnetworks for publicly accessible system componentsSession hosts have no public IP addresses and are not internet-routable. All external connectivity is inbound via the AVD Gateway service tag and outbound via Azure Firewall private IP. The session host subnet is isolated from the public internet.
SC.L2-3.13.8Implement cryptographic mechanisms to prevent unauthorized disclosure of CUI in transitRDP sessions are encrypted via TLS 1.2+ enforced by the AVD Gateway. No unencrypted remote session path exists in this architecture.
SC.L2-3.13.16Protect the confidentiality of CUI at restSession host OS disks are encrypted with BitLocker (Intune policy) and Azure Storage Service Encryption (AES-256). All data and keys reside within the Azure Government FedRAMP High boundary.

For the detailed Azure Firewall rule reference (application rule collections, network rules, customer rule template, and troubleshooting KQL), see AVD Firewall Reference.

For the complete compliance control matrix, see Appendix A: Compliance Controls.

📩 Don't Miss the Next Solution

Join the list to see the real-time solutions I'm delivering to my GCC High clients.