Share via

Netzwerktopologie und Konnektivität für den Azure Spring Apps-Zielzonenbeschleuniger

  • Artikel

Dieser Artikel enthält Überlegungen und Empfehlungen für das Design des Netzwerks, in dem der Spring Boot-Workload platziert werden soll. Ihr Zieldesign hängt von den Anforderungen des Workloads sowie von den Sicherheits- und Complianceanforderungen Ihrer Organisation ab.

Das zentralisierte Plattformteam und das Anwendungsteam teilen sich die Verantwortung für den Netzwerkentwurfsbereich. Das Plattformteam wählt die Netzwerktopologie aus. Dabei kann es sich um ein herkömmliches Hub-Spoke-Modell oder eine Virtual WAN-Netzwerktopologie (die von Microsoft verwaltet wird) handeln. Das Anwendungsteam ist für die Designentscheidungen im Rahmen des Spoke-Netzwerks verantwortlich. Es ist zu erwarten, dass der Workload Abhängigkeiten zu gemeinsam genutzten Diensten hat, die von der Plattform verwaltet werden. Das Anwendungsteam muss die Auswirkungen dieser Abhängigkeiten verstehen und ihre Anforderungen kommunizieren, damit die Gesamtziele des Workloads erreicht werden können.

Weitere Informationen zum Plattformdesign finden Sie unter Netzwerktopologie und Konnektivität.

Befolgen Sie diese Überlegungen und Empfehlungen zum Design, da sie bewährte Methoden für Subnetz-, Eingangs- und Ausgangskontrollen darstellen.

Überlegungen zum Entwurf

  • Isolation. Das zentrale Team kann ein virtuelles Netzwerk für das Anwendungsteam bereitstellen, um seine Workloads auszuführen. Wenn der Spring Boot-Workload eine Trennung der Zuständigkeiten von anderen Workloads hat, sollten Sie ihr eigenes virtuelles Netzwerk für die Spring App Service-Runtime und die Anwendung bereitstellen.

  • Subnetz. Berücksichtigen Sie die Skalierbarkeit der Anwendung, wenn Sie sich für eine Größe des Subnetzes und die Anzahl der Anwendung entscheiden.

    Wenn Sie vorhandene Subnetze oder eigene Routingtabellen verwenden, sollten Sie Richtlinien erstellen, um dafür zu sorgen, dass von Azure Spring Apps hinzugefügte Regeln nicht aktualisiert oder gelöscht werden.

    Ein weiterer Aspekt ist die Sicherheit. Ziehen Sie Regeln in Betracht, die Datenverkehr in das Subnetz zulassen oder unterbinden.

  • Ausgehender Datenverkehr. Datenverkehr aus dem virtuellen Netzwerk muss über Azure Firewall oder ein virtuelles Netzwerkgerät (Network Virtual Appliance, NVA) weitergeleitet werden.

    Berücksichtigen Sie dabei die Einschränkungen des von Azure Spring Apps bereitgestellten integrierten Lastenausgleichs. Basierend auf Ihren Anforderungen müssen Sie ausgehende Pfade möglicherweise mithilfe des benutzerdefinierten Routings (User Defined Routing, UDR) anpassen, z. B. um den gesamten Datenverkehr über ein virtuelles Netzwerkgerät zu leiten.

  • Eingehender Datenverkehr. Erwägen Sie für Datenverkehr, der an Azure Spring Apps geht, die Verwendung eines Reverseproxys. Wählen Sie basierend auf Ihren Anforderungen native Optionen wie Azure Application Gateway und Front Door oder regionale Dienste wie API Management (APIM) aus. Wenn diese Optionen den Anforderungen des Workloads nicht genügen, können Nicht-Azure-Dienste in Betracht gezogen werden.

Entwurfsempfehlungen

Diese Empfehlungen bieten einen ausführlichen Leitfaden für die obigen Überlegungen.

