Die vorliegende Übersetzung wurde maschinell erstellt. Im Falle eines Konflikts oder eines Widerspruchs zwischen dieser übersetzten Fassung und der englischen Fassung (einschließlich infolge von Verzögerungen bei der Übersetzung) ist die englische Fassung maßgeblich.

Verfügbarkeitszonen

Eine Availability Zone (AZ) besteht aus einem oder mehreren diskreten Rechenzentren mit redundanter Stromversorgung, Vernetzung und Konnektivität in einem AWS-Region. Availability Zones sind besser hoch verfügbar, fehlertoleranter und skalierbarer als herkömmliche Infrastrukturen mit einem oder mehreren Rechenzentren.

Amazon WorkSpaces Applications benötigt nur ein Subnetz, in dem eine Flotte starten kann. Es hat sich bewährt, mindestens zwei Availability Zones zu konfigurieren, also ein Subnetz pro eindeutiger Availability Zone. Verwenden Sie mehr als zwei Availability Zones, um die auto Skalierung von Flotten zu optimieren. Die horizontale Skalierung hat den zusätzlichen Vorteil, dass der IP-Speicherplatz in Subnetzen für das Wachstum hinzugefügt wird. Dieser Aspekt wird im folgenden Abschnitt zur Subnetzgröße in diesem Dokument behandelt. Die AWS-Managementkonsole sieht vor, dass bei der Erstellung einer Flotte nur zwei Subnetze angegeben werden müssen. Verwenden Sie die AWS Command Line Interface(AWS CLI) oder AWS CloudFormation , um mehr als zwei Subnetz-IDs zuzulassen.

Subnetzdimensionierung

Dedizieren Sie Subnetze für WorkSpaces Anwendungsflotten, um Flexibilität bei den Routing-Richtlinien und der Network Access Control List zu gewährleisten. Für Stacks gelten wahrscheinlich separate Ressourcenanforderungen. Beispielsweise können für WorkSpaces Anwendungsstapel Isolationsanforderungen gelten, die separaten Regelsätzen weichen. Wenn mehrere Amazon WorkSpaces Applications-Flotten dieselben Subnetze verwenden, stellen Sie sicher, dass die Summe der maximalen Kapazität aller Flotten die Gesamtzahl der verfügbaren IP-Adressen nicht überschreitet.

Wenn die maximale Kapazität für alle Flotten im selben Subnetz die Gesamtzahl der verfügbaren IP-Adressen überschreiten könnte oder hat, migrieren Sie Flotten in dedizierte Subnetze. Dadurch wird verhindert, dass automatische Skalierungsereignisse den zugewiesenen IP-Speicherplatz erschöpfen. Wenn die Gesamtkapazität einer Flotte den zugewiesenen IP-Bereich der zugewiesenen Subnetze übersteigt, verwenden Sie die API oder AWS CLI „Flotte aktualisieren“, um weitere Subnetze zuzuweisen. Weitere Informationen finden Sie unter Amazon VPC-Kontingente und wie Sie sie erhöhen können.

Es hat sich bewährt, die Anzahl der Subnetze zu skalieren, die Subnetze entsprechend zu dimensionieren und gleichzeitig Kapazität für das Wachstum in Ihrer VPC zu reservieren. Stellen Sie außerdem sicher, dass die Höchstwerte für die WorkSpaces Anwendungsflotte den gesamten IP-Speicherplatz, der den Subnetzen zugewiesen wurde, nicht überschreiten. Bei der Berechnung des gesamten IP-Speicherplatzes werden für jedes eingehende Subnetz fünf IP-Adressen reserviert. AWS Die Verwendung von mehr als zwei Subnetzen und die horizontale Skalierung bieten mehrere Vorteile, wie z. B.:

Bei der Dimensionierung von Subnetzen für Amazon WorkSpaces Applications sollten Sie die Gesamtzahl der Subnetze und die erwartete Parallelität bei Spitzenauslastung berücksichtigen. Dies kann mithilfe von (InUseCapacity) plus reservierter Kapazität (AvailableCapacity) für eine Flotte überwacht werden. In Amazon WorkSpaces Applications ist die Summe der verbrauchten und der verfügbaren WorkSpaces Applications-Flotteninstanzen gekennzeichnet. ActualCapacity Um den gesamten IP-Speicherplatz richtig zu dimensionieren, prognostizieren Sie den Bedarf und dividieren Sie ihn durch die Anzahl der SubnetzeActualCapacity, abzüglich eines Subnetzes aus Gründen der Resilienz, die der Flotte zugewiesen sind.

