Régions et zones Scaleway : bien choisir où créer ses ressources

Parcours en cours de construction

Ce parcours Scaleway est en cours de production. Les pages sortent par vagues ; certains volets sont encore en construction.

Avant de créer la moindre ressource, il faut choisir où elle vivra, et ce choix est le seul de cette formation qu'on ne corrige pas après coup. Chez Scaleway, il se fait à deux niveaux : la région (une zone géographique) et la zone de disponibilité (un datacenter précis). Cette page, pour qui débute sur Scaleway, explique la différence, liste les quatre régions et leurs dix zones, vous fait vérifier vous-même quel service existe où avec scw, et vous donne une méthode de choix en trois critères. Elle se termine par le réglage qui évite l'erreur la plus courante : créer un serveur au mauvais endroit.

Ce que vous allez apprendre

Niveau : débutant. Prérequis : avoir la CLI scw configurée (voir le guide précédent).

À la fin de cette page, vous saurez :

• Distinguer une région d'une zone de disponibilité, et une ressource zonale d'une ressource régionale
• Nommer les quatre régions Scaleway et leurs dix zones
• Vérifier avec scw quel service existe dans quelle zone, plutôt que de le supposer
• Choisir la bonne localité selon trois critères
• Fixer votre région et votre zone par défaut

Région et zone : quelle différence ?

Une région est une zone géographique qui regroupe plusieurs datacenters ; une zone de disponibilité est l'un de ces datacenters, isolé des autres avec sa propre alimentation et son propre réseau. Le nom d'une zone reprend celui de la région suivi d'un numéro : fr-par-1 est la première zone de la région fr-par. La documentation officielle (page « Product availability guide », validée le 2026-01-05) utilise aussi les formes courtes PAR1, AMS2, WAW3, MIL1.

Cette séparation a un intérêt concret : une panne dans une zone n'affecte pas les autres. En répartissant une application sur plusieurs zones d'une même région, vous la rendez plus résiliente. Une zone mérite une mention : d'après la FAQ Instances, fr-par-2 est alimentée entièrement en énergie renouvelable (hydraulique) et se passe de climatisation, pour une empreinte énergétique annoncée 30 à 40 % inférieure à un datacenter classique. C'est un critère de choix pour qui doit rendre compte de son empreinte.

Zonal ou régional : la propriété qui décide de votre architecture

Chaque ressource Scaleway est soit zonale, soit régionale, et cette propriété se lit dans le nom de l'argument que la commande attend : zone= ou region=. Une Instance, un volume Block, un groupe de sécurité, une Flexible IP ou un Load Balancer vivent dans une zone précise. Un VPC, un Private Network, un bucket Object Storage, un cluster Kubernetes ou une base managée se raisonnent à l'échelle de la région.

La conséquence tient en une règle : ce qui est zonal se duplique pour survivre à la perte d'une zone, ce qui est régional se partage. Deux Instances dans fr-par-1 et fr-par-2 peuvent être attachées au même Private Network régional, mais un volume créé dans fr-par-1 ne s'attachera jamais à une Instance de fr-par-2 : il faut passer par un snapshot exporté vers Object Storage puis réimporté. Ce mécanisme est décrit dans la doc « Moving Instances between Availability Zones » et vous le retrouverez au volet Fondations.

Les quatre régions et leurs dix zones

Scaleway opère quatre régions, toutes en Europe, pour dix zones de disponibilité. Voici la liste complète, avec un ordre de grandeur de l'étendue du catalogue d'Instances par zone, relevé le 2026-09-08 avec scw instance server-type list zone=… -o json (scw 2.56.3).

Région	Ville	Zones	Types d'Instances par zone (relevé)
fr-par	Paris	fr-par-1, fr-par-2, fr-par-3	125, 134, 33
nl-ams	Amsterdam	nl-ams-1, nl-ams-2, nl-ams-3	115, 99, 32
pl-waw	Varsovie	pl-waw-1, pl-waw-2, pl-waw-3	40, 61, 41
it-mil	Milan	it-mil-1	72

Glissez pour voir

