February 24, 2026

Capacity Planning: Wie dimensioniert man Firewalls richtig?

Capacity Planning für Firewalls ist eine der wichtigsten, aber gleichzeitig am häufigsten unterschätzten Aufgaben in der Netzwerksicherheit. Wer eine Firewall „nach Datenblatt-Durchsatz“ dimensioniert, riskiert im Alltag böse Überraschungen: VPN-Lastspitzen, viele gleichzeitige Sessions, TLS-Inspection, IPS-Signaturen, SD-WAN-Features oder Logging können die Performance drastisch reduzieren. Umgekehrt führt eine überdimensionierte Anschaffung zu unnötigen Kosten – nicht nur beim Gerät, sondern auch bei Lizenzen, Support und Strom/Platz. Eine professionell dimensionierte Firewall ist deshalb immer das Ergebnis eines strukturierten Capacity Plannings: Sie analysieren reale Traffic-Profile, definieren Sicherheitsfunktionen, berücksichtigen Wachstum und Redundanz (HA), und testen die Annahmen. In diesem Artikel erfahren Sie, wie man Firewalls richtig dimensioniert – mit klaren Kennzahlen, praxisnahen Rechen- und Planungsansätzen, typischen Fallstricken und einer Checkliste, die Sie direkt in Projekten oder Ausschreibungen verwenden können.

Warum Firewall-Dimensionierung mehr ist als „Gbit/s“

Hersteller geben häufig mehrere Durchsatzwerte an: „Firewall Throughput“, „Threat Prevention Throughput“, „VPN Throughput“ oder „TLS Inspection Throughput“. Diese Zahlen sind nicht falsch, aber sie sind stark von Laborbedingungen abhängig und lassen sich nur begrenzt auf Ihre Umgebung übertragen. In der Realität hängt die Performance einer Firewall vor allem von folgenden Faktoren ab:

  • Traffic-Mix: Viele kleine Flows (Web, APIs) verhalten sich anders als wenige große Flows (Backups, Replikation).
  • Session-Anzahl: Die Anzahl gleichzeitiger Verbindungen (Sessions) ist oft limitierender als reiner Durchsatz.
  • Features: IPS, Anti-Malware, URL-Filter, Application Control, DLP und TLS-Inspection kosten CPU/ASIC-Ressourcen.
  • Encryption: VPN und TLS-Inspection sind kryptografisch teuer; Cipher Suites und Key-Längen wirken sich aus.
  • Logging: Umfangreiche Logs (inkl. Full-URL, User-IDs, Threat-Details) können IO/CPU und Log-Pipelines belasten.
  • HA-Design: Active/Passive bedeutet N+1, Active/Active bedeutet Lastverteilung, aber mehr Komplexität.
  • Traffic-Richtung: North-South (Internet/DMZ) vs. East-West (Zonenverkehr) erzeugt unterschiedliche Muster.

Die wichtigsten Kennzahlen im Firewall-Capacity-Planning

Ein gutes Capacity Planning arbeitet mit mehreren Kennzahlen, nicht nur mit einer. Die folgenden Metriken sollten Sie mindestens erfassen und verstehen.

Durchsatz (Throughput)

  • Peak Throughput: maximale Bandbreite in Lastspitzen (z. B. morgens, bei Deployments, bei Backups).
  • Average Throughput: mittlere Last über den Tag, hilfreich für Trendanalysen.
  • Pro Interface/Zone: getrennte Betrachtung für Internet, DMZ, Server, VPN.

Sessions und CPS (Connections per Second)

  • Concurrent Sessions: Anzahl gleichzeitig offener Verbindungen, kritisch bei Web- und Mikroservice-Umgebungen.
  • CPS: neue Verbindungen pro Sekunde, wichtig bei Burst-Verhalten (z. B. Browser, Kubernetes, Load Balancer, Scans).
  • Session-Churn: Wie schnell werden Sessions aufgebaut und wieder geschlossen? Hoher Churn belastet State Engines.

CPU/ASIC-Auslastung und Ressourcen

  • CPU/Dataplane Utilization: Dauerhaft hohe Werte deuten auf zu knappe Dimensionierung oder falsche Features hin.
  • Memory: Relevant für Session Tables, Threat Engines, Logging-Queues.
  • Disk/Storage: Lokale Logs, Crashdumps, temporäre Dateien – je nach Plattform wichtig.

Latenz und Jitter

  • Added Latency: Verzögerung durch Security-Inspection, besonders relevant für VoIP, Video, VDI.
  • Jitter: Schwankungen durch Lastspitzen oder Queueing, oft ein frühes Warnsignal.

