Erweitern eines lokalen Netzwerks per VPN

Bastion
Azure Stack
Virtual Machines
Virtual Network
VPN Gateway

Diese Referenzarchitektur zeigt, wie Sie ein lokales Netzwerk oder ein Netzwerk in Azure Stack mit einem Site-to-Site-VPN (virtuelles privates Netzwerk) auf ein virtuelles Azure-Netzwerk erweitern. Datenverkehr zwischen dem lokalen Netzwerk und Azure wird durch einen IPsec-VPN-Tunnel oder über das mehrinstanzenfähige VPN-Gateway von Azure Stack übertragen.

Hybrid network spanning on-premises and Azure infrastructures

Diagramm der VPN-Gatewayarchitektur. Ein lokales Netzwerk stellt eine Verbindung mit einem virtuellen Azure-Netzwerk über ein VPN-Gateway her. Ein virtuelles Netzwerk in Azure Stack stellt mithilfe von öffentlichen VIPs ebenfalls eine Verbindung mit dem VPN-Gateway her.

Laden Sie eine Visio-Datei dieser Architektur herunter.

Referenzbereitstellung

Bei dieser Bereitstellung werden zwei Ressourcengruppen erstellt: die erste enthält ein simuliertes lokales Netzwerk, und das zweite einen Satz mit Hub-and-Spoke-Netzwerken. Das simulierte lokale Netzwerk und das Hub-Netzwerk werden mit Azure Virtual Network-Gateways verbunden, um eine Site-to-Site-Verbindung zu ermöglichen. Diese Konfiguration weist eine starke Ähnlichkeit mit der Verbindungsherstellung für Ihr lokales Rechenzentrum mit Azure auf.

Der Bereitstellungsvorgang kann bis zu 45 Minuten dauern. Die empfohlene Bereitstellungsmethode ist die unten beschriebene Nutzung der Option über das Portal.

Verwenden Sie die folgende Schaltfläche, um die Referenz mithilfe des Azure-Portals bereitzustellen.

In Azure bereitstellen

Überprüfen Sie nach Abschluss der Bereitstellung die Site-to-Site-Konnektivität, indem Sie sich die neu erstellten Verbindungsressourcen ansehen. Suchen Sie im Azure-Portal nach „Verbindungen“, und achten Sie jeweils auf den Status der einzelnen Verbindungen.

Screenshot: Status von Verbindungen

Auf die IIS-Instanz im Spoke-Netzwerk kann über den virtuellen Computer zugegriffen werden, der sich im simulierten lokalen Netzwerk befindet. Erstellen Sie eine Verbindung mit dem virtuellen Computer, indem Sie den vorhandenen Azure Bastion-Host verwenden, öffnen Sie einen Webbrowser, und navigieren Sie zur Adresse des Netzwerk-Lastenausgleichsmoduls für die Anwendung.

Ausführliche Informationen und zusätzliche Bereitstellungsoptionen finden Sie in den ARM-Vorlagen, die für die Bereitstellung dieser Lösung verwendet werden.

Aufbau

