Du hast eine Web-App auf einem VPS — React im Frontend, Node.js im Backend, PostgreSQL als Datenbank und Redis für den Cache. Alles läuft gut auf einem Server für 15–30 €/Monat bei Hetzner oder DigitalOcean. Aber irgendwann steigt der Traffic, Kunden wollen SLAs, und du brauchst echte Skalierbarkeit. Dann ist es an der Zeit, sich AWS ernsthaft anzuschauen.
In diesem Artikel gehen wir die passende AWS-Architektur für eine solche Anwendung durch, vergleichen die Kosten konkret und erklären, wie Autoscaling auf EC2 funktioniert — mit echten Zahlen.
Der Ausgangspunkt: der klassische VPS
Das typische Szenario sieht so aus: ein einzelner Server (Hetzner CPX31 — 4 vCPU, 8 GB RAM, 160 GB SSD) für ca. 15 €/Monat, auf dem alles läuft — Node.js, PostgreSQL, Redis und eventuell Nginx als Reverse Proxy. Vielleicht kommt ein zweiter Server für Redundanz dazu, dann bist du bei 30–40 €/Monat gesamt.
Es funktioniert. Aber es gibt grundlegende Probleme: kein Autoscaling (Black-Friday-Traffic kann den Server lahmlegen), kein automatisches Failover (fällt der Server aus, fällt alles aus), Backups sind manuell oder halbautomatisch, und Skalierung heißt „größeren Server kaufen und manuell migrieren“.
Die vorgeschlagene AWS-Architektur
Bei AWS wird dieselbe Anwendung in spezialisierte Dienste aufgeteilt:
Frontend (React) — S3 + CloudFront. Statische Dateien (HTML, CSS, JS) werden aus S3 über das CloudFront-CDN ausgeliefert. Keine Server zu verwalten, geringe Latenz global, vernachlässigbare Kosten bei moderatem Traffic.
Load Balancer — Application Load Balancer (ALB). Verteilt HTTP/HTTPS-Traffic auf die Backend-Instanzen. Kostet ca. 0,0252 $/Stunde fix plus variable Kosten basierend auf LCU (Load Balancer Capacity Units) je nach Traffic.
Backend (Node.js) — EC2 Auto Scaling Group. Mindestens 2 Instanzen t3.medium (2 vCPU, 4 GB RAM) in verschiedenen Availability Zones. Die Auto Scaling Group fügt Instanzen automatisch hinzu oder entfernt sie je nach Traffic.
Datenbank (PostgreSQL) — RDS PostgreSQL. Instanz db.t3.medium mit Multi-AZ für automatisches Failover. Automatische Backups, von AWS verwaltete Patches, Point-in-Time-Wiederherstellung.
Cache (Redis) — ElastiCache. Vollständig verwalteter Knoten cache.t3.medium. Du musst den Redis-Prozess, Updates oder Monitoring nicht mehr selbst verwalten.
Kostenvergleich: VPS vs. AWS
Setzen wir die Zahlen nebeneinander. Preise für die Region eu-central-1 (Frankfurt), On-Demand, ohne Rabatte.
VPS-Szenario (Hetzner)
Ein typisches Produktions-Setup mit zwei Servern für Redundanz kostet ungefähr: zwei CPX31-Server à 15 €/Monat plus Managed Backup ca. 3 €/Monat, insgesamt etwa 33 €/Monat.
AWS-Szenario (On-Demand)
Bei AWS verteilen sich die Kosten auf die Dienste. Zwei EC2 t3.medium-Instanzen (Backend) kommen auf ca. 67 $/Monat (0,046 $/h × 730 h × 2). Der ALB kostet etwa 25 $/Monat (Fixgebühr plus LCUs bei moderatem Traffic). RDS PostgreSQL db.t3.medium Single-AZ liegt bei ~53 $/Monat (0,072 $/h × 730 h), mit Multi-AZ verdoppelt sich das auf etwa 106 $/Monat. ElastiCache Redis cache.t3.medium etwa 50 $/Monat. S3 und CloudFront für das statische Frontend unter 5 $/Monat bei moderatem Traffic. Insgesamt kommt AWS On-Demand auf etwa 200–306 $/Monat, je nach Single-AZ oder Multi-AZ für die Datenbank.
Optimiertes AWS-Szenario
Mit Reserved Instances (1 Jahr, ohne Vorauszahlung) sparst du etwa 30–40 %. Der Gesamtbetrag sinkt auf etwa 130–200 $/Monat. Mit Savings Plans über 1 Jahr geht es noch günstiger. Und mit Graviton-Instanzen (t4g statt t3) gewinnst du weitere 10–20 % beim Preis bei ähnlicher oder besserer Leistung.
Das Kostenurteil
Der VPS ist 5–8 mal günstiger im Rohpreis. Aber du vergleichst Äpfel mit Birnen. AWS bietet: automatisches Failover, verwaltete Backups, elastische Skalierbarkeit, integriertes Monitoring (CloudWatch), Zertifizierung und Compliance (SOC 2, ISO 27001, GDPR) und eine SLA von 99,99 % beim ALB. Wenn du die realen Kosten einrechnest — inklusive deiner Zeit für Administration, Ausfallrisiko und mögliche Verluste — wird der Unterschied deutlich kleiner.
Autoscaling auf EC2: So funktioniert es
Autoscaling ist der Hauptgrund für die Migration zu AWS. Statt rund um die Uhr maximale Kapazität zu bezahlen, zahlst du nur für das, was du nutzt.
Auto Scaling Group (ASG) legt fest: wie viele EC2-Instanzen minimal (z. B. 2), maximal (z. B. 8) und gewünscht (Desired Capacity). Die ASG hält die gewünschte Anzahl bei und ersetzt Instanzen, die Health-Checks nicht bestehen.
Scaling Policies legen fest, wann und wie skaliert wird. Es gibt zwei Hauptansätze.
Target Tracking Scaling — am einfachsten und empfohlen. Du setzt ein Ziel (z. B. „durchschnittliche CPU bei 60 %“), und AWS passt die Anzahl der Instanzen automatisch an, um diesen Wert zu halten. Funktioniert wie ein Thermostat: steigt der Traffic und die CPU über 60 %, werden Instanzen hinzugefügt; sinkt sie, werden sie entfernt.
Step Scaling — für feinere Steuerung. Du definierst Stufen: CPU über 70 % → 1 Instanz hinzufügen; über 90 % → 3 hinzufügen. Nützlich bei vorhersehbarem Traffic und differenzierten Reaktionen.
Metriken zum Skalieren. CPU ist am gebräuchlichsten, aber nicht immer die beste. Für eine Node.js-App kannst du skalieren nach: ALB Request Count per Target (wie viele Anfragen jede Instanz bekommt — ideal für Web-Apps), CPU Utilization (gut für rechenintensive Lasten) oder benutzerdefinierten Metriken über CloudWatch (z. B. Job-Queue-Länge, Antwortlatenz).
Cooldown-Periode — nach dem Hinzufügen einer Instanz wartet die ASG ein Intervall (Standard 300 Sekunden), bevor sie die nächste Skalierungsentscheidung trifft. Verhindert Oszillation: Du willst nicht 10 Instanzen in 10 Sekunden für einen kurzen Spike hinzufügen.
Praktisches Beispiel: Deine App liefert im Schnitt 500 req/s tagsüber und 50 req/s nachts, mit Spitzen von 2000 req/s bei Kampagnen. Du konfigurierst die ASG mit min. 2, max. 8 Instanzen und Target Tracking auf ALBRequestCountPerTarget bei 1000 Anfragen pro Instanz. Nachts laufen 2 Instanzen (~2 $/Tag). Tagsüber hält das System 2–3 Instanzen. Bei einem Spike skaliert es auf 4–5 und wieder runter. Du zahlst nur für die tatsächlich genutzten Stunden.
Was du nicht skalieerst: Datenbank und Redis
Ein wichtiger Punkt — RDS PostgreSQL und ElastiCache skalieren horizontal nicht so einfach wie EC2. Die Datenbank kann Read Replicas für Leselast nutzen, Schreiblast bleibt auf der Primärinstanz. Redis in ElastiCache unterstützt den Cluster-Modus mit Sharding, das erhöht aber die Komplexität.
Praktische Empfehlung: Dimensioniere Datenbank und Redis von Anfang an für den Spitzenbedarf (oder etwas darüber) und skaliere nur die Backend-Schicht (EC2). Das ist einfacher, vorhersehbarer und deckt 90 % der Szenarien ab.
Konkrete Migrationsschritte
Der Migrationsprozess umfasst mehrere Schritte. Zuerst das Deployment des React-Frontends auf S3 mit CloudFront. Dann Einrichtung von RDS PostgreSQL und Datenmigration mit pg_dump und pg_restore. Anschließend Aufsetzen von ElastiCache Redis. Dann Erstellung des AMI (Amazon Machine Image) mit der Node.js-App und Konfiguration von Launch Template und Auto Scaling Group. Der ALB wird vor die ASG gesetzt. Und nicht zuletzt Route 53 für DNS mit geplantem Cutover vom VPS zu AWS.
Realistischer Zeitrahmen für eine vollständige Migration: 2–4 Wochen inklusive Tests und paralleler Laufphase.
Wann es sich lohnt und wann nicht
Migriere zu AWS, wenn: du elastische Skalierbarkeit brauchst, Kunden SLAs und Compliance verlangen, du High Availability ohne manuellen Aufwand willst oder die Anwendung einen VPS überfordert.
Bleib auf dem VPS, wenn: der Traffic vorhersehbar und gering ist, das Budget an erster Stelle steht, das Team klein ist und keine AWS-Erfahrung hat oder die Anwendung ein MVP in der Validierungsphase ist.
Es gibt keine Universalantwort. Aber wenn deine Anwendung Umsatz bringt und jede Stunde Ausfall verlorenes Geld bedeutet, ist AWS kein Kostenpunkt — sondern eine Investition in Stabilität.
Veröffentlicht auf teninvent.ro — TEN INVENT S.R.L. bietet Beratung und Implementierung von AWS-Infrastruktur. Kontaktiere uns für eine kostenlose Bewertung deiner Cloud-Architektur.