Azure virtuelle Netzwerke und Subnetze

Azure virtuellen Netzwerke (VNets) und Subnetze sind die grundlegenden Bausteine jedes Azure Netzwerks. In diesem Artikel wird erläutert, wie VNets Isolation bereitstellen, wie Subnetze Ressourcen organisieren und wie Sie Ihr Netzwerk für Produktionsworkloads anpassen und strukturieren.

Inhalt dieses Artikels

In diesem Artikel werden VNet-Isolationsgrenzen, Subnetzgröße und reservierte Adressen, dedizierte Plattformsubnetze für Dienste wie Azure Firewall und Anwendungsgateway, VNet-Peering und allgemeine Netzwerklayoutmuster behandelt.

Wer diesen Artikel benötigt

Lesen Sie diesen Artikel, wenn Sie:

  • Sie stellen Ihre erste Workload in Azure bereit und müssen verstehen, wie Netzwerke funktionieren, bevor Sie Ressourcen erstellen.
  • Planen Sie eine Umgebung mit mehreren Workloads und müssen entscheiden, wie viele VNets und Subnetze Sie erstellen sollten.
  • Sie migrieren On-Premises-Workloads zu Azure und müssen verstehen, wie sich Azure-Netzwerke von physischen Netzwerken unterscheiden.
  • Subnetze für Azure-Plattformdienste wie Azure Firewall, VPN Gateway oder Azure Kubernetes Service (AKS) korrekt dimensionieren.
  • Möchten Sie verstehen, wann Workloads in verschiedene VNets getrennt werden sollen, anstatt sie im selben VNet zu behalten.

Heben und Verschieben des Fokus: Spiegeln Sie die lokale Subnetzsegmentierung in Azure. Ordnen Sie vorhandene VLANs und Sicherheitszonen Subnetzen zu, richten Sie die Adressräume an den Adressbereichen aus, die Ihr Team bereits betreibt, und dimensionieren Sie Subnetze großzügig, damit Sie während der Migration nicht neu adressieren müssen.

Modernisieren Sie den Fokus: Entwerfen Sie Subnetze rund um Plattformdienste und Automatisierung. Dimensionieren Sie Subnetze passend für AKS, private Endpunkte und dedizierte Plattformdienste, und berücksichtigen Sie den Azure Virtual Network Manager, um eine konsistente Konfiguration über viele VNets hinweg anzuwenden.

Cloud-übergreifender Fokus: Planen Sie einen sich nicht überschneidenden Adressraum für Azure, AWS und Google Cloud, bevor Sie ein VNet erstellen. Reservieren Sie CIDR-Bereiche, die sich nicht mit vorhandenen VPCs überschneiden, damit Sie Cloud-Umgebungen per Peering oder über VPN ohne NAT verbinden können.

Azure Dienste und Features

Die folgenden Dienste und Features bilden die Grundlage für virtuelle Netzwerke in Azure:

