Streamer des applications Windows sur AWS avec Amazon AppStream 2.0

Imaginez : des collaborateurs et des partenaires externes ont besoin d'accéder à des applications Windows métier, mais vous ne pouvez pas gérer un parc de postes, installer des logiciels sur des appareils non maîtrisés, ou laisser des données d'entreprise sur des ordinateurs personnels.

C'est précisément le défi de notre client. Notre réponse : diffuser les applications directement dans le navigateur, depuis AWS, pour que rien ne touche jamais l'appareil de l'utilisateur final.

Amazon AppStream 2.0 rend cela possible en exécutant les applications Windows sur des instances AWS et en les streamant en temps réel. Aucune installation locale, aucune donnée sur l'appareil, aucun port ouvert. Mais déployer AppStream en entreprise, ce n'est pas juste lancer une fleet. Il faut orchestrer un écosystème complet : réseau, Active Directory, stockage des profils, authentification SSO et gestion des images applicatives.

Dans cet article, nous détaillons comment nous avons mis tout cela en place.

Vue d'ensemble de l'architecture

AppStream s'appuie sur des instances Windows pour exécuter les applications — mais ces instances ne fonctionnent pas seules. Elles ont besoin de savoir qui est l'utilisateur, où stocker ses données, et comment l'authentifier.

C'est pourquoi l'infrastructure repose sur quatre briques essentielles :

• Amazon AppStream 2.0 — une fleet d'instances Windows qui diffuse les applications directement dans le navigateur de l'utilisateur
• AWS Managed Microsoft AD — un Active Directory entièrement managé qui gère les identités et les stratégies de domaine Windows
• FSx for Windows File Server — un stockage réseau où sont conservés les profils utilisateurs et les scripts de configuration, pour que chaque utilisateur retrouve un environnement cohérent d'une session à l'autre
• Entra ID (Azure AD) — le fournisseur d'identité existant du client, intégré via SSO pour que les utilisateurs se connectent avec leurs identifiants habituels

Le tout fonctionne au sein d'un réseau dédié (VPC) sur AWS. L'infrastructure principale est provisionnée avec AWS CDK en TypeScript. Passons en revue chaque couche.

Réseau et sécurité

Tout commence par le réseau. Le VPC est la fondation sur laquelle reposent tous les autres composants. Nous l'avons configuré avec deux Availability Zones pour la redondance, ainsi que des sous-réseaux publics et privés. Un seul NAT Gateway fournit l'accès internet sortant aux instances des sous-réseaux privés, tandis qu'un S3 Gateway Endpoint garde le trafic S3 hors de l'internet public, réduisant les coûts et améliorant la sécurité.

const vpc = new Vpc(this, "Vpc", {
    maxAzs: 2,
    natGateways: 1,
    subnetConfiguration: [
        {
            name: "Public",
            subnetType: SubnetType.PUBLIC,
        },
        {
            name: "Private",
            subnetType: SubnetType.PRIVATE_WITH_EGRESS,
        },
    ],
});
 
vpc.addGatewayEndpoint("S3Endpoint", {
    service: GatewayVpcEndpointAwsService.S3,
});

Côté sécurité, les Security Groups méritent qu'on s'y attarde. Chaque composant a ses propres règles. Les instances AppStream ont besoin de HTTPS, HTTP et UDP 8433 (le protocole de streaming), tandis que FSx nécessite SMB (port 445) et WinRM (port 5985) pour le partage de fichiers et l'administration à distance. Les deux ont besoin d'accéder aux ports Active Directory pour le domain join et l'authentification.

Plutôt que d'ouvrir des plages larges, nous avons défini des règles de sortie granulaires par composant, limitant ainsi le rayon d'impact en cas de compromission.

Identité et stockage

Active Directory managé

Dans un environnement Windows, Active Directory est le pilier de l'identité. C'est ce qui permet aux instances AppStream de rejoindre un domaine, d'appliquer des stratégies de groupe et de reconnaître les utilisateurs. Nous utilisons AWS Managed Microsoft AD, un service entièrement managé qui évite de devoir maintenir ses propres contrôleurs de domaine.

const ad = new CfnMicrosoftAD(this, "MicrosoftAD", {
    name: "ad.example.com",
    shortName: "CORP",
    edition: "Standard",
    password: adAdminPassword.secretValue.unsafeUnwrap(),
    vpcSettings: {
        vpcId: props.vpc.vpcId,
        subnetIds: props.vpc.selectSubnets({
            subnetType: SubnetType.PRIVATE_WITH_EGRESS,
        }).subnetIds.slice(0, 2),
    },
});

