Azure

    Azure Firewall vs. Palo Alto & Fortinet NVAs: Eine TCO-Analyse für 2026

    TechLeague Editorial··14 Min. Lesezeit

    Bis 2026 hat sich die Debatte über die Verwendung von Azure Firewall im Vergleich zu einer Drittanbieter Network Virtual Appliance (NVA) von Anbietern wie Palo Alto Networks oder Fortinet von einer einfachen Feature-Checkliste zu einer grundlegenden Architekturentscheidung entwickelt. Azure Firewall Premium ist kein junges Cloud-natives Tool mehr; es ist ein ausgereiftes Platform-as-a-Service (PaaS)-Angebot mit erheblichen Fähigkeiten. Es ist jedoch kein direkter Ersatz für eine dedizierte Next-Generation Firewall (NGFW) NVA. Die richtige Wahl hängt vollständig von Ihrem Betriebsmodell, Ihrem bestehenden Sicherheits-Ökosystem und Ihrer Toleranz gegenüber architektonischen Kompromissen ab, nicht von einer simplen Sicht auf „besser“ oder „schlechter“. Dies ist eine Entscheidung zwischen PaaS-Einfachheit und IaaS-Kontrolle.

    Architektonische Spaltung: PaaS vs. IaaS im Hub

    Der Kernunterschied zwischen Azure Firewall und einer NVA ist ihr Servicemodell. Azure Firewall ist ein vollständig verwalteter, zonenredundanter Stateful Service. Sie verwalten die zugrunde liegenden VMs nicht, patchen das Betriebssystem nicht, und es skaliert automatisch basierend auf Durchsatz und Verbindungsanzahl. Die Integration in die Azure Fabric ist nahtlos; Diagnosen sind nativ in Azure Monitor, und das Routing wird über Standard User-Defined Routes (UDRs) gehandhabt, die auf die private IP der Firewall zeigen. Sie konsumieren es als Dienst.

    Im Gegensatz dazu ist eine Palo Alto VM-Series oder FortiGate-VM ein Infrastructure-as-a-Service (IaaS)-Deployment. Sie stellen eine oder mehrere VMs (z.B. Standard_D5_v2, F-series) aus dem Marketplace bereit und sind für das OS, die High Availability (HA)-Konfiguration, das Patching und das Lifecycle Management der Firewall-Software (PAN-OS, FortiOS) verantwortlich. Der De-facto-Standard für die Bereitstellung dieser Komponenten zur Traffic Inspection im Jahr 2026 ist ein Gateway Load Balancer (GWLB). Dieses Setup erzeugt eine „transparent Firewall“-Service-Kette, bei der Traffic von einem Quell-VNet an das GWLB-Frontend geleitet, an einen Backend-Pool von NVA-Instanzen weitergeleitet und dann an sein Ziel gesendet wird. Diese Architektur, kombiniert mit Azure Route Server für den BGP Route Exchange, löst endlich die asymmetrischen Routing-Probleme, die frühe NVA-Deployments plagten.

    Das Gateway Load Balancer Sandwich

    Die GWLB-Architektur ist entscheidend zu verstehen. Sie fungiert als transparente „Bump-in-the-Wire“ und bewahrt die Quell-IP des ursprünglichen Clients. Ein Standard VNet-zu-VNet-Flow sähe so aus: Spoke VNet -> UDR zum GWLB -> NVA inspiziert -> GWLB kehrt zum ursprünglichen Spoke zurück -> Traffic routet zum Ziel-Spoke. Dies ermöglicht den NVAs volle Sichtbarkeit, ohne Source NAT (SNAT) durchzuführen, eine massive Verbesserung für Logging und Forensik. Es führt jedoch eine weitere Azure-Komponente ein, die verwaltet und behoben werden muss, mit eigenen Service Limits und Diagnoseproblemen.

    TLS Inspection: Managed Simplicity vs. Granular Control

    Für eine ernsthafte Sicherheitslage ist TLS Inspection nicht verhandelbar. Hier werden die philosophischen Unterschiede zwischen den Plattformen offensichtlich.

    Azure Firewall Premiums Ansatz

    Bis 2026 ist die TLS Inspection von Azure Firewall Premium für ihren vorgesehenen Zweck robust. Sie verwendet eine Managed Intermediate Certificate Authority (CA), die Sie generieren und von Ihrer Enterprise CA unterschreiben lassen, wobei der Private Key sicher in Azure Key Vault gespeichert wird. Es funktioniert und ist einfach zu konfigurieren. Diese Einfachheit geht jedoch auf Kosten der Kontrolle. Sie erhalten eine einzige, umfassende Richtlinie: entschlüsseln oder nicht entschlüsseln. Die Cipher Suite Unterstützung wird von Microsoft bestimmt, nicht von Ihnen. Der Umgang mit Anwendungen, die Certificate Pinning verwenden, kann eine Herausforderung sein und erfordert oft, dass Sie breite URL-basierte Ausnahmen erstellen, die Ihre Sicherheitslage schwächen.

    Palo Alto und Fortinet: Die Entschlüsselungsexperten

    Dies ist das Heimrevier für dedizierte NGFW-Anbieter. Eine Palo Alto VM-Series mit PAN-OS 11.2 oder eine FortiGate-VM mit FortiOS 7.6 bietet präzise Kontrolle über die TLS-Entschlüsselung. Sie können fein granulare Richtlinien erstellen, die beispielsweise Traffic, der für Social-Media-Kategorien bestimmt ist, entschlüsseln, aber Finanz- und Gesundheitskategorien unberührt lassen, um Datenschutzauflagen zu respektieren. Sie haben volle Kontrolle über die akzeptierten Cipher Suites und Protokollversionen, sodass Sie eine strenge kryptografische Richtlinie durchsetzen können. Noch wichtiger ist, dass ihre Engines überlegene Sichtbarkeit und Tools zur Identifizierung und Verwaltung von Pinned Certificates oder nicht-standardmäßigen TLS-Implementierungen bieten, die häufige Ursachen für operative Reibungen sind.

    IDPS: Kuratierte Signaturen vs. Weltweit führende Threat Intelligence

    Ein Intrusion Detection and Prevention System (IDPS) ist nur so gut wie seine Signaturen und die Informationen, die sie speisen. Azure Firewall Premium enthält ein signaturbasiertes IDPS, das bösartige Aktivitäten sowohl im Klartext- als auch im verschlüsselten Traffic erkennen und blockieren kann. Der Signature-Set wird von Microsofts Threat Intelligence Teams kuratiert und automatisch aktualisiert. Es bietet rund 60.000 Signaturen in über 50 Kategorien.

    Dies ist effektiv gegen gängige, bekannte Bedrohungen. Es funktioniert jedoch als Black Box. Sie haben nur begrenzte Möglichkeiten, die einzelnen Signaturen zu inspizieren, und Ihre einzige Aktion ist typischerweise „Alert“ oder „Alert and Deny“. Für viele Organisationen ist das ausreichend. Für ein sicherheitsorientiertes Unternehmen ist es das nicht. Der Threat Prevention Service von Palo Alto wird von Unit 42 gespeist, und das IPS von Fortinet wird von FortiGuard Labs gespeist. Dies sind weltbekannte Threat Research Teams. Ihre Produkte bieten Zugriff auf eine viel größere und dynamischere Datenbank von Signaturen, einschließlich erweiterter Schutzmaßnahmen gegen C2-Kanäle, DNS-Tunneling und dateibasierte Exploits, die über App-ID und Protokolldecoder bereitgestellt werden, die Azure Firewall fehlen. Sie können verschiedene IPS-Profile auf verschiedene Zonen oder Traffic Flows anwenden und die Aktion (Blockieren, Alarmieren, Zurücksetzen usw.) für einzelne Signaturen anpassen, was ein Maß an Tuning ermöglicht, das mit Azure Firewall unmöglich ist.

    Dimensionierung & TCO: Ein realer Financial Services Hub

    Betrachten wir ein häufiges Szenario: ein zentrales Hub-VNet, das den gesamten ausgehenden Internet- und VNet-zu-VNet-Traffic inspiziert. Die Organisation erfordert volle TLS Inspection und IDPS für alle inspizierten Flows.

    • Gesamt benötigter Durchsatz: 8 Gbit/s
    • TLS Inspection Anforderung: 40 % des Datenverkehrs (3,2 Gbit/s)
    • Log-Generierung: 1.200 Bytes durchschnittlich pro Log-Eintrag, 15.000 Logs/Sek. Spitze.

    Tägliche Log-Volumenberechnung: 15.000 Logs/Sek. * 1.200 Bytes/Log * 86.400 Sek./Tag = ~1,55 TB/Tag.

    Option 1: Azure Firewall Premium

    • Firewall-Kosten: Azure Firewall Premium wird pro Stunde des Deployments plus einer Datenverarbeitungsgebühr berechnet. Um 8 Gbit/s IDPS-inspizierten Traffic zu handhaben, können Sie sich nicht nur auf die 100 Gbit/s SKU-Skalierung verlassen. Performance mit aktivierten Features ist entscheidend. Realistisch erfordert dies ein Deployment von mindestens 4 Firewall-Instanzen, die im Hintergrund skaliert werden und als einzelne Ressource abgerechnet werden. Nach den Preisen Ende 2025 kostet eine Premium SKU als Basis ca. 1,75 $/Stunde. Die Datenverarbeitung kostet zusätzlich ca. 0,007 $/GB.
    • Firewall: 1,75 $/Std. * 24 * 30 = 1.260 $/Monat
    • Datenverarbeitung: (8 Gbit/s * 3600 Sek./Std. * 24 Std./Tag * 30 Tage) / 8 Bit/Byte / 1024^3 GB/TB * 0,007 $/GB ≈ 17.203 $/Monat
    • Log-Speicherkosten (Azure Sentinel/Log Analytics): 1,55 TB/Tag sind ~46,5 TB/Monat. Bei einem typischen Pay-as-you-go-Satz von 2,50 $/GB für die Ingestion ist dies ein No-Go. Ein Commitment Tier ist erforderlich. Ein 5 TB/Tag Tier kostet ca. 15.000 $/Monat. Die Logging-Kosten übersteigen die Firewall-Kosten bei weitem.
    • Geschätzte monatliche Gesamtkosten: 1.260 $ + 17.203 $ + 15.000 $ = 33.463 $

    Option 2: FortiGate-VM (HA-Paar)

    • VM- und Lizenzkosten: Um 8 Gbit/s „Threat Protection“-Durchsatz (die relevante Metrik) zu erzielen, können wir keine kleine VM verwenden. Wir bräuchten ein Paar `FortiGate-VM16S`-Instanzen, die auf `Standard_F16s_v2`-VMs für HA laufen.
    • VM-Kosten: 2 * 0,796 $/Std. * 24 * 30 = ~1.146 $/Monat
    • FortiGate PAYG-Lizenz: 2 * FortiGate-VM16 (inkl. FortiGuard-Bundle) ≈ 2 * 4,50 $/Std. * 24 * 30 = ~6.480 $/Monat
    • Log-Speicherkosten (FortiAnalyzer): Bereitstellung einer FortiAnalyzer-VM-Appliance zur Verarbeitung von 1,55 TB/Tag. Eine große `FAZ-VM3000G` kann dieses Volumen bewältigen. Die Lizenz ist ein einmaliger Kauf (oder BYOL), aber berücksichtigen wir die VM-Kosten und den Speicher. Das Speichern von 46,5 TB erfordert erhebliche Premium SSD Managed Disks (z.B. mehrere P40-Disks), die über 1.500 $/Monat kosten.
    • Geschätzte monatliche Gesamtkosten (PAYG): 1.146 $ + 6.480 $ + 1.500 $ = 9.126 $ (Exklusive einmaliger Kosten und unter Annahme von BYOL für Analyzer). Die PAYG-Lizenz ist teuer; ein 3-Jahres-BYOL-Vertrag würde die TCO drastisch senken.

    Option 3: Palo Alto VM-Series (HA-Paar)

    • VM- und Lizenzkosten: Um einen Threat Prevention-Durchsatz von 8 Gbit/s zu erreichen, bräuchten wir ein Paar `VM-500`-Firewalls. Diese würden auf Azure VMs wie `Standard_D8s_v4` laufen.
    • VM-Kosten: 2 * 0,384 $/Std. * 24 * 30 = ~553 $/Monat
    • Palo Alto PAYG-Lizenz: Das `VM-500`-PAYG-Bundle (Threat Prevention, etc.) kostet ca. 7,00 $/Std. 2 * 7,00 $/Std. * 24 * 30 = ~10.080 $/Monat.
    • Log-Speicherkosten (Panorama/Cortex Data Lake): Ähnlich wie bei FortiAnalyzer, Weiterleitung an eine Panorama M-Series VM oder Cortex Data Lake. Die Kostenstruktur für CDL ist verbrauchsabhängig und kann mit Log Analytics konkurrieren, wenn sie nicht sorgfältig verwaltet wird. Schätzen wir ähnliche 2.000 $/Monat für die Logging-Infrastruktur/-Dienste.
    • Geschätzte monatliche Gesamtkosten (PAYG): 553 $ + 10.080 $ + 2.000 $ = 12.633 $

    Die Zahlen sind eindeutig: Azure Firewalls Datenverarbeitungs- und native Logging-Kosten werden in großem Maßstab zu einer erheblichen finanziellen Belastung. Obwohl NVAs höhere anfängliche Lizenzkosten haben (insbesondere PAYG), kann ihre TCO für Szenarien mit hohem Durchsatz, insbesondere bei Verwendung mehrjähriger Enterprise Agreements (BYOL), erheblich niedriger sein. Die PaaS-Steuer ist real.

    Häufige Falle: Fehlkalkulation des Operational Overhead

    Ingenieure berechnen TCO oft nur auf der Grundlage von Lizenz- und Azure-Ressourcenkosten. Dies ist ein schwerwiegender Fehler. Die primären „Kosten“ des Betriebs von NVAs sind operativ. Sie sind verantwortlich für:

    • Patching und Updates: Regelmäßiges Anwenden von FortiOS- oder PAN-OS-Updates in Ihrem HA-Cluster, was oft ein Wartungsfenster erfordert.
    • High Availability Management: Sicherstellen, dass der HA-Mechanismus (aktiv/passiv, aktiv/aktiv) funktioniert, bei Tests korrekt fehlschlägt und sich ordnungsgemäß wiederherstellt.
    • Configuration Management: Obwohl Panorama und FortiManager exzellente Tools sind, sind sie komplexe Plattformen, die spezielle Fähigkeiten erfordern. Eine versehentliche Richtlinienfreigabe kann zu einem katastrophalen Ausfall führen.
    • Fehlerbehebung: Wenn ein Problem auftritt, liegt es an der NVA, dem GWLB, dem UDR, dem Route Server oder der Anwendung? Der Umfang der Fehlerbehebung ist deutlich größer als bei Azure Firewall, wo die zugrundeliegende Plattform in der Verantwortung von Microsoft liegt.

    Wann KEINE Drittanbieter NVA im Jahr 2026 verwendet werden sollte

    Trotz der TCO-Analyse für Hubs mit hohem Durchsatz sind NVAs nicht immer die richtige Wahl. Sie sollten Azure Firewall Premium bevorzugen, wenn:

    • Einfachheit entscheidend ist: Ihr Team besteht aus Azure-Generalisten, nicht aus spezialisierten Netzwerk- und Sicherheitstechnikern. Der reduzierte Betriebsaufwand eines PaaS-Services überwiegt die Funktionslücke.
    • Spoke VNet Egress: Für einfache Spoke VNets, die nur eine konforme Internet-Egress mit ausreichend guter URL-Filterung und IDPS benötigen, ist Azure Firewall eine perfekte Lösung. Es ist einfach über Azure Policy bereitzustellen und bietet grundlegenden Schutz ohne die Komplexität von GWLB und BGP.
    • 100% Cloud-native Umgebung: Wenn Sie keine On-Premises-Rechenzentren und keine bestehenden Investitionen in Fortinet oder Palo Alto haben, bedeutet die Einführung einer NVA die Einführung eines völlig neuen Management-Ökosystems (Panorama/FortiManager) für einen kleinen Teil Ihrer Infrastruktur. Das Festhalten an der nativen Azure-Toolchain (ARM, Bicep, Terraform, Azure Policy) hat einen erheblichen Wert.

    Die Kluft der Management-Ebene: Azure Policy versus Panorama/FortiManager

    Ihre Wahl bestimmt auch Ihr Security Operating Model. Mit Azure Firewall wird die Security Policy Teil Ihrer Infrastructure as Code (IaC) Pipeline. Sie definieren Firewall-Regeln, Richtlinien und IDPS-Einstellungen in ARM-, Bicep- oder Terraform-Templates. Änderungen werden durch Pull Requests und automatisierte Pipelines bereitgestellt, was einen konsistenten, auditierbaren Workflow bietet, der mit einer DevOps-Mentalität übereinstimmt.

    Mit NVAs lebt das Policy Management in einer dedizierten Sicherheitsplattform: FortiManager oder Panorama. Dies ist für Hybrid-Unternehmen ein massiver Vorteil. Eine Organisation mit 50 On-Premises FortiGates kann ihre bestehenden Regelwerke, Objekte und Sicherheitsprofile nahtlos auf Azure erweitern. Das Sicherheitsteam verwendet dieselben Tools und Workflows, die es über Jahre hinweg perfektioniert hat. Dies kann jedoch zu einer Trennung vom Cloud-Team führen. Das Netzwerksicherheitsteam pusht Richtlinien von Panorama, während das Cloud-Team die Infrastruktur über Terraform bereitstellt. Dies kann zu operativer Reibung und einem zweistufigen Managementsystem führen, wenn es nicht ordnungsgemäß gesteuert wird.

    Bis 2026 müssen Sie entscheiden, ob Ihre Firewall-Richtlinie eine Erweiterung Ihrer bestehenden Sicherheitsinfrastruktur oder eine integrierte Komponente Ihres Cloud-Infrastrukturcodes ist. Es gibt keine richtige Antwort, aber Sie müssen sich für eine Seite entscheiden.

    Letztendlich ist die Entscheidung zwischen Azure Firewall und NVA ein Mikrokosmos der größeren Cloud-Strategie-Debatte: PaaS vs. IaaS. Für Organisationen, die Agilität, DevOps-Integration und vereinfachten Betrieb in Cloud-nativen Umgebungen priorisieren, ist Azure Firewall Premium ein leistungsstarker und praktikabler Konkurrent. Für Unternehmen, die erstklassige Sicherheit, granulare Kontrolle und einen konsistenten Policy-Framework über eine Hybrid-Umgebung hinweg benötigen, bleibt die bewährte Leistungsfähigkeit einer Palo Alto oder Fortinet NVA die überlegene Wahl, trotz der zusätzlichen betrieblichen Komplexität. Bevor Sie sich entscheiden, führen Sie die TCO-Berechnung für Ihre spezifischen Durchsatz- und Logging-Anforderungen durch – die Ergebnisse werden Sie wahrscheinlich überraschen. Sind Sie bereit, Ihre Azure-Sicherheit zu architketieren? Die Experten von techleague.io können Ihnen helfen, die TCO zu modellieren und die richtige Lösung zu entwerfen. Lesen Sie unsere Folgeberichte zu Deep-Dive zu Azure Route Server mit BGP und Auswahl zwischen Panorama und FortiManager für die Hybrid Cloud.

    Häufige Fragen

    Verursacht die Verwendung einer NVA mit einem Gateway Load Balancer eine signifikante Latenzzeit?+

    Die GWLB- und NVA-Kette führt eine geringe Latenz ein, typischerweise im niedrigen einstelligen Millisekundenbereich pro Inspektionsknoten. Für die meisten Anwendungen ist dies vernachlässigbar. Bei ultra-niedrigen Latenzanforderungen für Finanzhandel oder Echtzeitkommunikationsaufgaben sollte dieser zusätzliche Hop jedoch während eines Proof-of-Concept gemessen und validiert werden.

    Kann ich meine bestehende BYOL (Bring Your Own License) für eine Palo Alto oder FortiGate NVA in Azure verwenden?+

    Ja, beide Anbieter unterstützen BYOL. Dies ist oft die kostengünstigste Option für Unternehmen mit bestehenden 3- oder 5-Jahres-Enterprise-Agreements. Sie würden die Lizenz von Ihrem Reseller erwerben und das BYOL-Image aus dem Azure Marketplace bereitstellen, wodurch die hohen stündlichen PAYG-Lizenzkosten vermieden werden.

    Wie handhabt Azure Firewall Premium High Availability (HA)?+

    Azure Firewall ist von Natur aus hochverfügbar. Wenn Sie es bereitstellen, stellt Microsoft mehrere Active-Active-Backend-Instanzen in verschiedenen Availability Zones (in unterstützenden Regionen) bereit. Diese zonenredundante HA ist integriert und automatisch, ohne dass eine Konfiguration durch den Benutzer erforderlich ist, im Gegensatz zur manuellen HA-Einrichtung für NVA-Paare.

    Kann ich Traffic zwischen Spokes, die mit demselben Virtual Hub verbunden sind, routen, ohne dass er die Firewall passiert?+

    Ja, mit Azure Virtual WAN können Sie Routing-Richtlinien konfigurieren, um die Inspektion zu steuern. Sie können den Inter-Spoke-Verkehr explizit zur Azure Firewall (oder NVA) zur Inspektion senden oder ihn vom Router des vWAN-Hubs direkt weiterleiten lassen, für Szenarien, die keine Sicherheitsprüfung erfordern, was architektonische Flexibilität bietet.

    Welche Fähigkeiten werden benötigt, um eine FortiGate/Palo Alto NVA in Azure zu verwalten?+

    Neben den grundlegenden Azure-Netzwerkkenntnissen (VNet, UDRs, GWLB, Route Server) benötigt Ihr Team herstellerspezifische Expertise. Dazu gehören Kenntnisse in FortiOS/PAN-OS, Verständnis der spezifischen HA-Mechanismen und Fähigkeiten im Umgang mit den zentralen Managementplattformen (FortiManager/Panorama). Dies ist ein signifikanter Aspekt für Schulung und Personalplanung.

    Unterstützt Azure Firewall Premium Threat-Intelligence-Feeds von Drittanbietern?+

    Anfang 2026 ermöglicht Azure Firewall Premium die Aufnahme von IP-basierten Threat-Intelligence-Feeds im STIX/TAXII-Format. Dadurch können Sie Microsofts native IDPS mit eigenen oder kommerziellen Feeds ergänzen, um bekannte bösartige IP-Adressen zu blockieren. Es unterstützt jedoch keine komplexeren signaturbasierten Feeds wie NGFW-Plattformen.

    Ist SNAT erforderlich, wenn eine NVA mit einem Gateway Load Balancer verwendet wird?+

    Für Traffic, der *durch* den GWLB inspiziert wird (wie VNet-zu-VNet oder Ingress), ist SNAT nicht erforderlich, da der GWLB die Quell-IP beibehält. Für Traffic, der *von der Firewall selbst* stammt (z. B. wenn die NVA einen Aufruf an einen Threat-Intelligence-Dienst tätigt), wird er jedoch auf die eigene Schnittstellen-IP der NVA mit SNAT versehen. Diese Unterscheidung ist entscheidend für ein korrektes Regeldesign.