VDI Zero Trust sans la facture cloud — Proxmox, Intel Arc Pro et Cloudflare Access

Ce que coûte réellement Azure Virtual Desktop

Azure Virtual Desktop livre un bureau Windows dans un navigateur. C’est vraiment ce qu’il fait, et ça marche. La question est ce qu’il en coûte de le maintenir en marche.

Le prix affiché n’est pas le prix. La pile de licences de Microsoft pour AVD tourne à peu près ainsi¹ :

• Une licence Microsoft 365 qui inclut le droit à Windows Enterprise — E3 ou E5, ou l’équivalent Business Premium
• Le calcul Azure sous le bureau — une VM facturée à l’heure, ou une instance réservée facturée au mois
• Le stockage Azure pour le disque système et le profil utilisateur
• Le réseau Azure pour le trafic entre le bureau et partout ailleurs
• Optionnellement, Microsoft Entra ID P1 ou P2 pour les politiques d’accès conditionnel

Windows 365 Cloud PC simplifie la facturation en un nombre plat par utilisateur et par mois, mais le nombre n’est pas petit. Une configuration 2 vCPU / 8 Go / 128 Go — qui est un bureau bureautique modeste — est à 35,60 £ par utilisateur et par mois². Ajoutez un GPU et cela bondit à 269,40 £ pour le palier GPU Standard. Multipliez par l’effectif et c’est un vrai poste de facture, chaque mois, pour toujours.

C’est le produit que ce billet remplace.

À quoi ressemble la pile de remplacement

Trois couches, chacune indépendante, aucune facturée par siège :

La couche GPU est le montage SR-IOV Intel Arc Pro du billet précédent. Une seule carte Arc Pro se découpe en fonctions virtuelles matérielles par SR-IOV PCIe standard — pas de licence vGPU, pas d’abonnement NVIDIA. Chaque VM Windows obtient sa propre VF et son propre bureau accéléré par le GPU. C’est la carte qui fixe le nombre de sièges, pas un serveur de licences.

La couche d’accès est Cloudflare Access avec du RDP rendu dans le navigateur. L’utilisateur ouvre une URL dans n’importe quel navigateur, s’authentifie contre votre fournisseur d’identité, et Cloudflare rend la session RDP directement dans l’onglet du navigateur. Pas de client RDP installé. Pas de VPN. Pas de ports exposés à l’internet. Access se fédère à tout fournisseur OAuth ou OIDC — cela inclut les fournisseurs sur site comme Keycloak ou Authentik empilés sur votre Active Directory existant, que ce soit Samba 4 AD ou un contrôleur de domaine Windows. L’annuaire continue de faire ce qu’il fait déjà : comptes utilisateurs, stratégies de groupe, VM jointes au domaine. Keycloak ou Authentik se fédère contre lui et ajoute la couche OAuth/OIDC et MFA dont Cloudflare Access a besoin. Le plan d’identité reste sur votre propre matériel. Pas d’abonnement Entra ID requis. Cloudflare Access gère ce qui se passe ensuite : il contrôle ce que l’utilisateur authentifié peut atteindre sur votre réseau — quelles applications, quels protocoles, quels hôtes. Le bureau est derrière un tunnel Cloudflare et inatteignable de partout sauf par la politique Access, et la politique décide à la fois l’identité et la portée.

La couche tunnel est un processus cloudflared qui tourne dans un conteneur LXC sur Proxmox, sur son propre VLAN — un /30 pour IPv4 avec son propre préfixe IPv6 dédié, rien d’autre dans le domaine de diffusion. Le pare-feu Proxmox contrôle ce que le LXC peut atteindre, et la réponse est courte : TCP 3389 vers les VM de bureau et rien d’autre. Si le point de terminaison du tunnel est compromis, le rayon d’explosion est un conteneur sur un VLAN par ailleurs vide, et la seule chose à laquelle il peut parler est ce que le pare-feu permet déjà. C’est une surface bien plus petite qu’un concentrateur VPN qui distribue un sous-réseau routé.

