Les traductions sont fournies par des outils de traduction automatique. En cas de conflit entre le contenu d'une traduction et celui de la version originale en anglais, la version anglaise prévaudra.

Zones de disponibilité

Une zone de disponibilité (AZ) est un ou plusieurs centres de données discrets dotés d'une alimentation, d'un réseau et d'une connectivité redondants dans un Région AWS. Les zones de disponibilité sont davantage disponibles, tolérantes aux pannes et ont une plus grande capacité de mise à l’échelle que les infrastructures traditionnelles à un ou plusieurs centres de données.

Amazon WorkSpaces Applications ne nécessite qu'un seul sous-réseau pour le lancement d'une flotte. La meilleure pratique consiste à configurer au moins deux zones de disponibilité, un sous-réseau par zone de disponibilité unique. Pour optimiser la mise à l'échelle automatique de votre flotte, utilisez plus de deux zones de disponibilité. La mise à l'échelle horizontale présente l'avantage supplémentaire d'ajouter de l'espace IP dans les sous-réseaux pour favoriser la croissance, ce qui est décrit dans la section suivante de ce document consacrée au dimensionnement des sous-réseaux. L'AWS Management Console ne permet de spécifier que deux sous-réseaux lors de la création d'une flotte. Utilisez la AWS Command Line Interface(AWS CLI) ou AWS CloudFormation pour autoriser plus de deux ID de sous-réseau.

Dimensionnement des sous-réseaux

Dédiez des sous-réseaux aux flottes d' WorkSpaces applications pour permettre une flexibilité dans les politiques de routage et la liste de contrôle d'accès au réseau. Les Stacks auront probablement des besoins en ressources distincts. Par exemple, les WorkSpaces applications Stacks peuvent avoir des exigences d'isolation qui cèdent la place à des ensembles de règles distincts. Lorsque plusieurs flottes Amazon WorkSpaces Applications utilisent les mêmes sous-réseaux, assurez-vous que la somme de la capacité maximale de toutes les flottes ne dépasse pas le nombre total d'adresses IP disponibles.

Si la capacité maximale de toutes les flottes d'un même sous-réseau peut ou a dépassé le nombre total d'adresses IP disponibles, migrez les flottes vers des sous-réseaux dédiés. Cela empêche les événements de dimensionnement automatique d'épuiser l'espace IP alloué. Si la capacité totale d'un parc dépasse l'espace IP alloué aux sous-réseaux assignés, utilisez l'API ou la AWS CLI pour « mettre à jour le parc » pour attribuer d'autres sous-réseaux. Pour plus d'informations, consultez les quotas Amazon VPC et comment les augmenter.

Il est recommandé d'augmenter le nombre de sous-réseaux, en dimensionnant les sous-réseaux en conséquence tout en réservant la capacité nécessaire à l'augmentation de la capacité de votre VPC. En outre, assurez-vous que le maximum du parc d' WorkSpaces applications ne dépasse pas l'espace IP total alloué par les sous-réseaux. Pour chaque sous-réseau AWS, cinq adresses IP sont réservées lors du calcul de la quantité totale d'espace IP. L'utilisation de plus de deux sous-réseaux et la mise à l'échelle horizontale présentent plusieurs avantages, tels que :

Lorsque vous dimensionnez des sous-réseaux pour Amazon WorkSpaces Applications, prenez en compte le nombre total de sous-réseaux et le pic de simultanéité attendu en cas de pic d'utilisation. Cela peut être surveillé en utilisant (InUseCapacity) plus la capacité réservée (AvailableCapacity) pour une flotte. Dans Amazon WorkSpaces Applications, la somme des instances du parc d' WorkSpaces applications consommées et disponibles pour être consommées est étiquetée. ActualCapacity Pour dimensionner correctement l'espace IP total, prévoyez l'espace requis ActualCapacity et divisez-le par le nombre de sous-réseaux, moins un sous-réseau pour la résilience, attribué à la flotte.

