Flache Netzwerktopologie für eine einzelne Workload

Ein flaches Netzwerk ist die einfachste Azure Netzwerktopologie: ein virtuelles Netzwerk mit mehreren Subnetzen, die eine einzelne Workload hosten. In diesem Artikel wird erläutert, wann sie dieses Muster verwenden und wie Sie es implementieren.

Inhalt dieses Artikels

In diesem Artikel wird die einfachste Azure Netzwerktopologie beschrieben: ein einzelnes virtuelles Netzwerk mit mehreren Subnetzen, die eine Workload hosten. Verwenden Sie dieses Muster, wenn Sie eine einzelne Anwendung von einem Team verwaltet haben und keine gemeinsamen Dienste wie eine zentrale Firewall oder ein VPN-Gateway benötigen.

Wer diesen Artikel benötigt

Lesen Sie diesen Artikel, wenn:

  • Sie stellen Ihre erste Workload in Azure bereit.
  • Ein einzelnes Team besitzt und betreibt alle Ressourcen.
  • Sie benötigen keine gemeinsamen Netzwerkdienste (Firewall, Bastion, Gateway) für mehrere Workloads.
  • Sie möchten das einfachste Netzwerk, das weiterhin die Isolation und Sicherheit auf Subnetzebene bereitstellt.

Heben und Verschieben des Fokus: Ein einzelnes flaches VNet mit einem Subnetz pro Komponente ist häufig der richtige erste Schritt zum Erneuten Hosten einer Workload in einer Region.

Modernisieren Sie den Fokus: Verwenden Sie ein flaches Netzwerk für ein frühes PaaS-Pilotprojekt oder eine einzelne modernisierte Workload, und entwerfen Sie ihre Subnetze so, dass es sauber auf Hub-and-Spoke absteigen kann, wenn Sie gemeinsame Dienste oder eine zweite Region hinzufügen.

Cloudübergreifender Fokus: Verwenden Sie ein flaches VNet als einzelnen Azure-Ausgangspunkt während der cloudübergreifenden Migration: Migrieren Sie zunächst die Workload und planen Sie anschließend ihren Adressraum und ihre Segmentierung, damit sie mit zunehmender Reife des Designs in einen Hub oder ein Virtual WAN eingebunden werden kann.

Azure Dienste und Features

Die flache Netzwerktopologie verwendet die folgenden zentralen Azure-Dienste:

Service Rolle in dieser Topologie
Virtuelles Azure-Netzwerk Stellt einen privaten, isolierten Adressraum für Ihre Workload bereit. Ein virtuelles Netzwerk ist auf eine einzelne Azure-Region beschränkt.
Subnetze + Netzwerksicherheitsgruppen (NSGs) Subnetze trennen Anwendungsebenen. NSGs filtern eingehenden und ausgehenden Datenverkehr an jeder Subnetzgrenze. NSGs sind zustandsbehaftet: Antwortdatenverkehr für erlaubte Verbindungen wird automatisch zugelassen.
Azure Privates DNS-Zone Stellt die interne Namensauflösung für Ressourcen innerhalb des virtuellen Netzwerks bereit. Verknüpfen Sie die Zone mit aktivierter automatischer Registrierung, sodass VMs automatisch DNS-Einträge abrufen.
Gateway-Subnetz(optional) Hostet ein VPN- oder ExpressRoute-Gateway, wenn Sie eine einzige Verbindung mit einem lokalen Netzwerk benötigen.

So wählen Sie: bei einer flachen Struktur bleiben oder zu einem Hub-and-Spoke-Modell übergehen?

Verwenden Sie die folgende Entscheidungstabelle, um zu bestimmen, ob die flache Topologie für Ihre Umgebung geeignet ist oder ob Sie stattdessen eine Hub-and-Spoke-Topologie übernehmen sollten.

Zustand Recommendation
Einzelne Workload, einzelnes Team, keine gemeinsamen Dienste Bleiben Sie flach: Dieser Artikel gilt
Eine zweite unabhängige Workload benötigt eine eigene Netzwerkisolation. Zu einer Hub-and-Spoke-Topologie wechseln
Sie benötigen eine freigegebene Firewall, ein VPN-Gateway oder Azure Bastion für mehrere Workloads. Wechseln Sie zu Hub-Spoke-Topologie
Sicherheitsrichtlinien müssen zentral über mehrere Workloads hinweg verwaltet werden Wechseln Sie zu Hub-and-Spoke-Topologie