Cloudflare Zero Trust est gratuit jusqu’à 50 utilisateurs³. Vous payez à partir de l’utilisateur 51. Azure Virtual Desktop facture dès le premier siège.

L’architecture

Le chemin que prend une session de bureau :

1. L’utilisateur ouvre https://vdi.example.com dans n’importe quel navigateur, sur n’importe quel appareil
2. Cloudflare Access intercepte la requête et redirige vers votre fournisseur d’identité — Keycloak ou Authentik fédéré contre votre Active Directory
3. Le fournisseur OAuth valide l’identité de l’utilisateur contre l’AD et gère le MFA
4. Access évalue la politique — le fournisseur a confirmé qui ils sont, Access décide ce qu’ils peuvent atteindre sur votre réseau
5. Cloudflare établit une session RDP à travers le tunnel vers la VM cible
6. La session RDP est rendue dans le navigateur — pas de client, pas de greffon, pas de téléchargement
7. Le tunnel se termine dans un conteneur LXC sur l’hôte Proxmox, sur un VLAN verrouillé
8. Le LXC transmet le RDP à la VM Windows, qui a une fonction virtuelle de GPU de la carte Arc Pro

À aucun moment la VM Windows n’a d’IP publique. À aucun moment le port 3389 n’est ouvert à l’internet. La seule chose à l’écoute sur l’internet public est Cloudflare, et la seule chose qui passe Cloudflare est un utilisateur qui a passé la politique Access.

Le point de terminaison du tunnel : un LXC sur son propre VLAN

Le processus cloudflared doit tourner quelque part, et où vous le mettez est une décision de sécurité.

Le faire tourner directement sur l’hôte Proxmox est l’option la plus simple et la pire. Un point de terminaison de tunnel qui partage l’espace de noms réseau de l’hôte peut atteindre tout ce que l’hôte peut atteindre, ce qui sur un hyperviseur est tout. Un tunnel compromis devient un pivot vers le plan de gestion.

Le faire tourner dans une VM complète est propre mais lourd. Un relais de tunnel est un unique binaire Go qui n’utilise presque pas de CPU et quelques centaines de mégaoctets de RAM. Lui donner un noyau complet et un disque virtuel est excessif.

Un conteneur LXC est la bonne forme. Il obtient son propre espace de noms réseau, son propre VLAN — un /30 IPv4 et un préfixe IPv6 dédié, rien d’autre partageant le domaine de diffusion — et ses propres règles de pare-feu dans le pare-feu Proxmox. Il partage le noyau de l’hôte mais pas sa pile réseau. Le pare-feu permet TCP 3389 vers les VM de bureau, le DNS pour les résoudre, et le HTTPS sortant vers la bordure de Cloudflare. À ce titre, même un point de terminaison de tunnel compromis ne peut parler qu’aux choses auxquelles il était déjà censé parler — et le VLAN sur lequel il siège n’a pas d’autres résidents à atteindre.

La configuration du LXC, les règles de pare-feu Proxmox pour le VLAN, et la mise en place du tunnel cloudflared sont toutes dans le prochain billet.

Comment Cloudflare Access s’emboîte

Il y a deux moitiés à cela. Le fournisseur OAuth — Keycloak ou Authentik, fédéré contre votre Active Directory (Samba 4 ou Windows) — gère la validation de l’identité et le MFA. Il prouve que l’utilisateur est bien qui il prétend être, à partir du même annuaire auquel les VM sont jointes au domaine. Cloudflare Access gère tout ce qui suit : ce que l’utilisateur authentifié est autorisé à atteindre, par quel protocole, et comment la session est rendue.

Cloudflare Access rend la session RDP directement dans le navigateur. Ce n’est ni un téléchargement ni un greffon — la bordure de Cloudflare fait tourner un client RDP sans affichage et diffuse le résultat en tant que canvas dans l’onglet du navigateur. L’utilisateur voit un bureau Windows. Le navigateur voit du HTTPS vers Cloudflare. La VM Windows voit une connexion RDP depuis le tunnel cloudflared.

