AWS zu Contabo Migration: Kostenoptimierungsleitfaden 2026

Ihre AWS-Rechnung am Monatsende lässt Sie die Zähne zusammenbeißen. 157 €/Monat für einen Node.js + Postgres 40 GB + 30 GB statische Objekte Stack, von dem etwa die Hälfte auf RDS und NAT Gateway entfällt. Sie wissen, dass es etwas Günstigeres gibt, zögern jedoch, den Komfort von EC2 und die Magie von S3 aufzugeben. Dieser Leitfaden beschreibt ein repräsentatives AWS-zu-Contabo-Migrationsszenario: von AWS zu einem einzigen Contabo VPS für 5,50 €/Monat, rund 80-85 % Einsparungen über 12 Monate je nach Stack, ohne signifikanten Funktionsverlust für eine vergleichbare kleine bis mittlere Arbeitslast.

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 klein beginnt, kann seine Rechnung ohne sichtbare Funktionsänderung um ein Mehrfaches wachsen sehen. Bei dem repräsentativen Profil, das in diesem Leitfaden beschrieben wird, erreicht die AWS-Rechnung etwa 157 €/Monat für einen Stack, der auf einem einzigen 5,50 €/Monat VPS laufen könnte - eine Größenordnung 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.

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 ein paar Jahren ist das "einfach Umziehen" ein echtes Projekt geworden. 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.

Ü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, 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 viele 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 ausgehend verwalten und Ihr dauerhaft hoher ausgehender Traffic die Fair-Use-Drosselung von Contabo erreicht (Traffic ist „unbegrenzt", unterliegt aber einer Fair-Use-Richtlinie).

Ein typischer Fall für diese Migration: ein einzelnes Node.js-Backend + Postgres + statische Objekte, bei dem jede der obigen Boxen abgehakt ist.

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: 1.884 €. Beachten Sie das Detail: bei diesem Profil machen NAT Gateway + Datentransfer = 59 €/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 4 von Contabo: 4 vCPU, 8 GB RAM, 100 GB SSD, unbegrenzter Traffic (Fair-Use-Richtlinie). 5,50 €/Monat zzgl. MwSt. für die ersten 24 Monate (contabo.com, 19.10.2026). Wenn Ihre Datenbank plus Objekte ~60 GB überschreiten, wechseln Sie zu einem Cloud VPS 6 oder 30 für mehr NVMe.

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. Standardverfahren:

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 40 GB Datenbank erwarten Sie 10-20 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 30 GB: budgetieren Sie 30-60 Minuten, abhängig von der AWS-Ausgangsbandbreite (die Sie ein paar Euro 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 4, erste 24 Monate - 5,50 €/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.597,20 €/Jahr, oder rund 85 % bei diesem repräsentativen Profil. Die genaue Zahl hängt von Ihrem Stack ab: Erstellen Sie diese Tabelle mit Ihrem eigenen Cost-Explorer-Export neu. 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 (1-3 €/Monat für diesen Datensatz 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 bearbeitet Support über Tickets im Kundenpanel (my.contabo.com seit dem 19. Oktober 2026), 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.