Tip

Wenn Sie davon ausgehen, innerhalb von sechs bis zwölf Monaten einen zweiten Workload hinzuzufügen, sollten Sie von Anfang an mit Hub-and-Spoke beginnen. Der Aufwand ist minimal, da Sie nur ein zusätzliches virtuelles Netzwerk und eine Peeringverbindung hinzufügen. Dieser Ansatz vermeidet später eine störende Migration.

Überlegungen zum Entwurf

Designfokus für Lift-and-Shift-Flachnetzwerke

  • Verwenden Sie ein VNet mit einem Subnetz für jede Anwendungskomponente (Web, App, Daten), um ein typisches lokales dreistufiges Layout mit minimaler Neugestaltung zu spiegeln.
  • Wenden Sie NSGs zwischen Subnetzen an, um Ihre vorhandene Segmentierung nachzubilden, und stimmen Sie den Adressraum auf die lokalen Adressbereiche ab, um Überlappungen zu vermeiden.
  • Behalten Sie eine flache Struktur bei, solange ein einzelnes Team für die Workload verantwortlich ist und Sie keine gemeinsam genutzten Firewall-, Gateway- oder Bastion-Dienste benötigen.
  • Planen Sie den Wechsel zu einer Hub-and-Spoke-Architektur, bevor Sie einen zweiten Workload hinzufügen, damit gemeinsame Dienste in einem Hub untergebracht werden, anstatt nachträglich integriert zu werden.

Modernisieren des Designfokus für flache Netzwerke

  • Verwenden Sie ein flaches Netzwerk für ein frühes PaaS-Pilotprojekt oder eine einzelne modernisierte Workload: Platzieren Sie die App-Ebenen in Subnetzen und erreichen Sie Azure PaaS über private Endpunkte in einem dedizierten Subnetz.
  • Reservieren Sie von vornherein dedizierte Subnetze für die Plattformdienste, die Sie hinzufügen werden, z. B. Application Gateway und private Endpunkte, damit das Netzwerk ohne Neuadressierung wachsen kann.
  • Wenden Sie NSGs und Anwendungssicherheitsgruppen pro Ebene an, damit Ihre Segmentierung bereits eingerichtet ist, falls die Workload später in einer Hub-and-Spoke-Architektur zu einem Spoke wird.
  • Achten Sie darauf, dass sich der Adressraum nicht mit Ihren anderen Regionen und VNets überschneidet, damit Sie ihn später per Peering verbinden oder ohne Umnummerierung zu einer Hub-Architektur migrieren können.

Schwerpunkt des cloudübergreifenden Flachnetzwerkdesigns

  • Verwenden Sie ein flaches VNet als einzelner Azure Fußpunkt während der cloudübergreifenden Migration: Landen Sie zuerst die Workload, und fügen Sie dann die Konnektivität von einem Hub an, während das Design reift.
  • Planen Sie den Adressraum des flachen VNetzwerks so, dass es nicht zu Überschneidungen mit AWS-VPCs und Google-Cloud-Netzwerken kommt, damit es später ohne Adressübersetzung in IPsec- oder Interconnect-Routing eingebunden werden kann.
  • Behalten Sie die Ebenensegmentierung mit NSGs bei, sodass der Sicherheitsstatus der Workload übernommen wird, wenn sie sich hinter einem gesicherten Virtual WAN Hub befindet.
  • Standardisieren Sie subnetzbenennung und Tagging so, dass sie ihren anderen Clouds entsprechen, damit die Workload während und nach der Migration leicht korreliert werden kann.

Voraussetzungen

Bevor Sie diese Topologie implementieren:

  • Ein Azure-Abonnement mit Berechtigungen zum Erstellen virtueller Netzwerke und NSGs.
  • Ein geplanter IP-Adressraum. Ein /16-Adressraum stellt 65.536 Adressen bereit, bei denen es sich um einen gemeinsamen Ausgangspunkt für eine einzelne Workload handelt. Azure reserviert 5 Adressen pro Subnetz für die interne Verwendung. Ausführliche Anleitungen finden Sie unter Planen der IP-Adressierung.
  • Ein Verständnis ihrer Anwendungsebenen (z. B. Web, Anwendung und Daten), damit Sie sie Subnetzen zuordnen können. Anleitungen zum Subnetzentwurf finden Sie unter Entwerfen virtueller Netzwerke und Subnetze.

