Conception en VPC

Cette section décrit les meilleures pratiques en matière de dimensionnement de votre VPC et de vos sous-réseaux, le flux de trafic et les implications pour la conception des services d'annuaire.

Voici quelques éléments à prendre en compte lors de la conception du VPC, des sous-réseaux, des groupes de sécurité, des politiques de routage et des listes de contrôle d'accès réseau (ACL) pour votre Amazon WorkSpaces afin de pouvoir créer votre WorkSpaces environnement en termes d'évolutivité, de sécurité et de facilité de gestion :

• VPC — Nous vous recommandons d'utiliser un VPC distinct spécialement pour votre déploiement. WorkSpaces Avec un VPC distinct, vous pouvez définir la gouvernance et les garde-fous de sécurité nécessaires pour votre entreprise en WorkSpaces créant une séparation du trafic.

• Services d'annuaire : chaque AWS Directory Service construction nécessite une paire de sous-réseaux fournissant un service d'annuaire hautement disponible réparti entre les AZ.

• Taille du sous-réseau : WorkSpaces les déploiements sont liés à une structure de répertoire et résident dans le même VPC que celui que vous avez choisi AWS Directory Service, mais ils peuvent se trouver dans des sous-réseaux VPC différents. Quelques considérations :

  • La taille des sous-réseaux est permanente et ne peut pas être modifiée. Vous devez laisser suffisamment de place à la croissance future.

  • Vous pouvez définir un groupe de sécurité par défaut pour votre choix AWS Directory Service. Le groupe de sécurité s'applique à tous WorkSpaces ceux qui sont associés à la AWS Directory Service construction spécifique.

  • Vous pouvez avoir plusieurs instances d' AWS Directory Service utilisation du même sous-réseau.

Pensez à vos projets futurs lors de la conception de votre VPC. Par exemple, vous souhaiterez peut-être ajouter des composants de gestion, tels qu'un serveur antivirus, un serveur de gestion des correctifs ou un serveur MFA AD ou RADIUS. Il vaut la peine de prévoir des adresses IP supplémentaires disponibles dans la conception de votre VPC pour répondre à ces exigences.

Pour obtenir des conseils et des considérations approfondis concernant la conception des VPC et le dimensionnement des sous-réseaux, reportez-vous à la présentation de re:Invent How Amazon.com is Moving to Amazon. WorkSpaces

Interfaces réseau

Chacune WorkSpaces possède deux interfaces réseau élastiques (ENI), une interface réseau de gestion (eth0) et une interface réseau principale (eth1). AWS utilise l'interface réseau de gestion pour gérer le WorkSpace  : il s'agit de l'interface sur laquelle se termine votre connexion client. AWS utilise une plage d'adresses IP privées pour cette interface. Pour que le routage réseau fonctionne correctement, vous ne pouvez pas utiliser cet espace d'adressage privé sur un réseau capable de communiquer avec votre WorkSpaces VPC.

Pour obtenir la liste des plages d'adresses IP privées utilisées par région, consultez Amazon WorkSpaces Details.

Note

Amazon WorkSpaces et ses interfaces réseau de gestion associées ne résident pas dans votre VPC, et vous ne pouvez pas consulter l'interface réseau de gestion ou l'ID d'instance Amazon Elastic Compute Cloud (Amazon EC2) dans AWS Management Console votre (reportez-vous Figure 5 à, et). Figure 6 Figure 7 Toutefois, vous pouvez consulter et modifier les paramètres du groupe de sécurité de votre interface réseau principale (eth1) dans la console. L'interface réseau principale de chacun d'entre eux WorkSpace est prise en compte dans vos quotas de ressources ENI Amazon EC2. Pour les déploiements d'Amazon à grande échelle WorkSpaces, vous devez ouvrir un ticket d'assistance via le AWS Management Console pour augmenter vos quotas ENI.

Flux de trafic

Vous pouvez diviser le WorkSpaces trafic Amazon en deux composantes principales :

• Le trafic entre l'appareil client et le WorkSpaces service Amazon.

• Le trafic entre le WorkSpaces service Amazon et le trafic réseau du client.

La section suivante traite de ces deux composants.

Appareil client pour WorkSpace