L’application Access est une application auto-hébergée pointée sur l’entrée RDP du tunnel. La politique Access est là où les deux moitiés se rencontrent. Le fournisseur OAuth a déjà confirmé l’identité et passé le défi MFA. Access prend ce jeton et décide quoi en faire — quelle application l’utilisateur peut atteindre, si la posture de son appareil passe, si sa localisation est permise. Le fournisseur dit qui. Access dit quoi.

La création du tunnel, les règles d’entrée, la configuration du LXC, les règles de pare-feu Proxmox et la politique Access elle-même sont toutes dans le prochain billet — celui-ci expose ce qu’est la pile et pourquoi elle existe. Le prochain la construit.

Ce que voit l’utilisateur

Cloudflare Access inclut un App Launcher — un portail de ressources qui liste chaque application que l’utilisateur authentifié est autorisé à atteindre. Après que l’utilisateur s’est connecté par le fournisseur OAuth, le portail lui montre ses bureaux disponibles, ses applications web internes, et toute autre ressource tunnelée, le tout en un seul endroit. Une URL, une connexion, et une tuile pour chaque chose à laquelle il a accès. C’est la page d’accueil de toute la pile, pas seulement du RDP.

L’utilisateur clique sur une tuile de bureau, et obtient un bureau Windows dans un onglet de navigateur. Pas de client, pas de greffon, pas de téléchargement. Cela marche sur n’importe quel appareil qu’il possède déjà — un portable d’entreprise, une machine personnelle, un Chromebook, une tablette. C’est là le but. Le système est bâti pour les entreprises qui laissent les gens utiliser leur propre matériel.

Le presse-papiers, l’audio et le multi-écran ne sont pas pris en charge à travers la session rendue dans le navigateur. C’est par conception, pas par accident. Chacun de ces canaux est une voie d’exfiltration de données. Un presse-papiers qui traverse la frontière fait sortir des fichiers. La capture audio fait sortir des conversations. Le multi-écran avec un bureau local à côté du distant rend le glisser-déposer trivial. Couper ces canaux veut dire qu’un utilisateur peut travailler dans le bureau mais ne peut pas en tirer du travail par un canal détourné. La politique Access contrôle qui entre. Le rendu par le navigateur contrôle ce qui sort.

Si l’entreprise a besoin du presse-papiers ou de l’audio pour un flux de travail précis, Cloudflare Access prend aussi en charge un client RDP natif à travers le tunnel — le même tunnel, la même politique, la même vérification d’identité. Le chemin natif donne toutes les fonctions RDP aux utilisateurs qui en ont besoin et garde le chemin navigateur verrouillé pour tous les autres. Deux méthodes d’accès, un moteur de politique, un tunnel.

La comparaison de coût

Un exemple concret. Un serveur, 42 bureaux accélérés par GPU :

• Un CPU 64 cœurs avec hyperthreading vous donne 128 threads. Chaque VM obtient 8 vCPU — une allocation de vrai bureau, pas un client léger. 42 × 8 = 336 vCPU, ce qui est bien au-delà de 128 threads sur le papier. Mais c’est du VDI. Les bureaux bureautiques sont inactifs la plupart du temps. Un utilisateur qui lit un document ou tape un courriel ne charge pas 8 cœurs. La sur-souscription n’est pas un risque ici, c’est la conception. Proxmox vous laisse allouer plus de vCPU que de threads physiques parce que l’ordonnanceur sait que la plupart d’entre eux dorment. Le CPU est dimensionné pour le pic, et le pic est une poignée d’utilisateurs qui compilent ou rendent en même temps, pas les 42. Ce n’est pas un raccourci — les hyperscalers du cloud sur-souscrivent de la même façon. Chaque VM Azure que vous louez partage des cœurs physiques avec d’autres locataires sur le même hôte. Le modèle de performance est identique. La différence est à qui appartient l’hôte.
• 12 Go de RAM par VM est un solide bureau bureautique. 42 × 12 Go = 504 Go, plus 4 Go pour Proxmox lui-même = 508 Go sur le papier. En pratique KSM effondre les pages identiques à travers ces 42 images Windows, donc la RAM physique nécessaire est nettement moindre — mais budgétez 512 Go de DIMM et laissez KSM vous rendre la marge.
• Trois cartes doubles Intel Arc Pro B60 dans une carte comme la Supermicro H13SSL-NT. Chaque carte physique présente deux GPU au système, donc trois cartes vous donnent 6 GPU. Chaque GPU prend en charge 7 fonctions virtuelles SR-IOV⁴. Cela fait 42 bureaux accélérés par GPU depuis trois emplacements PCIe. Le B60 est listé autour de 599 à 799 $ par carte. Le B70 est l’option plus grosse à 949 $ au lancement pour 32 Go et 4 fonctions virtuelles par GPU⁵ — moins de sièges mais plus de VRAM par siège.