Dienst oder Feature Was es bietet Wann wird es verwendet?
Azure Virtual Network (VNet) Ein isoliertes, privates Netzwerk in Azure. Alle Azure-Netzwerke beginnen hier. Ressourcen im selben VNet können standardmäßig kommunizieren; Ressourcen in verschiedenen VNets können nur kommunizieren, wenn Sie sie explizit verbinden. Immer: Jede Workload, die Netzwerkkonnektivität benötigt, erfordert ein VNet.
Subnet Eine Partition des VNet-Adressraums. Subnetze sind der Geltungsbereich für die Zuordnung von Netzwerksicherheitsgruppen (NSGs) und Routentabellen. Immer: Organisieren Sie Workloadkomponenten nach Funktion oder Sicherheitsgrenze in Subnetze.
VNet-Peering Geringe Latenz, private Konnektivität zwischen zwei VNets in derselben Region oder regionenübergreifend. Der Datenverkehr bleibt auf dem Microsoft Backbone. Peering ist nicht transitiv; Bei jedem Peering handelt es sich um einen direkten Link. Wenn Ressourcen in separaten VNets kommunizieren müssen. Informationen zum regionsübergreifenden Peering finden Sie unter "Regionsübergreifende Konnektivität".
Subnetz-Peering (Vorschau) Peering zwischen bestimmten Subnetzen und nicht zwischen ganzen VNets. Bietet eine präzise Kontrolle darüber, welche Subnetze an Peeringbeziehungen teilnehmen. Wenn Sie eine differenzierte Peeringsteuerung zwischen bestimmten Subnetzen in verschiedenen VNets benötigen. Weitere Informationen finden Sie im Abschnitt "Einschränkungen ".
Route-Tabelle /Benutzerdefinierte Routen (UDRs) Überschreiben Sie standardsystemrouten in Azure, um zu steuern, wo Datenverkehr gesendet wird. Auf Subnetzebene angewendet. Wenn Sie den Datenverkehr über eine Firewall oder eine virtuelle Netzwerk-Appliance (NVA) erzwingen müssen. Erforderlich für Hub-and-Spoke-Ausgangskontrolle. Siehe Azure Firewall Design- und Hub-and-Spoke-Topologie.
Azure Virtual Network Manager (AVNM) Netzwerkkonfigurationen für VNets abonnementübergreifend zentral erstellen, verwalten und anwenden. Beim Verwalten vieler VNets über mehrere Abonnements hinweg. Siehe zentrale Netzwerkverwaltung.

Diagramm, das VNet mit Workload-Subnetzen für Web-, App- und Datenebenen zusammen mit dedizierten Plattformsubnetzen für Gateway, Firewall und Bastion zeigt

Wie man auswählt

Was ist ein virtuelles Netzwerk?

Ein virtuelles Netzwerk (VNet) ist ein softwaredefiniertes, isoliertes Netzwerk in Azure. Stellen Sie sich dies als Ihr privates Netzwerk in Azure vor. Im Gegensatz zu einem physischen Netzwerk, das Kabel, Switches und Router verwendet, ist ein VNet vollständig softwaredefiniert. Sie erstellen es, weisen sie einem Adressraum zu und stellen Ressourcen darin bereit.

Wichtige Merkmale:

  • Regionenbezogen: Ein VNet existiert in einer einzelnen Azure-Region. Alle Ressourcen in diesem VNet müssen sich in derselben Region befinden. Ein VNet umfasst Verfügbarkeitszonen innerhalb dieser Region.
  • Isolation standardmäßig: Ressourcen in einem VNet können nicht mit Ressourcen in einem anderen VNet kommunizieren, es sei denn, Sie erstellen explizit eine Verbindung (Peering oder VPN).
  • Standardmäßige interne Konnektivität: Ressourcen innerhalb desselben VNet können standardmäßig über Systemrouten kommunizieren, die Azure bereitstellt.

Was ist ein Subnetz?

Ein Subnetz ist ein Bereich von IP-Adressen innerhalb Ihres VNet. Subnetze ermöglichen Folgendes:

  • Segmentieren Sie Ihr Netzwerk nach Workloadkomponente (z. B. Webebene, Anwendungsebene, Datenebene).
  • Sicherheitsregeln anwenden: NSGs werden auf Subnetzebene angewendet, um den Datenverkehr zu filtern.
  • Routing steuern: Routingtabellen werden dem Subnetz zugewiesen, um den Datenverkehr zu lenken.

Azure reserviert fünf IP-Adressen in jedem Subnetz: die ersten vier Adressen und die letzte Adresse. Beispielsweise können in einem /24-Subnetz (256 Adressen) nur 251 verwendet werden. Berücksichtigen Sie diese Reserve bei Ihren Dimensionierungsberechnungen.

Beispiel: Anwendung mit drei Ebenen

Eine typische dreistufige Webanwendung verwendet drei Subnetze, um Bedenken zu trennen und unterschiedliche Sicherheitsregeln anzuwenden:

Subnet CIDR-Bereich Purpose Beispielressourcen
web-subnet 10.0.1.0/24 Front-End-Webserver, die eingehenden HTTP/HTTPS-Datenverkehr vom Internet oder Anwendungsgateway akzeptieren Azure App Service-Umgebung, mit NGINX ausgeführte Virtual Machine Scale Sets
app-subnet 10.0.2.0/24 Anwendungslogik der mittleren Ebene. Akzeptiert nur Datenverkehr aus dem Websubnetz. Azure Functions (VNet-integriert), VMs mit Geschäftslogik
data-subnet 10.0.3.0/24 Datenspeicher. Akzeptiert nur Datenverkehr aus dem App-Subnetz. Kein direkter Internetzugang. Azure SQL Managed Instance, private Endpunkte für Azure SQL-Datenbank oder Cosmos DB

Mit diesem Layout können Sie eine NSG auf jedes Subnetz anwenden, das den Datenverkehr nur auf die Anforderungen dieser Ebene beschränkt. Das Websubnetz ermöglicht eingehendes HTTPS (Port 443). Das App-Subnetz ermöglicht eingehenden Datenverkehr nur aus dem IP-Bereich des Websubnetz. Das Datensubnetz ermöglicht eingehenden Datenverkehr nur aus dem IP-Bereich des App-Subnetzes.

Bei einem AKS-basierten Modernisierungsmuster können Sie ein aks-nodes Subnetz wie 10.0.4.0/24 für die Clusterknotenpools verwenden, wenn Sie Azure CNI-Overlay bereitstellen. In diesem Modell nutzen nur die Knoten VNet-IP-Adressen aus dem Subnetz. Pods verwenden ein separates Overlay-CIDR, wodurch Sie das Knotensubnetz kleiner halten können als bei einem AKS-Design mit flachem Netzwerk.

Allgemeine Muster

Die folgenden Subnetzlayouts decken die am häufigsten verwendeten Azure Bereitstellungsszenarien ab:

Muster Subnetze Wann verwenden?
Einfache Web-App web + data Zweistufige Anwendungen mit einem Front-End und einer Datenbank. Minimale Komplexität.
Dreistufiges Unternehmen web + app + data + management Herkömmliche Unternehmensworkloads mit unterschiedlichen Ebenen und einem Sprungfeld oder Bastion-Subnetz für die Verwaltung.
AKS mit gemeinsamen Diensten aks-nodes + aks-ingress + appgw + shared Kubernetes-Workloads mit einem dedizierten Eingangs-Controller-Subnetz und Application Gateway für WAF.
Hub-and-Spoke-Ausgang AzureFirewallSubnet + GatewaySubnet + AzureBastionSubnet + management Das Hub-VNet in einer Hub-and-Spoke-Topologie. Freigegebene Dienste, über die Spoke-VNets Datenverkehr leiten. Siehe Hub-and-Spoke-Topologie.
Datenarbeitsauslastung compute + data + private-endpoints + management Analyse- und Datenplattform-Workloads, bei denen Private Endpunkte für Speicher und Datenbanken zur klaren IP-Planung ein eigenes Subnetz benötigen.

Wie viele VNets und Subnetze?

Das Leitprinzip ist einfach: Verwenden Sie ein virtuelles Netzwerk pro Anwendung und ein Subnetz pro Komponente (Ebene). Diese Standardkonfiguration hält jede Arbeitslast isoliert, macht den Datenverkehr zwischen den Ebenen mithilfe von Netzwerksicherheitsgruppen einfach steuerbar und bietet Spielraum für Wachstum. Passen Sie von dort aus basierend auf gemeinsamen Diensten, Isolationsanforderungen und Skalierung an.

Verwenden Sie diese Entscheidungstabelle, um Ihre VNet- und Subnetzstrategie zu ermitteln:

Ihre Situation Empfohlener Ansatz
Einzelne Workload, einzelnes Team, keine gemeinsamen Dienste erforderlich Ein VNet mit Subnetzen pro Anwendungskomponente (Web, Anwendungslogik, Daten). Siehe Topologie mit einem einzelnen Workload.
Mehrere unabhängige Workloads, die ein Gateway oder eine Firewall gemeinsam nutzen Hub-VNet für freigegebene Dienste + ein Speichen-VNet pro Workload. Siehe Hub-and-Spoke-Topologie.
Strikte Isolierung zwischen Workloads (Auswirkungsbereich, Compliance-Anforderungen) Ein VNet je Workload ohne Peering zwischen ihnen.
Sehr große Umgebung mit vielen Abonnements und Regionen Azure Virtual WAN mit automatisierter Hubverwaltung. Siehe Virtual WAN Topologie.

Referenz zur Dimensionierung dedizierter Subnetze

Viele Azure Plattformdienste benötigen ein eigenes dediziertes Subnetz mit einem bestimmten Namen und einer mindesten Größe. Das folgende Diagramm zeigt die Benennungsanforderungen und Mindestgrößen für dedizierte Plattformsubnetze:

Diagramm mit minimalen Subnetzgrößen für fünf dedizierte Plattformsubnetze, einschließlich Gateway, Firewall, Bastion und Route Server

Verwenden Sie diese Tabelle, wenn Sie Ihren Adressraum planen:

Azure-Dienst Minimale Subnetzgröße Erforderlicher Subnetzname Hinweise
Azure Firewall /26 (59 verwendbare IPs) AzureFirewallSubnet Erforderlich für alle Firewall-SKUs. Siehe Azure Firewall Entwurf.
VPN Gateway /27 (27 verwendbare IPs) GatewaySubnet Microsoft empfiehlt /27 oder größer, um genügend Skalierungsreserve zu haben.
Azure Bastion /26 (59 verwendbare IPs) AzureBastionSubnet Mindestens /26 für alle Bereitstellungen, die nach November 2021 erstellt wurden.
Application Gateway v2 /24 empfohlen (251 verwendbare IPs) Kein erforderlicher Name Sehr empfohlen /24, um die automatische Skalierung zu berücksichtigen. Das Minimum ist formelbasiert (Instanzen + 5 reserviert + 1 private Frontend-IP).
App-Dienstumgebung /24 (Produktivbetrieb), /23 (maximale Skalierung) Kein erforderlicher Name Die Skalierung verbraucht IPs aus dem Subnetz. Verwenden Sie /23, wenn Sie planen, nahe an die maximale Anzahl von 200 Instanzen heranzuskalieren.
Azure Route Server /26 (59 verwendbare IPs) RouteServerSubnet Erforderlich für den BGP-Routenaustausch mit NVAs.
Azure DNS Private Resolver (privater DNS-Auflösungsdienst) /28 Minimum pro Endpunktsubnetz Dedizierte eingehende und ausgehende Subnetze Erfordert separate Subnetze für eingehende und ausgehende Endpunkte. Kann nicht mit anderen Ressourcen geteilt werden.
AKS (Azure Kubernetes Service) Formelbasiert (CNI-abhängig) Kein erforderlicher Name Siehe die Hinweise zur AKS-Größenbestimmung.

Note

Private Endpunkte nutzen IP-Adressen aus vorhandenen Subnetzen. Sie benötigen kein dediziertes Subnetz. Berücksichtigen Sie diesen IP-Verbrauch in Ihrer Subnetzgröße. Ausführliche IP-Planung finden Sie unter IP-Adressplanung.

AKS-Subnetzgröße

Die Größe des AKS-Subnetz hängt von der CNI-Plug-In-Auswahl (Container Networking Interface) ab. Es gibt keine einzige Mindestgröße:

  • Azure CNI Overlay: Das Subnetz muss nur die Knoten aufnehmen, da Pods einen separaten privaten CIDR-Block (Classless Inter-Domain Routing) verwenden. Ein deutlich kleineres Subnetz ist im Vergleich zu flachen Netzwerken akzeptabel.
  • Azure CNI (flaches Netzwerk):Das Subnetz muss beide Knoten UND Pods enthalten. Formel: (nodes + surge) × (max_pods + 1). Ein /21 oder größer ist für Cluster mit 50 oder mehr Knoten üblich.
  • Kubenet: Nur Knoten nutzen VNet-Subnetz-IPs. Pods rufen clusterinterne IP-Adressen ab.