Die Architektur umfasst die folgenden Komponenten.

  • Lokales Netzwerk. Ein in einer Organisation betriebenes privates lokales Netzwerk.

  • Azure Stack: Eine Netzwerkumgebung in einem Azure Stack-Mandantenabonnement, die innerhalb einer Organisation ausgeführt wird. Das Azure Stack-VPN-Gateway sendet verschlüsselten Datenverkehr über eine öffentliche Verbindung an virtuelle IP-Adressen (VIP). Es umfasst die folgenden Komponenten:

    • Gatewaysubnetz: Ein spezielles Subnetz, das für die Bereitstellung des VPN-Gateways in Azure Stack erforderlich ist.
    • Lokales Netzwerkgateway: Gibt die Ziel-IP-Adresse des VPN-Gateways in Azure sowie den Adressraum des virtuellen Azure-Netzwerks an.
    • Site-to-Site-VPN-Tunnel: Der Verbindungstyp (IPsec) und der Schlüssel, der mit dem Azure-VPN-Gateway geteilt wird, um den Datenverkehr zu verschlüsseln.
  • VPN-Gerät. Ein Gerät oder ein Dienst, das bzw. der externe Konnektivität mit dem lokalen Netzwerk bereitstellt. Bei dem VPN-Gerät kann es sich um ein Hardwaregerät oder eine Softwarelösung, z.B. den Routing- und RAS-Dienst unter Windows Server 2012, handeln. Eine Liste unterstützter VPN-Geräte und Informationen zu ihrer Konfiguration für die Verbindung mit einem Azure-VPN-Gateway finden Sie in den Anweisungen für das ausgewählte Gerät unter Informationen zu VPN-Geräten für VPN Gateway-Verbindungen zwischen Standorten.

  • Virtuelles Netzwerk. Die Cloudanwendung und die Komponenten für das Azure-VPN-Gateway befinden sich im selben virtuellen Netzwerk.

  • Azure-VPN-Gateway. Der VPN Gateway-Dienst ermöglicht es Ihnen, das virtuelle Netzwerk über eine VPN-Appliance mit dem lokalen Netzwerk zu verbinden oder über einen Site-to-Site-VPN-Tunnel eine Verbindung mit Azure Stack herzustellen. Weitere Informationen finden Sie unter Verbinden eines lokalen Netzwerks mit einem Microsoft Azure Virtual Network. Das VPN-Gateway enthält die folgenden Elemente:

    • Gateway des virtuellen Netzwerks. Eine Ressource, die eine virtuelle VPN-Appliance für das virtuelle Netzwerk bereitstellt. Diese Ressource ist für die Weiterleitung des Datenverkehrs vom lokalen Netzwerk zum virtuellen Netzwerk zuständig.
    • Gateway des lokalen Netzwerks. Eine Abstraktion des lokalen VPN-Geräts. Netzwerkdatenverkehr aus der Cloudanwendung zum lokalen Netzwerk wird durch dieses Gateway geleitet.
    • Verbindung. Die Verbindung verfügt über Eigenschaften, die den Verbindungstyp (IPSec) und den Schlüssel angeben, der für das lokale VPN-Gerät freigegeben wird, um Datenverkehr zu verschlüsseln.
    • Gatewaysubnetz. Das virtuelle Netzwerkgateway befindet sich in einem eigenen Subnetz, das verschiedenen Anforderungen unterliegt, die im Abschnitt „Empfehlungen“ weiter unten beschrieben werden.
  • Cloudanwendung. Die in Azure gehostete Anwendung. Sie kann mehrere Schichten umfassen, wobei mehrere Subnetze über Azure Load Balancer verbunden sind. Weitere Informationen zur Anwendungsinfrastruktur finden Sie unter Ausführen von Windows-VM-Workloads und Ausführen von Linux-VM-Workloads.

  • Interner Load Balancer. Netzwerkverkehr aus dem VPN-Gateway wird über einen internen Load Balancer an die Cloudanwendung weitergeleitet. Der Load Balancer befindet sich im Front-End-Subnetz der Anwendung.

  • Bastion. Azure Bastion ermöglicht Ihnen, sich über SSH oder RDP (Remotedesktopprotokoll) bei den VMs im virtuellen Netzwerk anzumelden, ohne die VMs direkt im Internet verfügbar zu machen. Wenn die Verbindung über das VPN unterbrochen wird, können Sie die VMs im virtuellen Netzwerk weiterhin mit Bastion verwalten.

Empfehlungen

Die folgenden Empfehlungen gelten für die meisten Szenarios. Sofern Sie keine besonderen Anforderungen haben, die Vorrang haben, sollten Sie diese Empfehlungen befolgen.

Virtuelles Netzwerk und Gatewaysubnetz