Quel que soit son emplacement (sur site ou à distance), l'appareil exécutant le WorkSpaces client Amazon utilise les deux mêmes ports pour se connecter au WorkSpaces service Amazon. Le client utilise le port 443 (port HTTPS) pour toutes les informations relatives à l'authentification et à la session, et le port 4172 (port PCoIP), avec le protocole TCP (Transmission Control Protocol) et le protocole UDP (User Datagram Protocol), pour le streaming de pixels vers une donnée et les contrôles de santé du réseau. WorkSpace Le trafic sur les deux ports est crypté. Le trafic du port 443 est utilisé pour l'authentification et les informations de session et utilise le protocole TLS pour chiffrer le trafic. Le trafic de streaming de pixels utilise le cryptage AES-256 bits pour la communication entre le client et le WorkSpace, via la passerelle eth0 de streaming. Vous trouverez de plus amples informations dans la Sécurité section de ce document.

Nous publions les plages d'adresses IP par région de nos passerelles de streaming PCoIP et de nos points de terminaison de contrôle de l'état du réseau. Vous pouvez limiter le trafic sortant sur le port 4172 depuis le réseau de votre entreprise vers la passerelle de AWS streaming et les points de terminaison de contrôle de l'état du réseau en autorisant uniquement le trafic sortant sur le port 4172 à destination des AWS régions spécifiques dans lesquelles vous utilisez Amazon. WorkSpaces Pour les plages d'adresses IP et les points de terminaison de vérification de l'état du réseau, reportez-vous à la section Plages d'adresses IP Amazon WorkSpaces PCoIP Gateway.

Le WorkSpaces client Amazon dispose d'une fonction intégrée de vérification de l'état du réseau. Cet utilitaire indique aux utilisateurs si leur réseau peut prendre en charge une connexion au moyen d'un indicateur d'état en bas à droite de l'application. La figure suivante montre une vue plus détaillée de l'état du réseau accessible en choisissant Réseau en haut à droite du client.

Figure 1 : WorkSpaces Client : vérification du réseau

Un utilisateur établit une connexion entre son client et le WorkSpaces service Amazon en fournissant ses informations de connexion pour le répertoire utilisé par la structure Directory Service, généralement son annuaire d'entreprise. Les informations de connexion sont envoyées via HTTPS aux passerelles d'authentification du WorkSpaces service Amazon dans la région où ils WorkSpace se trouvent. La passerelle d'authentification du WorkSpaces service Amazon transmet ensuite le trafic à la structure de AWS Directory Service spécifique associée à votre WorkSpace.

Par exemple, lorsque vous utilisez l'AD Connector, celui-ci transmet la demande d'authentification directement à votre service AD, qui peut être sur site ou dans un AWS VPC. Pour plus d'informations, reportez-vous à la section Scénarios de déploiement AD DS de ce document. L'AD Connector ne stocke aucune information d'authentification et agit comme un proxy apatride. Par conséquent, il est impératif que l'AD Connector soit connecté à un serveur AD. L'AD Connector détermine le serveur AD auquel se connecter en utilisant les serveurs DNS que vous définissez lorsque vous créez l'AD Connector.

Si vous utilisez un AD Connector et que l'authentification MFA est activée sur l'annuaire, le jeton MFA est vérifié avant l'authentification du service d'annuaire. En cas d'échec de la validation MFA, les informations de connexion de l'utilisateur ne sont pas transmises à votre AWS Directory Service.

Une fois qu'un utilisateur est authentifié, le trafic de streaming démarre en utilisant le port 4172 (port PCoIP) via la passerelle de AWS streaming vers le. WorkSpace Les informations relatives à la session sont toujours échangées via HTTPS tout au long de la session. Le trafic de streaming utilise le premier ENI sur le WorkSpace (eth0sur le WorkSpace) qui n'est pas connecté à votre VPC. La connexion réseau entre la passerelle de streaming et l'ENI est gérée par AWS. En cas d'échec de connexion entre les passerelles de diffusion et l'ENI de WorkSpaces diffusion, un CloudWatch événement est généré. Pour plus d'informations, consultez la CloudWatch section Surveillance ou journalisation à l'aide d'Amazon de ce document.

La quantité de données envoyée entre le WorkSpaces service Amazon et le client dépend du niveau d'activité des pixels. Pour garantir une expérience optimale aux utilisateurs, nous recommandons que le temps d'aller-retour (RTT) entre le WorkSpaces client et la AWS région où vous vous WorkSpaces trouvez soit inférieur à 100 millisecondes (ms). Cela signifie généralement que votre WorkSpaces client est situé à moins de trois mille kilomètres de la région dans laquelle WorkSpace il est hébergé. La page Web Connection Health Check peut vous aider à déterminer la AWS région la plus optimale pour vous connecter au WorkSpaces service Amazon.

