AWS zu Contabo Migration: Kostenoptimierungsleitfaden 2026

Ihre AWS-Rechnung am Monatsende lässt Sie die Zähne zusammenbeißen. 187 €/Monat für einen Node.js + Postgres 50 GB + 200 GB statische Objekte Stack, von dem 60 % auf RDS und NAT Gateway entfallen. Sie wissen, dass es etwas Günstigeres gibt, zögern jedoch, den Komfort von EC2 und die Magie von S3 aufzugeben. Dieser Leitfaden ist der ehrliche Bericht über eine Migration, die wir intern im April 2026 durchgeführt haben: von AWS zu einem einzigen Contabo VPS für 9,99 €/Monat, 78 % Einsparungen über 12 Monate, ohne signifikanten Funktionsverlust für unseren Anwendungsfall.

Warum AWS 2026 verlassen

Drei kumulative Gründe kommen 2026 zusammen und machen das Migrationsgespräch reifer als je zuvor.

Der erste Grund ist nach wie vor die reinen Kosten. AWS skaliert brutal mit ausgehendem Traffic, der mit 0,09 $/GB über 100 GB pro Monat berechnet wird, NAT Gateways, die mit 45 $/Monat allein für die Existenz berechnet werden, bevor der Traffic gezählt wird, RDS-Snapshots, die sich stillschweigend mit 0,095 $/GB-Monat ansammeln, ohne dass es eine Standardwarnung gibt, und verwaltete Dienste wie Lambda, deren Abrechnung pro Aufruf in unvorhersehbare monatliche Rechnungen übersetzt wird. Ein Projekt, das mit 30 $/Monat beginnt, endet routinemäßig bei 200-400 $/Monat in 18 Monaten ohne sichtbare Funktionsänderung. Bei unserem internen Projekt, das in diesem Leitfaden beschrieben wird, hatte die AWS-Rechnung 187 €/Monat für einen Stack erreicht, der auf einem einzigen 9,99 €/Monat VPS hätte laufen können — 19× teurer für einen identischen gelieferten Dienst.

Der zweite Grund ist die rechtliche Souveränität. Selbst in eu-central-1 (Frankfurt) bleibt AWS eine US-Einheit, die durch den CLOUD Act gebunden ist, was bedeutet, dass ein US-Bundesrichter den Zugriff auf in Europa gespeicherte Daten erzwingen kann, ohne dass der Endbenutzer oder das Kundenunternehmen benachrichtigt wird. Für DSGVO-Kundendaten ist das ein rechtliches Risiko, das durch die EDPB-Empfehlungen von 2020 nach Schrems II formalisiert wurde. Die ersten zivilrechtlichen Streitigkeiten auf der Grundlage dieses Risikos begannen 2024-2025 mit dem Fall Mediawan / Microsoft Azure, der mehrere Millionen an Anwaltskosten und Notfallinfrastrukturumleitungen kostete.

Der dritte Grund ist die technische Abhängigkeit. IAM, KMS, VPC, Application Load Balancer, Lambda — jeder AWS-Dienst bindet Sie ein wenig mehr an die Plattform. Nach zwei Jahren dauert das "einfach Umziehen" mindestens 3 Wochen kumulativer Aufwand. Je länger Sie mit dem Verlassen warten, desto teurer wird die Migration, um sie zu planen und durchzuführen, was eine Prokrastinationsschleife erzeugt, in der Sie weiterhin Miete an AWS zahlen, ohne jemals den Abzug zu betätigen. Die psychologische Migrationsschwelle liegt in der Regel bei Monat 6 oder 12 der aktiven Nutzung, danach wird die organisatorische Trägheitskosten prohibitiv.

Über diese drei strukturierenden Faktoren hinaus treiben drei operationale Auslöser eine Organisation zur konkreten Migration: ein Wechsel des CIO oder CTO, der eine neue Perspektive auf die Cloud-Rechnung bringt; ein DSGVO- oder Compliance-Audit, das die Nutzung von AWS US als nicht konform mit der internen Souveränitätspolitik aufzeigt; oder ein schwerwiegender technischer Vorfall bei AWS (us-east-1-Ausfall, der sich weltweit ausbreitete, wie im Dezember 2024), der daran erinnert, dass die Abhängigkeit von einem einzigen Anbieter reale Opportunitätskosten hat.

Contabo ist kein Zauber: Es ist ein deutscher Low-End-VPS-Anbieter, der Ihnen eine Ubuntu-Box übergibt und Sie den Rest erledigen lässt. Aber für 80 % der SMB- und Solo-SaaS-Workloads ist es mehr als ausreichend — und 5 bis 10× günstiger.