Virtuelles Netzwerk und Subnetze

  • Azure Spring Apps erfordert die Berechtigung als Besitzer für Ihr virtuelles Netzwerk. Diese Rolle ist erforderlich, um einen dedizierten und dynamischen Dienstprinzipal für die Bereitstellung und Wartung zuzuweisen. Weitere Informationen finden Sie unter Bereitstellen von Azure Spring Apps in einem virtuellen Netzwerk.

  • Der in einem einem privaten Netzwerk bereitgestellte Dienst Azure Spring Apps stellt einen vollqualifizierten Domänennamen (Fully Qualified Domain Name, FQDN) bereit, auf den nur innerhalb des privaten Netzwerks zugegriffen werden kann. Erstellen Sie eine private Azure-DNS-Zone für die IP-Adresse Ihrer Spring-App. Verbinden Sie das private DNS mit Ihrem virtuellen Netzwerk, indem Sie in Azure Spring Apps einen privaten FQDN zuweisen. Eine Schritt-für-Schritt-Anleitung finden Sie unter Zugreifen auf eine Anwendung im privaten Netzwerk.

  • Azure Spring Apps erfordert zwei dedizierte Subnetze. In einem Subnetz wird die Dienstruntime ausgeführt, in dem anderen Subnetz die Spring Boot-Anwendungen.

    Die minimale CIDR-Blockgröße jedes dieser Subnetze beträgt /28. Das Runtimesubnetz und das Anwendungssubnetz benötigen einen Mindestadressraum von /28. Die Anzahl der bereitstellbaren Spring-Apps wirkt sich jedoch auf die Größe des Subnetzes aus. Informationen zu den maximalen App-Instanzen abhängig vom Subnetzbereich finden Sie unter Verwenden kleinerer Subnetzbereiche.

  • Wenn Sie Azure Application Gateway als Reverseproxy vor Azure Spring Apps verwenden, benötigen Sie für diese Instanz ein anderes Subnetz. Weitere Informationen finden Sie unter Verwenden von Application Gateway als Reverseproxy.

  • Verwenden Sie Netzwerksicherheitsgruppen (Network Security Groups, NSGs) in Subnetzen, um Ost-West-Datenverkehr zu filtern und den Datenverkehr auf Ihr Dienstruntime-Subnetz zu beschränken.

  • Ressourcengruppen und Subnetze, die von der Azure Spring Apps-Bereitstellung verwaltet werden, dürfen nicht geändert werden.

Ausgehender Datenverkehr

  • Standardmäßig verfügt Azure Spring Apps über uneingeschränkten Internetzugriff in ausgehender Richtung. Verwenden Sie ein virtuelles Netzwerkgerät (Network Virtual Appliance) wie Azure Firewall, um Nord-Süd-Datenverkehr zu filtern. Profitieren Sie von Azure Firewall im zentralisierten Hubnetzwerk, um den Verwaltungsaufwand zu reduzieren.

    Hinweis

    Ausgehender Datenverkehr an Azure Spring-Komponenten ist erforderlich, um die Dienstinstanzen zu unterstützen. Informationen zu bestimmten Endpunkten und Ports finden Sie unter Netzwerkanforderungen für Azure Spring Apps.

  • Azure Spring Apps bietet als „OutboundType“ eine benutzerdefinierte Route (User Defined Route, UDR), um den ausgehenden Datenverkehrspfad vollständig zu steuern. OutboundType sollte definiert werden, wenn eine neue Azure Spring Apps-Dienstinstanz erstellt wird. Eine spätere Aktualisierung ist nicht möglich. Außerdem kann OutboundType nur mit einem virtuellen Netzwerk konfiguriert werden. Weitere Informationen finden Sie unter Anpassen des ausgehenden Azure Spring Apps-Datenverkehrs mit einer benutzerdefinierten Route.

  • Die Anwendung muss mit anderen Azure-Diensten in der Lösung kommunizieren. Verwenden Sie Azure Private Link für unterstützte Dienste, wenn Ihre Anwendungen private Konnektivität erfordern.

Eingehender Datenverkehr

  • Verwenden Sie einen Reverseproxy, um sicherzustellen, dass böswillige Benutzer daran gehindert werden, die Web Application Firewall (WAF) oder Drosselungslimits zu umgehen. Wir empfehlen Azure Application Gateway mit integrierter WAF.

    Wenn Sie den Enterprise-Tarif nutzen, verwenden Sie den zugewiesenen Endpunkt der Spring Cloud Gateway-App als Back-End-Pool des Application Gateways. Dieser Endpunkt wird im Azure Spring Apps Service Runtime-Subnetz in eine private IP-Adresse aufgelöst.

    Fügen Sie im Subnetz der Dienstruntime eine Netzwerksicherheitsgruppe (NSG) hinzu, die nur Datenverkehr aus dem Application Gateway-, dem Azure Spring Apps-Subnetz sowie von Azure Load Balancer zulässt.

    Hinweis

    Sie können eine Alternative für den Reverseproxy auswählen, z. B. Azure Front Door oder Nicht-Azure-Dienste. Informationen zu Konfigurationsoptionen finden Sie unter Verfügbarmachen von Azure Spring Apps über einen Reverseproxy.

  • Azure Spring Apps kann in einem virtuellen Netzwerk durch VNet-Einschleusung oder außerhalb des Netzwerks bereitgestellt werden. Weitere Informationen finden Sie unter Konfigurationszusammenfassung.

Nächste Schritte

Überlegungen zur Sicherheit des Azure Spring Apps-Zielzonenbeschleunigers