VPN-Kennzahlen

  • VPN-Throughput: realer Durchsatz unter den verwendeten Cipher Suites und mit aktivem Rekeying.
  • Simultane VPN-Tunnels: Site-to-Site und Remote Access getrennt betrachten.
  • Remote Users: gleichzeitige Nutzer, pro Nutzer typisches Traffic-Profil (Video, Files, SaaS).

Schritt für Schritt: So dimensionieren Sie Firewalls professionell

Ein praxistauglicher Prozess besteht aus Datensammlung, Sicherheitsanforderungen, Modellierung und Validierung. Damit vermeiden Sie „Schätzen nach Bauchgefühl“.

Traffic messen und profilieren

  • NetFlow/IPFIX/sFlow: Bandbreite, Top Talker, Ports/Protokolle, CPS, Flow-Dauer.
  • Firewall-Logs: Session Counts, NAT Hits, Threat Events, App-IDs, Denies.
  • Proxy/SWG/SASE: Web-Mix, Upload/Download-Profile, Kategorien, TLS-Anteile.
  • Cloud Flow Logs: Bei hybriden Umgebungen: Ost-West- und Cloud-Egress-Profile.

Wichtig: Sammeln Sie nicht nur „einen Peak“, sondern mindestens zwei bis vier Wochen, um Wochenmuster, Monatswechsel, Patch-Tage und Sonderereignisse zu sehen.

Sicherheitsfunktionen festlegen, die wirklich aktiv sind

Die Dimensionierung hängt stark davon ab, welche Features Sie tatsächlich einschalten. Eine Firewall ohne Threat Prevention ist oft um Größenordnungen schneller als eine mit IPS, Malware-Scanning und TLS-Inspection.

  • Stateful Firewalling: Basisfunktion, meist gut kalkulierbar.
  • IPS/Threat Prevention: Signaturen und Protokolldecoder kosten Ressourcen, insbesondere bei hohen CPS.
  • URL-Filter/Application Control: Zusätzliche Lookups/Engines, abhängig vom Traffic-Mix.
  • TLS Inspection: Sehr ressourcenintensiv; entscheidet häufig über die Gerätegröße.
  • DLP/CASB-ähnliche Funktionen: Je nach Implementierung stark performancelimitierend.

Use Cases in Traffic-Klassen übersetzen

Teilen Sie Traffic in Klassen, um realistisch zu planen:

  • Business Critical: VPN/VDI/VoIP, zentrale SaaS, ERP-Schnittstellen.
  • Bulk Traffic: Backups, Updates, Replikation, große Downloads.
  • High Churn: Web-Browsing, API/Microservices, Container-Plattformen.
  • Inbound: DMZ-Services, Reverse Proxy/WAF, API-Gateways.

Jede Klasse hat andere Engpässe: Bulk belastet Bandbreite, High Churn belastet Sessions/CPS, TLS-Inspection belastet CPU/ASIC.

Wachstum, Reserven und „Worst Case“ berücksichtigen

  • Wachstumsfaktor: realistisch 20–40% pro Jahr in digitalen Unternehmen, je nach Umfeld.
  • Reserve: Planen Sie nicht auf 100% Auslastung; 40–60% „Normalbetrieb“ ist ein stabiler Zielbereich.
  • Worst Case: Peak + Failover + Incident (z. B. DDoS-Abwehr, erhöhte Logs) kann gleichzeitig auftreten.

HA und Capacity: Warum N+1 oft Pflicht ist

High Availability ist nicht nur eine Verfügbarkeitsfrage, sondern auch Capacity Planning. In Active/Passive muss die aktive Firewall im Failover-Fall die gesamte Last allein tragen. Das ist klassisch N+1: Sie dimensionieren so, dass ein Knoten den Peak tragen kann, inklusive der aktivierten Security-Funktionen.

  • Active/Passive: Dimensionierung pro Gerät = Peak (plus Reserve). Passive ist Standby, aber muss gleich leistungsfähig sein.
  • Active/Active: Lastverteilung möglich, aber planen Sie trotzdem so, dass bei Ausfall eines Knotens die verbleibenden Knoten nicht sofort am Limit laufen.
  • State Sync Overhead: Session-Sync und HA-Healthchecks erzeugen zusätzlichen Traffic und CPU-Last.

Der große Performance-Killer: TLS Inspection richtig einplanen