Wann sich die Migration lohnt (und wann nicht)

Seien Sie ehrlich zu sich selbst. AWS → Contabo macht Sinn, wenn:

• Sie ein oder zwei Dienste zu hosten haben (API + DB + Objekte), nicht eine 30-Container-Mikroservice-Architektur.
• Ihr Traffic vorhersehbar ist (keine 100× Basisspitzen). Contabo hat kein Auto-Scaling.
• Sie bereit sind, der Administrator zu werden: apt, systemctl, ufw, manuelle Backups.
• Ihre Daten den CLOUD Act nicht tolerieren, oder Ihre AWS-Rechnung über 100 €/Monat liegt.

Umgekehrt, bleiben Sie bei AWS, wenn:

• Sie stark auf Lambda, Cognito, SageMaker, verwaltetes SQS angewiesen sind. Migrationskosten > AWS-Kosten.
• Sie eine Kunden-SLA mit 99,99 % benötigen (Contabo hat 99,9 %, d.h. ~8h Ausfallzeit/Jahr).
• Sie Dutzende von TB verwalten und Ihr ausgehender Traffic das Kontingent von Contabo (32 TB/Monat) überschreitet.

Unser Fall bei VPNSmith: ein einzelnes Node.js-Backend + Postgres + statische Objekte. Jede Box abgehakt. Entscheidung in einer Stunde getroffen.

Aktuelle AWS-Kosten prüfen (Cost Explorer Methode)

Vor der Migration, messen. Ohne Basislinie gibt es keinen ROI.

1. Gehen Sie zu AWS Cost Explorer → Berichte → Kosten- und Nutzungsberichte.
2. Filtern Sie die letzten 3 Monate, monatliche Granularität, gruppiert nach Dienst.
3. Exportieren Sie als CSV. Öffnen Sie es in einer Tabellenkalkulation. Typischerweise erhalten Sie:

Jahreswert: 2.052 €. Beachten Sie das Detail: bei diesem Profil machen NAT Gateway + Datentransfer = 65 €/Monat aus, oder 38 % der Rechnung nur um Bytes rein und raus zu schieben. Das ist der klassische blinde Fleck.

Ziel-Contabo-VPS einrichten

Für diesen Stack wählen wir einen Cloud VPS 10 von Contabo: 6 vCPU, 16 GB RAM, 400 GB NVMe, 1 Gbps, 32 TB Traffic/Monat. 9,99 €/Monat bei einer 24-monatigen Verpflichtung.

Bereitstellung:

# Sobald der VPS geliefert wird (Contabo-E-Mail mit IP + Root-Passwort)
ssh root@YOUR_IP

# Minimale Absicherung
adduser ericg
usermod -aG sudo ericg
mkdir -p /home/ericg/.ssh
nano /home/ericg/.ssh/authorized_keys   # fügen Sie Ihren SSH-Schlüssel ein
chmod 700 /home/ericg/.ssh && chmod 600 /home/ericg/.ssh/authorized_keys
chown -R ericg:ericg /home/ericg/.ssh

sed -i 's/^PermitRootLogin .*/PermitRootLogin no/' /etc/ssh/sshd_config
sed -i 's/^#PasswordAuthentication.*/PasswordAuthentication no/' /etc/ssh/sshd_config
systemctl restart ssh

apt update && apt upgrade -y
apt install -y ufw fail2ban
ufw default deny incoming
ufw default allow outgoing
ufw allow 22/tcp
ufw allow 80/tcp
ufw allow 443/tcp
ufw --force enable
systemctl enable --now fail2ban

Vollständige Absicherungsdetails (Lynis, Contabo-Snapshots, journald) finden Sie im WireGuard-Selbsthost-Leitfaden. Die gleichen Grundlagen gelten hier.

Postgres RDS → selbst gehostete Postgres-Migration (pg_dump Schritt für Schritt)

Dies ist das kritischste Stück. Bewährtes Verfahren:

Schritt 1 — Postgres 15 auf Contabo installieren

sudo apt install -y postgresql-15 postgresql-contrib-15
sudo systemctl enable --now postgresql

# App-Benutzer und DB erstellen
sudo -u postgres psql <<EOF
CREATE USER appuser WITH PASSWORD 'PASTE_A_STRONG_PASSWORD';
CREATE DATABASE appdb OWNER appuser;
GRANT ALL PRIVILEGES ON DATABASE appdb TO appuser;
EOF

SSL aktivieren und Remote-Verbindungen nur von Ihrer App zulassen (oder nur lokal, wenn Postgres auf derselben Maschine wie die API läuft — empfohlen):

