Die wichtigsten Networking Related Cloud Services

• VNets
  • Virtual Networks sind separiert von anderen virtual Networks und können als physical Networks gesehen werden.
  • Ressources (VMs, DBs,…) können per default im eigenen VNet communizieren aber nicht in anderen VNets
  • VNets sind kostenfrei, aber limitiert bis 50 über alle Regions
  • VNets sind nicht Region übergreifend.
  • VNets können via „Peering“ verbunden werden
  • VNets sind in Subnetze unterteilt (CIDR Notation) max. 65.536 IP Adressen
  • VNets sind mit NSG geschützt, die aber den Subnets zugeordnet sind.
  • z.B.: 10.0.0.0/16 = 10.0.0.0 – 10.0.255.255 (65.536 addresses)
  • Die Azure Firewall kann einem VNet zugewiesen werden (https://learn.microsoft.com/de-de/azure/firewall/overview).
  • Always minimize the Access to the Ressources in a VNet
• SubNets
  • logisches Segment in einem VNet
  • bekommt einen IP Bereich aus dem VNet
  • Ressourcen werden in einem Subnet deplyed und nicht direkt im VNet
  • Subnetze im selben VNet können untereinander kommunizieren
  • Subnetze sind kostenfrei, es gibt ein Limit von 3000
  • z.B. : 10.0.0.0 – 10.0.0.255 (/24) (256 addresses)
  • Front und Backend Services können in verschiedene Subnetze deployed werden
• Load Balancer
• Application Gateway
• Network Security Group (NSG)
  • Filter Regeln (Security Rule) nach SourceIP, SourcePort, DestinationIP, DestinationPort, Protokoll
• Network Peering
  • Verbindet zwei VNets
  • NSG können angewand werden
  • Traffic wird berechnet mit 1ct pro GB (jeweils inbound und outbound)

1. Verschiedene Subnetze im selben VNET

Dies ist die häufigste und empfohlene Praxis in vielen Umgebungen. Die Idee ist, Frontend und Backend in getrennten Subnetzen innerhalb desselben Virtual Network zu platzieren.

Vorteile:

• Segmentierung und Sicherheit: Frontend- und Backend-Services können getrennt werden, und Firewall-Regeln oder NSGs (Network Security Groups) können implementiert werden, um den Zugriff nur auf das Nötigste zu beschränken. Beispielsweise könnte das Backend-Subnetz nur Anfragen vom Frontend akzeptieren und keine direkte Verbindung zum Internet haben.
• Leichtes Routing: Da sich beide Subnetze im selben VNET befinden, ist das Routing zwischen ihnen einfach und performant. Es ist keine zusätzliche Konfiguration für die Kommunikation zwischen den Services nötig.
• Sicherheit auf Layer-3 (Netzwerk): Durch die Trennung in Subnetze können Zugriffskontrollen feiner granuliert werden. Regeln können beispielsweise sicherstellen, dass das Frontend auf das Backend zugreifen kann, aber nicht umgekehrt.
• Kosteneffizienz: Da alles im selben VNET bleibt, gibt es keine zusätzlichen Kosten oder Komplexität für die Verbindung von verschiedenen VNETs (z.B. Peering oder Gateways).

Wann sinnvoll?:

• Wenn beide Services regelmäßig miteinander kommunizieren müssen (z.B. API-Aufrufe des Frontends an das Backend).
• Wenn Sicherheit durch Netzwerksicherheit (Subnetz, Firewalls, NSGs) erreicht werden soll.
• Wenn die Verwaltung einfach bleiben soll und der Overhead einer separaten Netzwerkverwaltung vermieden werden soll.

2. Verschiedene VNETs für Frontend und Backend

In einigen Szenarien kann es sinnvoll sein, Frontend und Backend in verschiedenen Virtual Networks zu deployen. Dies bietet zusätzliche Isolation, kommt aber auch mit mehr Komplexität.

Vorteile:

• Stärkere Isolation: Durch die Verwendung von separaten VNETs können Sie eine noch stärkere Trennung zwischen Frontend und Backend erreichen. Dies ist besonders nützlich, wenn es notwendig ist, die Umgebung stark voneinander zu isolieren (z.B. aus regulatorischen oder Compliance-Gründen).
• Erweiterte Sicherheitskontrollen: Separate VNETs ermöglichen eine noch granularere Kontrolle über die Netzwerkkommunikation. Sie können striktere VNET-Peering-Regeln festlegen oder Gateways zur Kommunikation zwischen VNETs verwenden.
• Multi-Cloud oder Multi-Regionen: Wenn Ihr Frontend in einer anderen Cloud oder einer anderen Region läuft, ist ein separates VNET möglicherweise erforderlich. Das Backend könnte in einer anderen Cloud-Umgebung liegen, um Daten geografisch oder aus Compliance-Gründen zu trennen.

Nachteile:

• Komplexität: Die Verwaltung mehrerer VNETs bringt zusätzliche Komplexität. Sie müssen VNET-Peering oder andere Netzwerktechnologien konfigurieren, um sicherzustellen, dass die beiden Netzwerke miteinander kommunizieren können.
• Kosten: VNET-Peering oder die Verwendung von Gateways (z.B. VPN oder ExpressRoute) zwischen VNETs kann zusätzliche Kosten verursachen.
• Leistungsüberlegungen: Die Latenz kann zunehmen, wenn die Kommunikation zwischen zwei verschiedenen VNETs über ein Gateway oder andere Netzwerkmechanismen erfolgt.

Wann sinnvoll?:

• Wenn Sie eine besonders starke Trennung zwischen Frontend und Backend benötigen (z.B. um strenge Sicherheitsvorgaben zu erfüllen).
• Wenn Ihre Frontend- und Backend-Services in unterschiedlichen Regionen oder Cloud-Providern betrieben werden.
• Wenn Sie eine hoch skalierbare Multi-Tenant-Architektur haben, bei der jeder Teil einer Anwendung in einer eigenen isolierten Umgebung liegt.

Zusammenfassung:

• Verschiedene Subnetze innerhalb desselben VNET:
  • Die bevorzugte Lösung für die meisten Anwendungsfälle.
  • Einfaches Routing, hohe Effizienz und ausreichende Sicherheit.
  • Ideal, wenn Frontend und Backend regelmäßig miteinander kommunizieren müssen.
• Verschiedene VNETs:
  • Mehr Isolation und Sicherheit, aber komplexer und kostspieliger.
  • Sinnvoll, wenn besonders hohe Sicherheitsanforderungen bestehen oder wenn die Systeme stark voneinander getrennt sein müssen (z.B. aus Compliance-Gründen oder in Multi-Region-Szenarien).

In den meisten Fällen ist es effizienter und einfacher, Frontend- und Backend-Services in getrennte Subnetze innerhalb desselben VNET zu deployen. Separate VNETs sind eher in speziellen Szenarien mit besonderen Anforderungen erforderlich.