Régions, zones et conception pour la panne

Pourquoi

Dans la nuit du 9 au 10 mars 2021, un incendie se déclare dans le centre de données SBG2 d'OVHcloud, à Strasbourg. Au matin, SBG2 est détruit, SBG1 est en partie endommagé, et SBG3 et SBG4, épargnés par les flammes, sont arrêtés par précaution. Des centaines de milliers de sites deviennent inaccessibles. Pour beaucoup, l'interruption dure quelques jours, le temps de redémarrer ailleurs. Pour d'autres, elle est définitive : leurs sauvegardes étaient stockées sur le même site que leurs serveurs, et elles ont brûlé avec eux.

Ces clients n'avaient pas commis d'erreur de manipulation. Ils avaient commis une erreur de géographie : ils croyaient avoir deux copies de leurs données, ils en avaient deux exemplaires exposés au même événement. Une copie n'est une protection que contre les pannes qui ne la touchent pas en même temps que l'original.

C'est tout le sujet de cette leçon. Dans le cloud, chaque ressource que vous créez vit quelque part : sur un hyperviseur, dans une salle, dans un bâtiment, dans une ville. Les fournisseurs regroupent ces lieux en zones et en régions, et ces deux mots sont des promesses précises sur ce qui peut tomber en panne ensemble. Les ignorer, c'est construire une architecture qui a l'air redondante sur un schéma et qui s'effondre d'un bloc au premier incident sérieux. Les comprendre permet de répondre à la seule question qui compte : quelle panne mon application doit-elle survivre, et combien suis-je prêt à payer pour cela ?

À la fin de la leçon, l'équipe de Signalements aura décidé où placer ses deux instances, sig-app-1 et sig-app-2, et pourquoi pas au même endroit.

Les concepts

Le domaine de panne

Le concept de base est le domaine de panne (failure domain) : un ensemble d'équipements qui peuvent tomber en panne ensemble parce qu'ils partagent une dépendance. Un serveur physique est un domaine de panne (son alimentation, sa carte mère). Une baie en est un autre, plus grand : ses serveurs partagent un commutateur de haut de baie et une arrivée électrique. Une salle partage une climatisation, un bâtiment partage un poste de livraison électrique et des groupes électrogènes, une ville partage un réseau électrique, des inondations et des fibres optiques.

Ces domaines s'emboîtent comme des poupées russes. Le cloud ne fait pas disparaître cette hiérarchie : il vous en montre deux niveaux, la zone et la région, et vous laisse choisir sur lesquels répartir vos ressources. Les niveaux inférieurs (hyperviseur, baie) sont gérés par le fournisseur, avec un réglage optionnel, le groupe de placement, vu plus bas.

    flowchart TB
  subgraph R["Région fr-par (Paris)"]
    subgraph Z1["Zone fr-par-1"]
      direction TB
      H1["hyperviseur"] --- H2["hyperviseur"]
    end
    subgraph Z2["Zone fr-par-2"]
      direction TB
      H3["hyperviseur"] --- H4["hyperviseur"]
    end
    subgraph Z3["Zone fr-par-3"]
      direction TB
      H5["hyperviseur"] --- H6["hyperviseur"]
    end
  end
  subgraph R2["Région nl-ams (Amsterdam)"]
    Z4["nl-ams-1"] --- Z5["nl-ams-2"] --- Z6["nl-ams-3"]
  end
  R -. "plusieurs centaines de km" .- R2
  

La zone de disponibilité

Une zone de disponibilité (availability zone, souvent abrégée AZ) est un ou plusieurs centres de données d'une même région, conçus pour ne pas tomber en panne en même temps que les autres zones de la région. Concrètement, une zone a sa propre alimentation électrique, son propre refroidissement et son propre raccordement réseau.

Les fournisseurs ne mettent pas tous les mêmes garanties derrière ce mot. Comparez ce qu'ils écrivent eux-mêmes :