Erstellen Sie ein virtuelles Azure-Netzwerk mit einem Adressraum, der ausreichend groß für alle erforderlichen Ressourcen ist. Stellen Sie sicher, dass der Adressraum des virtuellen Netzwerks genügend Platz für Wachstum bietet, falls in Zukunft voraussichtlich weitere VMs benötigt werden. Der Adressraum des virtuellen Netzwerks darf sich nicht mit dem des lokalen Netzwerks überschneiden. Im obigen Diagramm wird beispielsweise der Adressraum 10.20.0.0/16 für das virtuelle Netzwerk verwendet.

Erstellen Sie ein Subnetz mit dem Namen GatewaySubnet mit dem Adressbereich „/27“. Dieses Subnetz ist für das Gateway für virtuelle Netzwerke erforderlich. Durch Zuweisung von 32 Adressen zu diesem Subnetz wird eine künftige Überschreitung von Beschränkungen der Gatewaygröße verhindert. Vermeiden Sie außerdem, dieses Subnetz in der Mitte des Adressraums zu platzieren. Es empfiehlt sich, den Adressraum für das Gatewaysubnetz am oberen Ende des Adressraums des virtuellen Netzwerks festzulegen. In dem im Diagramm gezeigten Beispiel wird „10.20.255.224/27“ verwendet. Es folgt eine schnelle Methode zur CIDR-Berechnung:

  1. Legen Sie die variablen Bits im Adressraum des virtuellen Netzwerks bis zu den Bits, die vom Gatewaysubnetz verwendet werden, auf 1 und die restlichen Bits auf 0 fest.
  2. Konvertieren Sie die resultierenden Bits in Dezimalzahlen, und drücken Sie sie als Adressraum aus, wobei die Präfixlänge auf die Größe des Subnetzes des Gateways festgelegt wird.

Beispielsweise ändert sich der IP-Adressbereich „10.20.0.0.0/16“ eines virtuellen Netzwerks nach Anwenden von Schritt 1 oben in „10.20.0b11111111.0b11100000“. Nach der Konvertierung in Dezimalzahlen und deren Ausdruck als Adressraum ergibt sich „10.20.255.255.224/27“.

Warnung

Stellen Sie im Gatewaysubnetz keine VMs bereit. Weisen Sie außerdem diesem Subnetz keine Netzwerksicherheitsgruppe (NSG) zu, da das Gateway sonst nicht mehr funktioniert.

Gateway des virtuellen Netzwerks

Ordnen Sie dem Gateway für virtuelle Netzwerke eine öffentliche IP-Adresse zu.

Erstellen Sie das Gateway für virtuelle Netzwerke im Gatewaysubnetz, und weisen Sie ihm die neu zugeordnete öffentliche IP-Adresse zu. Verwenden Sie den Gatewaytyp, der Ihren Anforderungen am ehesten entspricht und der von Ihrem VPN-Gerät unterstützt wird:

  • Erstellen Sie ein richtlinienbasiertes Gateway , wenn Sie die Weiterleitung von Anforderungen anhand von Richtlinienkriterien wie Adresspräfixen genau steuern müssen. Richtlinienbasierte Gateways arbeiten mit statischem Routing und funktionieren nur mit Verbindungen zwischen Standorten.

  • Erstellen Sie in den folgenden Fällen ein routenbasiertes Gateway:

    • Sie stellen mithilfe von RRAS eine Verbindung mit dem lokalen Netzwerk her.
    • Sie unterstützen standort- oder regionsübergreifende Verbindungen.
    • Sie haben Verbindungen zwischen virtuellen Netzwerken, einschließlich Routen durch mehrere virtuelle Netzwerke.

    Routenbasierte Gateways verwenden dynamisches Routing, um den Datenverkehr zwischen Netzwerken zu lenken. Sie können Ausfälle im Netzwerkpfad besser verkraften als statische Routen, weil sie alternative Routen ausprobieren können. Routenbasierte Gateways können auch den Verwaltungsaufwand reduzieren, da Routen nicht manuell aktualisiert werden müssen, wenn sich Netzwerkadressen ändern.

Eine Liste der unterstützten VPN-Geräte finden Sie unter Informationen zu VPN-Geräten für VPN Gateway-Verbindungen zwischen Standorten.

Hinweis

