Migration AWS → Contabo : guide cost optimization 2026

Ta facture AWS de fin de mois te fait grincer des dents. Près de 190 €/mois pour une stack Node.js + Postgres 40 Go + 30 Go d'objets statiques, dont une grande part part en RDS et NAT Gateway. Tu sais qu'il existe moins cher, mais tu hésites à abandonner le confort d'EC2 et la magie de S3. Ce guide détaille la migration d'une telle stack vers un seul VPS Contabo à 5,50 €/mois, avec une économie de l'ordre de 75-85 % sur 12 mois d'après les prix publics, sans perte de fonctionnalité significative pour ce type de cas d'usage.

Pourquoi quitter AWS en 2026

Trois raisons cumulatives convergent en 2026 et rendent la conversation de migration plus mûre qu'elle n'a jamais été.

La première raison reste le coût brut. L'addition AWS scale brutalement avec le trafic sortant facturé à 0,09 $/Go au-delà de 100 Go par mois, les NAT Gateways facturés à 45 $ par mois rien que pour exister sans même compter le trafic, les snapshots RDS qui s'empilent silencieusement à 0,095 $/Go-mois sans alarme par défaut, et les services managés type Lambda dont la facturation par invocation se traduit en facture mensuelle imprédictible. Un projet qui démarre à 30 $/mois finit fréquemment à 200-400 $/mois en 18 mois sans changement de feature visible. Sur notre projet interne décrit dans ce guide, la facture AWS avait atteint 187 €/mois pour une stack qui aurait pu tourner sur un VPS unique à 5,50 €/mois - soit un ordre de grandeur plus cher pour un service rendu identique.

La deuxième raison est la souveraineté juridique. Même en région eu-central-1 à Frankfurt, AWS reste une entité américaine soumise au CLOUD Act, ce qui veut dire qu'un juge fédéral US peut exiger l'accès à des données stockées en Europe sans que l'utilisateur final ou l'entreprise cliente ne soit notifié. Pour des données clients RGPD, c'est un risque juridique formalisé par les recommandations EDPB de 2020 post-Schrems II. Les premiers contentieux civils basés sur ce risque ont commencé à émerger en 2024-2025 avec l'affaire Mediawan / Microsoft Azure qui a coûté plusieurs millions en frais d'avocats et redirection d'infrastructure d'urgence.

La troisième raison est le verrouillage technique. IAM, KMS, VPC, Application Load Balancer, Lambda - chaque service AWS te lie un peu plus à la plateforme. Au bout de 2 ans, « juste déménager » prend 3 semaines minimum d'effort cumulé. Plus tu attends pour partir, plus la migration devient coûteuse à projeter et donc à faire, ce qui crée une boucle de procrastination où on continue à payer une rente à AWS sans jamais déclencher la décision. Le seuil psychologique de migration se situe généralement vers le sixième ou douzième mois d'usage actif, après quoi le coût d'inertie organisationnel devient prohibitif.

Au-delà de ces trois facteurs structurants, trois déclencheurs opérationnels font basculer une organisation vers la migration concrète : un changement de DSI ou de CTO qui apporte un regard neuf sur la facture cloud ; un audit RGPD ou de conformité qui pointe du doigt l'utilisation d'AWS US comme non-conforme à la politique interne de souveraineté ; ou un incident technique majeur AWS (panne us-east-1 propagée mondialement comme en décembre 2024) qui rappelle que la dépendance à un fournisseur unique a un coût d'opportunité réel.

Contabo n'est pas magique : c'est un fournisseur allemand de VPS bas de gamme qui te livre une machine Ubuntu et te laisse faire le reste. Mais pour 80 % des workloads SaaS de PME / solopreneurs, c'est largement suffisant - et 5 à 10× moins cher.

Cas d'usage où la migration vaut le coup (et où elle ne vaut pas)

Sois honnête avec toi-même. La migration AWS → Contabo a du sens si :

• Tu as un ou deux services à héberger (API + DB + objets), pas une architecture micro-services à 30 conteneurs.
• Ton trafic est prévisible (pas de pic 100× la baseline). Contabo n'a pas d'auto-scaling.
• Tu acceptes de devenir admin : apt, systemctl, ufw, backups manuels.
• Tes données ne tolèrent pas le CLOUD Act, ou ta facture AWS dépasse 100 €/mois.

À l'inverse, reste sur AWS si :