Retenez deux choses de ce tableau. D'abord, une zone n'est pas forcément un bâtiment : elle peut en regrouper plusieurs, proches. Chez Scaleway, l'article de 2021 indiquait que la zone fr-par-1 regroupait les centres de données DC2 et DC3, et fr-par-2 le centre DC5 (Saint-Ouen-l'Aumône) ; fr-par-3 correspond à DC4, l'ancien abri antiatomique du 15e arrondissement de Paris. Ensuite, la distance réelle entre zones varie : elle se mesure en dizaines de kilomètres au mieux, parfois moins. Les zones d'une même région partagent donc toujours certains risques : une crue de la Seine, une panne du réseau électrique régional, une erreur sur le cœur de réseau qui les relie. Elles protègent contre la perte d'un site, pas contre celle d'une agglomération.

La région

Une région est une zone géographique (une agglomération, en pratique) qui regroupe plusieurs zones de disponibilité reliées par un réseau rapide. Scaleway la définit comme une zone géographique, la France (Paris), les Pays-Bas (Amsterdam), la Pologne (Varsovie), dans laquelle ses produits sont situés, et visait en 2021 trois zones par région dans un rayon d'environ 200 km.

D'après l'aide de la CLI scw 2.62 et la page de disponibilité des produits, Scaleway compte aujourd'hui quatre régions :

Deux régions sont séparées par des centaines de kilomètres : un même événement physique ne peut pas raisonnablement les toucher toutes les deux. Elles sont aussi séparées logiciellement : chaque région a ses propres points d'accès d'API, ses propres plans de contrôle, et la plupart des ressources ne peuvent pas en franchir la frontière. Un réseau privé de Paris ne s'étend pas à Amsterdam ; une base de données de Paris ne se réplique pas d'elle-même à Varsovie. Passer d'une région à l'autre est un choix d'architecture, que vous construisez vous-même.

La région est aussi une frontière juridique commode : une donnée stockée dans fr-par est physiquement en France. Ce n'est pas toute la question de la souveraineté (qui contrôle le fournisseur, quel droit s'applique à lui), que traite le cours Cloud souverain : choisir et justifier, mais c'est le premier critère qu'un client public ou réglementé vérifie, et le RGPD rend la localisation des données personnelles visible dans les contrats.

Tous les produits ne sont pas partout

Un piège fréquent : une région affichée au catalogue ne propose pas tous les produits, ni tous les types d'instances, dans toutes ses zones. La page Product availability by region de Scaleway le montre produit par produit. Par exemple, au moment de la rédaction : les instances GP1 existent dans les trois zones de Paris mais dans deux seulement à Amsterdam et à Varsovie, et pas à Milan ; les instances GPU L4 sont disponibles en fr-par-1 et fr-par-2 mais pas en fr-par-3 ; le stockage objet « Standard Multi-AZ » est annoncé comme « bientôt disponible » à Milan. La fiche technique de chaque type d'instance donne d'ailleurs, zone par zone, son empreinte carbone, ce qui révèle indirectement où il est proposé.

Conséquence pratique : avant de dessiner une architecture « une instance dans chaque zone », vérifiez que le type d'instance choisi existe dans chacune des zones et qu'il y est en stock. Nous le ferons plus bas.

Zonal, régional, global

Chaque type de ressource cloud a une portée : l'endroit où elle existe et d'où on peut l'utiliser. Google Cloud formalise trois portées, que l'on retrouve chez tous les fournisseurs :

• une ressource zonale vit dans une zone précise, et une panne de cette zone l'emporte ;
• une ressource régionale est utilisable depuis toutes les zones d'une région ; selon le service, elle est répartie sur plusieurs zones, ou posée dans l'une d'elles sans que vous le choisissiez ;
• une ressource globale n'appartient à aucune région.

Chez Scaleway, l'aide de la CLI trahit la portée de chaque ressource : une commande qui accepte un argument zone= crée une ressource zonale, une commande qui accepte region= une ressource régionale, une commande sans l'un ni l'autre une ressource globale. Voici ce que donne scw ... create --help pour les ressources du cours :

