Migrer depuis AWS S3 vers Hetzner Object Storage : tutoriel 2026

📍 Article principal : Hetzner Object Storage 2026

Introduction

Une plateforme de partage de documents médicaux à Dakar payait depuis 2022 une facture AWS S3 + CloudFront mensuelle de 280 dollars pour servir 4 To de PDF aux praticiens et patients ouest-africains. La répartition de la facture : 92 dollars en stockage S3 Frankfurt, 180 dollars en frais d’egress vers les utilisateurs, 8 dollars en requêtes API. La migration progressive vers Hetzner Object Storage Falkenstein avec Cloudflare en frontal a ramené la facture à 26 euros par mois (24 euros stockage Hetzner, 2 euros divers, 0 dollar Cloudflare Free), soit une économie annuelle de 3 000 dollars. La migration s’est faite en cinq semaines sans interruption de service. Ce tutoriel décrit le plan exact suivi : audit initial, copie en parallèle, dual-write applicatif, bascule progressive, vérification, et nettoyage final. À la fin, vous avez un playbook applicable à n’importe quelle migration S3 vers Hetzner.

Prérequis

• Bucket AWS S3 source avec credentials de lecture
• Bucket Hetzner Object Storage cible créé
• rclone installé localement ou sur un serveur de transfert
• Code applicatif modifiable pour basculer la cible storage
• Niveau : intermédiaire avancé — Temps : 2 heures pour parcourir, 3-6 semaines pour la migration complète

Étape 1 — Audit du bucket source

Avant toute action, on cartographie ce qui existe. Trois métriques à mesurer. Le volume total stocké : aws s3 ls s3://mon-bucket --recursive --human-readable --summarize | tail -2 donne le nombre d’objets et la taille totale. Le pattern d’accès : qui lit ces fichiers, à quelle fréquence, avec quelle latence acceptable. Le couplage applicatif : quelles parties du code référencent directement les URLs S3, et quelles utilisent un mécanisme d’abstraction. Cet audit prend une à deux journées et conditionne le reste de la migration.

L’audit révèle souvent des opportunités de nettoyage avant migration. Par exemple, beaucoup de buckets accumulent des fichiers temporaires non purgés (logs anciens, uploads abandonnés, sauvegardes obsolètes). Migrer ces données mortes vers Hetzner double le temps de transfert et le coût final. Pour une plateforme de plusieurs To, prévoir une journée de nettoyage avant migration peut diviser le volume effectif par deux ou trois — bénéfice direct sur le coût final et la durée de migration.

Étape 2 — Copie initiale

La copie complète AWS S3 vers Hetzner se fait avec rclone qui supporte les deux providers nativement. La commande clé est rclone sync qui copie en évitant les transferts inutiles si la copie est interrompue et reprise. Pour un volume important, lancer la copie depuis un VPS Hetzner temporaire (CX22 à 5 euros par mois) plutôt que depuis le poste local : la bande passante datacenter à datacenter est largement supérieure et le transfert prend une fraction du temps.

# ~/.config/rclone/rclone.conf - ajout des deux remotes
[aws-s3]
type = s3
provider = AWS
region = eu-central-1
access_key_id = AKIA...
secret_access_key = ...

[hetzner]
type = s3
provider = Other
endpoint = https://fsn1.your-objectstorage.com
region = fsn1
access_key_id = ...
secret_access_key = ...

# Copie complète avec progression
rclone sync aws-s3:mon-bucket-source hetzner:mon-bucket-cible \
  --progress \
  --transfers 16 \
  --checkers 32 \
  --fast-list

Pour 4 To depuis AWS Frankfurt vers Hetzner Falkenstein via un VPS Hetzner, le transfert prend typiquement 8 à 14 heures avec ces paramètres optimisés. Le coût : 0 dollar côté Hetzner (ingress gratuit), quelques dollars côté AWS pour l’egress (0,09 dollar par Go, soit 360 dollars pour 4 To). Cette dépense unique de migration se rentabilise en moins d’un mois grâce aux économies récurrentes.

Étape 3 — Dual-write applicatif

Pendant la migration, on bascule le code applicatif en mode dual-write : chaque nouveau fichier uploadé est écrit simultanément dans AWS S3 ET dans Hetzner. Cette stratégie garantit qu’aucun nouvel upload n’est perdu pendant la transition, et permet de comparer les deux bucket en parallèle pour valider la cohérence avant la bascule finale en lecture.

// Dual-write transitoire
async function uploaderFichier(cle: string, body: Buffer, contentType: string) {
  await Promise.all([
    s3Aws.send(new PutObjectCommand({ Bucket: 'aws-bucket', Key: cle, Body: body, ContentType: contentType })),
    s3Hetzner.send(new PutObjectCommand({ Bucket: 'hetzner-bucket', Key: cle, Body: body, ContentType: contentType }))
  ]);
}