Informationen zum Skalieren von Formeln pro CNI-Option finden Sie unter Planen der IP-Adressierung für Ihren AKS-Cluster.

Einschränkungen beim Subnetz-Peering

Subnetz-Peering verbindet bestimmte Subnetze zwischen VNets anstelle vollständiger Adressräume. Dieser Ansatz bietet eine präzise Kontrolle darüber, welche Subnetze an Peeringbeziehungen teilnehmen.

Important

Subnetz-Peering befindet sich derzeit in der Vorschau und weist die folgenden Einschränkungen auf:

  • Erfordert, dass ein Abonnement zu einer genehmigten Liste hinzugefügt wird (keine Self-Service-Registrierung)
  • NUR CLI, ARM-Vorlage, Terraform oder PowerShell (keine Portalunterstützung)
  • Intel-basierte V5-SKUs (oder AMD Genoa-/Cobalt 100-basierte SKUs) sind für den Produktionseinsatz erforderlich, um einen bekannten Fehler bei SKUs älterer Generationen zu vermeiden: siehe Konfigurieren von Subnetz-Peering für die aktuellen Hardwareanforderungen
  • Maximum von 200 Subnetzen pro Seite pro Peering-Link
  • Maximal 1.000 Subnetze insgesamt über alle Peeringverbindungen hinweg pro VNet
  • Subnetze müssen zu eindeutigen, nicht überlappenden Adressräumen gehören.

Aktuelle Einschränkungen und Registrierung finden Sie unter Konfigurieren von Subnetz-Peering.

Note

Azure Virtual Network Manager (AVNM) kann Subnetz-Peering nicht von VNet-Peering unterscheiden. Wenn Sie AVNM zum Verwalten von Peeringkonfigurationen verwenden, beachten Sie, dass Peeringbeziehungen auf Subnetzebene als Standard-VNet-Peering in AVNM angezeigt werden.

Überlegungen zum Entwurf

VNet- und Subnetz-Designfokus per Lift & Shift migrieren

  • Erstellen Sie ihre lokale Segmentierung neu: Ordnen Sie jede VLAN- oder Sicherheitszone einem Subnetz zu, damit vorhandene Firewallgrenzen und betriebsinterner Besitz mit minimaler Neugestaltung übernommen werden.
  • Dimensionieren Sie Subnetze mit ausreichender Reserve. Die Neuadressierung nach der Migration ist mit erheblichen Beeinträchtigungen verbunden. Weisen Sie daher größere CIDR-Bereiche zu, als Ihre aktuelle Hostanzahl erfordert, um künftiges Wachstum und die fünf von Azure pro Subnetz reservierten Adressen zu berücksichtigen.
  • Stimmen Sie Azure-Adressräume nach Möglichkeit auf die Adressbereiche in Ihrer lokalen Umgebung ab, um das Routing zu vereinfachen und Überschneidungen zu vermeiden, wenn Sie über VPN Gateway oder ExpressRoute eine Verbindung herstellen.
  • Standardeinstellung für ein VNet pro migrierter Anwendung mit einem Subnetz pro Ebene. Dieses Design spiegelt typische lokale Layouts mit drei Ebenen und sorgt dafür, dass die Verschiebung vorhersagbar bleibt.