Wenn Sie nach Erstellung des Gateways die Gatewaytypen ändern möchten, müssen Sie das Gateway löschen und neu erstellen.

Wählen Sie die Azure VPN Gateway SKU, die Ihren Durchsatzanforderungen am ehesten entspricht. Weitere Informationen finden Sie unter Gateway-SKUs.

Hinweis

Die SKU „Basic“ ist nicht mit Azure ExpressRoute kompatibel. Sie können die SKU ändern, nachdem das Gateway erstellt wurde.

Erstellen Sie Routingregeln für das Gatewaysubnetz, die eingehenden Anwendungsdatenverkehr vom Gateway zum internen Load Balancer leiten, anstatt Anforderungen direkt an die Anwendungs-VMs weiterleiten zu lassen.

Lokale Netzwerkverbindung

Erstellen Sie ein Gateway für das lokale Netzwerk. Geben Sie die öffentliche IP-Adresse des lokalen VPN-Geräts und den Adressraum des lokalen Netzwerks an. Beachten Sie, dass das lokale VPN-Gerät über eine öffentliche IP-Adresse verfügen muss, auf die das lokale Netzwerkgateway in Azure VPN Gateway zugreifen kann. Das VPN-Gerät darf sich nicht hinter einem Gerät für Netzwerkadressenübersetzung (Network Address Translation, NAT) befinden.

Richten Sie für das virtuelle und das lokale Netzwerkgateway eine Verbindung zwischen Standorten ein. Wählen Sie den Typ der Verbindung zwischen Standorten (IPSec) aus, und geben Sie den gemeinsam verwendeten Schlüssel an. Die Verschlüsselung zwischen Standorten mit dem Azure-VPN-Gateway basiert auf dem IPSec-Protokoll, wobei zur Authentifizierung vorinstallierte Schlüssel verwendet werden. Sie können den Schlüssel angeben, wenn Sie das Azure-VPN-Gateway erstellen. Sie müssen das VPN-Gerät, das lokal ausgeführt wird, mit demselben Schlüssel konfigurieren. Andere Authentifizierungsmechanismen werden derzeit nicht unterstützt.

Stellen Sie sicher, dass die lokale Routinginfrastruktur so konfiguriert ist, dass Anforderungen für Adressen im virtuellen Azure-Netzwerk an das VPN-Gerät weitergeleitet werden.

Öffnen Sie im lokalen Netzwerk alle Ports, die von der Cloudanwendung benötigt werden.

Testen Sie die Verbindung, um zu überprüfen, ob:

  • Das lokale VPN-Gerät den Datenverkehr über das Azure-VPN-Gateway ordnungsgemäß an die Cloudanwendung weiterleitet.
  • Das virtuelle Netzwerk den Datenverkehr korrekt zum lokalen Netzwerk zurückleitet.
  • Unzulässiger Datenverkehr in beide Richtungen ordnungsgemäß blockiert wird.

Azure Stack-Netzwerkverbindung

Diese Referenzarchitektur veranschaulicht, wie Sie ein virtuelles Netzwerk in Ihrer Azure Stack-Bereitstellung über das mehrinstanzenfähige Azure Stack-VPN-Gateway mit einem virtuellen Netzwerk in Azure verbinden. Ein häufiges Szenario besteht darin, wichtige Vorgänge und vertrauliche Daten in Azure Stack zu isolieren und Azure für öffentliche Transaktionen und vorübergehende, nicht sensible Vorgänge zu nutzen.

In dieser Architektur fließt der Netzwerkdatenverkehr über einen VPN-Tunnel, der das mehrinstanzenfähige Gateway in Azure Stack verwendet. Alternativ kann der Datenverkehr über das Internet zwischen Azure Stack und Azure über Mandanten-VIPs, Azure ExpressRoute oder ein virtuelles Netzwerkgerät übertragen werden, das als VPN-Endpunkt fungiert.

Kapazität des Gateways für virtuelle Azure Stack-Netzwerke