Wenn die erwartete maximale Anzahl von Flotteninstanzen zu Spitzenzeiten beispielsweise 1000 beträgt und die Geschäftsanforderung darin besteht, bei einem Ausfall einer Availability Zone widerstandsfähig zu sein, erfüllen 3 x/23 Subnetze die technischen und geschäftlichen Anforderungen.

Beispiel für die Größe eines Subnetzes

2 x /22-Subnetze würden zwar auch die Ausfallsicherheit gewährleisten, aber bedenken Sie Folgendes:

Subnetz-Routing

Es hat sich bewährt, private Subnetze für WorkSpaces Anwendungsinstanzen zu erstellen, die über eine zentrale VPC für ausgehenden Datenverkehr an das öffentliche Internet weitergeleitet werden. Eingehender Datenverkehr für das Streaming der WorkSpaces Anwendungssitzung wird über den Amazon WorkSpaces Applications Service über Streaming Gateways abgewickelt: Sie müssen dafür keine öffentlichen Subnetze konfigurieren.

Intra-Region Konnektivität

Für WorkSpaces Anwendungsflotteninstanzen, die mit einer Active Directory-Domäne verbunden sind, konfigurieren Sie Active Directory-Domänencontroller in jeder AWS-Region Shared Services-VPC. Quellen für Active Directory können entweder Amazon EC2 EC2-basierte Domain-Controller oder AWS Microsoft Managed AD sein. Das Routing zwischen den VPCs für gemeinsame Dienste und WorkSpaces Anwendungen kann entweder über eine VPC-Peering-Verbindung oder über ein Transit-Gateway erfolgen. Obwohl Transit-Gateways die Komplexität des Routings in großem Umfang lösen, gibt es eine Reihe von Gründen, warum VPC-Peering in den meisten Umgebungen vorzuziehen ist:

Dies gilt insbesondere dann, wenn WorkSpaces Anwendungsinstanzen eine Verbindung zu and/or Dateiservern der Anwendungsinfrastruktur mit großen Datensätzen in einer Shared Service-VPC herstellen. Durch die Optimierung des Pfads zu diesen Ressourcen, auf die häufig zugegriffen wird, wird eine VPC-Peering-Verbindung bevorzugt, selbst bei Designs, bei denen alle anderen VPC- und Internet-Routings über ein Transit-Gateway ausgeführt werden.

Ausgehender Internetverkehr

Während das direkte Routing zu Shared Services größtenteils über eine Peering-Verbindung optimiert wird, kann ausgehender Datenverkehr für WorkSpaces Anwendungen entworfen werden, indem mithilfe AWS von Transit Gateway ein einziger Internetausgangspunkt aus mehreren VPCs erstellt wird. In einem Multi-VPC-Design ist es üblich, über eine dedizierte VPC zu verfügen, die den gesamten ausgehenden Internetverkehr steuert. Mit dieser Konfiguration verfügen Transit Gateways über eine größere Flexibilität und können das Routing über Standard-Routingtabellen steuern, die an Subnetze angeschlossen sind. Dieses Design unterstützt auch transitives Routing ohne zusätzliche Komplexität und macht redundante Network Address Translation (NAT) -Gateways oder NAT-Instances in jeder VPC überflüssig.

Sobald der gesamte ausgehende Internetverkehr in einer einzigen VPC zentralisiert ist, sind NAT-Gateways oder NAT-Instances eine gängige Designwahl. Um herauszufinden, welches für Ihr Unternehmen am besten geeignet ist, schauen Sie sich das Administratorhandbuch zum Vergleich von NAT-Gateways und NAT-Instances an.AWS Die Network Firewall kann den Schutz über Sicherheitsgruppen- und Netzwerkzugriffskontrollen hinaus erweitern, indem sie auf Routenebene schützt und statusfreie und statusbehaftete Regeln auf den Ebenen 3 bis 7 im OSI-Modell anbietet. Weitere Informationen finden Sie unter Bereitstellungsmodelle für die AWS Network Firewall. Wenn sich Ihr Unternehmen für ein Drittanbieterprodukt entschieden hat, das erweiterte Funktionen wie URL-Filterung bietet, stellen Sie den Service in Ihrer ausgehenden Internet-VPC bereit. Dies kann NAT-Gateways oder NAT-Instances ersetzen. Folgen Sie den Richtlinien des Drittanbieters.

On-premises

Wenn Konnektivität zu lokalen Ressourcen erforderlich ist, insbesondere für WorkSpaces Anwendungsinstanzen, die mit Active Directory verknüpft sind, stellen Sie eine äußerst stabile Verbindung her. AWS Direct Connect