Deux enseignements se lisent dans la dernière colonne. D'abord, les troisièmes zones de Paris et d'Amsterdam offrent trois à quatre fois moins de types que les deux premières : elles servent à répartir, pas à héberger n'importe quoi. Ensuite, Milan (it-mil) ne compte qu'une seule zone au 2026-09-08 : pour une architecture multi-zone dès aujourd'hui, tournez-vous vers Paris, Amsterdam ou Varsovie.

Comment choisir sa localité ?

Trois critères guident le choix, et leur ordre dépend de votre contexte : la proximité des utilisateurs, la résidence des données, et la disponibilité du service. Le tableau se lit ligne par ligne : trouvez la contrainte qui vous concerne, la colonne Choix dit où aller.

Besoin	Choix	Pourquoi
Utilisateurs en France, pas de contrainte particulière	fr-par, zones 1 et 2	catalogue le plus large, tous les services, GPU en fr-par-2
Données de santé (HDS) ou obligation d'hébergement en France	fr-par exclusivement	le périmètre HDS est limité aux datacenters français DC2 à DC5 ; il ne couvre pas tout le catalogue et se vérifie produit par produit
Empreinte carbone à justifier	fr-par-2	zone alimentée en renouvelable, sans climatisation
Utilisateurs au Benelux ou en Allemagne	nl-ams	latence, catalogue proche de Paris en zones 1 et 2
Utilisateurs en Europe centrale, GPU L4 disponibles	pl-waw, GPU en pl-waw-2	les quatre L4 étaient available en pl-waw-2 lors du relevé, en pénurie à Paris
Utilisateurs en Italie	it-mil	seule zone, catalogue plus étroit : vérifier chaque service avant
Haute disponibilité multi-zone	fr-par, nl-ams ou pl-waw	trois zones chacune ; Milan n'en a qu'une
Bare metal (Elastic Metal)	fr-par-1, fr-par-2, nl-ams-1, nl-ams-2, pl-waw-2, pl-waw-3	les six seules zones bare metal

Glissez pour voir

La proximité de vos utilisateurs joue sur la latence : plus le datacenter est proche, plus votre application répond vite. La résidence des données peut être une contrainte réglementaire : toutes les régions étant européennes, vous restez dans l'UE, mais l'hébergement de données de santé impose des datacenters en France. La disponibilité du service est le critère qu'on oublie le plus souvent, et c'est l'objet de la section suivante.

Tous les services existent-ils dans toutes les régions ?

Non, et la vraie compétence n'est pas de savoir lesquels, c'est de savoir le vérifier. Le catalogue Scaleway bouge tous les mois : un service absent d'une région l'an dernier y est arrivé depuis, et n'importe quelle liste publiée vieillit plus vite qu'elle ne se relit. Cette section donne donc la méthode, puis un instantané daté à titre d'illustration seulement.

Comment savoir si un service existe dans une localité ?

Trois sources répondent, et elles ne se valent pas. Les voici de la plus fiable à la moins fiable, avec ce qui les disqualifie.

Source	Fiabilité	La limite qui la disqualifie
Le catalogue public (product-catalog)	la meilleure	aucune, c'est la donnée dont Scaleway se sert pour ses propres fiches
L'API du service dans la zone visée	bonne	il faut connaître la commande de listage propre à chaque service
L'aide du CLI (scw … create -h)	la moins fiable	elle est figée dans le binaire : votre version l'a apprise le jour de sa compilation

Glissez pour voir

Le catalogue public répond sans authentification, et un SKU y existe par couple produit/localité. C'est la source à interroger en premier :

curl -s 'https://api.scaleway.com/product-catalog/v2alpha1/public-catalog/products?page_size=1000' \
  | jq -r '.products[] | "\(.product_category)\t\(.locality.zone // .locality.region)"' \
  | sort -u | grep -i loadbalancer

La sortie doit lister une ligne par localité où la catégorie existe. Si votre zone n'y figure pas, le service n'y est pas déployé, quoi qu'en dise l'aide de votre CLI.

Pour une vérification ciblée sur un seul service, l'API du service répond aussi, et c'est le geste le plus rapide quand on hésite entre deux zones :

scw lb lb-types list zone=fr-par-3
scw vpc-gw gateway-type list zone=fr-par-3

La sortie doit lister des types si le service existe dans la zone ; Unknown service signifie qu'il n'y est pas déployé. Remplacez la zone par celle que vous visez.