Windows 365 Cloud PC pour 42 utilisateurs² :

Même sans GPU, les nombres ne sont pas petits. Le palier Basic — 2 vCPU, 4 Go, 128 Go — est à 26,90 £/utilisateur/mois. Le palier Standard — 2 vCPU, 8 Go, 128 Go, qui est un bureau bureautique modeste — est à 35,60 £/utilisateur/mois. Pour 42 utilisateurs sur Standard, cela fait 1 495,20 £/mois, 17 942,40 £/an, avant aucun des extras ci-dessous.

Avec un GPU cela empire. Le palier GPU Standard est à 269,40 £/utilisateur/mois. Pour 42 utilisateurs, cela fait 11 314,80 £/mois, 135 777,60 £/an.

Les deux paliers ajoutent ensuite :

• Les licences Microsoft 365 si vous ne les avez pas déjà
• Le réseau Azure — l’entrée et la sortie sont facturées séparément, et un bureau qui diffuse vers un navigateur n’est pas léger en sortie
• Azure Backup ou une solution de sauvegarde tierce — les instantanés de VM et le stockage de profils ne sont pas sauvegardés gratuitement
• Les adresses IPv4 publiques — Azure facture chaque IP publique attachée à une ressource, et le prix n’a fait que monter
• La tarification sous-jacente d’Azure est en USD, donc les coûts en GBP bougent avec le taux de change — une livre faible rend chaque poste plus cher et vous n’avez de contrôle sur aucun des deux côtés de cela
• La facture ne s’arrête jamais. La cinquième année coûte autant que la première.

Cette pile pour 42 utilisateurs — le coût de construction :

• Carte mère Supermicro H13SSL-NT : ~700 £
• CPU AMD EPYC 64 cœurs : ~1 500 £
• 512 Go DDR5 ECC RDIMM (8 × 64 Go) : ~5 200 £
• Trois cartes doubles B60 : ~1 800 £
• Châssis, alimentation, SSD de démarrage : ~800 £
• Total matériel : environ 10 000 £

Amorti sur une vie de cinq ans, cela fait 2 000 £/an en coût de capital. Ajoutez :

• Cloudflare Zero Trust : gratuit jusqu’à 50 utilisateurs
• Droits VDI Windows 11 Enterprise — le Software Assurance sur Pro passe à Enterprise, qui inclut l’accès VDI pour jusqu’à quatre VM par utilisateur, ou licence via Microsoft 365 E3/E5⁶
• L’électricité — et cela vaut d’y mettre un chiffre

Le budget électrique en tirage de pointe : un EPYC 64 cœurs à 360 W de TDP, trois cartes doubles B60 à 400 W chacune (1 200 W), 512 Go de RAM à environ 80 W, plus le stockage, les ventilateurs et les pertes d’alimentation à environ 150 W. Cela fait approximativement 1 800 W à la prise sous pleine charge. Les bureaux VDI ne sont pas sous pleine charge — l’usage bureautique est surtout du CPU inactif et du GPU léger, donc une moyenne réaliste est plus proche de 1 000 à 1 200 W. Disons 1 100 W.

À 0,35 £ le kWh, 1,1 kW tournant 24h/24 et 7j/7, c’est :

