Il costo di una soluzione Windows Virtual Desktop è composto da diversi fattori tra cui:
- Licensing
- Costo delle macchine virtuali che compongono un Host Pool
- Costo della banda in uscita generato dalle macchine virtuali che l’utente utilizza (egress cost)
- Storage consumato dai dischi delle macchine virtuali e dai profili utente
- Costo dell’infrastruttura a supporto (Active Directory, VPN S2S o Express Route)
- Automazioni varie (i runbook di automazione di spegnimento e accensione delle macchine virtuali per esempio)
- Monitoraggio (Log Analytics)
- Soluzioni di sicurezza (Azure Security Center, Web Content Filtering, Firewall…)
- Soluzioni di terze parti
Alcune di questi costi sono mandatori (licensing, VM, Banda in uscita) mentre altri sono opzionali (per esempio il salvataggio dei profili tramite FSLogix, o anche il monitoraggio anche se è fortemente consigliato averlo oppure alcuni sono “un costo aggiuntivo che fa diminuire il costo totale” come nel caso dell’automazione di spegnimento e accensione macchine virtuali).
Inoltre, alcuni costi variano tra le varie region di Azure (è possible che un dato taglio di Virtual Machine nella region West Europe potrebbe costare leggermente meno o leggermente di più dello stesso taglio in una region differente) e nel tempo (tendenzialmente i costi delle Virtual Machine si abbassano nel tempo in relazione alla potenza a disposizione come riportato da questo articolo di Michel Roth – How WVD gets cheaper over time)
Iniziamo ad analizzare i costi mandatori lasciando quelli opzionali a futuri articoli.
Licensing
Una soluzione Windows Virtual Desktop è composta da una o più macchine virtuali che espongono i propri servizi (delle applicazioni o l’intero desktop). Queste macchine virtuali possono essere:
- Windows Client – Windows 7 o Windows 10
- Windows Server – Windows 2012 R2 o superiori
Quindi il licensing si divide a seconda di quale sistema operativo montano le mie macchine virtuali:
- Windows Client – Ciascun utente che vi accede deve avere una licenza VDA PER USER (per device non va bene). Questa licenza può essere venduta separatamente oppure essere incorporata in licenze più ampie tipo Windows E3 o Microsoft 365 Business Premium. Quindi 100 utenti = 100 VDA.
- Windows Server – Serve una RDS CAL con Software Assurance ma a differenza della VDA va bene anche quella per device.
Per maggiori informazioni, potete leggere il seguente articolo: Windows Virtual Desktop Pricing | Microsoft Azure
Una domanda tecnica relativa al licensing, che spesso viene fuori, è “ma come faccio ad assegnare le licenze agli utenti?” e la risposta è che non è necessario almeno per quanto riguarda Windows 10 Multisession che è il sistema operativo più utilizzato nelle soluzioni Windows Virtual Desktop.
Se io creo un pool di macchine con a bordo Windows 10 Multisession, queste verranno automaticamente licenziate dal server KMS disponibile in Azure e tutti gli utenti che vorranno accedervi potranno farlo. Questo fa si che io mi debba preoccupare di essere in possesso di un numero sufficiente di licenze VDA utilizzabili dagli utenti che accedono al pool WVD senza doverle assegnare a livello tecnico (assegno all’utente l’applicazione o il desktop virtuale e lui entra. Al primo check di compliance da parte di Microsoft dello stato delle licenze dovrò dimostrare che quell’utente è coperto da una licenza VDA).
Le soluzioni basate su Windows Server invece necessitano invece di un caro e vecchio license server ospitato su di una macchina Windows Server (quindi è un costo aggiuntivo da calcolare).
E’ da notare che diversi clienti si trovano nella condizione di avere già la VDA perché hanno M365 Business Premium o F3 o E3 o E5, per altri motivi e magari pagano anche la RDS CAL per utilizzare una soluzione VDI basata su Windows Server (che ha il grande vantaggio di permettere il multiutenza). In questi casi si può pensare se non sia più conveniente utilizzare una soluzione basata su WVD e Windows 10 Multisession così da abbattere i costi di licensing (non pagherei più l’RDS CAL perché mi basterebbe la VDA che già ho e che non sto usando). Ovviamente non è sempre possibile ma spesso si, quindi è da tenere presente come possibilità in fase di definizione della proposizione.
Costo Macchine Virtuali
Il costo di una macchina virtuale in Windows Virtual Desktop è standard nel senso che è uguale a qualsiasi altra macchina virtuale Azure (una D4v3 esposta da WVD costa come una D4v3 utilizzata come macchina virtuale generica di Azure) in più il costo è quello Linux ovvero pago per il numero di CPU, quantitativo RAM e disco impiegato e per il tempo che la macchina viene utilizzata ma non per il sistema operativo Windows in essa ospitata.
Quindi, sia che io scelga una soluzione WVD basata su Windows Client che su Windows Server, il costo della macchina NON comprende e non deve comprendere il costo del sistema operativo.
Questo è un ulteriore beneficio in termini di costo rispetto ad una soluzione di terze parti dove oltre alla licenza CAL di accesso (la VDA o la RDS CAL con software assurance) io debba pagare anche la licenza del sistema operativo (es. Windows Server). Posso ottimizzare i miei costi utilizzando sistemi operativi multisessione come Windows 10 MultiSesssion o Windows Server.
Sul discorso macchine virtuali è da tenere in considerazione il concetto di Reserved Instance ovvero la possibilità di avere una forte riduzione del prezzo a fronte di un commitment di utilizzo. Per maggiori informazioni, potete leggere il seguente articolo: Azure Reserved Virtual Machine Instances | Microsoft Azure
E’ tipico che il numero di utenti che richiede il mio servizio sia variabile nel corso dei giorni o anche delle ore per cui è possibile integrare in Windows Virtual Desktop un automatismo che accenda e spenga le macchine virtuali alla bisogna. Quindi essendo il numero di utenti variabile esisterà probabilmente sempre un numero minimo di utenti da servire. A questo punto è possibile ottimizzare i costi utilizzando Reserved Instance per mantenere il mio “picco minimo” di utenti (nella figura 1 sono 20) e continuare ad utilizzare le tariffe pay as you go per supportare i “picchi massimi”.
Costo Banda
Questo è il costo tipicamente più difficile da calcolare anche se incide in maniera minima sul costo totale (un calcolo “rule of the thumb” di una soluzione WVD che utilizzi anche FSLogix per i profili è che il 70% del costo sia dovuto alle macchine virtuali, il 20% ai profili e solo il 10% alla banda).
In Azure si paga il traffico in uscita ovvero tutto quello che Azure dà alla macchina fisica da cui mi collego (con dei distinguo che ora vedremo). Se faccio upload di un file dalla mia macchina fisica ad una macchina virtuale di Azure, non pago. Se faccio download di un file da una macchina virtuale di Azure verso la mia macchina fisica invece pago.
Quanto pago? Ecco qui dipende da che region si usa che tecnologia si usa (Site 2 Site VPN, Express Route -e che tipo di Express Route) e da varie soglie ecc. Per maggiori informazioni, potete leggere il seguente articolo: Pricing – Bandwidth | Microsoft Azure.
Ma a parte le tariffe, la domanda è: cosa devo includere nel calcolo? Mettiamoci in un caso standard in cui utilizzo una Site-to-Site VPN: se faccio copia incolla di un file dal desktop virtuale verso il desktop della mia macchina fisica pago il traffico (il file è grande 2GB? Pago la tariffa per 2 GB). Inoltre, pago il traffico dalla macchina virtuale verso OneDrive for Business (perché OneDrive for Business non è in Azure (non ancora… Microsoft ci sta lavorando) per cui se per esempio mi collego da un thin-client ad una VM WVD, apro Word e creo un articolo che salvo su OneDrive for Business, quei 5MB o quel che sarà di dimensione del documento generano un traffico in uscita dalla macchina verso OneDrive for Business e questo concorre al costo.
Inoltre, ci sono i Gateway, cioè i punti di accesso che creano un tunnel (Reverse proxy) tra la nostra macchina fisica (es. thin-client) e la macchina virtuale. Non ci sono Gateway in tutte le region di Azure per cui se create un Pool WVD in West Europe avete il Gateway le macchine virtuali in West Europe.
Quindi si crea una connessione tra la mia macchina fisica che sta in Italia verso il Gateway che sta in West Europe (Olanda) e la macchina virtuale che sta sempre in West Europe. In questo caso pago quello che ci siamo detti finora tipo il fatto che scarico un file dalla macchina virtuale.
Mettiamo invece che io crei il mio pool nella region Francese, perché magari il mio cliente è Italo/Francese, e ci tiene a mantenere i dati all’interno dei confini Francesi. Nella region Francese (al momento in cui scrivo questo articolo) non c’è un Gateway per cui quando io richiedo il servizio dal mio device fisico finisco con il parlare con il Gateway più vicino in termini di latenze (mettiamo che sia West Europe) il quale crea una connessione con le macchine virtuali che sono nella regione Francese. In questo caso oltre a pagare il download del file dalla macchina virtuale Francese al mio device fisico passando per il Gateway Olandese, pago anche il traffico tra le due region (quella Francese e quella Olandese) questo costo è definito dall’articolo sopra riportato.
Microsoft continua ad espandere il numero di Gateway per cui è probabile che ne verranno inseriti sempre di più andando a mitigare questo aspetto (personalmente mi aspetto che a tendere tutte le region di Azure abbiano un Gateway ma è un’aspettativa personale…). Comunque, come potete vedere, ad oggi (Gennaio 2021) ci sono già diversi Gateway presenti nelle region Azure che ci circondano (si ringrazia Tom Hickling per l’immagine).
Posso decidere quale Gateway utilizzare? La risposta è no perché la mia richiesta di connessione viene gestita da un Azure Front Door a cui non ho accesso (e che non pago come non pago i gateway e gli altri ruoli di pubblicazione in WVD).
E se accedo ad una macchina virtuale in West Europe tramite il Gateway di West Europe e guardo un video YouTube quanto pago? La risposta è niente!
Perché? Perché il traffico RDP in uscita da un Gateway verso un client fisico non viene conteggiato. Microsoft non distingue verso quale utente un determinato traffico generato da un Gateway stia andando per cui è semplicemente “incluso nel prezzo del fatto che utilizzo Windows Virtual Desktop”. E se faccio una call Audio/Video con Teams? Anche in questo caso non pago anche perché se utilizzo l’ottimizzazione di Teams (o di Zoom) la parte Audio e Video verrà mandata dal mio device fisico verso il device fisico di destinazione senza interagire con il cloud.
E se la mia virtual machine in Azure interagisce con un applicazione nel mio datacenter on-premise? In questo caso pagherò, in quanto ci sarà sicuramente un flusso in uscita dalla VM verso l’applicazione (es. un gestionale oppure il domain controller). E se l’applicazione è in Azure nella stessa region della macchina virtuale WVD? In questo caso non pagherò perché è traffico intra-region (almeno per ora dato che dal 1 luglio 2021 cambieranno alcune logiche). Per maggiori informazioni, potete leggere il seguente articolo: Pricing – Bandwidth | Microsoft Azure
Quindi in definitiva quanto pago di consumo di banda in una soluzione WVD? La cosiddetta “rule of thumb” suggerisce che un utente consumi intorno ai 340kbps ovvero 0.15 GB/ora; quindi, ponendo che lavori per 8 ore, consumerebbe 1.2 GB al giorno per 22 giorni lavorativi sarebbero 27GB/mese. Una stima credibile potrebbe essere sui 30GB/mese per utente (giusto per avere un po’ di margine in più rispetto ai 27 sopra calcolati) e quindi utilizzando il tool di pricing si può avere una stima del costo.
Conclusioni
Come abbiamo visto, la soluzione Windows Virtual Desktop richiede un’analisi dei costi per evitare brutte sorprese a fine mese. L’utilizzo degli strumenti messi a disposizione da Microsoft, consentono di fare i dovuti calcoli sia in termini di potenzia computazionale, che per quanto riguarda l’utilizzo della banda.