Sowohl das Azure-VPN-Gateway als auch das Azure Stack-VPN-Gateway unterstützen das Border Gateway Protocol (BGP) für das Austauschen von Routinginformationen zwischen Azure und Azure Stack. Azure Stack unterstützt kein statisches Routing für das mehrinstanzenfähige Gateway.

Erstellen Sie ein virtuelles Azure Stack-Netzwerk mit einem zugewiesenen IP-Adressraum, der für alle erforderlichen Ressourcen ausreichend groß ist. Der Adressraum des virtuellen Netzwerks darf sich nicht mit einem anderen Netzwerk überlappen, das mit diesem virtuellen Netzwerk verbunden werden soll.

Beim Bereitstellen von Azure Stack wird dem mehrinstanzenfähigen Gateway eine öffentliche IP-Adresse zugewiesen. Diese wird aus dem öffentlichen VIP-Pool entnommen. Der Azure Stack-Verantwortliche hat keine Kontrolle darüber, welche IP-Adresse verwendet wird, er kann aber die Zuweisung festlegen.

Achtung

Workload-VMs können nicht im Subnetz des Azure Stack-Gateways bereitgestellt werden. Weisen Sie außerdem diesem Subnetz keine Netzwerksicherheitsgruppe (NSG) zu, da das Gateway sonst nicht mehr funktioniert.

Überlegungen zur Skalierbarkeit

Sie können eine begrenzte vertikale Skalierbarkeit erreichen, indem Sie von den VPN Gateway SKUs „Basic“ oder „Standard“ zur VPN SKU „High Performance“ wechseln.

Für virtuelle Netzwerke mit einem voraussichtlich hohen Volumen an VPN-Datenverkehr sollten Sie ggf. die verschiedenen Workloads auf separate kleinere virtuelle Netzwerke verteilen und für jedes dieser Netzwerke ein VPN-Gateway konfigurieren.

Das virtuelle Netzwerk kann entweder horizontal oder vertikal partitioniert werden. Verschieben Sie zum horizontalen Partitionieren einige VM-Instanzen von jeder Ebene in Subnetze des neuen virtuellen Netzwerks. Dadurch hat jedes virtuelle Netzwerk die gleiche Struktur und Funktionalität. Um eine vertikale Partitionierung vorzunehmen, müssen Sie jede Ebene neu gestalten, um die Funktionalität in verschiedene logische Bereiche zu unterteilen (z.B. Auftragsbearbeitung, Fakturierung, Kundenbetreuung usw.). Jeder Funktionsbereich kann dann in einem eigenen virtuellen Netzwerk platziert werden.

Die Replikation eines lokalen Active Directory-Domänencontrollers im virtuellen Netzwerk und die Implementierung von DNS im virtuellen Netzwerk können dazu beitragen, einen Teil des sicherheitsrelevanten und administrativen Datenverkehrs von den lokalen Systemen in die Cloud zu reduzieren. Weitere Informationen finden Sie unter Erweitern von Active Directory Domain Services (AD DS) auf Azure.

Überlegungen zur Verfügbarkeit

Wenn Sie sicherstellen müssen, dass das lokale Netzwerk für das Azure-VPN-Gateway verfügbar bleibt, implementieren Sie für das lokale VPN-Gateway einen Failovercluster.

Wenn Ihre Organisation über mehrere lokale Standorte verfügt, richten Sie Multi-Site-Verbindungen mit einem oder mehreren virtuellen Azure-Netzwerken ein. Dieser Ansatz erfordert dynamisches (routenbasiertes) Routing. Stellen Sie daher sicher, dass das lokale VPN-Gateway dies unterstützt.

Weitere Informationen zu Vereinbarungen zum Servicelevel finden Sie unter SLA für VPN Gateway.

Sie können die VPN-Gateways in Azure Stack erweitern, um Schnittstellen für mehrere Azure Stack-Stempel und Azure-Bereitstellungen hinzuzufügen.

Überlegungen zu DevOps