Da ein Großteil des Internet- und API-Traffics heute TLS-verschlüsselt ist, wird TLS Inspection (auch SSL Inspection) häufig eingesetzt, um Malware, C2 oder Datenabfluss zu erkennen. Für die Dimensionierung ist das kritisch, weil jede Verbindung kryptografisch terminiert und neu aufgebaut wird.

  • Anteil TLS-Traffic: In vielen Unternehmen > 80–90% der Web-/API-Flows.
  • Handshake-Last: Viele kurze Verbindungen bedeuten viele Handshakes; CPS wird entscheidend.
  • Ausnahmen: Banking, Health, Certificate Pinning, bestimmte Apps – reduzieren die Inspection-Quote, ändern aber nicht den Peak-Charakter.
  • Zertifikatsmanagement: Eigene CA, Verteilung der Root-CA, Monitoring auf Fehler und Ausnahmen.

Wenn Sie TLS Inspection planen, kalkulieren Sie konservativ und testen realistisch. Als technische Basis für TLS ist RFC 8446 (TLS 1.3) hilfreich, um Handshake-Mechanismen und Randbedingungen einzuordnen.

VPN-Dimensionierung: Remote Access und Site-to-Site getrennt betrachten

VPN-Last ist selten konstant. Remote Work erzeugt Tagespeaks, Videokonferenzen und Dateiübertragungen. Site-to-Site hängt oft an Replikationen, Cloud-Anbindungen oder Standorttraffic.

Remote Access VPN

  • Nutzerzahl: gleichzeitige Nutzer in Peakzeiten (Montagmorgen ist oft höher als Freitag).
  • Profil pro Nutzer: Office/SaaS, VDI, Entwickler (Git, Container), Support (RDP/SSH).
  • MFA und Auth: kann Login-Spitzen erzeugen, ist aber meist nicht der Durchsatzengpass, eher die Control Plane.

Site-to-Site VPN

  • Tunnelanzahl: Standorte, Cloud-Tunnels, Partner, redundante Tunnels.
  • Rekeying: Rekey-Intervalle können Lastspitzen auslösen, wenn viele Tunnels gleichzeitig rekeyen.
  • Cipher Suites: beeinflussen die Krypto-Last; planen Sie nicht mit „Minimalverschlüsselung“.

Für IPsec als Standardrahmen eignet sich RFC 4301.

Logging und Reporting: Performance und Betrieb gleichzeitig planen

Security ohne Logging ist blind. Gleichzeitig kann Logging die Firewall belasten und nachgelagerte Systeme überfordern. Capacity Planning muss daher auch die Log-Pipeline betrachten.

  • Log-Volume: Wie viele Events pro Sekunde (EPS) entstehen bei Allow/Deny/Threat?
  • Detailgrad: Full URL, User-ID, App-ID, Threat-Details erhöhen Datenmenge.
  • Transport: Syslog/JSON/Agents; TLS-gesicherte Logübertragung kann zusätzlich Last erzeugen.
  • Pufferung: Bei SIEM-Ausfall müssen Logs zwischengespeichert werden, sonst verlieren Sie Evidence.

Als Referenz für Syslog eignet sich RFC 5424.

Performance-Tests: Wie Sie Datenblattwerte in Ihre Realität übersetzen

Die sicherste Dimensionierung entsteht, wenn Sie messen statt vermuten. Dafür müssen Tests nicht riesig sein, aber sie müssen repräsentativ sein.

  • Proof of Concept: Testen Sie Ihr eigenes Policy-Set, typische Apps, TLS-Inspection-Ausnahmen und IPS-Profile.
  • Replay realer Flows: Wenn möglich, nutzen Sie Traffic-Samples oder synthetische Profile, die Ihrem Flow-Mix ähneln.
  • Failover-Test: HA-Switchover unter Last (Sessions, VPN, NAT) ist ein Muss für Capacity + Verfügbarkeit.
  • Grenzwerte finden: Ab welcher CPU/Dataplane-Auslastung steigen Latenz und Drops? Planen Sie darunter.

Typische Fehler beim Dimensionieren von Firewalls

  • Nur nach „Firewall Throughput“ kaufen: Threat Prevention und TLS-Inspection werden ignoriert.
  • Sessions/CPS vergessen: Besonders bei Web/API/Microservices ist CPS limitierend.
  • HA nicht als N+1 geplant: Failover führt zu Überlast, obwohl Normalbetrieb „okay“ war.
  • Logging unterschätzt: Logs werden entweder reduziert (Sicherheitsverlust) oder überlasten Systeme (Betriebsproblem).
  • Wachstum ignoriert: Cloud-Nutzung, Video und Remote Work treiben Bandbreite und Sessions schnell hoch.
  • Falsche Annahmen über TLS: „Wir inspecten nur ein bisschen“ wird in der Praxis schnell zu „wir müssen mehr sehen“.
  • Keine Tests: Ohne PoC bleibt die Dimensionierung ein Ratespiel.