async function lireFichier(cle: string): Promise<Stream> {
  // Lecture depuis AWS pendant la phase de validation
  // Bascule vers Hetzner après validation complète
  const r = await s3Aws.send(new GetObjectCommand({ Bucket: 'aws-bucket', Key: cle }));
  return r.Body as Stream;
}

Cette phase dure typiquement deux à quatre semaines selon le rythme d’uploads et la confiance qu’on veut acquérir avant bascule. Pendant cette période, on monitore que les deux bucket reçoivent bien les mêmes fichiers, on lance des comparaisons périodiques (rclone check), et on valide que les latences sont acceptables des deux côtés. Au moindre signal d’écart, on diagnostique avant de continuer.

Étape 4 — Bascule en lecture

Une fois la confiance acquise, on bascule progressivement les lectures de AWS vers Hetzner. Trois approches coexistent. La bascule binaire : un flag dans la configuration applicative bascule toutes les lectures d’un coup. Risquée mais simple. La bascule progressive par hash : un module de routing utilise un hash de l’ID utilisateur ou de la clé pour décider de la source — on commence à 5 % vers Hetzner, on monte progressivement à 100 %. La bascule canary par sous-domaine : un sous-domaine medias.example.sn pointe sur Hetzner, l’ancien medias-aws.example.sn reste sur AWS, et on bascule progressivement les références dans le code applicatif.

Pour la majorité des SaaS ouest-africains, la bascule progressive par hash est le meilleur compromis entre sécurité et simplicité. Une régression silencieuse n’impacte qu’une fraction des utilisateurs, ce qui laisse le temps de diagnostiquer avant impact massif. Le script de routing tient en quelques lignes et se contrôle via une variable d’environnement.

Étape 5 — Vérification de cohérence

Tout au long de la migration, on vérifie périodiquement que les deux bucket restent cohérents. rclone check compare les checksums des objets et liste les divergences. Pour un bucket de 4 To avec quelques millions d’objets, la vérification prend 30 à 60 minutes mais donne une garantie statistique forte. On lance cette vérification avant chaque palier de bascule (5 %, 25 %, 50 %, 100 %).

rclone check aws-s3:mon-bucket hetzner:mon-bucket --size-only --fast-list 2> differences.txt
wc -l differences.txt

Les différences attendues sont quelques objets en transit qui n’existent pas encore dans la destination — cohérent avec un dual-write actif. Toute différence persistante mérite investigation : fichier corrompu, permission incorrecte, échec d’upload silencieux. Pour un projet de production, accepter une vérification « presque parfaite » est acceptable. Pour des données critiques (santé, finance), viser la parité absolue avant bascule finale.

Étape 6 — Bascule finale et nettoyage

Quand 100 % du trafic lit depuis Hetzner, on retire le dual-write et on stoppe les uploads vers AWS. Le bucket AWS reste en place quelques semaines en mode « read-only de secours » au cas où une régression surviendrait. Après une période d’observation rassurante (typiquement 30 jours), on archive les données AWS vers Glacier Deep Archive (économie immédiate) puis on supprime définitivement après une rétention finale de 90 jours.

Le nettoyage final inclut aussi les éléments d’infrastructure AWS associés : CloudFront distributions, Route 53 records spécifiques, IAM policies, lifecycle rules. Cette suppression révèle souvent des coûts annexes oubliés qui s’additionnent. Pour une plateforme typique, on observe une économie supplémentaire de 10-20 dollars par mois après ce nettoyage approfondi, en plus de l’économie principale sur le stockage.

Erreurs fréquentes

Adaptation au contexte ouest-africain

Trois aspects pratiques. Premièrement, pour les SaaS ouest-africains qui paient AWS depuis l’Europe ou les États-Unis sans avoir de besoin spécifique aux services AWS premium, la migration vers Hetzner est presque toujours rentable. L’économie typique va de 50 à 80 % selon la répartition stockage / egress / requêtes. Pour les structures qui démarrent et veulent contrôler leurs coûts dès le début, démarrer directement sur Hetzner évite la migration ultérieure. Deuxièmement, la simplicité tarifaire d’Hetzner facilite considérablement la prévision budgétaire face aux investisseurs ou banques. Au lieu d’expliquer la complexité tarifaire AWS avec ses multiples lignes, on présente un coût mensuel quasi-fixe et prévisible. Cette lisibilité plait aux non-techniques (CEO, CFO, investisseurs) qui valident plus facilement les budgets infrastructure. Troisièmement, le paiement Hetzner depuis l’Afrique se fait via Wave Visa, Wise, ou virement SEPA — moyens accessibles aux structures ouest-africaines qui ne disposent pas forcément d’une carte de crédit internationale acceptée par AWS.