• 1,1 × 24 × 365 = 9 636 kWh/an
• 9 636 × 0,35 £ = 3 373 £/an en électricité

Le coût annuel total de cette pile est donc à peu près 5 400 £/an — 2 000 £ de matériel amorti et 3 400 £ d’électricité, avant les licences Windows et l’internet. Mettez cela à côté de la facture Azure : 5 400 £ contre 135 778 £ pour le palier GPU, ou 17 942 £ pour des bureaux simples sans GPU. Même sur le palier Azure le moins cher, cette pile coûte moins d’un tiers. Sur le palier GPU, c’est 4 % de la facture Azure.

Pourquoi le VDI convient à Proxmox

Le VDI est l’une des charges pour lesquelles Proxmox est discrètement très bon, pour deux raisons qui n’ont rien à voir avec l’hyperviseur lui-même.

KSM. Proxmox active KSMd — le démon de fusion de pages identiques du noyau — d’office. Vingt VM Windows bâties depuis la même image partagent d’énormes quantités de pages mémoire identiques : le système d’exploitation, les bibliothèques de base, les parties inchangées du profil utilisateur. KSMd trouve ces doublons et les effondre en une seule page physique, en copie sur écriture. Le résultat est que vingt bureaux tiennent dans la mémoire dont vous auriez sinon besoin pour huit ou dix. Sur un hôte VDI où chaque VM fait tourner la même image, KSM n’est pas une optimisation marginale. C’est ce qui rend la densité abordable.

bcache. Si votre stockage est du Ceph sur HDD avec bcache Optane, le VDI en est la charge idéale. Les tempêtes de démarrage et les tempêtes de connexion sont lourdes en lecture et répétitives — exactement le schéma qu’un cache absorbe. Une fois l’ensemble de travail chaud, les bureaux lisent depuis l’Optane à la latence du NVMe et les plateaux bougent à peine. Les écritures sont des changements de profil utilisateur et des fichiers temporaires, assez petits et séquentiels pour que le writeback de bcache les gère sans jamais engorger le HDD.

Profils — deux options, toutes deux sur Ceph. Les profils utilisateurs sont l’autre moitié du stockage VDI, et il y a deux façons propres de les gérer sans quitter le cluster.

Les conteneurs de profil FSLogix sont la façon standard d’itinérer un profil de bureau Windows, et ils marchent sur un stockage objet compatible S3. Le Ceph de Proxmox expose une passerelle S3 par le RADOS Gateway, donc le magasin de profils vit sur le même cluster que les disques de VM. Pas de serveur de fichiers séparé, pas de facture Azure Files, pas de dépendance externe.

L’autre option est de sauter FSLogix entièrement et d’utiliser la redirection de dossiers Windows vers des partages SMB servis par un Samba en cluster sur CephFS. Les bureaux redirigent Documents, Bureau, AppData et le reste vers un partage Samba adossé à CephFS, et le cluster Samba gère la bascule. Pas de conteneur de profil du tout — les fichiers vivent sur le système de fichiers comme fichiers ordinaires, et CephFS gère la réplication. C’est plus simple à gérer, plus simple à sauvegarder, et cela contourne entièrement les licences FSLogix — utile si le coût de licence pose problème ou si vous voulez simplement moins de pièces mobiles. Dans un cas comme dans l’autre, les profils siègent sur votre propre stockage, adossés au même pool Ceph, et le coût est le disque que vous avez déjà acheté.

Entre KSM qui récupère de la mémoire, bcache qui récupère de la latence de stockage et les profils qui atterrissent sur Ceph — que ce soit par FSLogix sur S3 ou par redirection de dossiers sur CephFS — un seul hôte Proxmox avec des HDD et une quantité modeste de RAM sert plus de bureaux que la fiche technique ne le suggère. Azure facture chaque gigaoctet des trois. Ici, l’infrastructure fait le travail gratuitement.

Sauvegarde, résilience et conformité

Tout garder à l’intérieur du VDI n’est pas qu’une décision de coût. C’est une décision de conformité et de résilience.

