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.
Anti-Pattern für den Netzwerkzugriff in der AWS Cloud
Ein Anti-Pattern ist eine häufig verwendete Lösung für ein wiederkehrendes Problem, bei dem die Lösung kontraproduktiv, ineffektiv oder weniger wirksam als eine Alternative ist. Die in diesem Abschnitt genannten Designoptionen funktionieren in der Regel, sind jedoch mit erheblichen Nachteilen verbunden. Wenn möglich, sollten sie vermieden werden, da bessere Alternativen verfügbar sind.
In diesem Abschnitt werden die folgenden Anti-Pattern-Probleme und Herausforderungen behandelt:
Nichtübereinstimmung der Verfügbarkeitszone mit AWS PrivateLink
Bei der Bereitstellung des Zugriffs auf eine Anwendung über AWS PrivateLink können SaaS-Verbraucher VPC-Endpunkte nur in den Availability Zones erstellen, in denen die Anwendung bereitgestellt wird. Wenn die Anwendung beispielsweise in use1-az1 und bereitgestellt wirduse1-az2, kann der Verbraucher keinen VPC-Endpunkt in use1-az3 bereitstellen. Wir empfehlen, das SaaS-Angebot in jeder Availability Zone bereitzustellen. Die meisten AWS-Regionen haben drei Availability Zones, obwohl einige mehr haben. Eine umfassende Liste finden Sie unter Regionen und Availability Zones
Anmerkung
Die Namen der Verfügbarkeitszonen unterscheiden sich von denen der Availability Zone IDs. Weitere Informationen finden Sie unter Availability Zone IDs für Ihre AWS Ressourcen.
Wenn sich ein SaaS-Anbieter dafür entscheidet, nicht in allen Availability Zones zu implementieren, hat das einige Konsequenzen. Gehen Sie davon aus, dass das SaaS-Angebot in use1-az1 und bereitgestellt wirduse1-az2, der Verbraucher jedoch alle drei Availability Zones verwendet, einschließlichuse1-az3. Die VPC-Endpunkte der Schnittstelle werden auf der Verbraucherseite in use1-az1 und bereitgestelltuse1-az2, und jetzt use1-az3 muss die Anwendung auf einen dieser Endpunkte zugreifen. Zuallererst muss der Verkehr von den Subnetzen in den nicht übereinstimmenden Availability Zones zu den jeweiligen VPC-Endpunkten zugelassen werden. Der Verbraucher kann sich dafür entscheiden, den regionalen AWS PrivateLink
DNS-Namen zu verwenden, der in einen der beiden VPC-Endpunkte aufgelöst werden kann und der Datenverkehr gleichmäßig zwischen den beiden verteilt wird. Oder der Verbraucher kann sich dafür entscheiden, den Verkehr direkt an einen Endpunkt zu senden, z. B. use1-az2 Dies führt dazu, dass 67% des Datenverkehrs auf der Anbieterseite ankommen use1-az2 und 33% inuse1-az1. Die folgende Abbildung zeigt dieses Szenario.
Bei einer großen Anzahl von Verbrauchern und einer ungleichmäßigen Verteilung des Datenverkehrs kann es vorkommen, dass ein Workload in einer Availability Zone auf Kapazitätsprobleme und in einer anderen unter Kapazität stößt. Um dieses Problem zu lösen, kann der SaaS-Anbieter beschließen, den Datenverkehr auf seiner Seite gleichmäßig zu verteilen, indem er den zonenübergreifenden Lastenausgleich auf dem Network Load Balancer aktiviert. Dadurch fallen zusätzliche Gebühren an.
Wenn der Dienstanbieter nur einer Availability Zone entspricht, wird der gesamte Datenverkehr über einen einzigen Endpunkt geleitet. Dies führt zu einem noch größeren Ungleichgewicht. Infolgedessen ist das SaaS-Angebot für den Verbraucher nicht mehr hochverfügbar. Für den Verbraucher spielt es keine Rolle, ob die Anwendung über zusätzliche Availability Zones bereitgestellt wird, die er selbst nicht nutzt. Im schlimmsten Fall ist ein SaaS-Anbieter möglicherweise nicht in der Lage, einen Verbraucher zu bedienen, der keine der gleichen Availability Zones verwendet.
In dem seltenen Fall, dass es für den SaaS-Anbieter keine praktikable Option gibt, seine Anwendung über alle Availability Zones bereitzustellen, ist es auch möglich, ein Subnetz nur in den fehlenden Availability Zones zu erstellen und den Service dann auf diese leeren Availability Zones auszudehnen. Durch zonenübergreifendes Load Balancing kann der eingehende Verkehr dann auf die eigentlichen Anwendungsendpunkte in den anderen Availability Zones verteilt werden.
AWS Site-to-Site VPN Verbindungen zwischen AWS-Konten
Unternehmen, die von lokalen Umgebungen in die Cloud migrieren, versuchen manchmal, das gesamte Netzwerk nach oben zu verlagern. Dies kann zu Problemen führen, da es erhebliche Unterschiede zwischen lokalen und Cloud-Netzwerkpraktiken gibt. Wenn diese Änderung der Denkweise nicht stattfindet, können Dinge wie AWS Site-to-Site VPN Verbindungen von einer VPC zu einer anderen VPC passieren. Bei diesem Ansatz werden die Vorteile der speziell entwickelten Netzwerkdienste in der nicht genutzt AWS Cloud, die die Verwaltung vereinfachen und die Leistung verbessern. Die Anpassung an Cloud-native Designs trägt zur Reduzierung des Betriebsaufwands bei und führt zu einer zuverlässigeren, skalierbareren Konnektivität zwischen. VPCs
Wenn Sie darüber nachdenken, diese Konnektivitätsoption als SaaS-Anbieter anzubieten, fragen Sie sich selbst oder den Verbraucher, warum sie verwendet werden AWS Site-to-Site VPN sollte. Gehen Sie dann von diesen Anforderungen ausgehend von diesen Anforderungen zurück, um eine bessere Konnektivitätsoption zu finden. Der Abschnitt zum Vergleich der Servicefunktionen dieses Handbuchs enthält eine Matrix, anhand derer Sie Optionen identifizieren können. Anschließend können Sie die entsprechenden Abschnitte dieses Handbuchs durcharbeiten, um einen architektonischen Ansatz zu finden, der auf Ihren Anwendungsfall zugeschnitten ist.