Modernisieren des VNet- und Subnetzentwurfsfokus

  • Planen Sie Subnetze zunächst rund um Plattformdienste: dedizierte Subnetze für Azure Firewall, Application Gateway und Bastion sowie korrekt dimensionierte Subnetze für AKS, abhängig von Ihrer CNI-Auswahl.
  • Verwenden Sie Azure CNI Overlay für AKS, um die Knotensubnetze klein zu halten, da Pods ihre IP-Adressen aus einem separaten Overlay-CIDR-Bereich und nicht aus dem Adressraum des VNet beziehen.
  • Reservieren Sie ein dediziertes Subnetz für private Endpunkte, damit der IP-Verbrauch vorhersehbar bleibt, während Sie mehr Azure PaaS-Dienste einführen.
  • Übernehmen Sie Azure Virtual Network Manager frühzeitig, um Netzwerkgruppen, Konnektivität und Sicherheitskonfigurationen konsistent anzuwenden, da ihre VNet-Anzahl über Abonnements hinweg wächst.

Schwerpunkt des cloudübergreifenden VNet- und Subnetzdesigns

  • Richten Sie einen globalen Adressplan ein, bevor Sie ein VNet erstellen. Reservieren Sie für Azure sich nicht überschneidende CIDR-Blöcke, die sich nicht mit vorhandenen AWS-VPCs oder Google-Cloud-VPC-Netzwerken überschneiden. Diese Reservierung ist für ein geroutetes VPN oder ein Interconnect obligatorisch.
  • Ordnen Sie die Netzwerkgrundbausteine jeder Cloud Azure zu: Ein AWS-VPC oder ein Google-Cloud-VPC-Netzwerk entspricht in Azure einem VNet, und Sicherheitsgruppen entsprechen NSGs.
  • Reservieren Sie Subnetzraum für cloudübergreifende Konnektivitätskomponenten, z. B. eine GatewaySubnet für VPN Gateway oder den Hub, der von Azure Virtual WAN verwendet wird, sodass die Transitinfrastruktur über Platz zum Skalieren verfügt.
  • Standardisieren Sie die Subnetzbenennung und -kategorisierung in clouds, damit Betriebsteams gleichwertige Ebenen korrelieren können, wenn sie Probleme mit Multicloud-Datenverkehr beheben.

Prerequisites

Bevor Sie Ihr virtuelles Netzwerk und Ihr Subnetzlayout entwerfen, stellen Sie sicher, dass Sie folgendes haben:

  • Azure Abonnement: Ein aktives Azure-Abonnement mit Berechtigungen zum Erstellen von Netzwerkressourcen (Netzwerkmitwirkenderrolle oder höher).
  • Ressourcengruppe: Eine Ressourcengruppe in Ihrer Zielregion, die VNet-Ressourcen enthält.
  • Regionsentscheidung: Wählen Sie Ihre primäre Azure Region basierend auf der Nähe zu Benutzern, Complianceanforderungen und Dienstverfügbarkeit aus.
  • Adressraumplan: Entscheiden Sie für einen IP-Adressbereich (CIDR-Block), der sich nicht mit Ihren lokalen Netzwerken oder anderen VNets überlappt, die Sie peeren möchten. Anleitungen finden Sie unter IP-Adressplanung .

Sicherheitsüberlegungen

Virtuelle Netzwerke und Subnetze sind Ihre erste Ebene der Netzwerksegmentierung. Wenden Sie die folgenden Sicherheitspraktiken an:

  • Netzwerksicherheitsgruppen (NSGs): Ordnen Sie NSGs jedem Subnetz zu, um eingehenden und ausgehenden Datenverkehr zu filtern. Definieren Sie für die Rolle jedes Subnetzes spezifische Erlaubnisregeln und verweigern Sie standardmäßig sämtlichen anderen Datenverkehr. Ausführliche Anleitungen finden Sie unter Netzwerksicherheitsgruppen und Anwendungssicherheitsgruppen.
  • Erzwungenes Tunneln mit UDRs: Wenn Ihre Complianceanforderungen festlegen, dass der gesamte internetgebundene Datenverkehr über ein lokales Inspektionsgerät oder eine Cloudfirewall durchläuft, verwenden Sie Routentabellen mit benutzerdefinierten Routen, um standardmäßiges Internetrouting außer Kraft zu setzen. Siehe Ausgehende Verbindungen und Egressverbindungen.
  • Subnetzisolation: Platzieren Sie Ressourcen mit unterschiedlichen Vertrauensebenen in separaten Subnetzen. Bewahren Sie beispielsweise Datenbanken in einem Subnetz auf, das nur eingehenden Datenverkehr vom Subnetz der Anwendungsebene zulässt. Durch diese Trennung wird die laterale Bewegung begrenzt, wenn ein Angreifer eine Komponente kompromittiert.
  • Dedizierte Subnetze für Plattformdienste: Viele Azure Plattformdienste (Azure Firewall, Anwendungsgateway, Bastion) werden in dedizierten Subnetzen bereitgestellt. Diese Isolation stellt sicher, dass sich das Routing für Plattformdienste und Sicherheitsregeln nicht auf Ihre Workload-Subnetze auswirken.