Pourquoi l'aide du CLI vous trompera un jour

L'aide de scw <service> create -h énumère les localités que votre binaire connaissait le jour de sa compilation. Elle ne consulte rien au moment où vous la lancez. Un CLI installé il y a six mois ignore donc toute région ouverte depuis, et affiche une liste rassurante mais fausse.

Le cas s'est produit sur cette page même. Une version antérieure affirmait, sur la foi de l'aide de scw lb lb create en 2.56.3, que le Load Balancer n'existait pas à Milan. Le catalogue public le donne pourtant présent, avec cinq références. L'aide du CLI avait simplement plusieurs mois de retard.

Ne vous en servez donc que pour une orientation grossière, jamais pour trancher une décision d'architecture.

Pourquoi une liste de disponibilité vieillit plus vite qu'on ne la relit

Le catalogue d'un fournisseur cloud n'est pas un état, c'est un flux. Chaque mois, des services arrivent dans des régions où ils n'étaient pas, quelques-uns en repartent, et de nouvelles zones ouvrent. Une page qui publie une matrice de disponibilité fige donc une photographie, et cette photographie commence à se périmer le jour de sa publication. Le problème n'est pas la qualité du relevé, il est structurel : personne ne relit une matrice au rythme où le catalogue change. La conséquence pratique est qu'une décision d'architecture fondée sur une liste mémorisée, y compris une liste juste au moment où elle a été écrite, se prend sur des données périmées. C'est pourquoi cette section vous donne d'abord la commande, ensuite seulement un exemple de ce qu'elle renvoie. La compétence à acquérir n'est pas de savoir où se trouve le Load Balancer aujourd'hui, c'est de savoir le vérifier en trente secondes le jour où la question se pose.

Instantané au 12 septembre 2026

Le tableau ci-dessous est un exemple de ce que la méthode renvoie, pas une référence à mémoriser. Il vient du catalogue officiel de disponibilité par région, relevé à cette date, et il aura vieilli quand vous le lirez.

Service	Où il existe	Où il manque
Instances, VPC, IPAM	les 10 zones	aucune
Block Storage	Paris, Amsterdam, Varsovie, et Milan	aucune région entière
Load Balancer	9 zones, Milan comprise	fr-par-3
Public Gateway	les gabarits dans 9 zones	fr-par-3, où seule l'IP existe
Kubernetes, Secret Manager, Key Manager, Cockpit, Audit Trail	les 4 régions, Milan comprise	aucune
Bases managées PostgreSQL et MySQL	les 4 régions, Milan comprise	aucune
Container Registry, Serverless Containers	les 4 régions, Milan comprise	aucune
Serverless Functions et Jobs	Paris, Amsterdam, Varsovie	it-mil, annoncé « bientôt disponible »

Glissez pour voir

Trois enseignements se lisent dans ce tableau, et eux ne vieilliront pas. D'abord, l'absence se joue parfois à la zone et non à la région : fr-par-3 est en région Paris et n'a pourtant pas de Load Balancer. Ensuite, une famille de produits ne se déploie pas d'un bloc : le serverless arrive à Milan par morceaux, les Containers d'abord, les Functions et les Jobs ensuite. Écrire « le serverless est disponible à Milan » serait faux d'un tiers.

Enfin, et c'est le plus utile : la source que vous interrogez décide de la réponse que vous obtenez. L'aide du CLI énumère les régions que votre binaire connaît, pas celles que le produit sert aujourd'hui. Au 8 septembre 2026, scw registry namespace create -h en 2.56.3 n'annonçait que trois régions, alors que Container Registry est à Milan depuis le 31 août 2026. Le catalogue officiel de disponibilité, tenu par les équipes produit, est la référence ; le CLI dit seulement ce que votre poste sait faire.

Fixer sa région et sa zone par défaut

Plutôt que de préciser la localité à chaque commande, définissez des valeurs par défaut dans votre configuration scw : toute commande les utilisera, sauf mention contraire.

# Voir la région et la zone actuellement par défaut
scw config get default-region
scw config get default-zone
# Les définir (ici Paris, première zone)
scw config set default-region=fr-par
scw config set default-zone=fr-par-1

