Zagadnienia dotyczące topologii sieci i łączności dla akceleratora strefy docelowej usług Integration Services
Ten artykuł zawiera zagadnienia dotyczące projektowania i zalecenia dotyczące topologii sieci i łączności, które można zastosować podczas korzystania z akceleratora strefy docelowej usług Azure Integration Services (AIS). Sieć ma kluczowe znaczenie dla niemal wszystkich elementów w strefie docelowej.
Zagadnienia dotyczące topologii sieci i łączności dla tej architektury zależą od wymagań hostowanych obciążeń oraz wymagań dotyczących zabezpieczeń i zgodności organizacji.
Uwagi dotyczące projektowania
Użyj topologii sieci opartej na usłudze Virtual WAN , jeśli twoja organizacja:
Planuje wdrożenie zasobów w kilku regionach świadczenia usługi Azure i wymaga globalnej łączności między sieciami wirtualnymi w tych regionach platformy Azure i wielu lokalizacjach lokalnych.
Musi zintegrować sieć oddziałów na dużą skalę bezpośrednio z platformą Azure za pośrednictwem wdrożenia zdefiniowanej programowo sieci WAN (SD-WAN) lub wymaga więcej niż 30 lokacji gałęzi na potrzeby natywnego zakończenia protokołu IPsec.
Wymagane jest routing przechodnie między siecią VPN i usługą ExpressRoute, takie jak zdalne gałęzie połączone za pośrednictwem sieci VPN typu lokacja-lokacja lub użytkownicy zdalni połączeni za pośrednictwem sieci VPN typu punkt-lokacja, wymagają łączności z połączonym kontrolerem domeny usługi ExpressRoute za pośrednictwem platformy Azure.
Organizacje używają usługi Virtual WAN do spełnienia wymagań dotyczących połączeń międzyoperacyjności na dużą skalę. Firma Microsoft zarządza tą usługą, która pomaga zmniejszyć ogólną złożoność sieci i zmodernizować sieć organizacji.
Użyj tradycyjnej topologii sieci platformy Azure opartej na architekturze piasty i szprych, jeśli twoja organizacja:
Plany wdrażania zasobów tylko w wybranych regionach platformy Azure.
Nie wymaga globalnej, połączonej sieci.
Ma kilka lokalizacji zdalnych lub oddziałów na region i wymaga mniej niż 30 tuneli zabezpieczeń adresów IP (IPsec).
Wymaga pełnej kontroli nad konfiguracją lub wymaga ręcznej konfiguracji niestandardowej sieci platformy Azure.
Topologia sieci referencyjnej
Na poniższym diagramie architektury przedstawiono architekturę referencyjną wdrożenia usługi AIS dla przedsiębiorstw:
Planowanie adresowania IP
Wdrożenia sztucznej inteligencji w przedsiębiorstwie powinny obejmować korzystanie z prywatnych punktów końcowych i sieci wirtualnych. Podczas planowania adresowania IP należy wziąć pod uwagę następujące zagadnienia projektowe:
Niektóre usługi AIS wymagają dedykowanych podsieci
Możesz wyznaczyć daną podsieć t0 danej usługi, aby utworzyć wystąpienia tej usługi w podsieci. Można na przykład wyznaczyć podsieć do planów usługi App Service, aby można było dodawać dodatkowe aplikacje w czasie.
Usługa Azure VPN Gateway może łączyć nakładające się lokacje lokalne z nakładającymi się przestrzeniami adresów IP za pośrednictwem funkcji translatora adresów sieciowych (NAT).
Niestandardowe DNS
Większość usług AIS umożliwia klientom używanie własnych nazw DNS dla publicznych punktów końcowych przy użyciu własnych serwerów DNS lub za pośrednictwem oferty Azure DNS. Konfiguracja tych zasobów jest wykonywana na podstawie zasobów, ale obsługiwane zasoby są wymienione poniżej:
Usługa API Management obsługuje domeny niestandardowe.
Aplikacje funkcji i aplikacje logiki obsługują domeny niestandardowe, jeśli są hostowane przez plan usługi App Service lub środowisko App Service Environment.
Konta magazynu obsługują domeny niestandardowe dla punktów końcowych magazynu obiektów blob.
Usługi Data Factory, Service Bus i Event Grid nie obsługują domen niestandardowych.
Prywatna strefa DNS
Usługa Azure Prywatna strefa DNS zapewnia niezawodną i bezpieczną usługę DNS dla sieci wirtualnej. Usługa Azure Prywatna strefa DNS zarządza i rozpoznaje nazwy domen w sieci wirtualnej bez konieczności konfigurowania niestandardowego rozwiązania DNS.
Aby rozpoznać rekordy prywatnej strefy DNS z sieci wirtualnej, należy połączyć sieć wirtualną ze strefą. Połączone sieci wirtualne mają pełny dostęp i mogą rozpoznawać wszystkie rekordy DNS opublikowane w strefie prywatnej.
Uwagi dotyczące projektowania
Ważne jest, aby poprawnie skonfigurować ustawienia DNS, aby rozpoznać prywatny adres IP punktu końcowego do w pełni kwalifikowanej nazwy domeny (FQDN) zasobów.
Istniejące usługi platformy Microsoft Azure mogą już mieć konfigurację DNS dla publicznego punktu końcowego. Ta konfiguracja musi zostać zastąpiona, aby nawiązać połączenie przy użyciu prywatnego punktu końcowego.
Szyfrowanie i uwierzytelnianie certyfikatów
Jeśli projekt sieci wymaga szyfrowania ruchu tranzytowego i/lub uwierzytelniania opartego na certyfikatach, może być konieczne rozważenie miejsca i sposobu wykonywania tego szyfrowania/uwierzytelniania. Na przykład należy określić, która usługa wykonuje zakończenie protokołu TLS.
Uwagi dotyczące projektowania
Czy projekt wymaga szyfrowania ruchu między usługami platformy Azure? Czy szyfrowanie można zakończyć w usłudze Azure Front Door, a następnie być niezaszyfrowane podczas przechodzenia przez sieć szkieletową platformy Azure lub w sieci wirtualnej?
Czy konieczne będzie zakończenie szyfrowania w wielu miejscach?
Czy musisz obsługiwać uwierzytelnianie w wielu miejscach lub czy można je wykonać raz dla żądania zewnętrznego?
Zalecenia dotyczące projektowania
Jeśli korzystasz z projektu piasty i szprych przedsiębiorstwa, rozważ użycie usługi Azure Front Door jako punktu wejścia dla żądań internetowych.
Rozważ użycie aplikacja systemu Azure Gateway jako punktu zakończenia dla zewnętrznych żądań opartych na protokole TLS lub usługi API Management na potrzeby uwierzytelniania certyfikatu i/lub kończenia żądań SSL.
Połączenie ivity do zasobów lokalnych
Wiele scenariuszy integracji przedsiębiorstwa wymaga połączenia systemów lokalnych z platformą Azure. Ważne jest, aby wziąć pod uwagę zalecane modele, aby zapewnić tę łączność.
Uwagi dotyczące projektowania
Usługa Azure ExpressRoute zapewnia dedykowaną prywatną łączność z zasobami infrastruktury jako usługi (IaaS) i platformy jako usługi (PaaS) z lokalizacji lokalnych.
Usługa Azure VPN Gateway zapewnia współdzieloną łączność typu lokacja-lokacja (S2S) za pośrednictwem publicznego Internetu do zasobów sieci wirtualnej infrastruktury jako usługi (IaaS) platformy Azure z lokalizacji lokalnych.
Usługi Azure ExpressRoute i Azure VPN Gateway mają różne możliwości, koszty i wydajność.
Lokalna brama danych (OPDG) lub hybrydowe Połączenie platformy Azure mogą być używane, gdy usługa ExpressRoute lub usługa VPN Gateway nie jest praktyczna — opDG/hybrydowe Połączenie ions są przykładami usług przekazywania, korzystając z usługi Service Bus do nawiązywania połączeń wychodzących z sieci lokalnej w celu odbierania żądań z platformy Azure bez konieczności otwierania portów w zewnętrznej zaporze/sieci.
Grupa OPDG jest ograniczona w liczbie żądań na minutę, które obsługuje (limit ograniczania przepustowości), ma określone limity rozmiaru danych i działa tylko z ograniczonymi zasobami platformy Azure (Logic Apps, Power BI, Power Apps, Power Automate, Analysis Services).
Połączenia hybrydowe współpracują z usługami App Services (aplikacje funkcji lub aplikacje internetowe) i mają własne ograniczenia przepustowości i limity rozmiaru.
Hybrydowe Połączenie usługi Azure Relay to kluczowa część usługi Service Bus, która umożliwia przekaźniki poza usługami App Services lub OPDG.
Zalecenia dotyczące projektowania
Użyj usługi Azure ExpressRoute jako podstawowego kanału łączności do łączenia sieci lokalnej z platformą Azure.
Upewnij się, że używasz odpowiedniej jednostki SKU dla usługi ExpressRoute i/lub bramy sieci VPN na podstawie wymagań dotyczących przepustowości i wydajności.
Użyj usługi Azure VPN Gateway , aby połączyć gałęzie lub lokalizacje zdalne z platformą Azure.
Użyj Połączenie opDG i/lub hybrydowych, w których nie można używać usługi ExpressRoute lub usługi VPN Gateway, gdzie limity przepływności nie będą problemem i gdzie używasz obsługiwanego zasobu platformy Azure (np. usługi Logic Apps, aplikacji funkcji).
Połączenie ivity do usług PaaS AIS
Usługi PaaS usługi Azure AIS są zwykle dostępne za pośrednictwem publicznych punktów końcowych. Platforma Azure zapewnia możliwości zabezpieczania tych punktów końcowych, a nawet tworzenia ich całkowicie prywatnych.
Zabezpieczanie tych punktów końcowych można osiągnąć przy użyciu prywatnych punktów końcowych.
Aby zablokować cały ruch internetowy do zasobu docelowego, użyj prywatnego punktu końcowego.
Jeśli chcesz zabezpieczyć określony zasób podrzędny do zasobów sieci wirtualnej, użyj prywatnego punktu końcowego.
Jeśli chcesz zabezpieczyć określone konto magazynu w zasobach sieci wirtualnej, możesz użyć prywatnego punktu końcowego.
Usługa Azure Private Link umożliwia dostęp do usług Azure AIS ( na przykład Service Bus i API Management) oraz usług należących do klienta/partnerów platformy Azure za pośrednictwem prywatnego punktu końcowego w sieci wirtualnej.
W przypadku korzystania z usługi Private Link ruch między siecią wirtualną a usługą przechodzi przez sieć szkieletową firmy Microsoft, więc uwidacznianie usługi w publicznym Internecie nie jest już konieczne. Możesz również utworzyć własną usługę łącza prywatnego w sieci wirtualnej i dostarczyć ją do klientów. Konfiguracja i zużycie przy użyciu usługi Azure Private Link jest spójna w należących do klienta usługach PaaS platformy Azure i udostępnionych usługach partnerskich.
Uwagi dotyczące projektowania
Wstrzyknięcie sieci wirtualnej zapewnia dedykowane wdrożenia prywatne dla obsługiwanych usług. Ruch płaszczyzny zarządzania nadal przepływa przez publiczne adresy IP.
Usługa Azure Private Link zapewnia dedykowany dostęp przy użyciu prywatnych adresów IP dla wystąpień paaS platformy Azure lub usług niestandardowych za warstwą Standardowa usługi Azure Load Balancer.
Klienci korporacyjni często mają obawy dotyczące publicznych punktów końcowych dla usług PaaS, które muszą zostać odpowiednio rozwiązane.
Zalecenia dotyczące projektowania
Użyj iniekcji sieci wirtualnej dla obsługiwanych usług platformy Azure, aby udostępnić je z poziomu sieci wirtualnej.
Usługi PaaS platformy Azure wprowadzone do sieci wirtualnej nadal wykonują operacje płaszczyzny zarządzania przy użyciu określonych publicznych adresów IP usługi. Połączenie ivity musi być gwarantowana, aby usługa działała poprawnie.
Uzyskiwanie dostępu do usług PaaS platformy Azure ze środowiska lokalnego za pośrednictwem usługi ExpressRoute za pomocą prywatnej komunikacji równorzędnej. Użyj iniekcji sieci wirtualnej dla dedykowanych usług platformy Azure lub usługi Azure Private Link dla dostępnych udostępnionych usług platformy Azure.
Aby uzyskać dostęp do usług PaaS platformy Azure ze środowiska lokalnego, gdy iniekcja sieci wirtualnej lub usługa Private Link nie jest dostępna, użyj usługi ExpressRoute z komunikacją równorzędną firmy Microsoft, co pozwala uniknąć przechodzenia przez publiczny Internet.
Uzyskiwanie dostępu do usług PaaS platformy Azure ze środowiska lokalnego za pośrednictwem usługi ExpressRoute z komunikacją równorzędną firmy Microsoft nie uniemożliwia dostępu do publicznych punktów końcowych usługi PaaS. Należy skonfigurować i ograniczyć je oddzielnie zgodnie z potrzebami.
Nie włączaj domyślnie punktów końcowych usługi sieci wirtualnej we wszystkich podsieciach.
Wyłącz publiczny dostęp do usług PaaS AIS.
Projekt sieci dla usługi API Management
Uwagi dotyczące projektowania
Zdecyduj, czy interfejsy API są dostępne zewnętrznie, wewnętrznie lub hybrydowo.
Zdecyduj, czy chcesz użyć wewnętrznej bramy usługi API Management jako głównego punktu końcowego, czy chcesz użyć usługi Zapory aplikacji internetowej (WAF), takiej jak aplikacja systemu Azure Gateway lub Azure Front Door.
Zdecyduj, czy powinna istnieć wiele wdrożonych bram i jak są one ze zrównoważonym obciążeniem — na przykład przy użyciu usługi Application Gateway przed bramą usługi API Management.
Zdecyduj, czy wymagana jest łączność ze środowiskami lokalnymi, czy wielochmurowymi.
Zalecenia dotyczące projektowania
Wdróż wystąpienie usługi API Management w sieci wirtualnej, aby umożliwić dostęp do usług zaplecza w sieci.
Użyj usługi Application Gateway , aby uzyskać dostęp zewnętrzny do usługi API Management, gdy wystąpienie usługi API Management jest wdrażane w sieci wirtualnej w trybie wewnętrznym.
Użyj prywatnego punktu końcowego dla wystąpienia usługi API Management , aby umożliwić klientom w sieci prywatnej bezpieczny dostęp do wystąpienia za pośrednictwem usługi Azure Private Link.
Projekt sieci dla kont magazynu
Usługa Azure Storage jest używana jako rozwiązanie magazynu dla usług Azure Logic Apps i Azure Functions.
Zalecenia dotyczące projektowania
Aby uzyskać najlepszą wydajność, aplikacja logiki/aplikacja funkcji powinna używać konta magazynu w tym samym regionie, co zmniejsza opóźnienie.
Użyj prywatnych punktów końcowych dla kont usługi Azure Storage, aby umożliwić klientom w sieci wirtualnej bezpieczny dostęp do danych za pośrednictwem usługi Private Link.
Dla każdej tabeli, kolejki i usługi blob Storage należy utworzyć różne prywatne punkty końcowe.
Projekt sieci dla środowisk App Service Environment
Środowisko App Service Environment (ASE) to dedykowane, izolowane środowisko do uruchamiania aplikacji internetowych, aplikacji funkcji i usługi Logic Apps (Standard). Jest on wdrażany w sieci wirtualnej i zawiera wiele planów usługi App Service, z których każda jest używana do hostowania usług aplikacji.
Uwagi dotyczące projektowania
Środowiska ASE są wdrażane w jednej podsieci w sieci wirtualnej. Środowisko ASE można wdrożyć przy użyciu wirtualnego adresu IP (VIP), dzięki czemu połączenia zewnętrzne mogą używać publicznie widocznego adresu IP, który można dodać do publicznego rekordu DNS.
Aplikacje w ramach środowiska ASE będą miały dostęp do wszystkich innych zasobów w sieci wirtualnej, w zależności od reguł dostępu do sieci. Dostęp do zasobów w innych sieciach wirtualnych można uzyskać przy użyciu komunikacji równorzędnej sieci wirtualnych.
Aplikacje w środowisku ASE nie muszą być skonfigurowane tak, aby należały do sieci wirtualnej — są one automatycznie w sieci wirtualnej z powodu wdrażania w środowisku ASE. Oznacza to, że zamiast konfigurować dostęp sieciowy dla poszczególnych zasobów, można skonfigurować go raz na poziomie środowiska ASE.
Zalecenia dotyczące projektowania
- W miarę możliwości używaj środowiska ASE w wersji 3, ponieważ zapewnia to największą elastyczność sieci, jednocześnie zmniejszając konfigurację potrzebną dla poszczególnych zasobów w ramach środowiska ASE. Środowisko ASE w wersji 3 obsługuje również nadmiarowość strefową.
Projekt sieci dla planów usługi App Service
Usługi App Services w środowisku wielodostępnym można wdrożyć przy użyciu prywatnego lub publicznego punktu końcowego. Po wdrożeniu przy użyciu prywatnego punktu końcowego publiczne ujawnienie usługi App Service zostanie usunięte. Jeśli istnieje wymóg, aby prywatny punkt końcowy usługi App Service był również dostępny za pośrednictwem Internetu, rozważ użycie usługi App Gateway do uwidocznienia usługi App Service.
Starannie zaplanuj podsieci pod kątem integracji wychodzącej sieci wirtualnej, biorąc pod uwagę wymaganą liczbę adresów IP. Integracja z siecią wirtualną wymaga dedykowanej podsieci. Podczas planowania rozmiaru podsieci należy pamiętać, że platforma Azure rezerwuje 5 adresów IP w każdej podsieci . Ponadto jeden adres jest używany z podsieci integracji dla każdego wystąpienia planu. Podczas skalowania aplikacji do czterech wystąpień są używane cztery adresy. W przypadku skalowania w górę lub w dół wymagana przestrzeń adresowa jest dwukrotna przez krótki czas. Ma to wpływ na rzeczywiste, dostępne obsługiwane wystąpienia w podsieci.
Jeśli istnieje potrzeba nawiązania połączenia z usługi App Service z usługami lokalnymi, prywatnymi lub ograniczonymi adresami IP, należy wziąć pod uwagę następujące kwestie:
W przypadku uruchamiania w środowisku wielodostępnym wywołanie usługi App Service może pochodzić z szerokiego zakresu adresów IP, a integracja z siecią wirtualną może być wymagana do spełnienia wymagań sieciowych.
Usługi takie jak API Management (APIM) mogą służyć do wywołań serwera proxy między granicami sieci i w razie potrzeby mogą udostępniać statyczny adres IP.
Zalecenia dotyczące projektowania
- Ponieważ rozmiary podsieci nie mogą być zmieniane po przypisaniu, użyj podsieci, która jest wystarczająco duża, aby dopasować skalę aplikacji do osiągnięcia. Aby uniknąć problemów z pojemnością podsieci, należy użyć sufiksu /26 (64 adresów) na potrzeby integracji z siecią wirtualną.
Projekt sieci dla usługi Azure Data Factory
Uwagi dotyczące projektowania
Aby połączyć usługę Data Factory ze źródłem danych znajdującym się w sieci lokalnej, a może w usłudze platformy Azure, która została skonfigurowana do blokowania dostępu ze wszystkich usług platformy Azure, chyba że są one specjalnie dozwolone, należy rozważyć integrację usługi Data Factory z siecią wirtualną, która zapewnia dostęp sieciowy do docelowego źródła danych.
Usługa Data Factory korzysta z oddzielnych środowisk nazywanych środowiskami Integration Runtime. Domyślne środowisko uruchomieniowe usługi Data Factory, środowisko Azure Integration Runtime, nie jest skojarzone z siecią wirtualną i jako takie nie może służyć do łączenia się ze źródłami danych zabezpieczonymi najbardziej restrykcyjnymi zaporami. Rozważ , które z tych środowisk uruchomieniowych najlepiej spełniają Twoje wymagania.
Uruchamianie zarządzanych sieci wirtualnych zajmuje trochę czasu, podczas gdy normalne środowiska uruchomieniowe platformy Azure są dostępne niemal natychmiast. Jest to coś, o czym należy pamiętać podczas planowania potoków i debugowania ich.
Uruchamianie środowisk uruchomieniowych usług SSIS ze zintegrowanym środowiskiem uruchomieniowym sieci wirtualnej może potrwać do 30 minut.
Własne środowiska Integration Runtime mogą wykonywać tylko działanie kopiowania, które kopiuje dane z jednego źródła do innego. Jeśli chcesz wykonać jakiekolwiek przekształcenia danych, nie możesz wykonać tych operacji przy użyciu przepływów danych usługi Data Factory.
Zarządzane prywatne punkty końcowe to prywatne punkty końcowe utworzone w zarządzanej sieci wirtualnej usługi Azure Data Factory, które ustanawiają prywatny link do zasobów platformy Azure (zazwyczaj źródła danych dla usługi ADF). Usługa Azure Data Factory zarządza tymi prywatnymi punktami końcowymi w Twoim imieniu.
Prywatne punkty końcowe są dostępne tylko dla własnych środowisk Integration Runtime w celu nawiązania połączenia z usługą Data Factory.
Projekt sieci dla usługi Logic Apps (Standardowa) — zintegrowane aplikacje sieci wirtualnej
Uwagi dotyczące projektowania
Ruch przychodzący do aplikacji logiki będzie przechodził przez prywatne punkty końcowe. Zapoznaj się z zagadnieniami dotyczącymi ruchu przychodzącego za pośrednictwem prywatnych punktów końcowych podczas planowania projektu sieci usługi Logic Apps.
Ruch wychodzący z aplikacji logiki przepływa przez sieć wirtualną. Zapoznaj się z zagadnieniami dotyczącymi ruchu wychodzącego za pośrednictwem dokumentacji integracji sieci wirtualnej podczas planowania projektu sieci usługi Logic Apps.
Projekt sieci dla usługi Service Bus
Uwagi dotyczące projektowania
Czy używasz stref Prywatna strefa DNS lub własnego serwera DNS (z przekazywaniem DNS) do rozpoznawania zasobu łącza prywatnego?
Filtrowanie adresów IP i sieci wirtualne są obsługiwane tylko w warstwie Sku Premium dla usługi Service Bus. Jeśli warstwa Premium nie jest praktyczna, zapoznaj się z podstawowym sposobem blokowania dostępu do przestrzeni nazw przy użyciu tokenów SAS.
Zalecenia dotyczące projektowania
Dostęp do sieci publicznej powinien być wyłączony przy użyciu filtrowania adresów IP, które ma zastosowanie do wszystkich obsługiwanych protokołów (na przykład protokołu AMQP i HTTPS).
Ruch do tej przestrzeni nazw powinien być ograniczony tylko przez prywatne punkty końcowe, ograniczając dostęp do sieci publicznej (przy użyciu filtrowania adresów IP).
Umieść prywatny punkt końcowy we własnej dedykowanej podsieci zarezerwowanej dla usługi Service Bus.
Dodaj rekord DNS przy użyciu prywatnej strefy DNS dla prywatnego punktu końcowego. Włącz usługi zaufane na platformie Azure, aby uzyskać bezpośredni dostęp do przestrzeni nazw (tym samym pomijając zaporę), aby zapobiec problemom z projektem integracji.
Projekt sieci dla aplikacji funkcji
Uwagi dotyczące projektowania
- Czy używasz stref Prywatna strefa DNS lub własnego serwera DNS (z przekazywaniem DNS) do rozpoznawania zasobu łącza prywatnego?
Zalecenia dotyczące projektowania
Dostęp do sieci publicznej powinien być wyłączony.
Ruch do tej przestrzeni nazw powinien być ograniczony tylko przez prywatne punkty końcowe.
Umieść prywatny punkt końcowy we własnej dedykowanej podsieci zarezerwowanej dla usługi Functions.
Dodaj rekord DNS przy użyciu prywatnej strefy DNS dla prywatnego punktu końcowego.
Projekt sieci dla usługi Azure Key Vault
Zalecenia dotyczące projektowania
Dostęp do sieci publicznej powinien być wyłączony.
Utwórz prywatny punkt końcowy na potrzeby ograniczania dostępu tylko za pośrednictwem sieci wirtualnej.
Umieść prywatny punkt końcowy we własnej dedykowanej podsieci zarezerwowanej dla usługi Key Vault.
Dodaj rekord DNS przy użyciu prywatnej strefy DNS dla prywatnego punktu końcowego.
Projekt sieci dla usługi Event Grid
Uwagi dotyczące projektowania
- Czy używasz stref Prywatna strefa DNS lub własnego serwera DNS (z przekazywaniem DNS) do rozpoznawania zasobu łącza prywatnego?
Zalecenia dotyczące projektowania
Dostęp do sieci publicznej powinien być wyłączony przy użyciu filtrowania adresów IP.
Ruch do tematów i domeny powinien być ograniczony tylko przez prywatne punkty końcowe.
Umieść prywatny punkt końcowy we własnej dedykowanej podsieci zarezerwowanej dla usługi Event Grid.
Dodaj rekord DNS przy użyciu prywatnej strefy DNS dla prywatnego punktu końcowego.
Projekt sieci dla usługi Event Hubs
Uwagi dotyczące projektowania
- Ograniczanie dostępu do sieci nie działa z warstwą jednostki SKU Podstawowa w usłudze Event Hubs
Zalecenia dotyczące projektowania
Dostęp do sieci publicznej powinien być wyłączony przy użyciu filtrowania adresów IP.
Dostęp do sieci publicznej powinien być wyłączony przy użyciu punktów końcowych usługi: utwórz punkt końcowy usługi sieci wirtualnej w sieci wirtualnej i powiąż go z przestrzenią nazw usługi Event Hubs przy użyciu reguły sieci wirtualnej
Włącz opcję Zaufane usługi, aby zezwolić na wybieranie zasobów platformy Azure w celu uzyskania dostępu do przestrzeni nazw.
Następny krok
Przejrzyj krytyczne obszary projektowe, aby uwzględnić wszystkie zagadnienia i zalecenia dotyczące architektury.
Zalecana zawartość
Konfiguracja usługi DNS prywatnego punktu końcowego platformy Azure
Ochrona interfejsów API za pomocą usługi Application Gateway i usługi API Management
Zezwalaj na dostęp do przestrzeni nazw usługi Azure Event Hubs z określonych sieci wirtualnych
Omówienie kończenia żądań protokołu TLS przy użyciu usługi Application Gateway