Netzwerklayout

Diagramm mit einer flachen Netzwerktopologie mit Web-, Anwendungs- und Datenebenen-Subnetzen, die jeweils durch eine NSG geschützt sind, innerhalb eines einzelnen virtuellen Netzwerks.

Eine flache Netzwerktopologie folgt dieser Struktur:

  • Ein virtuelles Netzwerk mit einem einzigen Adressraum (z. B. 10.0.0.0/16).
  • Mehrere Subnetze: eine pro Anwendungsebene oder Komponente:
    • Webebenen-Subnetz (z. B. 10.0.1.0/24).
    • Subnetz der Anwendungsebene (z. B. 10.0.2.0/24).
    • Subnetz der Datenebene (z. B. 10.0.3.0/24).
    • Gateway-Subnetz (optional, z. B. 10.0.255.0/27).
  • NSGs, die jedem Subnetz zugeordnet sind mit Regeln, die nur den Datenverkehr zulassen, den jede Ebene benötigt.
  • Eine Privates DNS Zone, die mit dem virtuellen Netzwerk verknüpft ist, wobei die automatische Registrierung aktiviert ist.

Note

Planen Sie Ihre IP-Adressbereiche sorgfältig. Wenn Sie später zu einer Hub-and-Spoke-Topologie migrieren, müssen die virtuellen Speichennetzwerke über nicht überlappende CIDR-Bereiche mit dem Hub verfügen. Die Auswahl eines gut strukturierten Adressschemas verhindert jetzt Konflikte während der Migration.

Sicherheitsüberlegungen

Wenden Sie die folgenden Sicherheitspraktiken auf Ihr Flaches Netzwerk an:

  • NSGs für jedes Subnetz. Beginnen Sie mit einer Ausgangsbasis, die eingehenden Datenverkehr grundsätzlich verweigert, und fügen Sie spezifische Erlaubnisregeln für zulässigen Datenverkehr zwischen den Schichten hinzu. Erlauben Sie beispielsweise HTTPS von der Webebene zur Anwendungsebene und SQL von der Anwendungsebene zur Datenebene.
  • Keine öffentlichen IPs direkt auf virtuellen Computern. Stellen Sie Dienste über einen Load Balancer oder ein Application Gateway bereit. Verwenden Sie Azure Bastion für den Administratorzugriff.
  • Privates DNS für die interne Auflösung. Privates DNS Zonen verhindern, dass interne Hostnamen über öffentliche DNS-Abfragen ausgesetzt werden.
  • Gateway-Subnetzisolierung. Wenn Sie ein VPN- oder ExpressRoute-Gateway hinzufügen, platzieren Sie es in einem dedizierten Subnetz (benannt GatewaySubnet). NSGs im Gatewaysubnetz werden nicht unterstützt. Das Zuordnen eines NSG zu diesem Subnetz kann dazu führen, dass Ihr virtuelles Netzwerkgateway nicht mehr wie erwartet funktioniert.

Important

Wenn Sie eine NSG-Regel entfernen, die eine Verbindung zulässt, bleiben vorhandene aktive Verbindungen unterbrechungsfrei. Nur neue Verbindungen, die der entfernten Regel entsprechen, werden blockiert.

Die folgenden Artikel enthalten ausführlichere Anleitungen zu verwandten Themen:

Weitere Informationen

Weitere Informationen zu den in dieser Topologie verwendeten Azure-Diensten finden Sie unter:

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:

Entwerfen Sie Ihre Hub-and-Spoke-Topologie: Die meisten Lift-and-Shift-Migrationen übersteigen schnell die Möglichkeiten eines flachen Netzwerks. Planen Sie zentrale gemeinsame Dienste von Anfang an.

Als Nächstes in Ihrer Modernisierungsreise:

Entwerfen Sie Ihre Hub-and-Spoke-Topologie: Modernisierte Workloads mit mehreren Diensten, Sicherheitskontrollen und Teams benötigen hub-and-spoke von Tag 1 an.

Als Nächstes in Ihrer cloudübergreifenden Reise:

Planen Sie Ihre cloudübergreifende Konnektivitätsarchitektur: Cross-Cloud-Estates benötigen Transitarchitektur und keine flachen Netzwerke. Entwerfen Sie Ihr Multicloud-Konnektivitätsmodell.

  • Last updated on