NSG und Subnetzinteraktion

Wenn Sie eine NSG einem Subnetz zuordnen, gelten die NSG-Regeln für alle Ressourcen in diesem Subnetz. Verstehen Sie diese Interaktionsverhalten:

  • Kumulative Auswertung: Wenn die NIC eines virtuellen Computers auch über eine NSG verfügt, bewertet Azure sowohl die Subnetzebene NSG als auch die NIC-Ebene NSG. Bei eingehendem Datenverkehr wertet Azure zuerst das Subnetz NSG und dann die NIC NSG aus. Für ausgehenden Datenverkehr wertet Azure zuerst die NIC NSG und dann das Subnetz NSG aus.
  • Standardverweigerung: Azure enthält Standardregeln, die intra-VNet-Datenverkehr und ausgehenden Internetzugriff zulassen. Nachdem Sie benutzerdefinierte Ablehnungsregeln hinzugefügt haben, überprüfen Sie, ob legitimer Netzwerkdatenverkehr (z. B. Integritätstests des Azure Load Balancers von der IP-Adresse 168.63.129.16) nicht versehentlich blockiert wird.
  • Diensttags und ASGs: Verwenden Sie Diensttags (wie AzureLoadBalancer, Internet, VirtualNetwork) und Anwendungssicherheitsgruppen (ASGs) in NSG-Regeln anstelle von unformatierten IP-Adressen. Dieser Ansatz vereinfacht die Regelverwaltung und passt sich automatisch an, wenn sich Azure IP-Bereiche ändern.
  • Ablaufprotokolle zur Sichtbarkeit: Aktivieren Sie NSG-Ablaufprotokolle für alle Subnetzebenen-NSG, um akzeptierten und verweigerten Datenverkehr zu erfassen. Mithilfe von Ablaufprotokollen können Sie überprüfen, ob Sicherheitsregeln wie vorgesehen funktionieren und Nachweise für Complianceüberwachungen bereitstellen. Anweisungen zum Einrichten finden Sie in den NSG-Ablaufprotokollen .

In den folgenden Artikeln des Azure Netzwerkentwurfshandbuchs werden verwandte Themen behandelt:

Weitere Informationen

Weitere Informationen zu Azure virtuellen Netzwerken finden Sie in den folgenden Ressourcen:

Nächste Schritte

Tip

Auf eigene Faust erkunden? Kehren Sie zum Übersichtsnavigator zurück, um Ihren nächsten Artikel nach Funktion zu finden.

Als Nächstes in Ihrer Lift-and-Shift-Reise:

Planen Sie Ihren IP-Adressraum: Weisen Sie einen /16 CIDR-Pool zu, der keine Überschneidungen mit Ihren lokalen Adressbereichen verhindert.

Als Nächstes in Ihrer Modernisierungsreise:

Planen Sie Ihren IP-Adressraum: Weisen Sie regionenübergreifende IP-Pools mit nicht überlappenden Adressbereichen für Active-Active-Peering zu.

Als Nächstes in Ihrer cloudübergreifenden Reise:

Planen Sie Ihren IP-Adressraum: Entwerfen Sie nicht überlappende Adressierung in Azure, Amazon Web Services (AWS) und Google Cloud.

  • Last updated on