Überlegungen zur Netzwerktopologie und -konnektivität für den Integrationsdienste-Zielzonenbeschleuniger
Dieser Artikel enthält Überlegungen und Empfehlungen zum Entwurf der Netzwerktopologie und -konnektivität, die Sie bei der Verwendung des Azure-Integrationsdienste-Zielzonenbeschleunigers (AIS) anwenden können. In einer Zielzone ist das Netzwerk für fast alle Komponenten ein zentrales Element.
Die Überlegungen zur Netzwerktopologie und -konnektivität für diese Architektur hängen von den Anforderungen der gehosteten Workloads sowie den Sicherheits- und Konformitätsanforderungen Ihrer Organisation ab.
Überlegungen zum Entwurf
Verwenden Sie eine auf Virtual WAN basierende Netzwerktopologie, wenn Ihre Organisation:
Plant, Ressourcen in mehreren Azure-Regionen bereitzustellen und globale Konnektivität zwischen VNets in diesen Azure-Regionen sowie mehreren lokalen Umgebungen erfordert.
ein umfassendes Zweignetzwerk direkt in Azure integrieren muss, entweder über eine softwaredefinierte WAN-Bereitstellung (SD-WAN), oder es sind mehr als 30 Zweigniederlassungen für den nativen IPSec-Abschluss erforderlich.
Sie benötigen transitives Routing zwischen VPN und ExpressRoute, z. B. über Site-to-Site-VPN verbundene Remotebranches oder über Point-to-Site-VPN verbundene Remotebenutzer. Diese erfordern Konnektivität mit einem mit ExpressRoute verbundenen Domänencontroller über Azure.
Organisationen nutzen Virtual WAN, um die hohen Anforderungen in Bezug auf die Interkonnektivität zu erfüllen. Microsoft verwaltet diesen Dienst, um für Sie die allgemeine Komplexität des Netzwerks zu verringern und eine Modernisierung des Netzwerks Ihrer Organisation zu erzielen.
Verwenden Sie eine herkömmliche Azure-Netzwerktopologie, die auf einer Hub-and-Spoke-Architektur basiert, wenn Ihre Organisation:
Bereitstellung von Ressourcen nur in ausgewählten Azure-Regionen.
Kein globales verbundenes Netzwerk erforderlich.
Wenige Remote- oder Zweigstandorte pro Region und weniger als 30 benötigte IP-Sicherheitstunnel (IPsec).
Erfordert vollständige Kontrolle über die Konfiguration oder erfordert eine manuelle benutzerdefinierte Konfiguration Ihres Azure-Netzwerks.
Referenznetzwerktopologie
Das folgende Architekturdiagramm zeigt die Referenzarchitektur für eine AIS-Unternehmensbereitstellung:
Planen der IP-Adressierung
Unternehmensbereitstellungen von AIS sollten die Verwendung von privaten Endpunkten und virtuellen Netzwerken umfassen. Die folgenden Entwurfsüberlegungen sollten bei der Planung Ihrer IP-Adressierung berücksichtigt werden:
Einige Azure-Dienste erfordern dedizierte Subnetze.
Sie können ein bestimmtes Subnetz t0 für einen bestimmten Dienst festlegen, um Instanzen dieses Diensts innerhalb des Subnetzes zu erstellen. Beispielsweise können Sie ein Subnetz für App Service-Pläne festlegen, damit Sie im Laufe der Zeit zusätzliche Apps hinzufügen können.
Azure VPN Gateway kann überlappende, lokale Standorte mit überlappenden IP-Adressräumen durch die NAT-Funktion (Netzwerkadressenübersetzung) verbinden.
Benutzerdefinierter DNS
Die meisten AIS-Dienste ermöglichen es Kunden, ihre eigenen DNS-Namen für öffentliche Endpunkte zu verwenden, entweder über ihre eigenen DNS-Server oder über das Azure DNS-Angebot. Die Konfiguration dieser erfolgt auf Ressourcenbasis, aber die unterstützten Ressourcen sind unten aufgeführt:
API Management unterstützt benutzerdefinierte Domänen.
Funktions-Apps und Logik Apps unterstützen benutzerdefinierte Domänen, wenn sie in einem App Service-Plan oder einer App Service-Umgebung gehostet werden.
Speicherkonten unterstützen benutzerdefinierte Domänen für Blobspeicherendpunkte.
Data Factory, Service Bus und Event Grid unterstützen keine benutzerdefinierten Domänen.
Privates DNS
Privates DNS von Azure bietet einen zuverlässigen und sicheren DNS-Dienst für Ihr virtuelles Netzwerk. Privates Azure-DNS verwaltet Domänennamen im virtuellen Netzwerk und löst diese auf, ohne dass eine benutzerdefinierte DNS-Lösung konfiguriert werden muss.
Um die Datensätze einer privaten DNS-Zone in Ihrem virtuellen Netzwerk aufzulösen, müssen Sie das virtuelle Netzwerk mit der Zone verknüpfen. Verknüpfte virtuelle Netzwerke haben Vollzugriff auf alle in der privaten Zone veröffentlichten DNS-Datensätze und können diese auflösen.
Überlegungen zum Entwurf
Es ist wichtig, die DNS-Einstellungen ordnungsgemäß zu konfigurieren, um die IP-Adresse des privaten Endpunkts in den vollqualifizierten Domänennamen (FQDN) Ihrer Ressourcen aufzulösen.
Bestehende Microsoft Azure-Dienste verfügen möglicherweise bereits über eine DNS-Konfiguration für einen öffentlichen Endpunkt. Diese Konfiguration muss außer Kraft gesetzt werden, um eine Verbindung mithilfe Ihres privaten Endpunkts herzustellen.
Verschlüsselung und Zertifikatauthentifizierung
Wenn Ihr Netzwerkentwurf die Verschlüsselung des Datenverkehrs während der Übertragung und/oder die zertifikatbasierte Authentifizierung erfordert, müssen Sie möglicherweise überlegen, wo und wie diese Verschlüsselung/Authentifizierung durchgeführt wird. Beispielsweise müssen Sie ermitteln, welcher Dienst den TLS-Abschluss ausführt.
Überlegungen zum Entwurf
Erfordert Ihr Entwurf, dass der Datenverkehr zwischen Azure-Diensten verschlüsselt wird? Kann Ihre Verschlüsselung an einem Azure Front Door beendet und der Datenverkehr dann in nicht verschlüsselter Form im Azure-Backbone-Netzwerk oder in Ihrem VNET übertragen werden?
Müssen Sie die Verschlüsselung an mehreren Stellen beenden?
Müssen Sie die Authentifizierung an mehreren Stellen durchführen, oder kann sie einmal für eine externe Anforderung durchgeführt werden?
Entwurfsempfehlungen
Wenn Sie einen Hub-and-Spoke-Entwurf für Unternehmen verwenden, sollten Sie die Verwendung von Azure Front Door als Einstiegspunkt für internetbasierte Anforderungen erwägen.
Erwägen Sie die Verwendung von Azure Application Gateway als Endpunkt für externe TLS-basierte Anforderungen oder API Management für die Zertifikatauthentifizierung und/oder SSL-Beendigung.
Verbindung zu lokalen Ressourcen
Viele Unternehmensintegrationsszenarien erfordern eine Verbindung Ihrer lokalen Systeme mit Azure. Es ist wichtig, die empfohlenen Modelle zu berücksichtigen, um diese Konnektivität bereitzustellen.
Überlegungen zum Entwurf
Azure ExpressRoute bietet dedizierte private Konnektivität für Azure-IaaS- und -PaaS-Ressourcen (Infrastructure-as-a-Service und Platform-as-a-Service) von lokalen Standorten.
Azure VPN Gateway bietet von lokalen Standorten aus geteilte Site-to-Site-(S2S-)Konnektivität über das öffentliche Internet zu virtuellen IaaS-Netzwerkressourcen (Infrastructure-as-a-Service) von Azure.
Azure ExpressRoute und Azure VPN Gateway unterscheiden sich hinsichtlich der Funktionen, Kosten und der Leistung.
Das lokale Datengateway (OPDG) oder Azure-Hybridverbindungen können verwendet werden, wenn ExpressRoute oder VPN Gateway nicht praktikabel sind – OPDG/Hybridverbindungen sind beides Beispiele für Relaydienste, die Service Bus verwenden, um von Ihrem lokalen Netzwerk ausgehende Verbindungen herzustellen, sodass Anforderungen von Azure empfangen werden können, ohne dass Ports in Ihrer externen Firewall/Ihrem externen Netzwerk geöffnet werden müssen.
OPDG ist in der Anzahl von Anforderungen pro Minute begrenzt, die es unterstützt (Drosselungslimit), verfügt über bestimmte Datengrößenlimits und funktioniert nur mit begrenzten Azure-Ressourcen (Logic Apps, Power BI, Power Apps, Power Automate, Analysis Services).
Hybridverbindungen funktionieren mit App Services (Funktions-Apps oder Web-Apps) und haben eigene Drosselungs- und Größenbeschränkungen.
Azure Relay Hybrid Connections ist ein wichtiger Bestandteil von Service Bus, der Relays außerhalb von App Services oder OPDG ermöglicht.
Entwurfsempfehlungen
Verwenden Sie Azure ExpressRoute als primären Konnektivitätskanal für Verbindungen zwischen einem lokalen Netzwerk und Azure.
Stellen Sie sicher, dass Sie die richtige SKU für das ExpressRoute- und/oder VPN Gateway nutzen, entsprechend den Anforderungen in Bezug auf Bandbreite und Leistung.
Verwenden Sie Azure VPN Gateway, um Zweigstellen oder Remotestandorte mit Azure zu verbinden.
Verwenden Sie OPDG und/oder Hybridverbindungen, bei denen ExpressRoute oder VPN Gateway nicht verwendet werden kann, die Durchsatzgrenzwerte kein Problem sind und Sie eine Azure-Supportressource verwenden (z. B. Logic Apps, Funktions-Apps).
Konnektivität mit AIS-PaaS-Diensten
Der Zugriff auf Azure AIS-PaaS-Dienste erfolgt in der Regel über öffentliche Endpunkte. Die Azure-Plattform bietet Funktionen zum Schützen dieser Endpunkte und sogar zum vollständig als privat Einrichten.
Die Sicherung dieser Endpunkte kann mithilfe privater Endpunkte erreicht werden.
Verwenden Sie einen privaten Endpunkt, um den gesamten Internetdatenverkehr an eine Zielressource zu blockieren.
Wenn Sie eine bestimmte Unterressource in Ihren VNet-Ressourcen sichern möchten, verwenden Sie einen privaten Endpunkt.
Wenn Sie ein bestimmtes Speicherkonto in Ihren VNet-Ressourcen sichern möchten, können Sie einen privaten Endpunkt verwenden.
Mit Azure Private Link können Sie über einen privaten Endpunkt in Ihrem virtuellen Netzwerk auf Azure AIS-Dienste (beispielsweise Service Bus und API Management) sowie auf in Azure gehostete kundeneigene Dienste/Partnerdienste zugreifen.
Bei der Verwendung von Private Link wird der Datenverkehr zwischen Ihrem virtuellen Netzwerk und dem Dienst über das „Backbone“-Netzwerk von Microsoft übertragen. Sie müssen Ihren Dienst also nicht mehr für das öffentliche Internet verfügbar machen. Sie können Ihren eigenen Private Link-Dienst in Ihrem virtuellen Netzwerk erstellen und Ihren Kunden zur Verfügung stellen. Die Einrichtung und Nutzung von Azure Private Link ist in Azure PaaS-, Kunden- und gemeinsam genutzten Partnerdiensten einheitlich.
Überlegungen zum Entwurf
Die Einschleusung von virtuellen Netzwerken ermöglicht dedizierte private Bereitstellungen für unterstützte Dienste. Der Datenverkehr auf Verwaltungsebene fließt weiter über öffentliche IP-Adressen.
Azure Private Link bietet über private IP-Adressen dedizierten Zugriff auf Azure-PaaS-Instanzen bzw. benutzerdefinierte Dienste hinter einer Azure Load Balancer-Instanz im Standard-Tarif.
Unternehmenskunden haben häufig Bedenken in Bezug auf öffentliche Endpunkte für PaaS-Dienste, die entsprechend adressiert werden müssen.
Entwurfsempfehlungen
Verwenden Sie die Einschleusung von virtuellen Netzwerken für unterstützte Azure-Dienste, um diese aus Ihrem virtuellen Netzwerk verfügbar zu machen.
Azure-PaaS-Dienste, die in ein virtuelles Netzwerk eingeschleust werden, führen immer noch Vorgänge auf der Verwaltungsebene mit dienstspezifischen öffentlichen IP-Adressen durch. Die Konnektivität muss gewährleistet sein, damit der Dienst ordnungsgemäß funktioniert.
Greifen Sie von Ihrer lokalen Umgebung aus über das private ExpressRoute-Peering auf Azure-PaaS-Dienste zu. Verwenden Sie entweder die Einschleusung virtueller Netzwerke für dedizierte Azure-Dienste oder Azure Private Link für verfügbare freigegebene Azure-Dienste.
Verwenden Sie ExpressRoute mit Microsoft-Peering, um aus einem lokalen Netzwerk auf Azure-PaaS-Dienste zuzugreifen, wenn die Einschleusung virtueller Netzwerke und Private Link nicht verfügbar sind. Damit können Sie eine Übertragung über das öffentliche Internet vermeiden.
Der Zugriff auf Azure-PaaS-Dienste aus einer lokalen Umgebung über ExpressRoute mit Microsoft-Peering verhindert nicht den Zugriff auf die öffentlichen Endpunkte des PaaS-Diensts. Sie müssen dies bei Bedarf konfigurieren und einschränken.
Aktivieren Sie VNET-Dienstendpunkte nicht standardmäßig in allen Subnetzen.
Deaktivieren Sie den öffentlichen Zugriff auf AIS-PaaS-Dienste.
Netzwerkentwurf für API Management
Überlegungen zum Entwurf
Entscheiden Sie, ob auf APIs extern, intern oder in einer hybriden Kombination aus beidem zugegriffen werden kann.
Entscheiden Sie, ob Sie das interne API Management-Gateway als Hauptendpunkt oder einen WAF-Dienst (Web Application Firewall) wie Azure Application Gateway oder Azure Front Door verwenden möchten.
Entscheiden Sie, ob mehrere Gateways bereitgestellt werden sollen und wie diese lastenausgleichend sind – z. B. mithilfe von Application Gateway vor dem API Management-Gateway.
Entscheiden Sie, ob die Konnektivität mit lokalen oder Multi-Cloud-Umgebungen erforderlich ist.
Entwurfsempfehlungen
Stellen Sie Ihre API Management-Instanz in einem VNet bereit, um den Zugriff auf Back-End-Dienste im Netzwerk zu ermöglichen.
Verwenden Sie Application Gateway für den externen Zugriff auf API Management, wenn die API Management Instanz im internen Modus in einem VNet bereitgestellt wird.
Verwenden Sie einen privaten Endpunkt für Ihre API Management-Instanz, um Clients in Ihrem privaten Netzwerk den sicheren Zugriff auf die Instanz über Azure Private Link zu ermöglichen.
Netzwerkentwurf für Speicherkonten
Azure Storage wird als Speicherlösung für Azure Logic Apps und Azure Functions verwendet.
Entwurfsempfehlungen
Für eine optimale Leistung sollte Ihre Logik-App/Funktions-App ein Speicherkonto in derselben Region verwenden, um die Latenz zu verringern.
Verwenden Sie private Endpunkte für Azure Storage-Konten, um Clients in einem virtuellen Netzwerk (VNET) den sicheren Zugriff auf Daten über Private Link zu ermöglichen.
Für jeden Tabellen-, Warteschlangen- und Blobspeicherdienst sollten unterschiedliche private Endpunkte erstellt werden.
Netzwerkentwurf für App Service-Umgebungen
Eine App Service-Umgebung (ASE) ist eine dedizierte, isolierte Umgebung zum Ausführen von Web-Apps, Funktions-Apps und Logic Apps (Standard). Sie wird in Ihrem VNet bereitgestellt und enthält eine Reihe von App Service-Plänen, die jeweils zum Hosten Ihrer App-Dienste verwendet werden.
Überlegungen zum Entwurf
Eine ASE wird in einem einzelnen Subnetz in Ihrem VNet bereitgestellt. Eine ASE kann mithilfe einer virtuellen IP-Adresse (VIP) bereitgestellt werden, sodass externe Verbindungen eine öffentlich sichtbare IP-Adresse verwenden können, die einem öffentlichen DNS-Eintrag hinzugefügt werden kann.
Anwendungen innerhalb einer ASE haben je nach Netzwerkzugriffsregeln Zugriff auf alle anderen Ressourcen innerhalb des virtuellen Netzwerks. Der Zugriff auf Ressourcen in anderen VNets kann mittels Peering virtueller Netzwerke erreicht werden.
Anwendungen innerhalb einer ASE müssen nicht so konfiguriert werden, dass sie zu einem VNet gehören. Sie befinden sich automatisch innerhalb des VNet, da sie in der ASE bereitgestellt werden. Dies bedeutet, dass Sie den Netzwerkzugriff nicht auf Ressourcenbasis konfigurieren müssen, sondern nur einmal auf ASE-Ebene konfigurieren können.
Entwurfsempfehlungen
- Verwenden Sie nach Möglichkeit ASE v3, da dies die größtmögliche Netzwerkflexibilität bietet und gleichzeitig die erforderliche Konfiguration für einzelne Ressourcen innerhalb der ASE reduziert. ASE v3 unterstützt auch Zonenredundanz.
Netzwerkentwurf für App Service-Pläne
App Services in einer Umgebung mit mehreren Mandanten können mit einem privaten oder einem öffentlichen Endpunkt bereitgestellt werden. Wenn sie mit einem privaten Endpunkt bereitgestellt werden, wird die öffentliche Exposition des App Service entfernt. Wenn für den privaten Endpunkt der App Service auch über das Internet erreichbar sein muss, sollten Sie die Verwendung von App Gateway berücksichtigen, um den App-Dienst verfügbar zu machen.
Planen Sie Ihre Subnetze vorsichtig für die ausgehende VNet-Integration, und berücksichtigen Sie die Anzahl der IP-Adressen, die erforderlich sind. Die VNet-Integration erfordert die Verwendung eines dedizierten Subnetzes. Beachten Sie bei der Planung Ihrer Subnetzgröße, dass Azure 5 IP-Adressen in jedem Subnetz reserviert. Für jede Instanz des Plans wird außerdem eine Adresse aus dem Integrationssubnetz verwendet. Wenn Sie Ihre App auf vier Instanzen skalieren, werden vier Adressen verwendet. Wenn Sie die Größe hoch- oder herunterskaliert haben, wird der erforderliche Adressraum für einen kurzen Zeitraum verdoppelt. Dies wirkt sich auf die tatsächlichen, verfügbaren unterstützten Instanzen in Ihrem Subnetz aus.
Wenn eine Verbindung von einem App Service mit lokalen, privaten oder IP-eingeschränkten Diensten hergestellt werden muss, sollten Sie Folgendes berücksichtigen:
Wenn sie in der Umgebung mit mehreren Mandanten ausgeführt werden, kann der App Service-Aufruf aus einer Vielzahl von IP-Adressen stammen, und die VNet-Integration kann erforderlich sein, um Ihre Netzwerkanforderungen zu erfüllen.
Dienste wie API Management (APIM) können verwendet werden, um Aufrufe zwischen Netzwerkgrenzen weiterzuleiten und bei Bedarf eine statische IP bereitzustellen.
Entwurfsempfehlungen
- Da die Subnetzgrößen nach der Zuweisung nicht mehr geändert werden kann, verwenden Sie ein Subnetz, das für die Aufnahme jedweder Skalierung Ihrer App groß genug ist. Um jegliche Probleme mit der Subnetzkapazität zu vermeiden, wird das Suffix /26 (64 Adressen) für die Vnet-Integration empfohlen.
Netzwerkentwurf für Azure Data Factory
Überlegungen zum Entwurf
Wenn Sie Data Factory mit einer Datenquelle verbinden möchten, die sich in Ihrem lokalen Netzwerk oder möglicherweise in einem Azure-Dienst befindet, der so konfiguriert wurde, dass der Zugriff von allen Azure-Diensten blockiert wird, sofern diese nicht ausdrücklich zulässig sind, müssen Sie erwägen, Ihre Data Factory in ein virtuelles Netzwerk zu integrieren, das Netzwerkzugriff auf die Zieldatenquelle ermöglicht.
Data Factory verwendet separate Umgebungen, die als Integration Runtimes bezeichnet werden. Die standardmäßige Data Factory-Runtime, die Azure Integration Runtime, ist keinem VNet zugeordnet und kann daher nicht zum Herstellen einer Verbindung mit Datenquellen verwendet werden, die durch die restriktivsten Firewalls gesichert sind. Überlegen Sie, welche dieser Runtimes Ihre Anforderungen am besten erfüllen.
Verwaltete VNets brauchen einige Zeit für den Startvorgang, während normale Azure-Runtimes fast sofort verfügbar sind. Dies ist etwas, das Sie beim Planen und Debuggen Ihrer Pipelines beachten müssen.
SSIS-Runtimes mit einer VNe-integrierten Runtime erfordern für den Startvorgang bis zu 30 Minuten.
Selbstgehostete Integration Runtimes können nur die Kopieraktivität ausführen, bei der Daten unverändert aus einer Quelle in eine andere kopiert werden. Wenn Sie Transformationen für die Daten durchführen möchten, ist dies nicht mithilfe der Data Factory-Datenflüsse möglich.
Verwaltete private Endpunkte sind private Endpunkte, die im Azure Data Factory Managed Virtual Network erstellt werden und eine private Verbindung zu Azure-Ressourcen (im Allgemeinen Datenquellen für ADF) herstellen. Azure Data Factory verwaltet diese privaten Endpunkte für Sie.
Private Endpunkte sind nur für selbstgehostete Integration Runtimes verfügbar, um eine Verbindung zu Data Factory herzustellen.
Netzwerkentwurf für Logic Apps (Standard): Integrierte VNet-Apps
Überlegungen zum Entwurf
Eingehender Datenverkehr zu Ihren Logik-Apps erfolgt über private Endpunkte. Ziehen Sie bei der Planung Ihres Logic Apps-Netzwerkentwurfs die Dokumentation Überlegungen zum eingehenden Datenverkehr über private Endpunkte heran.
Ausgehender Datenverkehr von Ihren Logik-Apps wird durch das VNet geleitet. Ziehen Sie bei der Planung Ihres Logic Apps-Netzwerkentwurfs die Dokumentation Überlegungen zum ausgehenden Datenverkehr über die Integration virtueller Netzwerke heran.
Netzwerkentwurf für Service Bus
Überlegungen zum Entwurf
Verwenden Sie private DNS-Zonen oder Ihren eigenen DNS-Server (mit DNS-Weiterleitung), um eine private Verbindungsressource aufzulösen?
IP-Filterung und VNets werden nur im Premium-SKU-Tarif für Service Bus unterstützt. Wenn der Premium-Tarif nicht praktisch ist, sollten Sie die Verwendung von SAS-Token als primäre Möglichkeit zum Sperren des Zugriffs auf Ihren Namespace in Betracht ziehen.
Entwurfsempfehlungen
Der öffentliche Netzwerkzugriff sollte mithilfe der IP-Filterung deaktiviert werden, die für alle unterstützten Protokolle gilt (z. B. AMQP und HTTPS).
Der Datenverkehr zu diesem Namespace sollte nur über private Endpunkte beschränkt werden, indem der öffentliche Netzwerkzugriff eingeschränkt wird (mithilfe der IP-Filterung).
Platzieren Sie Ihren privaten Endpunkt in einem eigenen dedizierten Subnetz, das für Service Bus reserviert ist.
Fügen Sie einen DNS-Eintrag mithilfe der privaten DNS-Zone für den privaten Endpunkt hinzu. Ermöglichen Sie vertrauenswürdigen Diensten in Azure, direkt auf Ihren Namespace zuzugreifen (wodurch die Firewall umgangen wird), um Probleme mit Ihrem Integrationsentwurf zu vermeiden.
Netzwerkentwurf für Funktions-Apps
Überlegungen zum Entwurf
- Verwenden Sie private DNS-Zonen oder Ihren eigenen DNS-Server (mit DNS-Weiterleitung), um eine private Verbindungsressource aufzulösen?
Entwurfsempfehlungen
Der öffentliche Netzwerkzugriff sollte deaktiviert werden.
Datenverkehr zu diesem Namespace sollte nur über private Endpunkte beschränkt werden.
Platzieren Sie Ihren privaten Endpunkt in einem eigenen dedizierten Subnetz, das für Functions reserviert ist.
Fügen Sie einen DNS-Eintrag mithilfe einer privaten DNS-Zone für den privaten Endpunkt hinzu.
Netzwerkentwurf für Azure Key Vault
Entwurfsempfehlungen
Der öffentliche Netzwerkzugriff sollte deaktiviert werden.
Erstellen Sie einen privaten Endpunkt, um den Zugriff nur über VNets einzuschränken.
Platzieren Sie Ihren privaten Endpunkt in einem eigenen dedizierten Subnetz, das für Key Vault reserviert ist.
Fügen Sie einen DNS-Eintrag mithilfe einer privaten DNS-Zone für den privaten Endpunkt hinzu.
Netzwerkentwurf für Event Grid
Überlegungen zum Entwurf
- Verwenden Sie private DNS-Zonen oder Ihren eigenen DNS-Server (mit DNS-Weiterleitung), um eine private Verbindungsressource aufzulösen?
Entwurfsempfehlungen
Der öffentliche Netzwerkzugriff sollte mithilfe der IP-Filterung deaktiviert werden.
Der Datenverkehr zu Ihren Themen und Ihrer Domäne sollte nur auf private Endpunkte beschränkt werden.
Platzieren Sie Ihren privaten Endpunkt in einem eigenen dedizierten Subnetz, das für Event Grid reserviert ist.
Fügen Sie einen DNS-Eintrag mithilfe einer privaten DNS-Zone für den privaten Endpunkt hinzu.
Netzwerkentwurf für Event Hubs
Überlegungen zum Entwurf
- Das Einschränken des Netzwerkzugriffs funktioniert nicht mit dem Basic-SKU-Tarif in Event Hubs.
Entwurfsempfehlungen
Der öffentliche Netzwerkzugriff sollte mithilfe der IP-Filterung deaktiviert werden.
Der öffentliche Netzwerkzugriff sollte mithilfe von Dienstendpunkten deaktiviert werden: Erstellen Sie einen VNET-Dienstendpunkt in Ihrem VNET, und binden Sie diesen mithilfe einer VNET-Regel an Ihren Event Hubs-Namespace.
Aktivieren Sie die Option „Vertrauenswürdige Dienste“, um ausgewählten Azure-Ressourcen den Zugriff auf Ihren Namespace zu ermöglichen.
Nächster Schritt
Überprüfen Sie die kritischen Designbereiche, um umfassende Überlegungen hinsichtlich Ihrer Architektur anzustellen und Empfehlungen zu geben.