Pour les structures qui hésitent par crainte du verrouillage technique, rappelons que Hetzner est S3-compatible — le code applicatif peut basculer vers n’importe quel autre fournisseur S3 (R2, Backblaze, Wasabi, AWS retour) en changeant simplement les credentials et l’endpoint. Aucun verrouillage propriétaire n’est créé par cette migration, ce qui rend la décision réversible si nécessaire.

Tutoriels frères

• Uploads pré-signés
• Cloudflare CDN devant Hetzner
• Sauvegardes rclone

Pour aller plus loin

• 🔝 Pilier : Hetzner Object Storage 2026
• Articles : Paiement Hetzner Afrique
• Doc : rclone S3

FAQ

Combien coûte une migration de 1 To ?
Frais AWS egress : environ 90 dollars (1 To × 0,09 $/Go). Frais Hetzner : 0 (ingress gratuit). Total migration : 90 dollars une fois. Économie typique sur 12 mois : 1 500-2 500 dollars selon le profil.

Faut-il bloquer les uploads pendant la migration ?
Non, jamais. Le dual-write garantit que tous les nouveaux fichiers arrivent dans les deux bucket. Aucun temps d’arrêt n’est nécessaire.

Que faire des fichiers générés par CloudFront (signed URLs, lifecycle) ?
Hetzner fournit les fonctionnalités équivalentes natives. Les signed URLs S3 fonctionnent identiquement. Les lifecycle rules ne sont pas encore supportées par Hetzner en 2026 — gérer la rétention via cron applicatif.

Et pour migrer en sens inverse plus tard si nécessaire ?
Possible identiquement avec rclone. La compatibilité S3 mutuelle élimine tout verrouillage technique.

Trois cas réels de migration récente

Pour donner des références concrètes, voici trois migrations observées sur l’année 2025-2026 dans la communauté ouest-africaine. Premier cas : une plateforme e-learning à Cotonou avec 800 Go de vidéos pédagogiques. Migration en quatre semaines, économie passant de 110 à 14 dollars par mois (90 % de réduction grâce à l’absence d’egress sur les vidéos pédagogiques très consultées). Deuxième cas : un cabinet d’avocats à Abidjan avec 200 Go de documents clients confidentiels. Migration en deux semaines, économie de 35 à 4 euros mensuels et bénéfice supplémentaire de localisation EU plus stricte que AWS Frankfurt sur certains aspects de DPA. Troisième cas : une boutique e-commerce à Dakar avec 1,2 To d’images produits. Migration en six semaines avec configuration Cloudflare frontale, économie passant de 145 à 18 dollars par mois et amélioration de 60 % de la vitesse de chargement perçue par les utilisateurs grâce au PoP Lagos.

Ces trois cas convergent sur deux observations. L’économie réelle se situe systématiquement entre 70 % et 90 % de la facture précédente, validant que la migration est presque toujours rentable. La performance perçue s’améliore pour les utilisateurs ouest-africains grâce au couplage Hetzner + Cloudflare avec PoPs locaux, ce qui contredit l’a priori que migrer vers une infrastructure moins prestigieuse dégrade le service.

Synthèse

La migration AWS S3 vers Hetzner Object Storage est un projet à fort retour sur investissement pour la majorité des SaaS ouest-africains. Le coût ponctuel de migration (égress AWS plus temps équipe) se rentabilise en quelques semaines, et l’économie récurrente continue ensuite indéfiniment. Les seules raisons légitimes de rester sur AWS sont l’intégration profonde avec d’autres services AWS (Lambda, DynamoDB, Glue) ou des contraintes contractuelles spécifiques. Pour les autres cas, le passage à Hetzner libère du budget infrastructure qui peut être réinvesti dans la croissance produit ou la rémunération de l’équipe.

Checklist complète de migration en 12 points

Pour structurer la migration, cette checklist couvre les étapes essentielles dans l’ordre. D’abord la préparation : auditer le bucket source (taille, nombre d’objets, patterns d’accès), identifier les couplages applicatifs avec AWS, créer le bucket Hetzner cible avec configuration miroir, configurer rclone avec les deux remotes. Ensuite la transition : effectuer la copie initiale via rclone sync depuis un VPS Hetzner, activer le dual-write applicatif, vérifier la cohérence des deux bucket via rclone check. Puis la bascule : démarrer le routing progressif des lectures vers Hetzner (5 %, 25 %, 50 %, 100 %), monitorer activement les latences et erreurs, configurer Cloudflare en frontal sur le bucket Hetzner. Enfin le nettoyage : retirer le dual-write, conserver AWS en read-only 30 jours, archiver puis supprimer définitivement après période d’observation. Suivre cette checklist dans l’ordre garantit qu’aucune étape critique n’est oubliée et facilite la coordination en équipe.