La sortie de scw config get doit afficher la valeur attendue (par exemple fr-par puis fr-par-1). Vous pouvez toujours surcharger ce défaut pour une commande précise avec l'argument zone= ou region=. Un détail à connaître : les variables d'environnement SCW_DEFAULT_REGION et SCW_DEFAULT_ZONE, si elles sont exportées dans votre shell, l'emportent sur le fichier. Si scw config get et le comportement réel divergent, cherchez d'abord une variable exportée.

Limites, quotas et plafonds

Ces valeurs disent ce qu'une localité permet, avant toute question de prix. Elles viennent de l'aide du CLI, de la FAQ VPC et du relevé du 2026-09-08.

Plafond	Valeur	Source
Régions	4 (fr-par, nl-ams, pl-waw, it-mil)	aide de scw vpc vpc create -h
Zones de disponibilité	10, dont 1 seule à Milan	aide de scw instance server create -h
Zones avec GPU	3 (fr-par-1, fr-par-2, pl-waw-2)	relevé server-type list du 2026-09-08
Zones avec Elastic Metal	6	FAQ Elastic Metal et aide du CLI
Types d'Instances dans la zone la plus fournie	134 en fr-par-2	relevé du 2026-09-08
Types d'Instances dans la zone la moins fournie	32 en nl-ams-3	relevé du 2026-09-08
Bande passante d'une Instance	s'applique par connexion réseau : autant vers Internet que vers chaque Private Network	FAQ VPC
Déplacement d'un volume entre zones	impossible en direct ; snapshot exporté vers Object Storage puis importé	doc « Moving Instances between AZ »

Glissez pour voir

Antipatterns à éviter

Ces erreurs se ressemblent : elles fonctionnent le premier jour et se découvrent au moment de grandir. Une zone se choisit avec la fin en tête, parce qu'une ressource zonale ne déménage jamais sans reconstruction.