Cette table se lit comme une carte des risques. L'instance sig-app-1 est zonale : si fr-par-1 tombe, elle tombe. Le répartiteur de charge est zonal lui aussi, ce qui surprend souvent : un répartiteur posé en fr-par-1 peut envoyer du trafic vers des instances de fr-par-2 à travers le réseau privé régional, mais il disparaît avec sa zone. Le réseau privé est régional : il relie les zones, et c'est ce qui rend possible une architecture répartie. La base de données managée est régionale au sens de l'API, mais sa documentation ne dit pas que son nœud de secours (option haute disponibilité) se trouve dans une autre zone ; en revanche, elle propose explicitement des réplicas en lecture « Multi-AZ », hébergés dans une autre zone que le nœud principal. Quand une documentation ne dit pas où se trouve une copie, ne supposez pas qu'elle est ailleurs.

Le rayon d'impact

Le rayon d'impact (blast radius) d'une panne est l'ensemble de ce qu'elle emporte. Concevoir pour la panne, c'est s'assurer que le rayon d'impact de chaque panne probable est plus petit que votre application : qu'il en reste toujours assez debout pour servir.

Les zones et les régions servent précisément à borner ce rayon. Une panne d'hyperviseur emporte quelques instances ; une panne de zone, toutes les ressources zonales de cette zone ; une panne de région, tout ce qui est dans la région. Mais attention : le rayon d'impact ne suit pas toujours les frontières géographiques. Il suit les dépendances. Un plan de contrôle régional, un DNS, un service d'identité global, une erreur de configuration poussée partout en même temps : ces pannes traversent les zones. Les retours d'expérience publics, plus bas, le montrent.

Les groupes de placement

Les zones protègent contre la perte d'un site. À l'intérieur d'une zone, deux instances peuvent malgré tout tourner sur le même hyperviseur, et tomber ensemble si cette machine physique tombe. Le groupe de placement (placement group) permet d'exprimer une contrainte sur ce placement. Scaleway propose deux politiques :

• max_availability : répartir les instances du groupe sur des hyperviseurs aussi éloignés que possible, pour limiter l'effet d'une panne matérielle ;
• low_latency : les rapprocher au maximum, au mieux sur le même hyperviseur, pour obtenir le meilleur débit réseau entre elles.

Et deux modes : enforced (si la contrainte ne peut pas être respectée, l'instance n'est pas créée ou démarrée) ou optional (l'instance est placée quand même, et le groupe signale que la politique n'est pas respectée par un champ policy_respected à false).

Un groupe de placement est zonal : il ne peut contenir que des instances d'une même zone. Il ne remplace donc pas la répartition sur plusieurs zones ; il la complète, pour les cas où l'on a plusieurs instances dans une même zone. Les équivalents : placement groups chez AWS (stratégies spread, partition et cluster), availability sets et proximity placement groups chez Azure, placement policies spread ou compact chez Google Cloud.

Mesurer la disponibilité

La disponibilité d'un service est la proportion du temps pendant laquelle il fonctionne. On l'exprime en pourcentage, et on parle familièrement de « neuf » : « trois neuf » pour 99,9 %. Chaque neuf supplémentaire divise par dix le temps d'indisponibilité permis :

Le calcul est simple : une année compte 8 760 heures ; 0,1 % d'indisponibilité, c'est 8,76 heures. Ces chiffres donnent un ordre de grandeur utile pour discuter avec un client : à 99,99 %, une seule intervention humaine de vingt minutes par trimestre suffit à épuiser le budget annuel. Un tel objectif ne s'atteint qu'avec de l'automatisation et de la redondance, jamais avec une astreinte qui se connecte en SSH.

Les fournisseurs publient des objectifs pour chaque produit. La fiche des instances Scaleway STANDARD3 indique par exemple un objectif de disponibilité (SLO) de 99,5 %, et celle des BASIC3 de 99 %. Un engagement contractuel, avec des pénalités, s'appelle un SLA ; la leçon 8 en détaille le contenu et les limites.

Composer les disponibilités

Une application est faite de plusieurs éléments, et sa disponibilité dépend de la façon dont ils sont assemblés.