Une fois l'annuaire provisionné, certaines configurations ne peuvent pas être automatisées. CloudFormation ne gère tout simplement pas les objets AD. Pour créer les Organizational Units, les comptes de service et leurs permissions, les stratégies de groupe, les partages FSx et les comptes utilisateurs, nous nous sommes connectés à une instance EC2 de management via AWS Systems Manager (SSM) et avons exécuté la configuration manuellement en PowerShell. Pas de SSH, pas de port ouvert. Juste une session sécurisée via la console AWS. Des runbooks détaillés avec les commandes exactes à exécuter sont indispensables pour garantir la reproductibilité.

FSx for Windows et FSLogix

Une question qu'on oublie souvent de se poser : que deviennent le bureau, les paramètres et les fichiers d'un utilisateur entre deux sessions ? Sans stockage persistant, chaque session AppStream repart de zéro. C'est là qu'interviennent FSx for Windows File Server et FSLogix.

FSx fournit des partages SMB entièrement managés et intégrés à Active Directory. Nous en avons configuré cinq : trois utilisés à l'exécution par les instances AppStream, et deux utilisés uniquement lors de la construction de l'image.

Partages runtime :

• Profiles — utilisé par FSLogix (installé sur l'image AppStream) pour stocker le profil de chaque utilisateur dans un conteneur dédié. À la connexion, le profil est monté automatiquement. À la déconnexion, il est sauvegardé. Les utilisateurs retrouvent ainsi un environnement cohérent d'une session à l'autre.
• Sessions_Scripts — des scripts PowerShell exécutés à l'ouverture de session. L'avantage est considérable : au lieu de reconstruire l'image pour chaque petit changement, on met à jour ces scripts sur le partage et ils prennent effet dès la prochaine session.
• Mytools — utilitaires et scripts d'aide à l'exécution, copiés sur chaque instance AppStream à l'ouverture de session.

Partages pour la construction de l'image :

• Install — scripts d'installation et installateurs d'applications utilisés lors de la construction de l'image AppStream.
• Sources — ressources statiques pour la construction de l'image : templates de stratégies de groupe, icônes et installateurs d'applications à la demande.

const fileSystem = new CfnFileSystem(this, "FsxFileSystem", {
    fileSystemType: "WINDOWS",
    subnetIds: props.vpc.selectSubnets({
        subnetType: SubnetType.PRIVATE_WITH_EGRESS,
    }).subnetIds.slice(0, 2),
    windowsConfiguration: {
        activeDirectoryId: props.directoryId,
        deploymentType: "MULTI_AZ_1",
        automaticBackupRetentionDays: 7,
    },
});

Le déploiement Multi-AZ assure la disponibilité du système de fichiers même en cas de panne d'une Availability Zone, ce qui est critique quand les profils utilisateurs en dépendent.

FSx gère le stockage. FSLogix, quant à lui, est installé et configuré lors de la construction de l'image, ce que nous abordons dans la section suivante.

La couche AppStream

Le réseau, l'identité et le stockage sont en place. Passons à ce que l'utilisateur voit concrètement.

Fleet et Stack

Une fleet AppStream est un pool d'instances Windows prêtes à servir des sessions utilisateurs. Concrètement, c'est un groupe de bureaux virtuels prêts à l'emploi. Quand un utilisateur se connecte, une instance du pool lui est attribuée.

La fleet est provisionnée via Infrastructure as Code et configurée en mode always-on. Les instances tournent et sont prêtes avant même que les utilisateurs ne se connectent, éliminant les temps d'attente au démarrage. Chaque instance est jointe au domaine Managed AD, ce qui lui donne accès aux stratégies de groupe, aux profils utilisateurs sur FSx et à toutes les ressources réseau nécessaires.

const fleet = new CfnFleet(this, "AppStreamFleet", {
    instanceType: props.instanceType,
    fleetType: "ALWAYS_ON",
    computeCapacity: {
        desiredInstances: 3,
    },
    domainJoinInfo: {
        directoryName: props.directoryName,
        organizationalUnitDistinguishedName: props.ouPath,
    },
    vpcConfig: {
        subnetIds: props.vpc.selectSubnets({
            subnetType: SubnetType.PRIVATE_WITH_EGRESS,
        }).subnetIds,
        securityGroupIds: [props.appStreamSecurityGroup.securityGroupId],
    },
});

Le stack définit l'expérience utilisateur : accès au presse-papier (dans les deux sens), transfert de fichiers, redirection de l'imprimante locale et intégration OneDrive. L'ensemble rend la session streamée presque indiscernable d'un bureau local.

const appStreamStack = new CfnStack(this, "AppStreamStack", {
    storageConnectors: [{
        connectorType: "ONE_DRIVE",
        domains: [props.oneDriveDomain],
    }],
    // Presse-papier, transfert de fichiers, impression locale — tout activé
    userSettings: [
        { action: "CLIPBOARD_COPY_FROM_LOCAL_DEVICE", permission: "ENABLED" },
        { action: "FILE_UPLOAD", permission: "ENABLED" },
        // ...
    ],
});

L'Image Builder

L'image applicative définit quelles applications sont disponibles et comment l'environnement Windows est configuré. Contrairement à la fleet, l'image builder est créé manuellement depuis la console Amazon WorkSpaces Applications.

Au lancement d'un image builder, quelques choix de configuration sont importants :

• Base image — choisir une image Windows Server fournie par AWS comme point de départ
• Instance type — choisir un type correspondant à celui de la fleet
• VPC, Subnet et Security Groups — le placer dans un sous-réseau privé ayant accès à l'AD et aux partages FSx
• Default Internet Access — le désactiver si vous utilisez un NAT Gateway
• Directory Name et OU — le connecter au Managed AD et spécifier l'Organizational Unit pour les machines image builder

Une fois lancé, on s'y connecte via une session de streaming dans le navigateur. La connexion se fait en deux temps : d'abord en tant qu'Administrateur local pour accorder les droits d'admin AD sur la machine, puis en se reconnectant en tant qu'utilisateur du domaine pour accéder aux partages FSx via Kerberos.

À partir de là, la mise en place est pilotée par des scripts. Un premier script gère la configuration système : fuseau horaire, clés de registre, templates de stratégies de groupe, un ensemble de paquets de base via Chocolatey et les mises à jour Windows. Il copie aussi les scripts de session, les outils et les lanceurs d'applications depuis les partages FSx.

Un second script lit un fichier de configuration JSON pour installer les applications métier depuis FSx, puis les enregistre dans le catalogue AppStream.

Enfin, l'Image Assistant optimise l'image pour les performances de streaming et la publie pour utilisation par la fleet.

Conseil pratique : Conservez la liste de vos applications dans un fichier de configuration JSON sur FSx. Ajouter ou mettre à jour une application se résume à modifier la config et reconstruire l'image, sans refaire toute la configuration depuis zéro.

Voici à quoi ressemble une image publiée, avec les applications enregistrées visibles dans le catalogue :

Un choix de conception à souligner : nous conservons les scripts de session sur FSx plutôt que dans l'image. Cela permet de modifier le comportement à l'ouverture de session (monter de nouveaux lecteurs réseau, appliquer des paramètres, lancer des diagnostics) sans avoir à reconstruire l'image.

Authentification : SAML et Entra ID

Dernière pièce du puzzle : l'authentification. Les collaborateurs de notre client utilisent déjà Microsoft 365 au quotidien. Plutôt que de leur imposer de nouveaux identifiants, nous avons intégré AppStream avec leur tenant Entra ID (Azure AD) existant via une fédération SAML.

1. L'utilisateur accède à l'URL SAML dédiée d'AppStream ou lance l'application directement depuis le portail Entra ID
2. Il est redirigé vers Entra ID et se connecte avec ses identifiants Microsoft habituels
3. Entra ID émet une assertion SAML. AppStream assigne l'utilisateur à une instance de la fleet déjà jointe au domaine
4. FSLogix monte le profil de l'utilisateur depuis FSx
5. L'utilisateur arrive sur son bureau Windows, prêt à travailler

Pour que cela fonctionne, chaque utilisateur doit exister à la fois dans Entra ID et dans le Managed AD. Les comptes AD sont provisionnés via un script PowerShell qui lit un groupe Entra ID et crée les comptes correspondants dans Active Directory, sans agent de synchronisation.

Côté utilisateur, c'est transparent : une seule connexion, et c'est parti.

Ce que nous avons appris

Tout ne peut pas être en Infrastructure as Code, et ce n'est pas grave. Objets AD, stratégies de groupe, permissions FSx : certaines choses doivent être configurées manuellement. L'important est de documenter chaque étape dans des runbooks détaillés pour que le processus reste reproductible.

FSLogix change la donne. Sans profils persistants, chaque session repart de zéro. Combiné à FSx, les utilisateurs bénéficient d'une expérience fluide d'une session à l'autre, sans effort supplémentaire de leur part.

Les scripts de session valent mieux qu'une reconstruction d'image. Charger les scripts depuis FSx à l'ouverture de session permet d'itérer rapidement, sans reconstruire l'image à chaque petit changement.

CDK apporte de la cohérence. Avoir l'infrastructure principale en TypeScript nous donne le typage fort et un pipeline de déploiement unique.

Chez Necko Technologies, nous concevons et déployons des infrastructures cloud adaptées aux besoins réels des organisations. AppStream n'est qu'une pièce d'un puzzle plus large : identité, réseau, stockage, sécurité et automatisation doivent fonctionner ensemble. Si vous faites face à un défi similaire (livraison d'applications, migration cloud, ou autre chose), n'hésitez pas à nous contacter. Nous serons ravis d'échanger.