Diese Architektur bietet einen Leitfaden für die Entwicklung einer unternehmenskritischen Workload, die über strenge Netzwerksteuerungen verfügt, um unbefugten öffentlichen Zugriff aus dem Internet auf die Workloadressourcen zu verhindern. Die Absicht ist, Angriffsvektoren auf der Netzwerkebene zu stoppen, sodass die allgemeine Zuverlässigkeit des Systems nicht beeinträchtigt wird. So kann z. B. ein DDoS-Angriff (Distributed Denial of Service), wenn er unkontrolliert bleibt, dazu führen, dass eine Ressource nicht mehr verfügbar ist, da sie mit unzulässigem Datenverkehr überschwemmt wird.
Sie erstellt die unternehmenskritische Baselinearchitektur, die auf die Maximierung der Zuverlässigkeit und betrieblichen Effektivität ohne Netzwerksteuerungen ausgerichtet ist. Diese Architektur fügt Features hinzu, um Eingangs- und Ausgangspfade mithilfe der entsprechenden cloudnativen Funktionen einzuschränken, z. B. Azure Virtual Network (VNet) und private Endpunkte, Azure Private Link, Zone mit privatem Azure-DNS und andere.
Es wird empfohlen, dass Sie sich mit den Grundwerten vertraut machen, bevor Sie mit diesem Artikel fortfahren.
Wichtige Entwurfsstrategien
Die Entwurfsstrategien für die unternehmenskritische Baseline gelten auch in diesem Anwendungsfall. Im Folgenden finden Sie zusätzliche Überlegungen zum Netzwerk für diese Architektur:
Steuern des eingehenden Datenverkehrs
Die eingehende Kommunikation in das virtuelle Netzwerk muss eingeschränkt werden, um böswillige Angriffe zu verhindern.
Wenden Sie die Funktionen der Web Application Firewall (WAF) auf globaler Ebene an, um Angriffe am Netzwerkrand und damit näher an der Angriffsquelle zu stoppen.
Beseitigen der öffentlichen Konnektivität zu Azure-Diensten Eine Möglichkeit besteht darin, private Endpunkte zu verwenden.
Überprüfen des Datenverkehrs, bevor er in das Netzwerk gelangt Netzwerksicherheitsgruppen (NSGs) in Subnetzen helfen, den Datenverkehr zu filtern, indem sie den Fluss zu den konfigurierten IP-Adressen und Ports zulassen oder verweigern. Diese Ebene der Kontrolle hilft auch bei der präzisen Protokollierung.
Steuern des ausgehenden Datenverkehrs
Der Datenverkehr aus einem virtuellen Netzwerk zu Entitäten außerhalb dieses Netzwerks muss eingeschränkt werden. Fehlende Kontrollen können zu Datenexfiltrationsangriffen durch böswillige Dienste Dritter führen.
Einschränken des ausgehenden Datenverkehrs ins Internet mithilfe von Azure Firewall Die Firewall kann den Datenverkehr präzise filtern, indem sie vollqualifizierte Domänennamen (FQDN) verwendet.
Austarieren von Kompromissen mit der Sicherheit
Wenn Sicherheitsfeatures zu einer Workloadarchitektur hinzugefügt werden, gibt es erhebliche Kompromisse. Sie werden möglicherweise Auswirkungen auf die Leistung, die betriebliche Flexibilität und sogar die Zuverlässigkeit feststellen. Angriffe wie Denial-Of-Service (DDoS), Dateneinbrüche und andere können jedoch die allgemeine Zuverlässigkeit des Systems beeinträchtigen und schließlich zur Nichtverfügbarkeit führen.
Die Strategien basieren auf den allgemeinen Richtlinien, die für unternehmenskritische Workloads in wohlstrukturierten unternehmenskritischen Workloads bereitgestellt werden. Wir empfehlen Ihnen, sich im Entwurfsbereich von Netzwerk und Konnektivität nach Empfehlungen und bewährten Methoden umzusehen, wenn Sie Ihre eigene unternehmenskritische Architektur definieren.
Aufbau
Laden Sie eine Visio-Datei dieser Architektur herunter.
Die Komponenten dieser Architektur können auf diese Weise weitgehend kategorisiert werden. Eine Produktdokumentation zu Azure-Diensten finden Sie unter Zugehörige Ressourcen.
Globale Ressourcen
Die globalen Ressourcen sind persistent und während der gesamten Lebensdauer des Systems verfügbar. Sie können im Kontext eines Bereitstellungsmodells für mehrere Regionen global verfügbar gemacht werden. Weitere Informationen finden Sie unter der Globale Ressourcen.
Azure Front Door Premium SKU wird als globaler Lastenausgleich für die zuverlässige Weiterleitung des Datenverkehrs zu den regionalen Bereitstellungen verwendet, die über private Endpunkte zugänglich sind.
Weitere Informationen finden Sie unter Unternehmenskritische Well-Architected Framework-Workloads: Globales Datenverkehrsrouting.
Azure Cosmos DB for NoSQL wird weiterhin verwendet, um den Status außerhalb des Computeclusters zu speichern und verfügt über grundlegende Konfigurationseinstellungen für Zuverlässigkeit. Der Zugriff ist auf autorisierte private Endpunktverbindungen beschränkt.
Weitere Informationen finden Sie unter Unternehmenskritische Well-Architected Framework-Workloads: Global verteilter Datenspeicher für mehrere Schreibvorgänge.
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 Unternehmenskritische Well-Architected Framework-Workloads: Containerregistrierung.
Regionale Ressourcen
Die regionalen Ressourcen werden als Teil eines Bereitstellungsstempels in einer einzelnen Azure-Region bereitgestellt. Sie sind kurzlebig und bieten mehr Resilienz, Skalierbarkeit und Nähe zu den Benutzern. Diese Ressourcen sind von Ressourcen in anderen Regionen unabhängig. Sie können unabhängig voneinander entfernt oder in andere Regionen repliziert werden. Sie geben untereinander jedoch globale Ressourcen füreinander frei. Weitere Informationen finden Sie unter Regionale Stempelressourcen.
Eine statische Website in einem Azure Storage-Konto hostet eine Single-Page-Webanwendung (SPA), die Anforderungen an Back-End-Dienste sendet. Diese Komponente hat dieselbe Konfiguration wie das Baseline-Front-End. Der Zugriff ist auf autorisierte private Endpunktverbindungen beschränkt.
Azure Virtual Network-Instanzen bieten sichere Umgebungen zum Ausführen der Workload und der Verwaltungsvorgänge.
Der interne Lastenausgleich ist der Ursprung der Anwendung. Front Door verwendet diesen Ursprung, um mithilfe von Private Link eine private und direkte Verbindung mit dem Back-End herzustellen.
Azure Kubernetes Service (AKS) ist der Orchestrator für den Back-End-Compute, der eine Anwendung ausführt und zustandslos ist. Der AKS-Cluster wird als privater Cluster bereitgestellt. Somit wird der Kubernetes-API-Server nicht dem öffentlichen Internet ausgesetzt. Der Zugriff auf den API-Server ist auf ein privates Netzwerk beschränkt. Weitere Informationen finden Sie im Artikel Computecluster dieser Architektur.
Weitere Informationen finden Sie unter Unternehmenskritische Well-Architected Framework-Workloads: Containerorchestrierung und Kubernetes.
Azure Firewall überprüft und schützt den gesamten ausgehenden Datenverkehr von den Azure Virtual Network-Ressourcen.
Azure Event Hubs wird als Nachrichtenbroker verwendet. Der Zugriff ist auf autorisierte private Endpunktverbindungen beschränkt.
Weitere Informationen finden Sie unter Unternehmenskritische Well-Architected Framework-Workloads: Lose gekoppelte, ereignisgesteuerte Architektur.
Azure Key Vault wird als regionaler Geheimnisspeicher verwendet. Der Zugriff ist auf autorisierte private Endpunktverbindungen beschränkt.
Weitere Informationen finden Sie unter Unternehmenskritische Well-Architected Framework-Workloads: Datenintegritätsschutz.
Pipelineressourcen der Bereitstellung
Build- und Releasepipelines für eine unternehmenskritische Anwendung müssen vollständig automatisiert sein, um eine konsistente Bereitstellung eines überprüften Stempels zu gewährleisten.
GitHub wird als hochverfügbare Git-basierte Plattform immer noch für die Quellcodeverwaltung verwendet.
Azure Pipelines wird 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 Unternehmenskritische Well-Architected Framework-Workloads: DevOps-Prozesse.
Selbstgehostete Azure DevOps-Build-Agent-Pools werden verwendet, um mehr Kontrolle über die Builds und Bereitstellungen zu haben. Dieses Maß an Autonomie ist erforderlich, da der Computecluster und alle PaaS-Ressourcen privat sind, was eine Integration auf Netzwerkebene erfordert, die bei von Microsoft gehosteten Build-Agents nicht möglich ist.
Beobachtungsressourcen
Überwachungsdaten für globale und regionale Ressourcen werden unabhängig voneinander gespeichert. Ein einzelner, zentralisierter Speicher für Beobachtungsdaten wird nicht empfohlen, um einen Single Point of Failure zu vermeiden. Weitere Informationen finden Sie unter Beobachtungsressourcen.
Azure Log Analytics wird als einheitliche Senke zum Speichern von Protokollen und Metriken für Anwendungs- und Infrastrukturkomponenten verwendet.
Azure Application Insights wird als APM-Tool (Application Performance Management) zum Sammeln aller Anwendungsüberwachungsdaten und deren Speicherung in Log Analytics genutzt.
Weitere Informationen finden Sie unter Unternehmenskritische Well-Architected Framework-Workloads: Vorhersageaktionen und KI-Vorgänge.
Verwaltungsressourcen
Eine wesentliche Designänderung gegenüber der Baselinearchitektur ist der Computecluster. In diesem Entwurf ist der AKS-Cluster privat. Für diese Änderung müssen zusätzliche Ressourcen bereitgestellt werden, um Zugriff zu erhalten.
Azure Virtual Machine Scale Sets für die privaten Build-Agents und Jumpbox-Instanzen, um Tools für den Cluster auszuführen, z. B. kubectl.
Azure Bastion bietet sicheren Zugriff auf die Jumpbox-VMs und beseitigt die Notwendigkeit, dass die VMs über öffentliche IP-Adressen verfügen.
Private Endpunkte für PaaS-Dienste
Um Geschäfts- oder Bereitstellungsvorgänge zu verarbeiten, müssen die Anwendung und die Erstellungs-Agents mehrere Azure PaaS-Dienste erreichen, die global, innerhalb der Region und sogar innerhalb des Stempels bereitgestellt werden. In der Baselinearchitektur erfolgt diese Kommunikation über die öffentlichen Endpunkte der Dienste.
In diesem Entwurf wurden diese Dienste mit privaten Endpunkten geschützt, um sie vom öffentlichen Zugriff auf das Internet zu entfernen. Dieser Ansatz reduziert die gesamte Angriffsfläche, um direkte Manipulationen von Diensten aus unerwarteten Quellen zu entschärfen. Dies führt jedoch eine weitere potenzielle Fehlerquelle ein und erhöht die Komplexität. Wägen Sie sorgfältig die Kompromisse mit der Sicherheit ab, bevor Sie sich für diesen Ansatz entscheiden.
Private Endpunkte sollten in einem eigenen Subnetz des virtuellen Netzwerks des Stempels untergebracht werden. Die privaten IP-Adressen für die privaten Endpunkte werden aus diesem Subnetz zugewiesen. Im Wesentlichen kann jede Ressource im virtuellen Netzwerk mit dem Dienst kommunizieren, indem sie die private IP-Adresse erreicht. Vergewissern Sie sich, dass der Adressraum groß genug ist, um alle privaten Endpunkte unterzubringen, die für diesen Stempel erforderlich sind.
Um eine Verbindung über einen privaten Endpunkt herzustellen, benötigen Sie einen DNS-Eintrag. Es wird empfohlen, die den Diensten zugeordneten DNS-Einträge in privaten Azure DNS-Zonen aufzubewahren, 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, Speicherressourcen und Event Hubs konfiguriert. Außerdem wird der AKS-Cluster als privater Cluster bereitgestellt, wodurch ein privater Endpunkt für den Kubernetes API-Dienst im Netzwerk des Clusters erstellt wird.
In diesem Entwurf werden zwei virtuelle Netzwerke bereitgestellt, die beide über dedizierte Subnetze verfügen, in denen private Endpunkte für all diese Dienste untergebracht sind. Das Layout des Netzwerks ist in Layout des virtuellen Netzwerks beschrieben.
Wenn Sie der Architektur weitere Komponenten hinzufügen, sollten Sie weitere private Endpunkte hinzufügen. Sie können z. B. Einschränkungen zu den Beobachtungsressourcen hinzufügen. Sowohl Azure Log Analytics als auch Azure Application Insights unterstützen die Verwendung von privaten Endpunkten. Weitere Informationen finden Sie unter Verwenden von Azure Private Link zum Verbinden von Netzwerken mit Azure Monitor.
Sie können im gleichen oder in verschiedenen Subnetzen 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 weiterhin mithilfe von Netzwerksicherheitsgruppen im Subnetz.
Privater Eingang
Die Azure Front Door Premium SKU wird als globaler Einstiegspunkt für den gesamten eingehenden Datenverkehr des Clients verwendet. Es verwendet die Funktionen der Web Application Firewall (WAF), um den Datenverkehr am Netzwerkedge zuzulassen oder zu verweigern. Die konfigurierten WAF-Regeln verhindern Angriffe, noch bevor sie in die virtuellen Stempelnetzwerke gelangen.
Diese Architektur nutzt auch die Fähigkeit von Front Door, Azure Private Link für den Zugriff auf den Ursprung der Anwendung zu verwenden, ohne öffentliche IP-Adressen/Endpunkte auf den Back-Ends zu verwenden. Dies erfordert einen internen Lastenausgleich im virtuellen Stempelnetzwerk. Diese Ressource ist dem Kubernetes-Eingangscontroller vorgelagert, der im Cluster ausgeführt wird. Zusätzlich zu diesem privaten Lastenausgleich wird von AKS ein Private Link-Dienst erstellt, der für die private Verbindung von Front Door verwendet wird.
Nachdem die Verbindung hergestellt ist, haben private Endpunkte im Front Door-Netzwerk über Private Link eine direkte Verbindung mit dem Lastenausgleich und der statischen Website im Stempelnetzwerk.
Weitere Informationen hierzu finden Sie unter Funktionsweise von Private Link.
Weitere Informationen finden Sie unter Unternehmenskritische Well-Architected Framework-Workloads: Anwendungsbereitstellungsdienste.
Eingeschränkter Ausgang
Anwendungen benötigen möglicherweise eine ausgehende Internetverbindung. Die Kontrolle dieses Datenverkehrs bietet eine Möglichkeit, den ausgehenden Datenverkehr zu begrenzen, zu überwachen und zu beschränken. Andernfalls könnte ein unerwarteter Zugriff von innen nach außen zu einer Gefährdung und möglicherweise zu einem unzuverlässigen Systemzustand führen. Der eingeschränkte ausgehende Datenverkehr kann auch andere Sicherheitsbedenken ausräumen, z. B. die Datenexfiltration.
Mithilfe von Firewalls und Netzwerksicherheitsgruppen (NSGs) können Sie sicherstellen, dass der von der Anwendung ausgehende Datenverkehr überprüft und protokolliert wird.
In dieser Architektur ist Azure Firewall der einzige Ausgangspunkt und wird verwendet, um den gesamten ausgehenden Datenverkehr zu überprüfen, der vom virtuellen Netzwerk ausgeht. Benutzerdefinierte Routen (UDRs) werden in Subnetzen verwendet, die in der Lage sind, Datenverkehr zu generieren, 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).
Layout des virtuellen Netzwerk
Isolieren Sie regionale Ressourcen und Verwaltungsressourcen in separaten virtuellen Netzwerken. Sie haben unterschiedliche Eigenschaften, Zwecke und Sicherheitsaspekte.
Art des Datenverkehrs: Regionale Ressourcen, die an der Verarbeitung von Geschäftsvorgängen beteiligt sind, benötigen höhere Sicherheitskontrollen. So muss z. B. der Computecluster vor direktem Datenverkehr aus dem Internet geschützt werden. Die Verwaltungsressourcen werden nur für den Zugriff auf die regionalen Ressourcen für den Betrieb bereitgestellt.
Lebensdauer: Die erwartete Lebensdauer dieser Ressourcen ist ebenfalls unterschiedlich. Regionale Ressourcen sind voraussichtlich kurzlebig (ephemer). Sie werden als Teil des Bereitstellungsstempels erstellt und zerstört, wenn der Stempel abgebaut wird. Die Verwaltungsressourcen haben dieselbe Lebensdauer wie die Region und eine längere als die Stempelressourcen.
In dieser Architektur gibt es zwei virtuelle Netzwerke: das Stempelnetzwerk und das Betriebsnetzwerk. Sorgen Sie für die weitere Isolation innerhalb der einzelnen virtuellen Netzwerke mithilfe von Subnetzen und Netzwerksicherheitsgruppen (NSGs), um die Kommunikation zwischen den Subnetzen zu sichern.
Weitere Informationen finden Sie unter Unternehmenskritische Well-Architected Framework-Workloads: Isolierte virtuelle Netzwerke.
Regionales virtuelles Stempelnetzwerk
Der Bereitstellungsstempel stellt ein virtuelles Netzwerk in jeder Region bereit.
Das virtuelle Netzwerk ist in diese Hauptsubnetze unterteilt. Alle Subnetze verfügen über zugewiesene Netzwerksicherheitsgruppen (NSGs), die jeden nicht autorisierten Zugriff aus dem virtuellen Netzwerk blockieren. NSGs beschränken den Datenverkehr zwischen dem Subnetz der Anwendung und anderen Komponenten des Netzwerks.
Anwendungssubnetz
Die AKS-Clusterknotenpools sind in einem Subnetz isoliert. Wenn Sie den Systemknotenpool weiter vom Workerknotenpool isolieren möchten, können Sie diese in getrennten Subnetzen unterbringen.
Stempeleingangssubnetz
Der Einstiegspunkt für jeden Stempel ist ein interner Azure Load Balancer Standard, der sich in einem dedizierten Subnetz befindet. Der Private Link-Dienst, der für die private Verbindung von Front Door verwendet wird, wird ebenfalls hier platziert.
Beide Ressourcen werden im Rahmen der Bereitstellung des Stempels bereitgestellt.
Stempelausgangssubnetz
Azure Firewall befindet sich in einem separaten Subnetz und überprüft den ausgehenden Datenverkehr aus dem Anwendungssubnetz mithilfe einer benutzerdefinierten Route (UDR).
Subnetz privater Endpunkte
Das Anwendungssubnetz erfordert Zugriff auf die PaaS-Dienste im regionalen Stempel, Key Vault und andere. 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. Daher wird ein weiteres Subnetz für diese Endpunkte erstellt. Der eingehende Zugriff auf dieses Subnetz wird durch eine NSG gesichert, die nur Datenverkehr von der Anwendung zulässt.
Sie können eine weitere Einschränkung vornehmen, indem Sie UDR-Unterstützung für private Endpunkte verwenden, sodass dieser Datenverkehr auch durch das Stempelausgangssubnetz ausgehen kann.
Virtuelles Betriebsnetzwerk
Der Betriebsdatenverkehr wird in einem separaten virtuellen Netzwerk isoliert. Da der API-Dienst des AKS-Clusters in dieser Architektur privat ist, muss der gesamte Datenverkehr für die Bereitstellung und den Betrieb auch von privaten Ressourcen wie selbstgehosteten Build-Agents und Jumpbox-Instanzen ausgehen. Diese Ressourcen werden in einem separaten virtuellen Netzwerk bereitgestellt, das über eine direkte Verbindung mit den Anwendungsressourcen über seinen eigenen Satz von privaten Endpunkten verfügt. Die Build-Agents und Jumpbox-Instanzen befinden sich in separaten Subnetzen.
Anstatt private Endpunkte zu verwenden, können Sie auch das Peering virtueller Netzwerke verwenden. Peering führt jedoch zu einer zusätzlichen Komplexität, die schwer zu verwalten sein kann, insbesondere wenn virtuelle Netzwerke kurzlebig sein sollen.
Sowohl die Build-Agents (als auch optionale Jumpbox-Instanzen) müssen auf PaaS-Dienste zugreifen, die sich global und innerhalb des regionalen Stempels befinden. Ähnlich wie beim regionalen virtuellen Stempelnetzwerk wird ein dediziertes Subnetz für die privaten Endpunkte der benötigten PaaS-Dienste erstellt. Die NSG in diesem Subnetz stellt sicher, dass der eingehende Datenverkehr nur von den Subnetzen für die Verwaltung und Bereitstellung zugelassen wird.
Verwaltungsvorgänge
Ein typischer Anwendungsfall ist, wenn ein Betreiber 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 sind Jumpbox-Instanzen vorgesehen, in denen der Operator die Tools ausführen kann. Für die Jumpbox-Instanzen gibt es ein eigenes Subnetz.
Aber auch diese Jumpbox-Instanzen müssen vor unbefugtem Zugriff geschützt werden. Ein direkter Zugriff auf Jumpbox-Instanzen durch Öffnen von RDP/SSH-Ports sollte vermieden werden. Azure Bastion wird für diesen Zweck empfohlen und erfordert ein dediziertes Subnetz in diesem virtuellen Netzwerk.
Achtung
Die Konnektivität über Azure Bastion und Jumpbox-Instanzen kann sich auf die Produktivität von Entwicklern auswirken, da das Ausführen von Debugtools zusätzliche Prozesse erfordert. Seien Sie sich dieser Auswirkungen bewusst, bevor Sie sich entscheiden, die Sicherheit für Ihre unternehmenskritische Workload zu erhöhen.
Sie können den Zugriff auf das Jumpbox-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-Instanzen bereitstellen, um Build-Agents auszuführen. Diese Ressourcen wirken sich nicht direkt auf die Verfügbarkeit der Workload zur Laufzeit aus, aber ein Fehler bei der Zuverlässigkeit kann die Bereitstellung oder den Dienst Ihrer unternehmenskritischen Umgebung gefährden. Daher sollten die Zuverlässigkeitsfeatures auf diese Ressourcen ausgeweitet werden.
Diese Architektur verwendet VM-Skalierungsgruppen sowohl für Build-Agents als auch für Jumpbox-Instanzen (im Gegensatz zu einzelnen virtuellen Computern). Außerdem wird die Segmentierung des Netzwerks durch die Verwendung von Subnetzen gewährleistet. Der Eingang ist auf Azure DevOps beschränkt.
Kostenbetrachtung
Die Kosten für unternehmenskritische Workloads wirken sich erheblich aus. In dieser Architektur führen Technologieentscheidungen wie die Verwendung von Azure Front Door Premium SKU und die Bereitstellung von Azure Firewall in jedem Stempel zu höheren Kosten. Außerdem fallen zusätzliche Kosten für Wartung und Betriebsmittel an. Solche Kompromisse müssen sorgfältig abgewogen werden, bevor eine netzwerkgesteuerte Version der Baselinearchitektur eingeführt wird.
Bereitstellen dieser Architektur
Die Netzwerkaspekte dieser Architektur werden in der Implementierung „Unternehmenskritische Verbindung“ umgesetzt.
Hinweis
Die Implementierung vom Typ „Verbindung“ soll eine unternehmenskritische Workload veranschaulichen, die auf organisatorische Ressourcen angewiesen ist, mit anderen Workloads integriert wird und freigegebene Dienste verwendet. Sie baut auf dieser Architektur auf und verwendet die in diesem Artikel beschriebenen Netzwerksteuerungen. Das Szenario für den Typ „Verbindung“ geht jedoch davon aus, dass ein virtuelles privates Netzwerk oder eine private Azure DNS-Zone bereits innerhalb des Abonnements für die Azure-Zielzonenkonnektivität existiert.
Nächste Schritte
Einzelheiten zu den Entscheidungen hinsichtlich des Entwurfs, die in dieser Architektur getroffen wurden, finden Sie im Bereich zum Netzwerk- und Konnektivitätsentwurf für unternehmenskritische Workloads in Azure Well-Architected Framework.
Zugehörige Ressourcen
Eine Produktdokumentation zu den in dieser Architektur verwendeten Azure-Diensten finden Sie in den folgenden Artikeln.