Verwenden Sie den IaC-Prozess (Infrastructure-as-Code) für die Infrastrukturbereitstellung. Zum Automatisieren der Infrastrukturbereitstellung eignen sich Azure DevOps Services oder andere CI/CD-Lösungen. Der Bereitstellungsprozess ist außerdem idempotent.

Alle Hauptressourcen (VM-Skalierungsgruppe, VPN-Gateway, Azure Bastion) befinden sich im gleichen virtuellen Netzwerk und sind somit in der gleichen grundlegenden Workload isoliert. Das macht es leichter, die spezifischen Ressourcen einer Workload einem Team zuzuordnen, damit das Team unabhängig alle Aspekte dieser Ressourcen verwalten kann. Diese Isolation ermöglicht DevOps die Durchführung von Continuous Integration und Continuous Delivery (CI/CD).

Überwachung

Überwachen Sie von lokalen VPN-Geräten stammende Diagnoseinformationen. Dieser Vorgang hängt von den Funktionen ab, die das VPN-Gerät bietet. Wenn Sie z.B. den Routing- und RAS-Dienst unter Windows Server 2012 verwenden, wählen Sie die RRAS-Protokollierung.

Verwenden Sie die Azure VPN Gateway-Diagnose zum Erfassen von Informationen zu Verbindungsproblemen. Diese Protokolle können verwendet werden, um Informationen wie Quelle und Ziele von Verbindungsanforderungen nachzuverfolgen, welches Protokoll verwendet wurde und wie die Verbindung aufgebaut wurde (oder warum der Versuch fehlgeschlagen ist).

Überwachen Sie die Betriebsprotokolle des Azure-VPN-Gateways mithilfe der Überwachungsprotokolle, die im Azure-Portal verfügbar sind. Für das lokale Netzwerkgateway, das Azure-Netzwerkgateway und die Verbindung sind separate Protokolle verfügbar. Diese Informationen können verwendet werden, um jegliche Änderungen am Gateway nachzuverfolgen, und sind ggf. nützlich, wenn ein zuvor funktionierendes Gateway aus irgendeinem Grund nicht mehr funktioniert.

Audit logs in the Azure portal

Screenshot des Azure-Portals, der die Ereignisse im Überwachungsprotokoll nach Datum gefiltert zeigt.

Überwachen Sie Verbindungen, und verfolgen Sie Verbindungsfehlerereignisse nach. Sie können ein Überwachungspaket wie Nagios verwenden, um diese Informationen zu erfassen und zu melden.

Informationen zum Behandeln von Verbindungsproblemen finden Sie unter Behandeln von Problemen mit einer VPN-Hybridverbindung.

Wenn die Gatewaykonnektivität zwischen Ihrem lokalen Netzwerk und Azure unterbrochen ist, können Sie die VMs im virtuellen Azure-Netzwerk weiterhin über Azure Bastion erreichen.

Sicherheitshinweise

Generieren Sie für jedes VPN-Gateway einen anderen gemeinsam verwendeten Schlüssel. Wählen Sie einen sicheren gemeinsam verwendeten Schlüssel, um Brute-Force-Angriffe abzuwehren.

Generieren Sie bei Azure Stack-Verbindungen für jeden VPN-Tunnel einen anderen gemeinsam genutzten Schlüssel. Wählen Sie einen sicheren gemeinsam verwendeten Schlüssel, um Brute-Force-Angriffe abzuwehren.

Hinweis

Derzeit können Sie Azure Key Vault nicht für das Vorinstallieren von Schlüsseln für das Azure-VPN-Gateway nutzen.

Stellen Sie sicher, dass das lokale VPN-Gerät eine Verschlüsselungsmethode verwendet, die mit dem Azure-VPN-Gateway kompatibel ist. Für richtlinienbasiertes Routing unterstützt das Azure-VPN-Gateway die Verschlüsselungsalgorithmen AES256, AES128 und 3DES. Routenbasierte Gateways unterstützen AES256 und 3DES.