Praxisleitfaden: Dimensionierung in Zahlen denken

Ein pragmatischer Ansatz ist, Ihre Messwerte in Zielbereiche zu übersetzen und Sicherheitsfeatures als „Performance-Faktoren“ zu behandeln.

  • Schritt: Peak Throughput und Peak Sessions/CPS messen (mindestens 95. Perzentil + Spitzen).
  • Schritt: Feature-Set definieren (IPS, TLS, VPN, URL-Filter) und „Worst Case“-Profil daraus ableiten.
  • Schritt: Reserve einplanen (z. B. 40% Headroom) und Wachstum berücksichtigen (z. B. 2–3 Jahre).
  • Schritt: HA berücksichtigen: Bei Active/Passive muss ein Gerät Peak + Headroom allein tragen.
  • Schritt: PoC/Lasttest: Validieren, dass Latenz, Drops und CPU im Zielbereich bleiben.

Wenn Sie eine einfache Heuristik möchten: Planen Sie so, dass die Firewall im Normalbetrieb mit allen aktivierten Security-Funktionen typischerweise nicht dauerhaft über 60% der relevanten Leistungsindikatoren liegt (Dataplane/CPU/Sessions). Das ist keine Norm, aber ein bewährter Sicherheitsabstand für Peaks, Failover und Incidents.

Ausschreibung und Einkauf: Welche Angaben Sie vom Hersteller brauchen

Um Angebote vergleichbar zu machen, sollten Sie Hersteller nicht nur nach „Gbit/s“ fragen, sondern nach konkreten Szenarien. Eine saubere Ausschreibung enthält Ihr Feature-Profil und fordert Messwerte dazu an.

  • Threat Prevention Throughput: unter aktivierten Profilen (IPS/AV/URL) und typischem Traffic-Mix.
  • TLS Inspection Throughput: inklusive CPS/Handshake-Rate und unterstützten Cipher Suites.
  • Max Sessions und CPS: realistische Werte, nicht nur theoretische Tabellen.
  • VPN Performance: IPsec/SSL-VPN, Tunnelanzahl, Rekey-Verhalten, gleichzeitige Users.
  • HA-Verhalten: State Sync, Failover-Zeit, Session Preservation, getestete Limits.
  • Logging Limits: EPS, Logformat, Exportoptionen, lokale Pufferung.

Herstellerdokumentation kann hier helfen, weil sie die definierten Throughput-Kategorien erklärt, z. B. Palo Alto Networks Docs, Fortinet Docs oder Cisco Security Docs.

Checkliste: Capacity Planning für Firewalls richtig umsetzen

  • Traffic-Profil ist gemessen (mindestens mehrere Wochen): Peak Throughput, Peak Sessions, CPS, Traffic-Mix.
  • Feature-Set ist festgelegt: IPS/Threat Prevention, TLS-Inspection, URL-Filter, VPN, Logging-Detailgrad.
  • Dimensionierung berücksichtigt HA als N+1 (insbesondere Active/Passive) und Failover unter Last.
  • TLS-Inspection ist realistisch kalkuliert (TLS-Anteil, Handshake-Last, Ausnahmen, Zertifikatsbetrieb).
  • VPN ist getrennt betrachtet (Remote Access vs. Site-to-Site) inklusive Rekey- und Tunnel-Lastspitzen.
  • Logging-Pipeline ist dimensioniert (EPS, Retention, Pufferung, SIEM-Ingest), ohne Security-Qualität zu verlieren.
  • PoC/Tests validieren Annahmen: Latenz, Drops, CPU/Dataplane, Session-Stabilität, Failover-Verhalten.
  • Wachstum und Reserve sind eingeplant (Headroom), sodass neue Anforderungen nicht sofort zu Engpässen führen.

Weiterführende Informationsquellen

Related Articles

Cost-Aware Operations: Image Pull Policies, Cache und Bandbreite

Registry Mirror Setup: Pulls beschleunigen und Ausfälle überleben

Air-Gapped Deployments: Images, Dependencies und Updates offline managen

Compose Migration zu Swarm: Wann der Schritt Sinn macht

Compose Migration zu Kubernetes: Mapping von Services, Volumes, Secrets

Kubernetes vs. Compose: Betriebsaufwand, Resilienz und Komplexität

Multi-Host Networking ohne Kubernetes: Optionen und Grenzen

Security Posture Reviews: Threat Modeling für Compose Stacks

Incident Response für Container: Forensik, Artefakte, Evidence

Observability: OpenTelemetry Collector in Compose integrieren

Debugging ohne Shell: Distroless Container in Produktion analysieren

Metrics Pipeline: Prometheus + exporters für Container und Host