• Tu utilises lourdement Lambda, Cognito, SageMaker, SQS managé. Le coût migration > coût AWS.
• Tu as un SLA contractuel client qui exige 99,99 % (Contabo c'est 99,9 %, soit ~8h de downtime/an).
• Tu manipules des dizaines de To en sortie et ton trafic sortant soutenu est assez élevé pour atteindre la limite fair-use de Contabo (trafic « illimité » mais soumis à une politique fair-use).

Notre cas chez VPNSmith : un seul backend Node.js + Postgres + objets statiques. Cocher tous les "oui". Décision prise en 1 heure.

Audit coût AWS actuel (méthode Cost Explorer)

Avant de migrer, mesure. Sans baseline, pas de ROI.

1. Va dans AWS Cost Explorer → Reports → Cost & Usage Reports.
2. Filtre sur les 3 derniers mois, granularité mensuelle, regroupé par Service.
3. Exporte en CSV. Ouvre dans un tableur. Tu obtiens typiquement :

Sur 12 mois : 1 884 €. Note bien le détail : sur ce profil, NAT Gateway + Data Transfer = 59 €/mois, soit 38 % de la facture juste pour faire entrer/sortir des octets. C'est l'angle mort classique.

Setup VPS Contabo cible

Pour cette stack, on prend un Cloud VPS 10 Contabo : 4 vCPU, 8 Go RAM, 75 Go NVMe, trafic illimité (politique fair-use). Tarif 5,50 €/mois en engagement 12 mois. Si ta base plus tes objets dépassent ~60 Go, passe à un Cloud VPS 20 ou 30 pour le NVMe supplémentaire.

Provisioning :

# Une fois le VPS reçu (email Contabo avec IP + root password)
ssh root@TON_IP

# Hardening minimal
adduser ericg
usermod -aG sudo ericg
mkdir -p /home/ericg/.ssh
nano /home/ericg/.ssh/authorized_keys   # coller la clé SSH
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

Le détail complet du durcissement (Lynis, snapshots Contabo, journald) est dans le guide WireGuard self-host. On reprend les mêmes bases ici.

Migration Postgres RDS → Postgres self-hosted (pg_dump pas-à-pas)

C'est la pièce la plus critique. Procédure éprouvée :

Étape 1 - Installer Postgres 15 sur Contabo

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

# Créer l'utilisateur app et la DB
sudo -u postgres psql <<EOF
CREATE USER appuser WITH PASSWORD 'COLLE_UN_MDP_FORT';
CREATE DATABASE appdb OWNER appuser;
GRANT ALL PRIVILEGES ON DATABASE appdb TO appuser;
EOF

Active SSL et autorise les connexions distantes uniquement depuis ton app (ou en local si Postgres tourne sur la même machine que l'API - recommandé) :

sudo nano /etc/postgresql/15/main/postgresql.conf
# ssl = on
# listen_addresses = 'localhost'  (ou '*' si app sur autre VPS)

sudo nano /etc/postgresql/15/main/pg_hba.conf
# Ajouter : hostssl appdb appuser TON_IP_APP/32 scram-sha-256

sudo systemctl restart postgresql

Étape 2 - Dump depuis RDS

Depuis ton poste, avec accès RDS :

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

# Format custom (-Fc) = compressé + parallélisable au restore

Pour une base de 40 Go, compter 10-20 min selon la classe RDS et la bande passante.

Étape 3 - Transfert et restore

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

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

# Vérifier
sudo -u postgres psql -d appdb -c "SELECT count(*) FROM users;"

Vérifie l'intégrité en comparant les count(*) des grosses tables entre RDS et Contabo. Différence = 0.

Étape 4 - Backup automatique post-migration

Tu remplaces RDS automated backups par un cron simple :

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 vers MinIO ou S3 externe pour off-site
rclone copy /var/backups/postgres/appdb-$DATE.dump remote:backups/postgres/

Cron quotidien à 3h du matin : 0 3 * * * /usr/local/bin/pg-backup.sh.

Migration S3 → MinIO (rclone, compatibilité aws-cli)

MinIO est un serveur de stockage objet 100 % compatible API S3, open source, Go. Installation directe :

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=COLLE_UN_MDP_FORT_DE_32_CHARS

Service systemd : récupère le .service officiel (docs MinIO) et systemctl enable --now minio.

Migration des objets depuis S3 avec rclone :

sudo apt install -y rclone

rclone config
# n) New remote → name: aws / s3 / AWS / colle access_key + secret_key
# n) New remote → name: minio / s3 / Other / endpoint http://localhost:9000 / colle admin + mdp

# Bucket-to-bucket
rclone copy aws:mon-bucket-prod minio:mon-bucket-prod --transfers=8 --progress

Pour 30 Go : compter 30-60 min selon bande passante AWS sortante (qui te coûtera quelques euros de transfer-out final, c'est le coût d'évasion).

Côté code applicatif, aucun changement : ton SDK aws-sdk-js continue de fonctionner, tu pointes juste sur l'endpoint MinIO :

const s3 = new S3Client({
  endpoint: 'https://storage.tondomaine.com',
  region: 'us-east-1',           // valeur arbitraire requise
  credentials: { accessKeyId, secretAccessKey },
  forcePathStyle: true,          // important pour MinIO
});

DNS bascule sans downtime

La méthode propre, planifiée sur 10 jours :

• J-10 : déployer la stack complète sur Contabo, smoke-test interne via /etc/hosts override.
• J-7 : réduire le TTL des records A dans Route 53 de 3600 → 60 secondes. Laisser propager 48h.
• J-3 : freeze des features, dernier pg_dump incrémental, dernier rclone sync des objets.
• J-1 : bascule en heure creuse (typiquement 3h du matin UTC pour un public EU). Modifier l'enregistrement A : ancien IP AWS → nouveau IP Contabo. Propagation max 60s.
• J+0 → J+2 : monitoring agressif (latence, erreurs 5xx, métriques DB). Garder AWS allumé "au cas où".
• J+7 : cleanup AWS (terminate EC2, delete RDS snapshot final exporté, delete bucket S3 après backup off-site).

Aucun downtime perceptible utilisateur si Postgres est sync (read-only freeze de 5 min suffit pour basculer le delta final).

Tu veux un VPS Contabo pour démarrer la migration ? Cloud VPS 10 Contabo, engagement 12 mois - 5,50 €/mois

Estimation du ROI (tableau coût avant/après sur 12 mois)

Une comparaison avant/après représentative, basée sur les prix publics de chaque fournisseur :

Économie : 1 597,20 € / an, soit environ 85 % sur ce profil représentatif. Le chiffre exact dépend de ta stack, mais pour une charge comparable de petite à moyenne taille, une économie dans la fourchette 75-85 % est typique. Le payback est rapide : pas de coût de migration significatif (environ une journée de travail).

Ce qu'on perd vs AWS (managed services)

Pas de marketing, soyons clairs sur les pertes :

• RDS auto-failover Multi-AZ : sur AWS, si la primary tombe, la secondary prend la main en 60-120s. Sur Contabo en self-host, il faut un second VPS + streaming replication + Patroni. C'est faisable mais ça ajoute du temps ops.
• S3 11 nines de durabilité : Amazon garantit 99,999999999 % de durabilité par objet (réplication interne 3 AZ). MinIO sur 1 disque = la durabilité de ton disque NVMe. Solution : backups réguliers vers Wasabi ou Backblaze B2 (1-3 €/mois pour ce dataset off-site).
• IAM granulaire : remplacé par utilisateurs Linux + sudoers + MinIO policies. Moins fin, plus simple à gérer.
• CloudWatch unifié : à remplacer par Prometheus + Grafana ou Netdata (15 min de setup) ou un SaaS externe (Better Stack, Sentry).
• Support 24/7 entreprise : Contabo propose un support par email, pas l'offre entreprise 24/7 que vend AWS. Pour du critique, prévois un runbook + un second admin de garde.

Compter 3 à 5 heures d'ops par mois en régime de croisière : MAJ Ubuntu, vérif backups, monitoring alerts. C'est le vrai coût caché - pas insurmontable, mais réel.

Pour aller plus loin

• Self-host VPN sur Contabo : guide WireGuard complet 2026
• Cloud hosting GDPR : alternatives à AWS en Europe 2026
• Contabo vs Hetzner vs OVH : VPS Europe pour VPN self-host 2026
• Sources officielles : MinIO docs, PostgreSQL streaming replication, AWS Cost Explorer guide, EDPB Schrems II recommendations

Article publié le 2026-06-02. ROI estimé d'après les prix publics d'AWS et de Contabo. Divulgation affiliée : si tu prends un VPS Contabo via les liens de cet article, on touche une commission sans surcoût pour toi. Nos recommandations s'appuient sur les specs et prix publiés.