Antipattern	Conséquence	Discipline
Créer toutes les ressources dans la zone par défaut sans l'avoir choisie	Instance à Paris, volume à Amsterdam : attachement impossible	fixer default-zone avant la première commande, la vérifier avant chaque lab
Bâtir une architecture multi-zone à Milan	une seule zone : la redondance n'existe pas	Paris, Amsterdam ou Varsovie pour la haute disponibilité
Se fier à l'aide du CLI pour la disponibilité	l'aide est figée dans le binaire : une région ouverte depuis votre installation reste invisible	interroger le catalogue public ou l'API du service dans la zone visée
Recopier une matrice de disponibilité lue quelque part	le catalogue bouge tous les mois : la matrice est fausse avant d'être utile	vérifier à la source le jour de la décision
Supposer qu'un service existe partout parce qu'il existe à Paris	pas de Load Balancer ni de Public Gateway en fr-par-3, pas de bases managées à Milan	lb-types list et gateway-type list dans la zone visée, avant de décider
Choisir la zone sur la latence seule	GPU introuvables (nl-ams n'en a aucun), bare metal absent de nl-ams-3	croiser latence, résidence des données et disponibilité du service
Placer un volume et une Instance dans deux zones « voisines »	volume inutilisable, migration par export de snapshot	une zone par pile applicative, et la même pour ses disques

Glissez pour voir

Régions et zones sous l'angle Well-Architected

Reliability : que se passe-t-il si cette zone tombe ?

Tout ce qui est zonal disparaît avec elle. La discipline est de répartir les Instances sur deux zones de la même région, reliées par un Private Network régional, et de ne jamais choisir une région à zone unique pour un service qui doit survivre à un incident. L'export de snapshot vers Object Storage est le seul chemin d'un volume vers une autre zone : le tester une fois, avant d'en avoir besoin.

Performance : la latence se mesure, elle ne se devine pas

Vos utilisateurs sont-ils là où vous croyez ? La discipline est de mesurer la latence depuis leurs emplacements réels vers fr-par, nl-ams et pl-waw avant de trancher, et de rappeler que la bande passante d'une Instance s'applique par connexion : une machine à 500 Mbit/s les a vers Internet et vers chaque Private Network, ce qui rend le trafic interne gratuit en débit comme en argent.

Cost Optimization : la zone la moins chère est celle qui a du stock

Une zone en pénurie coûte du temps, pas de l'argent, et le temps se paie. Le relevé du 2026-09-08 montrait les L4 en pénurie à Paris et disponibles à Varsovie : la discipline est de relire availability avant chaque projet GPU, et de préférer une zone où la ressource est available à une zone plus proche où elle ne l'est pas.

Pièges courants

Le tableau se lit par la colonne Symptôme : c'est ce que vous voyez à l'écran, message exact compris quand il y en a un ; la colonne Cause dit ce qui se passe réellement, et la colonne Solution la commande ou le geste qui débloque.

Symptôme	Cause	Solution
La ressource est créée au mauvais endroit	zone ou région par défaut non vérifiée, ou variable SCW_DEFAULT_ZONE exportée	scw config get default-zone avant de créer, ou passer zone= explicitement
Unknown service sur un list de types	le service n'est pas déployé dans cette zone (cas de fr-par-3 pour Load Balancer et Public Gateway)	choisir une zone qui le couvre
Not Found sur scw instance server-type list zone=…	la zone n'existe pas (faute de frappe)	relire la liste des dix zones dans l'aide de la commande
Impossible de répartir sur plusieurs zones	la région choisie n'a qu'une zone (Milan)	utiliser une région à trois zones
Un volume ne s'attache pas à l'Instance	volume et Instance dans deux zones différentes	recréer le volume dans la zone de l'Instance, ou exporter un snapshot
Le CLI n'énumère pas une zone que l'API sert	aide figée dans le binaire, en retard sur le catalogue	mettre à jour scw, et se fier au list de types dans la zone

Glissez pour voir

Contrôle de connaissances

Vérifiez que l'essentiel de ce guide est acquis. Les questions portent uniquement sur ce qui vient d'être expliqué ici.

Contrôle de connaissances

Validez vos connaissances avec ce quiz interactif

6 questions

6 min.

70% requis

Informations

• Le chronomètre démarre au clic sur Démarrer
• Questions à choix multiples, vrai/faux et réponses courtes
• Vous pouvez naviguer entre les questions
• Les résultats détaillés sont affichés à la fin

Démarrer le quiz

Lance le quiz et démarre le chronomètre

À retenir

• Une région est une zone géographique ; une zone de disponibilité est un datacenter isolé (fr-par-1). L'argument zone= ou region= d'une commande dit si la ressource est zonale ou régionale.
• Scaleway compte quatre régions européennes : fr-par, nl-ams, pl-waw, it-mil, soit dix zones au total ; Milan n'a qu'une seule zone au 2026-09-08.
• fr-par-2 est la zone la plus fournie (134 types d'Instances relevés) et la seule alimentée en renouvelable sans climatisation.
• Tous les services ne sont pas partout : ni Load Balancer ni Public Gateway en fr-par-3 (Unknown service), ni Serverless Functions ni Jobs à Milan alors que les bases managées et les Serverless Containers y sont, GPU dans trois zones seulement.
• L'aide du CLI est figée dans le binaire : scw <cmd> -h donne ce que votre version connaît, scw lb lb-types list zone=… donne ce que l'API sert.
• Choisissez selon la latence, la résidence des données (HDS = France) et la disponibilité du service, dans l'ordre que votre contexte impose.
• Fixez vos valeurs par défaut avec scw config set default-region et default-zone, et souvenez-vous que SCW_DEFAULT_ZONE exportée l'emporte.
• Un volume ne change pas de zone : snapshot exporté vers Object Storage, puis importé.

Pour aller plus loin

• Organisations et Projets : Un Project traverse les régions ; c'est une frontière de droits, pas de géographie.
• Block Storage : Le volume, ressource zonale par excellence, et ce que sa zone impose à l'Instance.
• Réseau Scaleway : la carte avant de construire : Le tableau des briques régionales et zonales, et les zones sans Load Balancer.

Ressources externes

Les pages officielles sur lesquelles cette leçon s'appuie, avec ce qu'on y cherche ; leur champ de validation date chaque fait cité.

• Product availability guide : la page officielle de disponibilité par région et par zone, mise à jour par les équipes produit.
• Instances FAQ : la zone durable fr-par-2 et la localisation des gammes.
• Moving Instances between Availability Zones and Projects : la procédure d'export et d'import de snapshot entre zones.
• VPC FAQ : la portée régionale des Private Networks et la bande passante par connexion.

×

📖 Voir la documentation →