En série, quand chaque élément est indispensable (la requête traverse le répartiteur, puis l'instance, puis la base), les disponibilités se multiplient :

A_série = A1 × A2 × A3

Le résultat est toujours plus faible que le maillon le plus faible. Trois éléments à 99,9 % donnent 0,999³ = 99,70 %, soit 26 heures d'indisponibilité par an au lieu de 8,8.

En parallèle, quand il suffit qu'un seul élément fonctionne (deux instances derrière un répartiteur), c'est la probabilité que tous soient en panne en même temps qui compte :

A_parallèle = 1 − (1 − A1) × (1 − A2)

Deux instances à 99,5 % donnent 1 − 0,005 × 0,005 = 1 − 0,000025 = 99,9975 %. La redondance transforme deux éléments médiocres en un ensemble excellent.

À une condition, que la formule cache : les pannes doivent être indépendantes. Si les deux instances sont sur le même hyperviseur, dans la même zone, alimentées par le même onduleur, elles tombent ensemble et l'ensemble ne vaut guère mieux qu'une seule. C'est pour rendre cette hypothèse réaliste que l'on répartit les copies sur des domaines de panne différents. Le calcul parallèle est donc toujours optimiste : il donne une borne haute, que les pannes corrélées (un bogue présent sur les deux instances, une configuration erronée déployée partout) font baisser.

Survivre à la perte d'une zone : la stabilité statique

Répartir sur deux zones ne suffit pas : il faut que la zone survivante puisse absorber toute la charge, immédiatement. Une architecture qui compte sur la création de nouvelles instances au moment de la panne dépend du plan de contrôle du fournisseur, précisément au moment où il est le plus sollicité (tous les clients de la zone en panne recréent leurs ressources ailleurs) et parfois lui-même dégradé.

La Builders' Library d'AWS appelle stabilité statique (static stability) la propriété d'un système qui continue de fonctionner quand une dépendance défaille, sans avoir à agir. Appliquée aux zones, elle conduit à surdimensionner à l'avance : avec trois zones, AWS provisionne chaque zone pour qu'elle tourne à environ 66 % de sa capacité testée, de sorte que deux zones suffisent à porter toute la charge. Avec deux zones, chacune doit pouvoir porter seule 100 % du trafic, donc tourner en temps normal à 50 % au plus.

Cette distinction recoupe celle entre plan de contrôle (ce qui crée, modifie et supprime les ressources : l'API, la console) et plan de données (ce qui sert le trafic : les instances qui tournent, les paquets routés, les lectures et écritures). Un plan de données bien conçu continue de fonctionner quand le plan de contrôle est en panne. Une architecture statiquement stable ne dépend que du plan de données pendant une panne.

En pratique

L'équipe de Signalements prépare le placement de ses deux instances. Les instances elles-mêmes seront créées à la leçon 4 ; ici, on vérifie que le placement prévu est possible, on règle la configuration et l'on apprend à savoir où se trouve chaque ressource.

Les commandes ont été vérifiées avec l'aide de scw 2.62 ; elles appellent l'API de votre compte, et la leçon ne montre pas de sortie inventée.

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

Toutes les commandes zonales de scw prennent un argument zone=, et toutes les commandes régionales un argument region=. Sans lui, la CLI utilise la valeur par défaut de votre profil. Fixez-la explicitement, plutôt que de compter sur la valeur par défaut de l'outil :

$ scw config set default-region=fr-par
$ scw config set default-zone=fr-par-1
$ scw config get default-zone

La dernière commande affiche fr-par-1. Dans la suite du cours, les commandes qui visent fr-par-2 le disent explicitement par zone=fr-par-2 : ne comptez jamais sur la zone par défaut pour une ressource dont l'emplacement compte.

Vérifier que le type d'instance existe dans les deux zones

L'équipe a choisi le type PRO2-XXS (2 vCPU partagés, 8 Gio de mémoire, stockage bloc ; la leçon 4 justifie ce choix). Vérifions qu'il est proposé, et en stock, dans les deux zones visées :

$ scw instance server-type list zone=fr-par-1
$ scw instance server-type list zone=fr-par-2

En affichage humain, la commande liste chaque type avec son prix horaire, ses ressources et une colonne de disponibilité, que la CLI colore : available en vert, low stock en jaune, out of stock en rouge. En JSON, chaque élément a un champ name et un champ availability (valeurs available, scarce ou shortage) ; on peut donc filtrer :

$ for z in fr-par-1 fr-par-2 fr-par-3; do
    printf '%s : ' "$z"
    scw instance server-type list zone="$z" -o json \
      | jq -r '.[] | select(.name == "PRO2-XXS") | .availability'
  done

Une ligne vide pour une zone signifie que le type n'y est pas proposé du tout. scarce est un signal à prendre au sérieux : la création risque d'échouer, et surtout, en cas de panne d'une autre zone, ce type sera le premier à manquer. Une architecture qui doit pouvoir recréer des instances dans la zone survivante a besoin d'un type qui y est abondant, ou d'une liste de types de repli.

Un groupe de placement pour plus tard

Signalements n'aura qu'une instance par zone. Un groupe de placement ne sert donc à rien pour l'instant : il ne peut pas contenir sig-app-1 (fr-par-1) et sig-app-2 (fr-par-2), puisqu'il est zonal. Il deviendra utile le jour où l'équipe ajoutera une seconde instance dans fr-par-1. Voici comment le créer ce jour-là :

$ scw instance placement-group create name=pg-sig-par1 \
    policy-type=max_availability policy-mode=enforced zone=fr-par-1

• policy-type=max_availability demande des hyperviseurs différents ;
• policy-mode=enforced fait échouer la création ou le démarrage d'une instance plutôt que de la placer en violation de la règle. Le choix est un arbitrage : enforced garantit la propriété, au risque de ne pas pouvoir démarrer une instance un jour de pénurie ; optional démarre toujours, et il faut alors surveiller le champ policy_respected.

Une instance rejoint un groupe à sa création (placement-group-id= dans scw instance server create) ou ensuite, arrêtée, avec scw instance server update <id> placement-group-id=<id> : la documentation de Scaleway précise qu'un placement ne peut pas être appliqué à une instance en marche.

Savoir où se trouve chaque ressource

Une habitude à prendre dès maintenant : pouvoir répondre à « qu'avons-nous dans quelle zone ? ». L'argument zone=all des commandes de liste zonales interroge toutes les zones d'un coup :

$ scw instance server list zone=all -o json \
    | jq -r '.[] | [.name, .zone, .state] | @tsv'

Chaque instance du compte apparaît avec sa zone et son état. Pour les ressources régionales, l'équivalent est region=all quand la commande l'accepte (vérifiez avec --help) ; sinon, une boucle sur les régions. Ce réflexe vous servira à la leçon 8, pour vérifier qu'il ne reste rien de facturé à la fin d'une séance, et en incident, pour savoir en une commande ce qu'une panne de zone touche.

Le plan de Signalements

Avec ces éléments, l'équipe écrit son plan de placement, qu'elle versionne avec le code (un simple fichier docs/placement.md) :

Chaque instance devra pouvoir porter seule tout le trafic : c'est la condition de stabilité statique avec deux zones. Pour Signalements, dont la charge tient sur une petite instance, cela revient à dimensionner chacune comme si l'autre n'existait pas.

Sous le capot

Pourquoi une zone ne fait pas « un seul site ». Un fournisseur ne peut pas construire des centres de données à volonté : il dépend du foncier, de l'électricité disponible et des fibres existantes. Les zones sont donc souvent des regroupements administratifs de sites existants, choisis pour ne pas partager leurs dépendances critiques (poste électrique, opérateurs de fibre, refroidissement). La définition de Scaleway (un ou plusieurs centres de données dans un rayon de 5 km, 1,4 ms de latence interne au plus) le dit en creux : à l'intérieur d'une zone, les sites sont assez proches pour être traités comme un seul réseau local ; entre zones, ils sont assez éloignés pour ne pas partager les mêmes risques locaux.

La latence entre zones. La lumière parcourt environ 200 km par milliseconde dans une fibre. Trente kilomètres de fibre (le tracé réel est toujours plus long que la distance à vol d'oiseau) ajoutent donc environ 0,15 ms dans chaque sens ; ce sont surtout les équipements traversés qui fixent la latence observée, de l'ordre de la milliseconde ou de quelques millisecondes aller-retour. C'est assez peu pour qu'une base de données réplique de façon synchrone entre zones (chaque écriture attend la confirmation de l'autre zone), ce qui devient pénalisant entre Paris et Amsterdam (environ 430 km : plus de 4 ms aller-retour pour la seule propagation, souvent une dizaine en pratique, ajoutées à chaque écriture). D'où la règle générale : réplication synchrone entre zones d'une région, réplication asynchrone (avec perte possible des dernières secondes) entre régions. Mesurez la latence réelle entre vos instances une fois le réseau privé en place (leçon 6) plutôt que de la supposer.

Le trafic entre zones peut coûter. Certains fournisseurs facturent le trafic qui franchit une frontière de zone (AWS le fait ; Azure indique au contraire ne pas facturer le transfert entre zones d'une même région). Une architecture bavarde, où chaque requête traverse trois fois la frontière, peut coûter cher à grande échelle. La leçon 8 revient sur ces coûts de transfert.

Plan de contrôle régional. Même quand vos ressources sont zonales, l'API qui les gère est souvent servie au niveau de la région, voire globalement (l'IAM de Scaleway est globale). Une panne de ce plan de contrôle n'arrête pas vos instances, mais vous empêche de les modifier, d'en créer, parfois de vous authentifier. C'est exactement ce qu'ont vécu les clients d'AWS en décembre 2021.

Pièges courants

Croire que plusieurs zones protègent de tout. Le 10 mars 2025, une erreur humaine dans la configuration d'un routeur, lors du raccordement d'un nouveau centre de données au réseau de Scaleway à Paris, a fait passer plus d'un térabit par seconde de trafic sur un seul lien de 100 Gbit/s. Le compte rendu publié sur la page d'état de Scaleway indique que l'erreur a été corrigée en quatre minutes, mais que la connectivité Internet entre fr-par-2 et le reste de la région a été perturbée, et que plusieurs produits (DNS, stockage objet, Kubernetes, instances) ont été touchés ; le stockage objet a mis plus de temps à se rétablir à cause d'un bogue de réplication. Le compte rendu précise aussi que les communications par VPC n'ont pas été touchées et qu'aucune donnée n'a été perdue. Une application répartie sur trois zones de fr-par a pu être affectée. Seule une seconde région protège d'une panne de ce type.

Croire que le fournisseur réparera vite. En octobre 2025, un défaut latent (une situation de concurrence) dans l'automate qui gère les enregistrements DNS de DynamoDB, dans la région us-east-1 d'AWS, a produit un enregistrement vide pour le point d'accès régional du service. Le résumé publié par AWS décrit ensuite une cascade : le gestionnaire interne d'EC2 qui dépend de DynamoDB a perdu le contact avec ses machines physiques, puis s'est effondré sous la charge en voulant tout rétablir à la fois ; les vérifications de santé des répartiteurs de charge réseau (NLB) ont échoué alors que les cibles étaient saines. Le cœur de l'incident a duré environ trois heures dans la nuit du 19 au 20 octobre ; le retour complet à la normale a pris jusqu'à l'après-midi. Le rayon d'impact a suivi les dépendances entre services, pas la géographie.

Dépendre du plan de contrôle pendant la panne. Le 7 décembre 2021, toujours dans us-east-1, une opération automatique de mise à l'échelle d'un service interne d'AWS a provoqué une congestion du réseau interne. AWS écrit que les instances EC2 en marche n'ont pas été touchées, mais que les API servant à lancer ou à décrire des instances ont connu des taux d'erreur élevés pendant plusieurs heures, ainsi que la connexion à la console et le service de jetons STS ; même le tableau de bord d'état d'AWS n'a pas pu basculer sur sa région de secours. Une architecture qui tournait déjà a continué de tourner ; une architecture qui comptait sur la création d'instances pour absorber la panne n'a pas pu le faire.

Garder ses sauvegardes au même endroit. La leçon de Strasbourg : une sauvegarde dans le même site, ou dans la même zone, protège d'une erreur de manipulation, pas d'un sinistre. Les sauvegardes d'une application de production vont dans une autre région, et l'on vérifie régulièrement qu'on sait les restaurer (cours Sauvegarde, restauration et PRA).

Supposer qu'un service managé est multizone. « Managé » ne veut pas dire « réparti ». Lisez la documentation de chaque service : où sont les copies, qui bascule, en combien de temps. Quand elle ne dit rien, considérez le service comme zonal.

Le type d'instance absent de la zone de secours. L'architecture prévoit de recréer des instances en fr-par-2 si fr-par-1 tombe ; le jour J, le type choisi y est en pénurie, parce que tous les clients de fr-par-1 ont eu la même idée. Prévoyez des instances déjà en marche (stabilité statique) ou une liste de types de repli.

Un seul répartiteur de charge zonal devant deux zones. Les instances sont réparties, le point d'entrée ne l'est pas. Si fr-par-1 tombe, lb-signalements tombe avec elle et sig-app-2, saine, ne reçoit plus rien. La leçon 6 discute les parades (un second répartiteur dans l'autre zone et un DNS qui bascule, ou une IP flexible déplacée).

Sécurité

La répartition géographique est d'abord une question de disponibilité, l'un des trois piliers de la sécurité de l'information avec la confidentialité et l'intégrité. Quelques points méritent l'attention :

• La localisation des données est une exigence de sécurité et de conformité. Un contrat avec une collectivité peut imposer que les données restent en France. Une sauvegarde automatiquement copiée à Amsterdam, ou un réplica placé à Varsovie, peut alors être une non-conformité. Documentez où va chaque copie, et faites-le valider.
• Les copies multiplient la surface d'attaque. Chaque réplica, chaque sauvegarde dans une autre région doit être protégé (chiffrement, droits d'accès) aussi bien que l'original. Une sauvegarde oubliée dans une région que personne ne surveille est une fuite qui attend son heure.
• Un rançongiciel n'a pas de géographie. Si la même clé d'API peut supprimer les données de Paris et leurs sauvegardes d'Amsterdam, la seconde région ne protège pas d'un attaquant qui a volé cette clé. Isolez les sauvegardes par les droits (un projet distinct, une identité distincte, des sauvegardes non modifiables), pas seulement par la distance. La leçon 7 montre comment limiter les droits d'une identité à un projet.
• Les zones ne protègent pas des erreurs de configuration. Une règle de pare-feu trop ouverte, déployée par le même outil dans toutes les zones, est ouverte partout. L'incident de mars 2025 rappelle que la cause la plus fréquente des grandes pannes est un changement, et le cours Stratégies de déploiement montre comment déployer zone par zone pour limiter le rayon d'impact d'un changement, comme AWS et Azure le font pour leurs propres services.

En production

• Commencez par définir la panne à survivre. « Une instance », « une zone » et « une région » sont trois architectures de coût et de complexité très différents. Pour beaucoup d'applications métier, deux zones dans une région, avec des sauvegardes dans une autre région et une procédure de reprise testée, sont le bon compromis. Le multirégion actif-actif (les deux régions servent du trafic en permanence) est un projet en soi : données répliquées de façon asynchrone, conflits d'écriture, DNS, coûts doublés.
• Écrivez les objectifs de reprise. Le RTO (durée maximale d'interruption acceptable) et le RPO (quantité maximale de données que l'on accepte de perdre, exprimée en durée) découlent du besoin métier et dictent l'architecture : un RPO de zéro impose une réplication synchrone, donc des zones d'une même région. Le cours Sauvegarde, restauration et PRA les détaille.
• Exercez la panne. Une bascule jamais testée ne fonctionne pas le jour où l'on en a besoin. Arrêter volontairement toutes les instances d'une zone en préproduction, puis en production pendant une fenêtre choisie, est le seul moyen de vérifier la stabilité statique (cours Chaos engineering).
• Suivez la page d'état de votre fournisseur (status.scaleway.com pour Scaleway) et abonnez l'astreinte aux incidents des zones et des produits que vous utilisez. En octobre 2024, une défaillance logicielle d'un commutateur, puis des réflecteurs de routes BGP du VPC, a privé environ 25 % des hyperviseurs de fr-par-1 de connectivité VPC pendant onze minutes, affectant les bases managées, le serverless et Kapsule ; Scaleway indique que les autres zones n'ont pas été touchées. Une application répartie sur deux zones a traversé cet incident ; une application zonale l'a subi. Savoir lire ces comptes rendus, c'est vérifier que son architecture a les bonnes frontières.
• Chez Lyneko, les applications tournent sur le cluster Kapsule lyneko-apps dans la région fr-par, et les données suivent la même région : les clients publics le demandent. La question des zones se pose alors au niveau des nœuds du cluster, que le cours Kapsule : Kubernetes managé chez Scaleway traite.

Exercices

1. Traduire des neuf (niveau 100). Un fournisseur s'engage sur 99,95 % de disponibilité mensuelle pour son répartiteur de charge. Combien de minutes d'indisponibilité cela autorise-t-il sur un mois de 30 jours ? Et sur une année ?

2. Série et parallèle (niveau 200). Prenez des valeurs d'illustration : répartiteur de charge à 99,9 %, chaque instance à 99,5 %, base de données à 99,9 %. Calculez la disponibilité théorique de Signalements (a) avec une seule instance, (b) avec deux instances indépendantes derrière le répartiteur. Quelle hypothèse rend le résultat (b) optimiste ?

3. Lire une carte des risques (niveau 200). Pour chacune des pannes suivantes, dites ce que Signalements, placé selon le plan de la leçon, perd et ce qu'il garde : (a) panne d'un hyperviseur portant sig-app-2 ; (b) panne totale de fr-par-1 ; (c) panne de l'API de Scaleway dans la région fr-par, sans panne des centres de données ; (d) incendie qui détruit les trois zones de Paris.

4. Choisir l'outil (niveau 200). Pour chaque besoin, choisissez entre groupe de placement max_availability, groupe low_latency, répartition sur plusieurs zones, ou seconde région : (a) trois instances d'un calcul distribué qui échangent énormément de données entre elles ; (b) deux instances d'une API dans la même zone, parce que le type d'instance n'existe que dans cette zone ; (c) survivre à une erreur de configuration du cœur de réseau de Paris ; (d) survivre à la perte d'un bâtiment.

Récapitulatif

• Un domaine de panne est un ensemble d'équipements qui tombent ensemble ; les fournisseurs en exposent deux niveaux, la zone et la région.
• Une zone de disponibilité regroupe un ou plusieurs centres de données proches, à l'énergie, au refroidissement et au réseau indépendants des autres zones ; elle protège de la perte d'un site, pas d'une agglomération.
• Une région regroupe des zones dans une même agglomération ; deux régions sont distantes de centaines de kilomètres et séparées logiciellement. Scaleway en compte quatre : fr-par, nl-ams, pl-waw (trois zones chacune) et it-mil (une zone).
• Chaque ressource est zonale, régionale ou globale ; chez Scaleway, l'argument zone= ou region= de la CLI le révèle. Instances, volumes, IP, groupes de sécurité, répartiteurs et passerelles sont zonaux ; réseaux privés, bases managées, buckets et clusters sont régionaux ; projets et IAM sont globaux.
• Les groupes de placement (max_availability, low_latency) agissent à l'intérieur d'une zone et ne remplacent pas la répartition sur plusieurs zones.
• Les disponibilités se multiplient en série et se combinent en parallèle (1 − produit des indisponibilités), à condition que les pannes soient indépendantes.
• Une architecture statiquement stable survit à une panne sans avoir à agir : chaque zone peut porter seule la charge que l'autre ne porte plus.
• Le rayon d'impact suit les dépendances autant que la géographie : erreurs de configuration, plans de contrôle et services partagés traversent les zones.

Pour aller plus loin

• Le livre blanc AWS Fault Isolation Boundaries, qui détaille, au-delà d'AWS, la façon de raisonner en domaines de panne, plans de contrôle et plans de données.
• L'article Static stability using Availability Zones de la Builders' Library d'AWS.
• Les comptes rendus d'incidents publiés par Scaleway (blog et status.scaleway.com) et par AWS (Post-Event Summaries) : les lire régulièrement est la meilleure formation à la conception pour la panne.
• La leçon suivante, Le calcul : instances, images et cloud-init, où l'on crée sig-app-1 et sig-app-2 aux emplacements choisis ici.