Faut-il vider et supprimer les buckets S3 dès que la bascule est faite ?

Surtout pas dans la foulée. Tant que vous n'avez pas confirmé sur plusieurs jours que rien ne lit plus l'ancien stockage, gardez les buckets en place. Le piège classique, c'est un batch nocturne ou un service tiers qui pointe encore sur l'ancien endpoint et que personne n'avait en tête. Je ne supprime qu'une fois les logs d'accès AWS retombés à zéro.

Et si une URL pré-signée ou un lien public est codé en dur quelque part ?

C'est le cas limite qui fait mal. Les URL signées intègrent le domaine S3 d'origine, donc elles cassent à la bascule. Avant de migrer, je cherche les motifs de domaine AWS dans le code, les bases de données et les CMS. Si des liens publics sont déjà partis chez des clients ou dans des e-mails, il faut soit garder une redirection, soit accepter que ces anciens liens meurent.

Peut-on migrer sans jamais sortir les données par internet, pour éviter la facture AWS ?

Non, il n'existe pas de raccourci magique côté Scaleway pour aspirer un bucket AWS sans passer par le transfert sortant. La copie lit bien les objets via le réseau, donc la sortie est facturée. La seule vraie économie consiste à ne migrer que ce qui sert : beaucoup de buckets traînent des exports oubliés ou des sauvegardes périmées qu'on peut purger côté AWS avant, plutôt que de payer pour les déménager.

Quelle région Scaleway choisir pour la cible ?

Si votre trafic et vos utilisateurs sont en France, Paris est le choix par défaut. Le point à ne pas négliger, c'est la cohérence avec le reste de votre infra Scaleway : placer le stockage dans la même région que vos serveurs évite des allers-retours réseau facturés et de la latence. Vérifiez aussi la disponibilité des classes de stockage que vous visez, elles ne sont pas identiques partout.

Migrer son stockage objet de S3 vers Scaleway Object Storage

On imagine souvent qu’une migration de stockage objet hors d’AWS suppose de réécrire la couche d’accès aux fichiers. De toutes les sorties d’AWS que j’ai menées, celle-ci est pourtant la plus indolore pour le code, et ça tient à une seule chose : Scaleway Object Storage parle l’API S3.

Scaleway Object Storage parle l’API S3 : migrer revient à recopier les objets et à repointer l’application. Le poste de coût qui surprend, c’est le transfert sortant facturé par AWS au gigaoctet ; on le chiffre avant, on copie une bonne fois, on bascule proprement.

Pourquoi le code ne bouge pas

Vos applications passent par une bibliothèque S3 standard, le SDK AWS (la trousse à outils fournie par Amazon pour dialoguer avec S3) ou un équivalent. Scaleway expose la même API. Dans l’immense majorité des cas, vous touchez donc à deux choses : l’endpoint et les identifiants. Le code qui lit et écrit les objets ne change pas d’une ligne, ce qui rend ce chantier peu risqué côté développement.

La méthode, étape par étape

1. Chiffrer le coût de sortie. Le transfert sortant d’AWS se facture au gigaoctet, et c’est la ligne que tout le monde oublie. Comptez de l’ordre de 0,08 à 0,09 $ par Go selon la région : sur 20 To, vous êtes déjà autour de 1 700 $ rien que pour faire sortir les données. Ce poste, je le chiffre et je le fais valider avant la première commande de copie.

2. Copier les objets. Un outil de synchronisation compatible S3, du simple aws s3 sync à rclone, recopie les buckets (les conteneurs où S3 range vos fichiers) vers Scaleway en préservant l’arborescence et les métadonnées. Sur les gros volumes, je découpe par préfixe et je relis l’intégrité au fur et à mesure. Des données copiées qu’on n’a jamais relues, ce n’est pas une migration, juste un transfert sur lequel on croise les doigts.

3. Synchroniser le delta. La copie initiale peut durer des heures, et pendant ce temps l’application continue d’écrire dans S3. Juste avant la bascule, on resynchronise donc ce qui a été ajouté ou modifié entre-temps.

4. Basculer l’application. On change l’endpoint et les identifiants, on teste lecture et écriture pour de vrai, puis on garde S3 accessible quelques jours en lecture seule. Ce filet ne coûte presque rien et il sauve les week-ends, quand un cas oublié refait surface un vendredi soir.

Le piège qui n’est pas le coût

Avant de basculer, listez ce que vous utilisez vraiment au-delà de la simple lecture-écriture : politiques d’accès fines et classes de stockage type Glacier, mais surtout les déclencheurs à l’écriture façon Lambda. La compatibilité S3 couvre le cœur de l’API, et c’est large. Ces fonctions avancées, en revanche, demandent une vérification au cas par cas, et c’est généralement là que se cache la mauvaise surprise.

Un cas concret

J’ai accompagné une PME e-commerce dont tout le stockage d’images produit vivait sur S3, une quarantaine de téraoctets. La recopie a tenu en une nuit. La bascule, elle, n’a pris qu’une dizaine de minutes le lendemain matin, sans que personne côté boutique ne s’aperçoive de rien. Le seul vrai poste aura été la facture de sortie AWS : chiffrée et validée en amont, puis payée une bonne fois.

Une réserve, pour finir. Cette facilité tient à condition que vous restiez sur le cœur de l’API S3. Le jour où votre architecture dépend en profondeur de services AWS greffés autour du stockage, des notifications d’événements jusqu’aux traitements déclenchés à l’écriture, la migration cesse d’être un simple recopiage : elle redevient un chantier d’intégration, et il faut le dire avant de promettre une nuit de bascule.