Unternehmenskritische Basisarchitektur mit Netzwerksteuerelementen
Diese Architektur bietet Anleitungen zum Entwerfen einer unternehmenskritischen Workload mit strengen Netzwerkkontrollen, um nicht autorisierten öffentlichen Zugriff aus dem Internet auf eine der Workloadressourcen zu verhindern. Die Absicht besteht darin, Angriffsvektoren auf der Netzwerkebene zu stoppen, damit die Gesamtzuverlässigkeit des Systems nicht beeinträchtigt wird. Ein DDoS-Angriff (Distributed Denial of Service) kann z. B. dazu führen, dass eine Ressource nicht mehr verfügbar ist, indem sie mit unlegitim Datenverkehr überwältigt wird.
Sie baut auf der unternehmenskritischen Basisarchitektur auf, die sich auf die Maximierung von Zuverlässigkeit und Betriebseffizienz ohne Netzwerkkontrollen konzentriert. Diese Architektur fügt Features hinzu, mit deren Hilfe die entsprechenden cloudeigenen Funktionen wie Azure Virtual Network(VNet) und private Endpunkte, Azure Private Link, Azure Private DNS Zone und andere Pfade eingeschränkt werden.
Es wird empfohlen, sich mit dem Basisplan vertraut zu machen, bevor Sie mit diesem Artikel fortfahren.
Wichtige Designstrategien
Die Designstrategien für unternehmenskritische Basispläne gelten in diesem Anwendungsfall noch. Hier sind die zusätzlichen Netzwerküberlegungen für diese Architektur:
Steuern des Eingehenden Datenverkehrs
Eingehende oder eingehende Kommunikation in das virtuelle Netzwerk muss eingeschränkt werden, um böswillige Angriffe zu verhindern.
Wenden Sie die WaF-Funktionen (Web Application Firewall) auf globaler Ebene an, um Angriffe am Netzwerkrand näher an der Angriffsquelle zu stoppen.
Vermeiden Sie die öffentliche Konnektivität mit Azure-Diensten. Ein Ansatz besteht darin, private Endpunkte zu verwenden.
Überprüfen Sie den Datenverkehr, bevor er in das Netzwerk eintritt. Netzwerksicherheitsgruppen (Network Security Groups, NSGs) in Subnetzen helfen beim Filtern des Datenverkehrs, indem der Fluss zu den konfigurierten IP-Adressen und Ports zugelassen oder verweigert wird. Diese Steuerungsebene hilft auch bei der granularen Protokollierung.
Steuern des Ausgangsverkehrs
Der Datenverkehr von einem virtuellen Netzwerk an Entitäten außerhalb dieses Netzwerks muss eingeschränkt werden. Fehlende Kontrollen können zu Datenexfiltrationsangriffen durch böswillige Dienste von Drittanbietern führen.
Einschränken des ausgehenden Datenverkehrs in das Internet mithilfe der Azure-Firewall. Firewall kann Datenverkehr präzise mithilfe eines vollqualifizierten Domänennamens (FQDN) filtern.
Ausgleich von Kompromissen mit Sicherheit
Es gibt erhebliche Kompromisse, wenn Sicherheitsfeatures einer Workloadarchitektur hinzugefügt werden. Möglicherweise bemerken Sie einige Auswirkungen auf leistung, betriebliche Flexibilität und sogar Zuverlässigkeit. Angriffe wie Denial-Of-Service (DDoS), Datenangriffe und andere können jedoch auf die gesamte Zuverlässigkeit des Systems abzielen und schließlich zu einer Unverfügbarkeit führen.
Die Strategien basieren auf der allgemeinen Anleitung, die für unternehmenskritische Workloads in unternehmenskritischen Workloads in unternehmenskritischen Workloads bereitgestellt wird. Wir empfehlen Ihnen, den Entwurfsbereich der Vernetzung und Konnektivität nach Empfehlungen und bewährten Methoden zu erkunden, wenn Sie Ihre eigene unternehmenskritische Architektur definieren.
Architektur
Laden Sie eine Visio-Datei dieser Architektur herunter.
Die Komponenten dieser Architektur können auf diese Weise allgemein kategorisiert werden. Produktdokumentation zu Azure-Diensten finden Sie unter "Verwandte Ressourcen".
Globale Ressourcen
Die globalen Ressourcen leben lang und teilen die Lebensdauer des Systems. Sie haben die Möglichkeit, global im Kontext eines Multi-Region-Bereitstellungsmodells verfügbar zu sein. Weitere Informationen finden Sie unter "Globale Ressourcen".
Die Azure Front Door Premium-SKU wird als globaler Lastenausgleich für das zuverlässige Routing des Datenverkehrs an die regionalen Bereitstellungen verwendet, die über private Endpunkte verfügbar gemacht werden.
Weitere Informationen finden Sie unter "Gut konzipierte unternehmenskritische Workloads": Globales Datenverkehrsrouting.
Azure Cosmos DB für NoSQL wird weiterhin verwendet, um den Zustand außerhalb des Computeclusters zu speichern und verfügt über grundlegende Konfigurationseinstellungen für die Zuverlässigkeit. Der Zugriff ist auf autorisierte private Endpunktverbindungen beschränkt.
Weitere Informationen finden Sie unter "Gut konzipierte unternehmenskritische Workloads": Global verteilter Datenspeicher mit mehreren Schreibvorgängen.
Azure Container Registry wird verwendet, um alle Containerimages mit Georeplikationsfunktionen zu speichern. Der Zugriff ist auf autorisierte private Endpunktverbindungen beschränkt.
Weitere Informationen finden Sie unter "Wichtige arbeitskritische Arbeitslasten für gut konzipierte Aufgaben": Containerregistrierung.
Regionale Ressourcen
Die regionalen Ressourcen werden als Teil eines Bereitstellungsstempels für eine einzelne Azure-Region bereitgestellt. Sie sind kurzlebig, um mehr Resilienz, Skalierung und Nähe zu Benutzern zu bieten. Diese Ressourcen teilen nichts mit Ressourcen in einer anderen Region. Sie können unabhängig voneinander entfernt oder in andere Regionen repliziert werden. Sie teilen jedoch globale Ressourcen miteinander. Weitere Informationen finden Sie in den Ressourcen für regionale Stempel.
Statische Website in einem Azure Storage-Konto hosten eine Einzelseitenanwendung (Single Page Application, SPA), die Anforderungen an Back-End-Dienste sendet. Diese Komponente hat dieselbe Konfiguration wie das baseline-Frontend. Der Zugriff ist auf autorisierte private Endpunktverbindungen beschränkt.
Azure Virtual Networks bieten sichere Umgebungen für die Ausführung der Workload- und Verwaltungsvorgänge.
Interner Lastenausgleich ist der Anwendungsursprung. Front Door verwendet diesen Ursprung, um private und direkte Konnektivität mit dem Back-End mithilfe von privatem Link herzustellen.
Azure Kubernetes Service (AKS) ist der Orchestrator für back-End-Compute, der eine Anwendung ausführt und zustandslos ist. Der AKS-Cluster wird als privater Cluster bereitgestellt. Der Kubernetes-API-Server ist also nicht für das öffentliche Internet verfügbar. Der Zugriff auf den API-Server ist auf ein privates Netzwerk beschränkt. Weitere Informationen finden Sie im Computecluster-Artikel dieser Architektur.
Weitere Informationen finden Sie unter "Gut konzipierte unternehmenskritische Workloads": "Container Orchestration" und "Kubernetes".
Azure Firewall prüft und schützt den gesamten Datenverkehr aus den Azure Virtual Network-Ressourcen.
Azure Event Hubs wird als Nachrichtenbroker verwendet. Der Zugriff ist auf autorisierte private Endpunktverbindungen beschränkt.
Informationen zu unternehmenskritischen Arbeitslasten mit well-architected Mission: Lose gekoppelte ereignisgesteuerte Architektur.
Azure Key Vault wird als regionaler geheimer Speicher verwendet. Der Zugriff ist auf autorisierte private Endpunktverbindungen beschränkt.
Weitere Informationen finden Sie unter "Gut konzipierte unternehmenskritische Workloads": Schutz der Datenintegrität.
Bereitstellungspipelineressourcen
Erstellen und Freigeben von Pipelines für eine unternehmenskritische Anwendung müssen vollständig automatisiert sein, um eine konsistente Möglichkeit zur Bereitstellung eines validierten Stempels zu gewährleisten.
GitHub wird weiterhin für die Quellcodeverwaltung als hochverwendige gitbasierte Plattform verwendet.
Azure-Pipelines werden ausgewählt, um Pipelines zu automatisieren, die zum Erstellen, Testen und Bereitstellen einer Workload in Vorproduktions- und Produktionsumgebungen erforderlich sind.
Weitere Informationen finden Sie unter "Gut konzipierte unternehmenskritische Workloads": DevOps-Prozesse.
Selbst gehostete Azure DevOps-Build-Agentpools werden verwendet, um mehr Kontrolle über die Builds und Bereitstellungen zu haben. Diese Autonomiestufe ist erforderlich, da der Computecluster und alle PaaS-Ressourcen privat sind, was eine Integration auf Netzwerkebene erfordert, die für von Microsoft gehostete Build-Agents nicht möglich ist.
Observability-Ressourcen
Überwachungsdaten für globale Ressourcen und regionale Ressourcen werden unabhängig voneinander gespeichert. Ein einzelner, zentralisierter Observability-Speicher wird nicht empfohlen, um einen einzelnen Fehlerpunkt zu vermeiden. Weitere Informationen finden Sie unter Beobachtungsressourcen.
Azure Log Analytics wird als einheitliche Spüle zum Speichern von Protokollen und Metriken für alle Anwendungs- und Infrastrukturkomponenten verwendet.
Azure Application Insights wird als APM-Tool (Application Performance Management) verwendet, um alle Anwendungsüberwachungsdaten zu sammeln und direkt in Log Analytics zu speichern.
Weitere Informationen finden Sie unter "Gut konzipierte unternehmenskritische Workloads": "Predictive action" und "AI operations".
Verwaltungsressourcen
Eine wesentliche Entwurfsänderung von der Basisarchitektur ist der Computecluster. In diesem Design ist der AKS-Cluster privat. Diese Änderung erfordert zusätzliche Ressourcen, um Zugriff zu erhalten.
Skalierungssätze für virtuelle Azure-Computer für die privaten Build-Agents und Sprungfeldinstanzen zum Ausführen von Tools für den Cluster, z. B. Kubectl.
Azure Bastion bietet sicheren Zugriff auf virtuelle Sprungbox-VMs und entfernt die Notwendigkeit, dass die virtuellen Computer öffentliche IPs besitzen.
Private Endpunkte für PaaS-Dienste
Um Geschäfts- oder Bereitstellungsvorgänge zu verarbeiten, müssen die Anwendung und die Build-Agents mehrere Azure PaaS-Dienste erreichen, die global, innerhalb der Region und sogar innerhalb des Stempels bereitgestellt werden. In der Basisarchitektur liegt diese Kommunikation über den öffentlichen Endpunkten der Dienste.
In diesem Design wurden diese Dienste durch private Endpunkte geschützt, um sie aus dem öffentlichen Internetzugriff zu entfernen. Dieser Ansatz reduziert den gesamten Angriffsflächenbereich, um direkte Dienstmanipulationen aus unerwarteten Quellen zu verringern. Es führt jedoch einen weiteren potenziellen Fehlerpunkt ein und erhöht die Komplexität. Berücksichtigen Sie sorgfältig die Kompromisse mit Sicherheit, bevor Sie diesen Ansatz einführen.
Private Endpunkte sollten in einem dedizierten Subnetz des virtuellen Netzwerks des Stempels platziert werden. Private IP-Adressen an die privaten Endpunkte werden von diesem Subnetz zugewiesen. Im Wesentlichen kann jede Ressource im virtuellen Netzwerk mit dem Dienst kommunizieren, indem sie die private IP-Adresse erreicht. Stellen Sie sicher, dass der Adressraum groß genug ist, um alle privaten Endpunkte aufzunehmen, die für diesen Stempel erforderlich sind.
Um eine Verbindung über einen privaten Endpunkt herzustellen, benötigen Sie einen DNS-Eintrag. Es wird empfohlen, dns-Einträge, die den Diensten zugeordnet sind, in Azure Private DNS-Zonen zu halten, die von Azure DNS bedient werden. Stellen Sie sicher, dass der vollqualifizierte Domänenname (FQDN) in die private IP-Adresse aufgelöst wird.
In dieser Architektur wurden private Endpunkte für Azure Container Registry, Azure Cosmos DB, Key Vault, Storage-Ressourcen und Event Hubs konfiguriert. Außerdem wird der AKS-Cluster als privater Cluster bereitgestellt, der einen privaten Endpunkt für den Kubernetes-API-Dienst im Netzwerk des Clusters erstellt.
In diesem Design werden zwei virtuelle Netzwerke bereitgestellt, und beide verfügen über dedizierte Subnetze, die private Endpunkte für alle diese Dienste enthalten. Das Netzwerklayout wird im Layout des virtuellen Netzwerks beschrieben.
Wenn Sie der Architektur weitere Komponenten hinzufügen, sollten Sie weitere private Endpunkte hinzufügen. Beispielsweise können Sie den Observability-Ressourcen Einschränkungen hinzufügen. Sowohl Azure Log Analytics als auch Azure Application Insights unterstützen die Verwendung privater Endpunkte. Ausführliche Informationen finden Sie unter Verwenden des privaten Azure-Links zum Verbinden von Netzwerken mit Azure Monitor.
Sie können in demselben oder unterschiedlichen Subnetz innerhalb desselben virtuellen Netzwerks erstellt werden. Die Anzahl der privaten Endpunkte, die Sie in einem Abonnement anlegen können, ist begrenzt. Weitere Informationen finden Sie unter Azure-Grenzwerte.
Steuern Sie den Zugriff auf die Dienste weiter, indem Sie Netzwerksicherheitsgruppen im Subnetz verwenden.
Privater Eingangseingang
Die Azure Front Door Premium-SKU wird als globaler Einstiegspunkt für den gesamten eingehenden Clientdatenverkehr verwendet. Es verwendet WAF-Funktionen (Web Application Firewall), um den Datenverkehr am Netzwerkrand zuzulassen oder zu verweigern. Die konfigurierten WAF-Regeln verhindern Angriffe, noch bevor sie in virtuelle Stempelnetzwerke gelangen.
Diese Architektur nutzt auch die Möglichkeit der Front Door, Azure Private Link für den Zugriff auf den Anwendungsursprung zu verwenden, ohne öffentliche IPs/Endpunkte in den Back-Ends zu verwenden. Dies erfordert einen internen Lastenausgleich im virtuellen Stempelnetzwerk. Diese Ressource befindet sich vor dem Kubernetes Ingress Controller, der im Cluster ausgeführt wird. Darüber hinaus wird ein privater Lastenausgleichsdienst von AKS erstellt, der für die private Verbindung von Front Door verwendet wird.
Nachdem die Verbindung hergestellt wurde, verfügen private Endpunkte im Front Door-Netzwerk über eine direkte Verbindung mit dem Lastenausgleich und der statischen Website im Stempelnetzwerk über private Verknüpfungen.
Weitere Informationen finden Sie unter Funktionsweise von privatem Link.
Weitere Informationen finden Sie unter "Gut konzipierte unternehmenskritische Workloads": Anwendungsbereitstellungsdienste.
Eingeschränkter Ausgang
Anwendungen erfordern möglicherweise eine ausgehende Internetverbindung. Die Steuerung dieses Datenverkehrs bietet eine Möglichkeit zum Einschränken, Überwachen und Einschränken des Ausgehenden Datenverkehrs. Andernfalls kann unerwarteter Inside-Out-Zugriff zu Kompromittierung und potenziell zu einem unzuverlässigen Systemzustand führen. Eingeschränkter Ausgang kann auch für andere Sicherheitsbedenken wie Datenexfiltration gelöst werden.
Die Verwendung von Firewall- und Netzwerksicherheitsgruppen (Network Security Groups, NSGs) kann sicherstellen, dass ausgehender Datenverkehr aus der Anwendung überprüft und protokolliert wird.
In dieser Architektur ist Azure Firewall der einzige Ausgangspunkt und wird verwendet, um den gesamten ausgehenden Datenverkehr zu prüfen, der aus dem virtuellen Netzwerk stammt. Benutzerdefinierte Routen (USER-Defined Routes, UDRs) werden in Subnetzen verwendet, die den Ausgehenden Datenverkehr generieren können, z. B. das Anwendungssubnetz.
Informationen zum Einschränken des ausgehenden Datenverkehrs finden Sie unter Steuern des Ausgehenden Datenverkehrs für Clusterknoten in Azure Kubernetes Service (AKS).For information about restricting outbound traffic, see Control egress traffic for cluster nodes in Azure Kubernetes Service (AKS).
Layout des virtuellen Netzwerks
Isolieren Sie regionale Ressourcen und Verwaltungsressourcen in separaten virtuellen Netzwerken. Sie weisen unterschiedliche Merkmale, Zwecke und Sicherheitsaspekte auf.
Art des Datenverkehrs: Regionale Ressourcen, die an der Verarbeitung von Geschäftsvorgängen teilnehmen, benötigen höhere Sicherheitskontrollen. Beispielsweise muss der Computecluster vor direktem Internetdatenverkehr geschützt sein. Verwaltungsressourcen werden nur für den Zugriff auf die regionalen Ressourcen für Vorgänge bereitgestellt.
Lebensdauer: Die erwarteten Lebensdauern dieser Ressourcen unterscheiden sich ebenfalls. Regionale Ressourcen werden voraussichtlich kurzlebig (kurzlebig) sein. Sie werden als Teil des Bereitstellungsstempels erstellt und zerstört, wenn der Stempel heruntergerissen wird. Verwaltungsressourcen teilen die Lebensdauer der Region und leben die Stempelressourcen.
In dieser Architektur gibt es zwei virtuelle Netzwerke: Stempelnetzwerk und Betriebsnetzwerk. Erstellen Sie eine weitere Isolation innerhalb jedes virtuellen Netzwerks, indem Sie Subnetze und Netzwerksicherheitsgruppen (NSGs) verwenden, um die Kommunikation zwischen den Subnetzen zu sichern.
Verweisen Sie auf unternehmenskritische Arbeitslasten mit gut architekturiertem Entwurf: Isolierte virtuelle Netzwerke.
Virtuelles Netzwerk für regionale Stempel
Der Bereitstellungsstempel stellt ein virtuelles Netzwerk in jeder Region bereit.
Das virtuelle Netzwerk ist in diese Hauptsubnetze unterteilt. Alle Subnetze haben Netzwerksicherheitsgruppen (Network Security Groups, NSGs) zugewiesen, um unbefugten Zugriff aus dem virtuellen Netzwerk zu blockieren. NSGs beschränken den Datenverkehr zwischen dem Anwendungssubnetz und anderen Komponenten im Netzwerk.
Anwendungssubnetz
Die AKS-Clusterknotenpools sind in einem Subnetz isoliert. Wenn Sie den Systemknotenpool weiter vom Workerknotenpool isolieren müssen, können Sie ihn in separaten Subnetzen platzieren.
Stempelingress-Subnetz
Der Einstiegspunkt zu jedem Stempel ist ein interner Azure Standard Load Balancer, der in einem dedizierten Subnetz platziert wird. Der private Link-Dienst, der für die private Verbindung von Front Door verwendet wird, wird auch hier platziert.
Beide Ressourcen werden als Teil der Stempelbereitstellung bereitgestellt.
Stempelausgangssubnetz
Azure Firewall wird in einem separaten Subnetz platziert und prüft den Datenverkehr aus dem Anwendungssubnetz mithilfe einer benutzerdefinierten Route (UDR).
Subnetz für private Endpunkte
Das Anwendungssubnetz muss auf die PaaS-Dienste im regionalen Stempel, key Vault und anderen zugreifen. Außerdem ist der Zugriff auf globale Ressourcen wie die Containerregistrierung erforderlich. In dieser Architektur sind alle PaaS-Dienste gesperrt und können nur über private Endpunkte erreicht werden. Für diese Endpunkte wird also ein anderes Subnetz erstellt. Der eingehende Zugriff auf dieses Subnetz wird durch NSG gesichert, das nur Datenverkehr von der Anwendung zulässt.
Sie können weitere Einschränkungen hinzufügen, indem Sie udR-Unterstützung für private Endpunkte verwenden, damit dieser Datenverkehr auch über das Stempelausgangssubnetz gesendet werden kann.
Virtuelles Betriebsnetzwerk
Der Betriebsdatenverkehr ist in einem separaten virtuellen Netzwerk isoliert. Da der API-Dienst des AKS-Clusters in dieser Architektur privat ist, müssen alle Bereitstellungs- und Betriebsdatenverkehr auch aus privaten Ressourcen wie selbst gehosteten Build-Agents und Sprungfeldern stammen. Diese Ressourcen werden in einem separaten virtuellen Netzwerk mit direkter Verbindung mit den Anwendungsressourcen über ihre eigenen privaten Endpunkte bereitgestellt. Die Build-Agents und Sprungfelder befinden sich in separaten Subnetzen.
Anstatt private Endpunkte zu verwenden, besteht ein alternativer Ansatz darin, virtuelles Netzwerk-Peering zu verwenden. Peering fügt jedoch Komplexität hinzu, die schwierig zu verwalten sein kann, insbesondere wenn virtuelle Netzwerke als kurzlebig konzipiert sind.
Sowohl die Build-Agents (als auch optional Sprungfelder) müssen auf PaaS-Dienste zugreifen, die sich global und innerhalb des regionalen Stempels befinden. Ähnlich wie das virtuelle Regionale Stempelnetzwerk wird ein dediziertes Subnetz für die privaten Endpunkte für die erforderlichen PaaS-Dienste erstellt. NSG in diesem Subnetz stellt sicher, dass der Datenverkehr nur aus den Verwaltungs- und Bereitstellungssubnetzen zulässig ist.
Verwaltungsvorgänge
Ein typischer Anwendungsfall ist, wenn ein Operator auf den Computecluster zugreifen muss, um Verwaltungstools und -befehle auszuführen. Auf den API-Dienst in einem privaten Cluster kann nicht direkt zugegriffen werden. Aus diesem Grund werden Sprungfelder bereitgestellt, in denen der Operator die Tools ausführen kann. Es gibt ein separates Subnetz für die Sprungfelder.
Diese Sprungfelder müssen jedoch auch vor unbefugtem Zugriff geschützt werden. Der direkte Zugriff auf Sprungfelder durch Öffnen von RDP/SSH-Ports sollte vermieden werden. Azure Bastion wird zu diesem Zweck empfohlen und erfordert ein dediziertes Subnetz in diesem virtuellen Netzwerk.
Vorsicht
Die Konnektivität über Azure Bastion und Sprungfelder kann sich auf die Produktivität der Entwickler auswirken, z. B. das Ausführen von Debuggingtools, erfordert zusätzlichen Prozess. Beachten Sie diese Auswirkungen, bevor Sie sich entscheiden, die Sicherheit für Ihre unternehmenskritische Arbeitsauslastung zu härten.
Sie können den Zugriff auf das Sprungfeld-Subnetz weiter einschränken, indem Sie eine NSG verwenden, die nur eingehenden Datenverkehr vom Bastion-Subnetz über SSH zulässt.
Bereitstellungsvorgänge
Zum Erstellen von Bereitstellungspipelines müssen Sie zusätzliche Compute bereitstellen, um Build-Agents auszuführen. Diese Ressourcen wirken sich nicht direkt auf die Laufzeitverfügbarkeit der Workload aus, aber ein Zuverlässigkeitsfehler kann die Fähigkeit zum Bereitstellen oder Dienst Ihrer unternehmenskritischen Umgebung gefährden. Daher sollten Zuverlässigkeitsfeatures auf diese Ressourcen erweitert werden.
Diese Architektur verwendet Skalierungssätze für virtuelle Computer sowohl für Build-Agents als auch Sprungfelder (im Gegensatz zu einzelnen VMs). Darüber hinaus wird die Netzwerksegmentierung über die Verwendung von Subnetzen bereitgestellt. Ingress ist auf Azure DevOps beschränkt.
Kostenaspekte
Es gibt erhebliche Auswirkungen auf die Kosten für unternehmenskritische Workloads. In dieser Architektur führen Technologieentscheidungen wie die Verwendung der Azure Front Door Premium-SKU und die Bereitstellung von Azure Firewall in jedem Stempel zu höheren Kosten. Es gibt auch zusätzliche Kosten im Zusammenhang mit Wartungs- und Betriebsressourcen. Solche Kompromisse müssen sorgfältig berücksichtigt werden, bevor eine netzwerkgesteuerte Version der Basisarchitektur verwendet wird.
Bereitstellen dieser Architektur
Die Vernetzungsaspekte dieser Architektur werden in der mission-critical Connected-Implementierung implementiert.
Hinweis
Die connected-Implementierung soll eine unternehmenskritische Workload veranschaulichen, die auf Organisationsressourcen basiert, in andere Workloads integriert und gemeinsame Dienste verwendet. Sie baut auf dieser Architektur auf und verwendet die in diesem Artikel beschriebenen Netzwerksteuerelemente. Das Szenario "Verbunden" geht jedoch davon aus, dass das virtuelle private Netzwerk oder die Azure Private DNS-Zone bereits innerhalb des Azure-Angebots für Die Zielzonen-Konnektivitätsabonnement vorhanden ist.
Nächste Schritte
Ausführliche Informationen zu den in dieser Architektur getroffenen Designentscheidungen erhalten Sie im Entwurfsbereich für Netzwerk- und Konnektivitätsdesigns für unternehmenskritische Workloads in Azure Well-architected Framework.
Verwandte Ressourcen
Eine Produktdokumentation zu den in dieser Architektur verwendeten Azure-Diensten finden Sie in den folgenden Artikeln.