Par exemple, si le nombre maximum prévu d'instances de flotte en période de pointe est de 1 000 et que l'exigence commerciale est de faire preuve de résilience en cas de défaillance d'une zone de disponibilité, 3 x/23 sous-réseaux répondent aux exigences techniques et commerciales.

Exemple de dimensionnement de sous-réseau

Bien que 2 sous-réseaux /22 puissent également satisfaire à la résilience, tenez compte des points suivants :

Routage des sous-réseaux

Il est recommandé de créer des sous-réseaux privés pour les instances d' WorkSpaces applications, en les acheminant vers l'Internet public via un VPC centralisé pour le trafic sortant. Le trafic entrant pour le streaming WorkSpaces des sessions Applications est géré via le service Amazon WorkSpaces Applications via Streaming Gateway : vous n'avez pas besoin de configurer de sous-réseaux publics pour cela.

Intra-Region connectivité

Pour les instances de parc d' WorkSpaces applications jointes à un domaine Active Directory, configurez les contrôleurs de domaine Active Directory dans un VPC Shared Services dans chacune d'elles. Région AWS Les sources d'Active Directory peuvent être des contrôleurs de domaine basés sur Amazon EC2 ou AWS Microsoft Managed AD. Le routage entre les services partagés et WorkSpaces les VPC d'applications peut se faire via une connexion d'appairage VPC ou une passerelle de transit. Bien que les passerelles de transit résolvent la complexité du routage à grande échelle, il existe un certain nombre de raisons pour lesquelles l'appairage VPC est préférable dans la plupart des contextes :

Cela est particulièrement vrai si WorkSpaces les instances d'applications se connectent à des serveurs de and/or fichiers d'infrastructure d'applications avec de grands ensembles de données dans un VPC de service partagé. En optimisant le chemin d'accès à ces ressources fréquemment consultées, la connexion d'appairage VPC est préférée, même dans les conceptions où tous les autres routages VPC et Internet sont effectués via une passerelle de transit.

Trafic Internet sortant

Alors que le routage direct vers les services partagés est principalement optimisé par le biais d'une connexion de peering, le trafic sortant pour les WorkSpaces applications peut être conçu en créant un point de sortie Internet unique à partir de plusieurs VPC à l'aide de Transit Gateway AWS . Dans une conception multi-VPC, il est courant de disposer d'un VPC dédié qui contrôle tout le trafic Internet sortant. Grâce à cette configuration, les passerelles de transit bénéficient d'une plus grande flexibilité et d'un meilleur contrôle du routage sur les tables de routage standard associées aux sous-réseaux. Cette conception prend également en charge le routage transitif sans complexité supplémentaire et élimine le besoin de passerelles de traduction d'adresses réseau (NAT) redondantes ou d'instances NAT dans chaque VPC.

Une fois que tout le trafic Internet sortant est centralisé dans un VPC unique, les passerelles NAT ou les instances NAT constituent un choix de conception courant. Pour déterminer ce qui convient le mieux à votre organisation, consultez le guide d'administration permettant de comparer les passerelles NAT et les instances NAT. AWS Network Firewall peut étendre la protection au-delà des niveaux du groupe de sécurité et du contrôle d'accès au réseau en protégeant au niveau de la route et en proposant des règles apatrides et dynamiques des couches 3 à 7 du modèle OSI. Pour plus d'informations, reportez-vous à la section Modèles de déploiement pour AWS Network Firewall. Si votre organisation a choisi un produit tiers doté de fonctionnalités avancées telles que le filtrage d'URL, déployez le service dans votre VPC Internet sortant. Cela peut remplacer les passerelles NAT ou les instances NAT. Suivez les directives fournies par le fournisseur tiers.

On-premises

Lorsque la connectivité aux ressources locales est requise, en particulier pour les instances d' WorkSpaces applications jointes à Active Directory, établissez une connexion hautement résiliente via AWS Direct Connect.