Wenn sich Ihr lokales VPN-Gerät in einem Umkreisnetzwerk (DMZ) befindet, das eine Firewall zwischen dem Umkreisnetzwerk und dem Internet aufweist, müssen Sie möglicherweise zusätzliche Firewallregeln konfigurieren, um die Site-to-Site-VPN-Verbindung zuzulassen.

Wenn die Anwendung im virtuellen Netzwerk Daten an das Internet sendet, erwägen Sie die Implementierung einer Tunnelerzwingung, um den gesamten internetgebundenen Datenverkehr durch das lokale Netzwerk zu leiten. Auf diese Weise können Sie aus der lokalen Infrastruktur ausgehende Anforderungen der Anwendung überprüfen.

Hinweis

Die Tunnelerzwingung kann die Konnektivität mit Azure-Diensten (z.B. Azure Storage) und dem Windows-Lizenz-Manager beeinträchtigen.

Kostenbetrachtung

Verwenden Sie den Azure-Preisrechner, um die voraussichtlichen Kosten zu ermitteln. Allgemeine Überlegungen finden Sie im Microsoft Azure Well-Architected Framework unter Grundsätze der Kostenoptimierung.

Die in dieser Architektur verwendeten Dienste werden wie folgt berechnet:

Azure VPN Gateway

Die Hauptkomponente dieser Architektur ist der VPN Gateway-Dienst. Gebühren fallen basierend auf der Bereitstellungs- und Verfügbarkeitsdauer des Gateways an.

Der gesamte eingehende Datenverkehr ist kostenlos, und für den gesamten ausgehenden Datenverkehr fallen Gebühren an. Für ausgehenden VPN-Datenverkehr gelten Internetbandbreitenkosten.

Weitere Informationen finden Sie unter VPN-Gateway: Preise.

Virtuelles Azure-Netzwerk

Azure Virtual Network ist kostenlos. Mit jedem Abonnement können bis zu 50 virtuelle Netzwerke in allen Regionen erstellt werden.

Der gesamte Datenverkehr, der innerhalb der Grenzen einer Virtual Network-Instanz entsteht, ist kostenlos. Die Kommunikation zwischen zwei virtuellen Computern in demselben virtuellen Netzwerk ist also kostenlos.

Azure Bastion

Mit Azure Bastion wird per RDP und SSH eine sichere Verbindung mit Ihrem virtuellen Computer im virtuellen Netzwerk hergestellt, ohne dass auf dem virtuellen Computer eine öffentliche IP-Adresse konfiguriert werden muss. Sie benötigen Bastion in jedem virtuellen Netzwerk mit virtuellen Computern, mit denen Sie eine Verbindung herstellen möchten. Diese Lösung ist wirtschaftlicher und sicherer als die Verwendung von Jumpboxes.

Beispiele hierzu finden Sie unter Azure Bastion – Preise.

Virtuelle Computer und interne Lastenausgleichsmodule

Bei dieser Architektur werden interne Lastenausgleichsmodule verwendet, um einen Lastenausgleich für Datenverkehr innerhalb eines virtuellen Netzwerks vorzunehmen. Der grundlegende Lastenausgleich zwischen virtuellen Computern in demselben virtuellen Netzwerk ist kostenlos.

VM-Skalierungsgruppen sind für alle Größen von Linux- und Windows-VMs verfügbar. Ihnen werden nur die Azure-VMs in Rechnung gestellt, die Sie bereitstellen, sowie die von Ihnen genutzten zugrunde liegenden Infrastrukturressourcen, z. B. Speicher und Netzwerk. Für den VM-Skalierungsgruppendienst fallen keine inkrementellen Gebühren an.

Weitere Informationen finden Sie auf der Preisseite für virtuelle Azure-Computer.

Bereitstellen der Lösung

Details zum Bereitstellen dieser Referenzarchitektur finden Sie in der GitHub-Infodatei.

Nächste Schritte

Obwohl VPNs zum Verbinden von virtuellen Netzwerken in Azure verwendet werden können, ist dies nicht immer die optimale Lösung. Weitere Informationen finden Sie unter Wählen zwischen Peering virtueller Netzwerke und VPN-Gateways in Azure.