Amazon WorkSpaces Service vers VPC

Une fois qu'une connexion est authentifiée entre un client WorkSpace et qu'un trafic de streaming est initié, votre WorkSpaces client affiche un poste de travail Windows ou Linux (votre Amazon WorkSpace) connecté à votre cloud privé virtuel (VPC), et votre réseau doit indiquer que vous avez établi cette connexion. La WorkSpace principale Elastic Network Interface (ENI), identifiée commeeth1, se verra attribuer une adresse IP par le service DHCP (Dynamic Host Configuration Protocol) fourni par votre VPC, généralement à partir des mêmes sous-réseaux que votre Directory AWS Service. L'adresse IP est conservée WorkSpace pendant toute la durée de vie du WorkSpace. L'ENI de votre VPC a accès à toutes les ressources du VPC et à tous les réseaux que vous avez connectés à votre VPC (via un peering VPC, une connexion ou une connexion VPN). AWS Direct Connect

L'accès de l'ENI aux ressources de votre réseau est déterminé par la table de routage du sous-réseau et du groupe de sécurité par défaut que votre AWS Directory Service configure pour chacun WorkSpace, ainsi que par tout groupe de sécurité supplémentaire que vous attribuez à l'ENI. Vous pouvez ajouter des groupes de sécurité à l'ENI faisant face à votre VPC à tout moment en utilisant le AWS Management Console ou. AWS CLI (Pour plus d'informations sur les groupes de sécurité, reportez-vous à la section Groupes de sécurité pour vous WorkSpaces.) Outre les groupes de sécurité, vous pouvez utiliser votre pare-feu hôte préféré sur un site donné WorkSpace pour limiter l'accès réseau aux ressources du VPC.

Il est recommandé de créer votre ensemble d'options DHCP avec les adresses IP du serveur DNS et les noms de domaine complets faisant autorité dans votre Active Directory et spécifiques à votre environnement, puis d'attribuer ces options DHCP personnalisées définies au VPC Amazon utilisé par Amazon. WorkSpaces Par défaut, Amazon Virtual Private Cloud (Amazon VPC) utilise le AWS DNS au lieu du DNS de votre service d'annuaire. L'utilisation d'un ensemble d'options DHCP garantit une résolution correcte des noms DNS et une configuration cohérente de vos serveurs de noms DNS internes, non seulement pour votre charge de travail ou instance de support WorkSpaces, mais également pour toute charge de travail ou instance de support que vous pourriez avoir planifiée pour votre déploiement.

Lorsque les options DHCP sont appliquées, il existe deux différences importantes dans la manière dont elles seront appliquées par rapport WorkSpaces à la manière dont elles sont appliquées aux instances EC2 traditionnelles :

• La première différence réside dans la manière dont les suffixes DNS de l'option DHCP seront appliqués. Les paramètres DNS de chacun WorkSpace sont configurés pour son adaptateur réseau, les options Ajouter les suffixes DNS principaux et spécifiques à la connexion et Ajouter les suffixes parents des suffixes DNS principaux étant activées. La configuration sera mise à jour avec le suffixe DNS configuré dans le AWS Directory Service que vous avez enregistré et auquel vous êtes associé WorkSpace par défaut. De même, si le suffixe DNS configuré dans le jeu d'options DHCP utilisé est différent, il sera ajouté et appliqué à tout suffixe associé. WorkSpaces

• La deuxième différence est que les adresses IP DNS de l'option DHCP configurées ne seront pas appliquées WorkSpace car le WorkSpaces service Amazon donne la priorité aux adresses IP des contrôleurs de domaine du répertoire configuré.

Vous pouvez également configurer une zone hébergée privée Route 53 pour prendre en charge un environnement DNS hybride ou partagé et obtenir une résolution DNS appropriée pour votre WorkSpaces environnement Amazon. Pour plus d'informations, reportez-vous aux options DNS du cloud hybride pour VPC et au DNS AWS hybride avec Active Directory.

Note

Chacun WorkSpace doit actualiser la table IP lors de l'application d'un ensemble d'options DHCP nouveau ou différent au VPC. Pour actualiser, vous pouvez exécuter ipconfig /renew ou redémarrer n'importe quel WorkSpace VPC configuré avec vos options DHCP mises à jour. Si vous utilisez AD Connector et que vous mettez à jour les adresses IP de vos adresses IP/contrôleurs de domaine connectés, vous devez ensuite mettre à jour la clé de DomainJoinDNS registre Skylight sur votre. WorkSpaces Il est recommandé de le faire via un GPO. Le chemin d'accès à cette clé de registre estHKLM:\SOFTWARE\Amazon\Skylight. La valeur de cette valeur n'REG_SZest pas mise à jour si les paramètres DNS du connecteur AD sont modifiés, et les ensembles d'options DHCP VPC ne mettront pas non plus à jour cette clé.

La figure de la section Scénarios de déploiement AD DS de ce livre blanc montre le flux de trafic décrit.

Comme expliqué précédemment, le WorkSpaces service Amazon donne la priorité aux adresses IP des contrôleurs de domaine du répertoire configuré pour la résolution DNS et ignore les serveurs DNS configurés dans votre ensemble d'options DHCP. Si vous avez besoin d'un contrôle plus précis des paramètres de votre serveur DNS pour votre Amazon WorkSpaces, vous pouvez suivre les instructions relatives à la mise à jour des serveurs DNS pour Amazon figurant WorkSpaces dans le WorkSpaces guide Update DNS servers for Amazon du Amazon WorkSpaces Administration Guide.

Si vous WorkSpaces devez résoudre d'autres services et si vous utilisez les options DHCP par défaut définies avec votre VPC, le service DNS de votre contrôleur de domaine dans AWS ce VPC doit donc être configuré pour utiliser le transfert DNS, en pointant vers le serveur Amazon DNS avec l'adresse IP à la base de votre CIDR VPC plus deux ; en d'autres termes, si votre CIDR VPC est 10.0.0.0/24, vous configurez le transfert DNS pour utiliser le résolveur DNS Route 53 standard à 10.0.0.2.

Si vous avez WorkSpaces besoin d'une résolution DNS des ressources de votre réseau local, vous pouvez utiliser un point de terminaison sortant Route 53 Resolver, créer une règle de transfert Route 53 et associer cette règle aux VPC nécessitant cette résolution DNS. Si vous avez configuré le transfert sur le service DNS de votre contrôleur de domaine vers le résolveur DNS Route 53 par défaut de votre VPC, comme expliqué dans le paragraphe précédent, le processus de résolution DNS se trouve dans le guide de résolution des requêtes DNS entre VPC et dans le guide de votre réseau du guide du développeur Amazon Route 53.

Si vous utilisez les options DHCP définies par défaut et que vous avez besoin d'autres hôtes de vos VPC qui ne font pas partie de votre domaine Active Directory pour résoudre les noms d'hôtes dans votre espace de noms Active Directory, vous pouvez utiliser ce point de terminaison sortant Route 53 Resolver et ajouter une autre règle de transfert Route 53 qui transmet les requêtes DNS de votre domaine Active Directory à vos serveurs DNS Active Directory. Cette règle de transfert Route 53 devra être associée au point de terminaison sortant du résolveur Route 53 capable d'accéder à votre service DNS Active Directory, ainsi qu'à tous les VPC que vous souhaitez activer pour résoudre les enregistrements DNS dans votre domaine WorkSpaces Active Directory.

De même, un point de terminaison entrant Route 53 Resolver peut être utilisé pour autoriser la résolution DNS des enregistrements DNS de votre domaine WorkSpaces Active Directory à partir de votre réseau local.

Figure 2 : Exemple de résolution WorkSpaces DNS avec les points de terminaison Route 53

• Votre Amazon WorkSpaces utilisera le service DNS AWS Directory Service for Microsoft Active Directory (AWS Managed Microsoft AD) pour la résolution DNS. Le service AWS Managed Microsoft AD DNS résout le example.aws domaine et transmet toutes les autres requêtes DNS au résolveur DNS Route 53 par défaut à l'adresse IP de base VPC CIDR +2 pour activer la résolution DNS

  Le VPC Shared Services contient un point de terminaison Route 53 Outbound Resolver, qui est associé à deux règles de transfert Route 53. L'une de ces règles transmet les requêtes DNS pour le example.com domaine aux serveurs DNS locaux. La deuxième règle transmet les requêtes DNS pour votre AWS Managed Microsoft AD domaine example.aws à votre service DNS Active Directory dans le VPC Shared Services.

  Grâce à cette architecture, votre Amazon WorkSpaces sera en mesure de résoudre les requêtes DNS pour les éléments suivants :

  • Votre AWS Managed Microsoft AD domaineexample.aws.

  • Les instances EC2 du domaine sont configurées avec votre ensemble d'options DHCP par défaut (par exemple,host1.eu-west-1.compute.internal) ainsi que d'autres AWS services ou points de terminaison.

  • Les hôtes et les services de votre domaine local, tels quehost3.example.com.

• • Les autres charges de travail EC2 du VPC Shared Services (host1.eu-west-1.compute.internal) et du WorkSpaces VPC (host2.eu-west-1.compute.internal) peuvent utiliser les mêmes résolutions DNS que les vôtres WorkSpaces, à condition que les règles de transfert Route 53 soient associées aux deux VPC. Dans ce cas, la résolution DNS du example.aws domaine passera par le résolveur DNS Route 53 par défaut à l'adresse IP de base VPC CIDR +2, qui, selon les règles de transfert Route 53 configurées et associées, les transmettra via le point de terminaison sortant du résolveur Route 53 au WorkSpaces service DNS Active Directory.

• • Enfin, un client local peut également effectuer la même résolution DNS, puisque le serveur DNS local est configuré avec des redirecteurs conditionnels pour les eu-west-1.compute.internal domaines example.aws et, transférant les requêtes DNS pour ces domaines aux adresses IP des points de terminaison entrants du résolveur Route 53.

Exemple de configuration typique

Imaginons un scénario dans lequel vous avez deux types d'utilisateurs et où votre AWS Directory Service utilise un AD centralisé pour l'authentification des utilisateurs :

• Travailleurs qui ont besoin d'un accès complet depuis n'importe où (par exemple, les employés à plein temps) : ces utilisateurs auront un accès complet à Internet et au réseau interne, et ils passeront par un pare-feu entre le VPC et le réseau sur site.

• Travailleurs qui ne devraient avoir qu'un accès restreint depuis le réseau de l'entreprise (par exemple, les sous-traitants et les consultants) — Ces utilisateurs ont un accès Internet restreint via un serveur proxy à des sites Web spécifiques du VPC, et auront un accès réseau limité dans le VPC et au réseau sur site.

Vous souhaitez donner aux employés à temps plein la possibilité de disposer d'un accès administrateur local WorkSpace pour installer leurs logiciels, et vous aimeriez appliquer l'authentification à deux facteurs grâce à la MFA. Vous souhaitez également permettre aux employés à temps plein d'accéder à Internet sans restrictions de leur part WorkSpace.

Pour les sous-traitants, vous souhaitez bloquer l'accès des administrateurs locaux afin qu'ils ne puissent utiliser que des applications préinstallées spécifiques. Vous souhaitez appliquer des contrôles d'accès réseau restrictifs à l'aide de groupes de sécurité pour ces derniers WorkSpaces. Vous devez ouvrir les ports 80 et 443 uniquement à des sites Web internes spécifiques, et vous souhaitez bloquer complètement leur accès à Internet.

Dans ce scénario, il existe deux types de personas d'utilisateurs complètement différents avec des exigences différentes en matière d'accès au réseau et aux postes de travail. Il est recommandé de les gérer et de les configurer WorkSpaces différemment. Vous devrez créer deux connecteurs AD, un pour chaque personnage utilisateur. Chaque AD Connector nécessite deux sous-réseaux dotés de suffisamment d'adresses IP disponibles pour répondre à vos estimations de croissance de WorkSpaces l'utilisation.

Note

Chaque sous-réseau AWS VPC consomme cinq adresses IP (les quatre premières et la dernière) à des fins de gestion, et chaque AD Connector consomme une adresse IP dans chaque sous-réseau dans lequel il persiste.

Les autres considérations relatives à ce scénario sont les suivantes :

• AWS Les sous-réseaux VPC doivent être des sous-réseaux privés, afin que le trafic, tel que l'accès à Internet, puisse être contrôlé via une passerelle de traduction d'adresses réseau (NAT), un serveur proxy NAT dans le cloud ou redirigé via votre système de gestion du trafic sur site.

• Un pare-feu est en place pour tout le trafic VPC à destination du réseau sur site.

• Le serveur Microsoft AD et les serveurs MFA RADIUS sont soit sur site (voir Scénario 1 : Utilisation du connecteur AD pour l'authentification par proxy auprès des services AD DS locaux dans ce document), soit font partie de l'implémentation dans le AWS cloud (reportez-vous aux scénarios 2 et 3, Scénarios de déploiement AD DS, dans ce document).

Étant donné que tous WorkSpaces ont accès à Internet sous une forme ou une autre et qu'ils sont hébergés dans un sous-réseau privé, vous devez également créer des sous-réseaux publics qui peuvent accéder à Internet via une passerelle Internet. Vous avez besoin d'une passerelle NAT pour les employés à plein temps, leur permettant d'accéder à Internet, et d'un serveur proxy NAT pour les consultants et les sous-traitants, afin de limiter leur accès à des sites Web internes spécifiques. Pour planifier les défaillances, concevoir une haute disponibilité et limiter les frais de trafic inter-AZ, vous devez disposer de deux passerelles NAT et de serveurs NAT ou proxy dans deux sous-réseaux différents dans un déploiement multi-AZ. Les deux zones de disponibilité que vous sélectionnez comme sous-réseaux publics correspondent aux deux zones de disponibilité que vous utilisez pour vos WorkSpaces sous-réseaux, dans les régions comportant plus de deux zones. Vous pouvez acheminer tout le trafic de chaque zone WorkSpaces de zone vers le sous-réseau public correspondant afin de limiter les frais de trafic inter-zones et de faciliter la gestion. La figure suivante montre la configuration du VPC.

Figure 3 : conception de VPC de haut niveau

Les informations suivantes décrivent comment configurer les deux WorkSpaces types différents :

Pour configurer WorkSpaces pour les employés à temps plein :

1. Dans l'Amazon WorkSpaces Management Console, choisissez l'option Répertoires dans la barre de menu.

2. Choisissez l'annuaire qui héberge vos employés à temps plein.

3. Choisissez Local Administrator Setting.

En activant cette option, toute personne nouvellement créée WorkSpace aura des privilèges d'administrateur local. Pour accorder l'accès à Internet, configurez le NAT pour l'accès Internet sortant depuis votre VPC. Pour activer le MFA, vous devez spécifier un serveur RADIUS, des adresses IP de serveur, des ports et une clé pré-partagée.

Pour les employés à plein temps WorkSpaces, le trafic entrant vers le Remote Desktop Protocol (RDP) WorkSpace peut être limité au Remote Desktop Protocol (RDP) depuis le sous-réseau Helpdesk en appliquant un groupe de sécurité par défaut via les paramètres AD Connector.

Pour configurer WorkSpaces pour les sous-traitants et les consultants :

1. Dans la console WorkSpaces de gestion Amazon, désactivez l'accès à Internet et le paramètre d'administrateur local.

2. Ajoutez un groupe de sécurité dans la section des paramètres du groupe de sécurité pour appliquer un groupe de sécurité à tous les nouveaux groupes WorkSpaces créés dans ce répertoire.

Pour les consultants WorkSpaces, limitez le trafic sortant et entrant au en appliquant un groupe de sécurité WorkSpaces par défaut via les paramètres AD Connector à tous les utilisateurs WorkSpaces associés à l'AD Connector. Le groupe de sécurité empêche l'accès sortant depuis le trafic WorkSpaces vers autre chose que le trafic HTTP et HTTPS, et le trafic entrant vers RDP depuis le sous-réseau Helpdesk du réseau local.

Note

Le groupe de sécurité s'applique uniquement à l'ENI qui se trouve dans le VPC (eth1sur le WorkSpace), et l'accès à celui-ci WorkSpace depuis le WorkSpaces client n'est pas restreint en raison d'un groupe de sécurité. La figure suivante montre la conception finale du WorkSpaces VPC.

Figure 4 : WorkSpaces design avec personas d'utilisateur

AWS Service de répertoire

Comme indiqué dans l'introduction, AWS Directory Service est un composant essentiel d'Amazon WorkSpaces. Avec AWS Directory Service, vous pouvez créer trois types d'annuaires avec Amazon WorkSpaces :

• AWS Managed Microsoft AD est un Microsoft AD géré, alimenté par Windows Server 2012 R2. AWS Managed Microsoft AD est disponible en édition Standard ou Enterprise.

• Simple AD est un service d'annuaire géré autonome, compatible avec Microsoft AD, alimenté par Samba 4.

• AD Connector est un proxy d'annuaire permettant de rediriger les demandes d'authentification et les recherches d'utilisateurs ou de groupes vers votre Microsoft AD local existant.

La section suivante décrit les flux de communication pour l'authentification entre le service de WorkSpaces courtage Amazon et AWS Directory Service, les meilleures pratiques de mise en œuvre WorkSpaces avec AWS Directory Service et les concepts avancés, tels que le MFA. Il aborde également les concepts d'architecture d'infrastructure pour Amazon WorkSpaces à grande échelle, les exigences relatives à Amazon VPC et AWS Directory Service, y compris l'intégration avec les services de domaine Microsoft AD (AD DS) sur site.