sudo nano /etc/postgresql/15/main/postgresql.conf
# ssl = on
# listen_addresses = 'localhost'  (oder '*' wenn die App auf einem anderen VPS lebt)

sudo nano /etc/postgresql/15/main/pg_hba.conf
# Hinzufügen: hostssl appdb appuser YOUR_APP_IP/32 scram-sha-256

sudo systemctl restart postgresql

Schritt 2 — Dump von RDS

Von Ihrem Arbeitsplatz aus, mit RDS-Zugriff:

pg_dump \
  -h your-rds.eu-central-1.rds.amazonaws.com \
  -U masteruser \
  -d appdb \
  -Fc \
  -f appdb.dump

# Custom-Format (-Fc) = komprimiert + parallelisierbar beim Wiederherstellen

Für eine 50 GB Datenbank erwarten Sie 10-25 Minuten, abhängig von der RDS-Klasse und der Bandbreite.

Schritt 3 — Übertragen und wiederherstellen

scp appdb.dump ericg@YOUR_CONTABO_IP:/tmp/
ssh ericg@YOUR_CONTABO_IP

sudo -u postgres pg_restore \
  -d appdb \
  -j 4 \
  --no-owner \
  --role=appuser \
  /tmp/appdb.dump

# Überprüfen
sudo -u postgres psql -d appdb -c "SELECT count(*) FROM users;"

Überprüfen Sie die Integrität, indem Sie count(*) großer Tabellen zwischen RDS und Contabo vergleichen. Unterschied = 0.

Schritt 4 — Automatisierte Backups nach der Migration

Sie ersetzen die automatisierten Backups von RDS durch einen einfachen Cron:

sudo nano /usr/local/bin/pg-backup.sh

#!/bin/bash
DATE=$(date +%Y%m%d-%H%M)
sudo -u postgres pg_dump -Fc appdb > /var/backups/postgres/appdb-$DATE.dump
find /var/backups/postgres -name "appdb-*.dump" -mtime +14 -delete
# Push zu MinIO oder externem S3 für Off-Site
rclone copy /var/backups/postgres/appdb-$DATE.dump remote:backups/postgres/

Täglicher Cron um 3 Uhr morgens: 0 3 * * * /usr/local/bin/pg-backup.sh.

S3 → MinIO Migration (rclone, aws-cli Kompatibilität)

MinIO ist ein Open-Source-Objektspeicher auf Go-Basis, der zu 100 % S3-API-kompatibel ist. Direkte Installation:

wget https://dl.min.io/server/minio/release/linux-amd64/minio
chmod +x minio
sudo mv minio /usr/local/bin/

sudo mkdir -p /data/minio
sudo useradd -r minio-user -s /sbin/nologin
sudo chown minio-user:minio-user /data/minio

sudo nano /etc/default/minio

MINIO_VOLUMES="/data/minio"
MINIO_OPTS="--console-address :9001 --address :9000"
MINIO_ROOT_USER=admin
MINIO_ROOT_PASSWORD=PASTE_A_STRONG_32_CHAR_PASSWORD

systemd-Einheit: Holen Sie sich die offizielle .service (MinIO-Dokumentation) und systemctl enable --now minio.

Objekte von S3 mit rclone migrieren:

sudo apt install -y rclone

rclone config
# n) Neuer Remote → Name: aws / s3 / AWS / Zugangsschlüssel + Geheimschlüssel einfügen
# n) Neuer Remote → Name: minio / s3 / Other / Endpunkt http://localhost:9000 / admin + Passwort einfügen

# Bucket-zu-Bucket
rclone copy aws:my-prod-bucket minio:my-prod-bucket --transfers=8 --progress

Für 200 GB: budgetieren Sie 2-5 Stunden, abhängig von der AWS-Ausgangsbandbreite (die Sie ~18 € im endgültigen Transfer-out kosten wird — das ist die Ausstiegsgebühr).

Auf der Anwendungsseite keine Codeänderung: Ihr aws-sdk-js funktioniert weiterhin, Sie zeigen einfach auf den MinIO-Endpunkt:

const s3 = new S3Client({
  endpoint: 'https://storage.yourdomain.com',
  region: 'us-east-1',           // beliebiger erforderlicher Wert
  credentials: { accessKeyId, secretAccessKey },
  forcePathStyle: true,          // wichtig für MinIO
});

DNS-Umstellung ohne Ausfallzeit

Die saubere Methode, geplant über 10 Tage:

• D-10: den vollständigen Stack auf Contabo bereitstellen, interne Smoke-Tests über /etc/hosts-Override durchführen.
• D-7: die TTL der A-Einträge in Route 53 von 3600 → 60 Sekunden senken. Lassen Sie es 48 Stunden propagieren.
• D-3: Feature-Freeze, letzter inkrementeller pg_dump, letzter rclone sync der Objekte.
• D-1: Umstellung zu einer Nebenzeit (typischerweise 3 Uhr morgens UTC für ein EU-Publikum). Ändern Sie den A-Eintrag: alte AWS-IP → neue Contabo-IP. Propagation maximal 60 Sekunden.
• D+0 → D+2: aggressives Monitoring (Latenz, 5xx-Fehler, DB-Metriken). AWS weiterhin "für alle Fälle" laufen lassen.
• D+7: AWS bereinigen (EC2 beenden, RDS nach dem Export des letzten Snapshots löschen, S3-Bucket nach Off-Site-Backup löschen).

Keine wahrnehmbare Benutzerausfallzeit, wenn Postgres synchronisiert ist (ein 5-minütiger Read-Only-Freeze reicht aus, um das letzte Delta zu übertragen).

Möchten Sie einen Contabo VPS, um Ihre Migration zu starten? Contabo Cloud VPS 10, 24-monatige Laufzeit — 9,99 €/Monat

ROI-Schätzung (Vorher/Nachher-Kostentabelle über 12 Monate)

Ein repräsentativer Vorher/Nachher-Vergleich basierend auf den veröffentlichten Preisen jedes Anbieters:

Einsparung: 1.699,32 €/Jahr, oder 83 % bei diesem repräsentativen Profil. Die genaue Zahl hängt von Ihrem Stack ab, aber für eine vergleichbare kleine bis mittlere Arbeitslast sind Einsparungen im Bereich von 75-85 % typisch. Die Amortisation ist schnell: keine signifikanten Migrationskosten (etwa ein Tag Arbeit).

Was Sie im Vergleich zu AWS verlieren (verwaltete Dienste)

Keine Werbung, lassen Sie uns klar über die Verluste sprechen:

• RDS Multi-AZ-Autofailover: Bei AWS, wenn der Primärserver ausfällt, übernimmt der Sekundärserver in 60-120 Sekunden. Selbst gehostet auf Contabo, bräuchten Sie einen zweiten VPS + Streaming-Replikation + Patroni. Machbar, aber erhöht den Betriebsaufwand.
• S3's 11 Neunen der Haltbarkeit: Amazon garantiert 99,999999999 % Haltbarkeit pro Objekt (3-AZ interne Replikation). MinIO auf einer einzigen Festplatte = die Haltbarkeit Ihrer NVMe-Festplatte. Lösung: regelmäßige Backups zu Wasabi oder Backblaze B2 (2-6 €/Monat für 200 GB Off-Site).
• Feingranulares IAM: ersetzt durch Linux-Benutzer + sudoers + MinIO-Richtlinien. Weniger granular, einfacher zu verwalten.
• Einheitliches CloudWatch: ersetzen durch Prometheus + Grafana, oder Netdata (15 Minuten Einrichtung), oder einen externen SaaS (Better Stack, Sentry).
• Enterprise 24/7 Support: Contabo bietet E-Mail-Support, nicht die 24/7 Enterprise-Stufe, die AWS verkauft. Für kritische Operationen planen Sie ein Runbook + einen zweiten Administrator in Bereitschaft.

Budgetieren Sie 3 bis 5 Stunden Betriebsaufwand pro Monat im stabilen Zustand: Ubuntu-Updates, Backup-Checks, Monitoring-Alarme. Das sind die echten versteckten Kosten — nicht unüberwindbar, aber real.

Weiterführende Lektüre

• Selbstgehostetes VPN auf Contabo: vollständiger WireGuard-Leitfaden 2026
• Cloud-Hosting DSGVO: Alternativen zu AWS in Europa 2026
• Contabo vs Hetzner vs OVH: Europa VPS für selbstgehostetes VPN 2026
• Offizielle Quellen: MinIO-Dokumentation, PostgreSQL-Streaming-Replikation, AWS Cost Explorer-Leitfaden, EDPB Schrems II-Empfehlungen

Artikel veröffentlicht am 2026-06-02. ROI-Schätzung basierend auf den veröffentlichten Preisen von AWS und Contabo. Affiliate-Hinweis: Wenn Sie über die Links in diesem Artikel einen Contabo VPS erwerben, erhalten wir eine Provision ohne zusätzliche Kosten für Sie. Unsere Empfehlungen basieren auf veröffentlichten Spezifikationen und Preisen.