Quand le bureau vit sur le serveur, les données vivent sur le serveur. Rien n’atterrit sur l’appareil de l’utilisateur. Un portable volé est un écran perdu, pas un jeu de données perdu. Il n’y a pas de disque local à chiffrer, pas de copie locale à exfiltrer, pas de point de terminaison à imager en criminalistique après une brèche. Les données n’ont jamais quitté l’infrastructure que vous contrôlez.

Cela rend la sauvegarde simple. Les disques de VM et les magasins de profils sont sur Ceph, et les instantanés Ceph sont atomiques et instantanés. Une seule politique d’instantané couvre chaque bureau et chaque profil. Restaurer un bureau à son état d’hier est un retour arrière d’instantané, pas une reconstruction. Restaurer un profil est la même opération sur un pool différent. La cible de sauvegarde est le cluster, pas vingt points de terminaison éparpillés.

Cela simplifie aussi la conformité. La résidence des données est facile à prouver quand les données sont sur du matériel qui vous appartient, dans un rack que vous pouvez montrer du doigt, dans une juridiction que vous avez choisie. Les pistes d’audit siègent sur vos propres journaux. L’accès est verrouillé par des politiques Cloudflare que vous avez écrites, authentifié par un IdP que vous exploitez, et enregistré par des systèmes que vous contrôlez. Il n’y a pas de fournisseur cloud tiers entre vous et la preuve qu’un auditeur demande.

La résilience suit la même ligne. Une VM de bureau morte est une nouvelle VM depuis l’image de référence avec le profil réattaché. L’utilisateur se reconnecte et le bureau est de retour. Il n’y a pas de point de terminaison à reconstruire, pas de système à réinstaller, pas de matériel à expédier. L’unité de récupération est la VM, et en lancer une prend des minutes.

Ce que vous abandonnez

Ce n’est pas gratuit dans tous les sens. Les choses qu’Azure Virtual Desktop gère et que cette pile ne gère pas :

• Microsoft gère les correctifs et les mises à jour. Ici, c’est vous.
• Intune et Endpoint Manager s’intègrent nativement avec AVD. Ici, vous gérez les VM Windows vous-même ou par l’outillage que vous choisissez.
• Le réseau d’Azure est le problème d’Azure. Ici, votre connexion internet est le chemin vers le bureau. Si elle tombe, les bureaux sont inatteignables jusqu’à ce qu’elle revienne.
• L’échelle est à une carte de crédit près sur Azure. Ici, l’échelle veut dire acheter une autre carte ou un autre hôte.
• AVD donne à l’utilisateur un jeu complet de fonctions RDP par défaut. Ici, le chemin rendu dans le navigateur retire le presse-papiers, l’audio et le multi-écran exprès. Les utilisateurs qui ont besoin de ces fonctions obtiennent un client RDP natif par le même tunnel et la même politique — mais le défaut est le navigateur verrouillé, et c’est le bon défaut pour un effectif BYOD.

Rien de cela n’est trivial. Que cela compte ou non dépend de ce que vous avez : si vous faites déjà tourner Proxmox, gérez déjà Windows, et avez déjà quelqu’un qui sait s’occuper d’un hyperviseur, alors tout cela, vous le faites déjà. Sinon, Azure vous vend le personnel que vous n’avez pas, et cela vaut vraiment quelque chose.

La question est de savoir si cela vaut 18 000 £ par an pour 42 bureaux simples — ou 136 000 £ pour des bureaux GPU — chaque année, plus le réseau, la sauvegarde, l’IPv4 et les licences par-dessus, avec le prix fixé par quelqu’un d’autre, le matériel appartenant à quelqu’un d’autre, et la facture libellée dans une monnaie que vous ne contrôlez pas. Ou si vous dépensez 5 400 £ par an en matériel et électricité et gardez le reste.

C’est ce que ce billet expose. Le prochain le construit — le tunnel cloudflared, le LXC, les règles de pare-feu Proxmox, la politique Cloudflare Access, et le bureau qui marche dans un onglet de navigateur.

Références