Selbst gehostetes n8n auf AWS ECS Fargate: Lasttest-Ergebnisse

Wie viel Traffic kann ein n8n-Setup für 35 $/Monat bewältigen? Wir haben n8n auf AWS ECS Fargate mit der günstigsten Konfiguration bereitgestellt und Webhook-Lasttests durchgeführt, um das herauszufinden.

Das Setup

Architektur: Einzelne Fargate-Task im öffentlichen Subnetz, ALB mit ACM-Zertifikat, RDS mit SSL, Auto-Scaling von 1-3 Tasks bei 70% CPU/Memory-Schwellenwert.

Test-Tool

hey — HTTP-Lastgenerator. Alle Tests trafen einen Webhook-Endpunkt:

POST https://workflow.example.com/webhook/...
Content-Type: application/json
Body: {"test": true}

Test 1: Smoke-Test (1 gleichzeitig)

hey -n 10 -c 1

Ergebnis: Basis-Antwortzeit ~145ms. Der 550ms-Ausreißer ist wahrscheinlich die erste kalte Anfrage mit SSL-Handshake-Overhead.

Test 2: Leichte Last (5 gleichzeitig, 30 Sekunden)

hey -n 100 -c 5 -z 30s

Ergebnis: Bewältigt 12 Anf./s ohne Fehler. p50 bleibt unter 315ms, was für eine 0.25-vCPU-Instanz ausgezeichnet ist. Der p95-Anstieg auf 1.3s deutet auf gelegentliche Garbage-Collection-Pausen oder Node.js-Event-Loop-Konflikte hin — erwartetes Verhalten für diese Stufe.

Latenzverteilung

  0.15s - 0.31s  ████████████████████████████████████████  167 (46%)
  0.31s - 0.46s  ██████████                                 37 (10%)
  0.62s - 0.78s  █                                           5 (1%)
  0.78s - 1.71s  ██                                         22 (6%)

83% der Anfragen werden unter 460ms abgeschlossen. Der lange Schwanz (6% über 780ms) liegt dort, wo n8n's Workflow-Engine wahrscheinlich Datenbank-Migrationen oder interne Verwaltungsaufgaben ausführt.

Test 3: Mittlere Last (20 gleichzeitig, 60 Sekunden)

hey -n 500 -c 20 -z 60s

Ergebnis: Immer noch keine Fehler bei 20 gleichzeitigen Nutzern. Der Durchsatz stieg auf 14 Anf./s, aber die Latenz sprang deutlich an — der Durchschnitt ging von 410ms auf 1.43s. Die 0.25 vCPU ist jetzt klar ausgelastet, mit einer bimodalen Verteilung, die zwei Cluster zeigt: einen um 1.1-1.3s (56% der Anfragen) und einen weiteren um 2.3-2.5s (19% der Anfragen).

Latenzverteilung

  0.36s - 0.85s  ████                                        5 (1%)
  0.85s - 1.33s  ██████████████████████████████████████████ 612 (71%)
  1.33s - 1.81s  ████                                       50 (6%)
  1.81s - 2.29s  ██                                         32 (4%)
  2.29s - 2.77s  █████████████                             166 (19%)

Das bimodale Muster deutet darauf hin, dass die Node.js-Event-Loop Anfragen in die Warteschlange stellt, wenn alle Worker-Threads beschäftigt sind. Der zweite Cluster (2.3-2.5s) repräsentiert Anfragen, die einen vollen Zyklus warten mussten, bevor sie verarbeitet wurden.

Test 4: Nach dem Upgrade (20 gleichzeitig, 0.5 vCPU)

Nach dem Upgrade von 0.25 vCPU / 512MB auf 0.5 vCPU / 1GB haben wir denselben mittleren Lasttest wiederholt.

hey -n 500 -c 20 -z 60s

Die Verdoppelung der CPU lieferte eine 2,5-fache Durchsatzsteigerung und eine 60%ige Latenzreduktion (1.43s auf 568ms Durchschnitt). Die bimodale Verteilung ist verschwunden — 83% der Anfragen werden jetzt unter 622ms abgeschlossen.

Latenzverteilung

  0.29s - 0.46s  ████████████████                               485 (23%)
  0.46s - 0.62s  ████████████████████████████████████████████  1274 (60%)
  0.62s - 0.79s  ██████                                         196 (9%)
  0.79s - 0.95s  █                                                27 (1%)
  0.95s - 1.28s  ███                                              99 (5%)
  1.28s - 1.94s  █                                                35 (2%)

Die Verteilung ist jetzt unimodal — keine Warteschlangeneffekte mehr. Die Node.js-Event-Loop hat genügend CPU-Spielraum, um alle Anfragen ohne Rückstau zu verarbeiten.

Vorher vs. Nachher Upgrade

Wichtigste Erkenntnisse

Kapazität nach Stufe

Auto-Scaling-Verhalten

Der ECS-Service ist so konfiguriert, dass er von 1 auf 3 Tasks skaliert, basierend auf CPU-Auslastung > 70% und Speicherauslastung > 70%.

Mit der 0.5-vCPU-Stufe und 3 laufenden Tasks erreicht die theoretische Kapazität ~105 Anf./s nachhaltig.

Kosten vs. Leistung

Die 0.5-vCPU-Stufe kostet nur ~$5 mehr pro Monat, liefert aber den 2,5-fachen Durchsatz mit 70% niedrigerer p90-Latenz. Dies ist die beste Preisstufe für selbst gehostetes n8n.

Wann hochskalieren?

• p95-Latenz konstant über 2 Sekunden
• Fehlerrate über 1%
• ECS-Auto-Scaling häufig am Maximum (3 Tasks)
• RDS-CPU-Credits erschöpft (CloudWatch CPUCreditBalance prüfen)

Fazit

Ein n8n-Setup für 40 $/Monat auf ECS Fargate (0.5 vCPU, 1GB) bewältigt 35 Anf./s nachhaltig mit unter 700ms p90-Latenz bei 20 gleichzeitigen Nutzern — und null Fehler. Das Upgrade von der minimalen $35-Stufe (0.25 vCPU) auf 0.5 vCPU lieferte eine 2,5-fache Durchsatzsteigerung für nur $5/Monat mehr.

Die wichtigste Erkenntnis: Dieses Setup verwirft niemals Anfragen. Es reiht sie ein und antwortet langsamer unter extremer Last, behält aber eine 0% Fehlerrate über alle Teststufen bei. Mit Auto-Scaling auf 3 Tasks erreicht die Burst-Kapazität ~105 Anf./s.

Für Teams, die weniger als 2.000 Webhook-Aufrufe pro Minute verarbeiten, ist die 0.5-vCPU-Stufe der Sweet Spot zwischen Kosten und Zuverlässigkeit.

Stack: n8n 2.9.4 | ECS Fargate (ARM64/Graviton, 0.5 vCPU, 1GB) | RDS PostgreSQL 17 | ALB + ACM | AWS CDK