Erste Schritte
Zuletzt aktualisiert am
Diese Seite hilft Ihnen bei der Entscheidung, welcher STACKIT-Dienst für Load Balancing und Content Delivery zu Ihrer Workload passt. Sie beantwortet zwei Fragen, die sich den meisten Nutzenden zu Beginn stellen: Welchen Load Balancer sollten Sie verwenden? Und mit welcher Web Application Firewall schützen Sie Ihren Datenverkehr? Wenn Sie sich entschieden haben, folgen Sie den verlinkten Anleitungen, um den Dienst einzurichten.
Voraussetzungen
Abschnitt betitelt „Voraussetzungen“- Sie haben ein STACKIT-Kundenkonto: Kundenkonto erstellen.
- Sie haben ein STACKIT-Nutzerkonto: Nutzerkonto erstellen.
- Sie haben ein STACKIT-Projekt: Projekt erstellen.
Load Balancer auswählen
Abschnitt betitelt „Load Balancer auswählen“STACKIT bietet zwei Load Balancer an. Sie unterscheiden sich vor allem in der OSI-Schicht, auf der sie arbeiten. Diese Schicht bestimmt, wie sie den Datenverkehr weiterleiten. Der Network Load Balancer (NLB) arbeitet auf Schicht 4 (TCP/UDP) und leitet Datenverkehr anhand von IP-Adresse und Port weiter. Der Application Load Balancer (ALB) arbeitet auf Schicht 7 (HTTP/HTTPS) und kann anhand des Inhalts jeder Anfrage weiterleiten.
Hier ist ein direkter Vergleich der beiden Load Balancer, damit Sie auf einen Blick sehen, welcher für Ihren Anwendungsfall besser geeignet ist:
| Dimension | Network Load Balancer (NLB) | Application Load Balancer (ALB) |
|---|---|---|
| OSI-Schicht | Schicht 4 (TCP/UDP) | Schicht 7 (HTTP/HTTPS) |
| Routing-Grundlage | IP-Adresse und Port | Host, Pfad, Header, Query-Parameter |
| TLS-Verarbeitung | TLS-Passthrough | TLS-Offloading und TLS-Bridging |
| Session-Persistenz | Quell-IP | Cookie |
| Firewall-Option | Nicht verfügbar | ALB WAF (pro Listener) |
| Typische Workloads | Datenbanken, Game-Server, eigene TCP/UDP-Protokolle, Datenverkehr mit hohem Durchsatz | Webanwendungen, REST-APIs, inhaltsbasiertes Routing |
Wählen Sie den STACKIT Network Load Balancer, wenn:
- Ihre Workload ein Nicht-HTTP-Protokoll oder rohes TCP/UDP verwendet (zum Beispiel Datenbanken, Message-Broker oder Game-Server).
- Sie maximalen Durchsatz und die geringstmögliche Latenz bei minimalem Verarbeitungsaufwand benötigen.
- die TLS-Session des Clients auf Ihrem Backend enden soll (TLS-Passthrough) und nicht auf dem Load Balancer.
Erfahren Sie mehr über die NLB-Funktionen oder erstellen Sie einen NLB.
Wählen Sie den STACKIT Application Load Balancer, wenn:
- Sie HTTP(S)-Datenverkehr bereitstellen und Anfragen nach Host, Pfad, Header oder Query-Parameter weiterleiten möchten.
- Sie Funktionen auf Schicht 7 benötigen, etwa TLS-Offloading, Cookie-basierte Session-Persistenz oder WebSocket-Unterstützung.
- Sie die Anwendung mit einer Web Application Firewall auf Schicht 7 schützen möchten (die ALB WAF).
Erfahren Sie mehr über die ALB-Funktionen oder erstellen Sie einen ALB.
Web Application Firewall auswählen
Abschnitt betitelt „Web Application Firewall auswählen“STACKIT bietet zwei Web Application Firewalls an. Beide prüfen HTTP(S)-Datenverkehr und blockieren gängige Angriffe wie SQL-Injection und Cross-Site-Scripting (XSS). Dafür nutzen sie das OWASP Core Rule Set. Der entscheidende Unterschied liegt darin, wo im Datenpfad sie ausgeführt werden. Das hängt wiederum davon ab, welches Produkt Sie bereits nutzen.
Die CDN WAF wird am CDN-Edge ausgeführt. Das CDN betreibt weltweit viele Points of Presence (PoPs). Jeder Client wird an den PoP geleitet, der ihm am nächsten liegt (nach Latenz und Nähe). Die CDN WAF prüft die Anfrage dort, bevor sie über die Distribution zu Ihrem Origin fließt.
Die ALB WAF wird auf dem Application Load Balancer ausgeführt. Dieser ist ein einzelner Eintrittspunkt, der den Datenverkehr aller Clients empfängt. Er prüft den Datenverkehr auf Schicht 7 pro Listener, bevor er ihn an Ihre Zielpools verteilt.
Die folgende Abbildung veranschaulicht beide Fälle:
Hier ist ein direkter Vergleich der beiden Web Application Firewalls, damit Sie auf einen Blick sehen, welche für Ihren Anwendungsfall besser geeignet ist:
| Dimension | ALB WAF | CDN WAF |
|---|---|---|
| Ausführungsort | Auf dem Application Load Balancer, pro Listener | Am CDN-Edge, pro Distribution |
| Voraussetzung | Ein STACKIT Application Load Balancer | Eine STACKIT CDN-Distribution |
| Eigene Regeln | Eigene Regelgruppen (strukturierte SecLang-Abstraktion) | Auf der Roadmap (Premium-Tarif) |
| Am besten für | Schutz von Apps hinter dem ALB, inklusive nicht gecachtem und internem Datenverkehr | Schutz von gecachten, weltweit ausgelieferten Inhalten am Edge |
ALB WAF
Abschnitt betitelt „ALB WAF“Nutzen Sie die STACKIT Application Load Balancer Web Application Firewall, wenn:
- Ihrem Datenverkehr ein Application Load Balancer vorgelagert ist und Sie Schutz auf Schicht 7 direkt am Load Balancer möchten.
- Sie zusätzlich zu den verwalteten OWASP-Regeln anwendungsspezifische Erkennungslogik über eigene Regelgruppen benötigen.
- Sie Datenverkehr schützen möchten, der nicht über ein CDN fließt, etwa interne oder nicht cachebare Anfragen.
Erfahren Sie mehr über die ALB WAF Funktionen.
CDN WAF
Abschnitt betitelt „CDN WAF“Nutzen Sie die STACKIT Content Delivery Network Web Application Firewall, wenn:
- Ihre Inhalte bereits über eine STACKIT CDN-Distribution ausgeliefert werden und Sie bösartige Anfragen am Edge blockieren möchten.
- Sie Angriffe stoppen möchten, bevor sie Ihr Origin erreichen, und so Ihr Backend entlasten.
- Sie Steuerungsmöglichkeiten auf Edge-Ebene möchten, etwa Paranoia-Level und das Allow-Listing von Anfragen, zusätzlich zum Caching.
Erfahren Sie mehr über die CDN WAF Funktionen oder wie Sie Ihre CDN WAF verwalten.