Régions et Sous-régions cloud : comprendre et choisir

Où déployer vos applications cloud ? Cette question simple cache des enjeux critiques : disponibilité, performance, conformité légale et coûts. Ce guide vous explique la hiérarchie géographique du cloud Outscale (régions et sous-régions), vous donne les critères de décision et vous aide à anticiper les coûts de vos choix d’architecture.

Ce que vous allez apprendre

• Comprendre la différence entre région et sous-région dans le cloud Outscale
• Savoir choisir une région selon vos contraintes (latence, conformité, coûts)
• Concevoir une architecture résiliente avec plusieurs sous-régions
• Anticiper les coûts cachés liés au transfert de données entre sous-régions et régions

Prérequis : connaître les bases du cloud computing. Si vous débutez, commencez par Qu’est-ce que le cloud ?.

Pourquoi la géographie compte dans le cloud

Quand vous utilisez le cloud, vos applications tournent sur des serveurs physiques réels, situés dans des datacenters quelque part dans le monde. Ce “quelque part” n’est pas anodin :

• Un utilisateur à Paris qui accède à un serveur aux États-Unis subira ~100 ms de latence
• Une panne électrique régionale peut affecter tous les serveurs d’une même zone physique
• Les lois sur les données varient selon les pays (RGPD en Europe, par exemple)
• Les coûts de transfert augmentent quand les données traversent les océans

Outscale a donc organisé son infrastructure en deux niveaux géographiques pour vous permettre de faire des choix éclairés : les Régions et les Sous-régions.

La hiérarchie géographique Outscale : Région → Sous-région

Imaginez le cloud comme une chaîne de supermarchés :

• La Région = un pays où la chaîne est implantée (France, États-Unis, Japon…)
• La Sous-région (Subregion) = un magasin dans ce pays (Paris Nord, Paris Sud…)

Chaque niveau offre un compromis différent entre isolation (protection contre les pannes) et proximité (performance et coûts).

Vue d’ensemble de l’infrastructure Outscale

Niveau	Ce que c’est	Isolation	Latence interne	Exemple Outscale
Région	Zone géographique large (pays/continent)	Maximale (datacenters séparés de centaines de km)	50-150 ms entre régions	eu-west-2 (France)
Sous-région (Subregion)	Datacenter(s) isolé(s) dans une région	Forte (alimentation, réseau, refroidissement séparés)	< 2 ms entre sous-régions	eu-west-2a, eu-west-2b, eu-west-2c

Terminologie Outscale vs autres providers

Outscale utilise le terme “Sous-région” (Subregion) pour désigner des datacenters isolés au sein d’une même région. C’est l’équivalent des “Availability Zones” chez AWS ou Azure. Dans ce guide, nous utiliserons la terminologie Outscale.

Les Régions Outscale : votre première décision stratégique

Une Région est une zone géographique large (généralement un pays ou une partie de continent) où Outscale a déployé son infrastructure. Chaque région est totalement indépendante des autres : ses propres datacenters, son propre réseau, ses propres équipes.

Particularité Outscale

Outscale est un cloud souverain français, certifié SecNumCloud par l’ANSSI. C’est un choix privilégié pour les entreprises ayant des exigences de souveraineté ou de conformité strictes. La région cloudgouv-eu-west-1 est spécifiquement conçue pour les données sensibles.

Pourquoi plusieurs régions existent

Les fournisseurs cloud ne construisent pas des régions par plaisir — chaque région répond à des besoins spécifiques :

Besoin	Pourquoi une région dédiée
Proximité des utilisateurs	Réduire la latence pour les clients locaux
Conformité réglementaire	Certaines lois exigent que les données restent dans le pays
Résilience globale	Une catastrophe naturelle n’affectera qu’une région
Souveraineté	Les données sensibles restent sous juridiction française

Les Régions disponibles chez Outscale

Outscale propose 5 régions publiques réparties sur 3 continents :

Région	Code	Sous-régions	Zones physiques	Particularité
France	eu-west-2	eu-west-2a, eu-west-2b, eu-west-2c	PAR1, PAR4, PAR7 (Île-de-France)	Région principale, RGPD
France SecNumCloud	cloudgouv-eu-west-1	cloudgouv-eu-west-1a, 1b, 1c	SEC1, SEC2, SEC3 (Île-de-France)	Certifié ANSSI, données sensibles
USA Est	us-east-2	us-east-2a, us-east-2b	NJ1, NJ2 (New Jersey)	Marché américain
USA Ouest	us-west-1	us-west-1a, us-west-1b	SV1, SV2 (Californie)	Côte ouest américaine
Japon	ap-northeast-1	ap-northeast-1a, ap-northeast-1b	JPN1, JPN2 (Tokyo)	Marché asiatique

Mapping aléatoire des sous-régions

Chez Outscale, le mapping entre sous-régions et zones physiques est aléatoire par compte. Par exemple, pour un compte, eu-west-2a peut correspondre à PAR1, tandis que pour un autre compte, eu-west-2a correspond à PAR4. Cette distribution aléatoire permet d’équilibrer la charge entre les datacenters.

Pour connaître le mapping de votre compte, utilisez l’API ReadSubregions.

Comment choisir sa région principale

Le choix de votre région principale repose sur quatre critères à pondérer selon votre contexte :

1. La proximité de vos utilisateurs (latence)

   C’est souvent le critère n°1. Chaque milliseconde compte pour l’expérience utilisateur.

   Distance serveur-utilisateur	Latence typique	Impact perçu
   Même pays	10-30 ms	Imperceptible
   Même continent	30-80 ms	Léger délai
   Intercontinental	100-300 ms	Noticeable

   Pour des utilisateurs français : privilégiez eu-west-2 ou cloudgouv-eu-west-1.

2. Les contraintes légales et réglementaires

   Certaines données doivent rester dans certains pays :

   • RGPD (Europe) : les données personnelles des Européens doivent être traitées selon les règles européennes
   • Données gouvernementales françaises → cloudgouv-eu-west-1 (certifié SecNumCloud)
   • Données de santé (HDS) → vérifier les certifications de la région

   Attention aux transferts de données

   Même si vos serveurs sont en France, si vos données transitent par une région US (backup, analytics…), vous devez vous assurer de la conformité. Outscale, en tant que cloud souverain français, garantit que les données restent sous juridiction française dans les régions eu-west-2 et cloudgouv-eu-west-1.

3. Les services disponibles

   Toutes les régions ne proposent pas tous les services ! Certains services peuvent être d’abord déployés dans les régions principales, puis étendus progressivement.

   Vérifiez toujours sur la documentation Outscale que les services dont vous avez besoin sont disponibles dans votre région cible.

4. Les coûts

   Les prix peuvent varier selon les régions en fonction des coûts d’infrastructure locaux.

   Région Outscale	Facteurs de coût
   eu-west-2 (France)	Coûts énergétiques européens
   cloudgouv-eu-west-1	Premium pour certification SecNumCloud
   us-east-2 / us-west-1	Coûts infrastructure US
   ap-northeast-1 (Japon)	Coûts infrastructure Asie

   Cloud souverain = investissement sécurité

   Le surcoût éventuel de cloudgouv-eu-west-1 est à mettre en perspective avec la valeur de la certification SecNumCloud : conformité garantie, protection juridique française, et confiance accrue des clients/partenaires.

Les Sous-régions : la clé de la haute disponibilité

Une Sous-région (Subregion) est un ou plusieurs datacenters physiquement séparés au sein d’une même région, mais reliés par un réseau à très faible latence (< 2 ms). C’est l’équivalent des “Availability Zones” d’AWS ou Azure.

Pourquoi les sous-régions existent

L’objectif est simple : survivre aux pannes locales sans sacrifier la performance.

Imaginez une région sans sous-régions : tous les serveurs sont dans le même datacenter. Si ce datacenter subit une panne (incendie, inondation, coupure électrique), tout tombe.

Avec plusieurs sous-régions :

• Chaque sous-région a son alimentation électrique indépendante
• Chaque sous-région a sa connexion réseau séparée
• Chaque sous-région a son système de refroidissement distinct
• Les sous-régions sont séparées de plusieurs kilomètres (pour éviter les catastrophes locales)

L'analogie du RAID pour vos serveurs

Si vous connaissez le RAID pour les disques durs (miroir sur plusieurs disques pour survivre à une panne), les sous-régions sont le même concept à l’échelle des datacenters. Vos données et applications sont répliquées sur des infrastructures physiquement séparées.

Zones physiques Outscale en France

Pour la région eu-west-2 (France), Outscale dispose de 3 zones physiques en Île-de-France :

Zone physique	Localisation	Caractéristiques
PAR1	Magny-les-Hameaux	Datacenter Île-de-France Sud
PAR4	Pantin	Datacenter Île-de-France Nord
PAR7	Aubergenville	Datacenter Île-de-France Ouest

Ces trois zones sont suffisamment éloignées pour garantir l’isolation en cas de catastrophe locale, tout en étant reliées par fibre optique pour une latence minimale.

Comment fonctionnent les sous-régions

Les sous-régions d’une même région sont conçues pour offrir le meilleur des deux mondes :

Caractéristique	Valeur typique	Bénéfice
Distance entre sous-régions	10-100 km	Protection contre catastrophes locales
Latence inter-sous-région	1-2 ms	Performance quasi-identique à une seule sous-région
Bande passante inter-sous-région	Très haute (10+ Gbps)	Réplication temps réel possible
Isolation électrique	Totale	Une panne n’affecte qu’une sous-région
Isolation réseau	Totale	Problème de routage isolé

Architecture mono-sous-région vs multi-sous-région

La différence de résilience est considérable :

Scénario	Mono-sous-région	Multi (2 sous-régions)	Multi (3 sous-régions)
Panne d’une sous-région	Indisponibilité totale	50% de capacité restante	66% de capacité restante
Disponibilité théorique	99.9%	99.99%	99.999%
Temps d’indisponibilité/an	~8.7 heures	~52 minutes	~5 minutes

Multi-sous-région ≠ automatiquement résilient

Déployer dans plusieurs sous-régions ne suffit pas ! Votre architecture applicative doit être conçue pour :

• Répliquer les données entre sous-régions (bases de données en mode réplica)
• Distribuer le trafic (load balancer multi-sous-région)
• Gérer le failover (détection de panne + bascule automatique)

Un serveur unique déployé dans une sous-région reste un point unique de défaillance, même si d’autres sous-régions existent.

Concevoir une architecture multi-sous-région sur Outscale

Voici les composants typiques d’une architecture multi-sous-région résiliente selon la documentation Outscale :

1. Créer un Net dans chaque sous-région

   Commencez par créer un Net (VPC Outscale) dans la première sous-région, puis un second Net dans une autre sous-région. Chaque Net contiendra vos subnets et ressources.

   # Exemple avec l'API Outscale
   osc-cli api CreateNet --NetRange "10.0.0.0/16" --Tenancy "default"

2. Créer des Subnets dans chaque sous-région

   Créez des subnets dédiés à chaque couche applicative (web, application, base de données) dans chaque Net/sous-région.

   Philosophie Outscale

   La recommandation Outscale est 1 service = 1 VM = 1 OMI (Outscale Machine Image). Cela permet de répliquer facilement vos services en créant de nouvelles VMs à partir de vos images.

3. Configurer le Net Peering entre sous-régions

   Pour que vos Nets communiquent entre sous-régions, créez un Net Peering. Cela permet la communication privée entre vos ressources réparties sur plusieurs sous-régions.

4. Déployer un Load Balancer (LBU)

   Utilisez le Load Balancing Unit (LBU) d’Outscale pour distribuer le trafic entre vos instances dans les différentes sous-régions. Le LBU détecte automatiquement les instances défaillantes.

5. Répliquer vos données

   Pour les bases de données, configurez une réplication entre sous-régions. Les données critiques doivent exister dans au moins 2 sous-régions pour survivre à une panne.

Coût du multi-sous-région

Le multi-sous-région a un coût — il faut le connaître pour faire des choix éclairés :

Composant	Surcoût multi-sous-région	Ce qui coûte
VMs / Instances	x2 ou x3	Vous payez chaque instance
Stockage répliqué	x2 ou x3	Volumes dupliqués
Transfert inter-sous-région	Faible	Données répliquées entre sous-régions
Load Balancer (LBU)	Minimal	Service managé
Transfert inter-AZ	~0.01-0.02 $/Go	Données répliquées entre AZ
Load Balancer (LBU)	Minimal	Service managé

Le calcul économique

Comparez le coût du multi-sous-région au coût d’une indisponibilité. Pour un e-commerce qui fait 10 000 €/heure de CA, 8 heures d’indisponibilité = 80 000 € de pertes. Le surcoût multi-sous-région est généralement rentabilisé dès qu’on a un business critique.

L’architecture multi-région : le niveau ultime

Pour les applications vraiment critiques, une seule région ne suffit pas. Une catastrophe régionale (tremblement de terre, cyberattaque massive, problème du provider) pourrait tout affecter.

Quand passer en multi-région sur Outscale

Besoin	Solution
Reprise d’activité (DR)	Région secondaire passive (ex: us-east-2 si primaire en eu-west-2)
Haute disponibilité globale	Régions actives simultanées
Faible latence mondiale	Plusieurs régions proches des utilisateurs
Séparation données sensibles	cloudgouv-eu-west-1 pour le sensible, eu-west-2 pour le reste

Architectures multi-région courantes

Active-Passive (DR)

Principe : une région principale active, une région secondaire en standby.

Exemple Outscale :

• Région primaire : eu-west-2 (France) — tout le trafic
• Région secondaire : us-east-2 (USA) — réplication, prêt à prendre le relais

Avantages :

• Coût modéré (région secondaire sous-dimensionnée)
• Simple à mettre en œuvre

Inconvénients :

• Temps de bascule (RTO) de quelques minutes à heures
• Possible perte de données (RPO) selon la réplication

Coût typique : +30-50% du coût mono-région

Active-Active

Principe : toutes les régions servent du trafic simultanément.

Exemple Outscale :

• eu-west-2 sert les utilisateurs européens
• us-east-2 sert les utilisateurs américains
• ap-northeast-1 sert les utilisateurs asiatiques

Avantages :

• Latence optimale pour tous les utilisateurs
• Bascule instantanée (le trafic va ailleurs)
• Pas de perte de données si réplication synchrone

Inconvénients :

• Complexité élevée (synchronisation des données)
• Coût doublé ou triplé

Coût typique : x2 à x3 du coût mono-région

Les coûts du multi-région

Le multi-région augmente significativement les coûts de transfert — c’est le piège principal :

Type de transfert	Coût approximatif	Impact
Intra-sous-région	Gratuit ou minimal	Aucun
Inter-sous-région (même région)	Faible	Modéré
Inter-région (même continent)	Plus élevé	Significatif
Inter-région (intercontinental)	Le plus élevé	Majeur

L'effet multiplicateur

Si vous répliquez une base de données de 1 To entre eu-west-2 et us-east-2 avec des changements fréquents, le coût de transfert seul peut devenir significatif. Ajoutez le stockage doublé, les instances doublées… Faites vos calculs avant de vous lancer !

Les pièges courants et comment les éviter

Piège n°1 : “Je déploie tout dans une seule sous-région, c’est plus simple”

Risque : une panne de sous-région = indisponibilité totale.

Solution : même pour les environnements de développement, prenez l’habitude du multi-sous-région. Le surcoût est faible et ça évite les mauvaises surprises en production.

Piège n°2 : “Je choisis la région la moins chère”

Risque : latence inacceptable pour vos utilisateurs, services manquants.

Solution : la région la moins chère n’est pas toujours la meilleure. Calculez le coût total incluant l’impact business de la latence. Pour des utilisateurs français, eu-west-2 sera presque toujours le bon choix.

Piège n°3 : “Multi-sous-région = je suis protégé contre tout”

Risque : une catastrophe régionale (rare mais possible) vous impacte quand même.

Solution : pour les applications vraiment critiques, ajoutez une stratégie de reprise d’activité multi-région (au moins des backups dans une autre région comme us-east-2).

Piège n°4 : “Je réplique tout entre régions pour être safe”

Risque : facture de transfert de données astronomique.

Solution : répliquez uniquement ce qui est nécessaire. Les données froides peuvent être répliquées moins fréquemment. Utilisez des outils de réplication incrémentale.

Piège n°5 : “Les sous-régions sont interchangeables”

Risque : certains services ou types d’instances ne sont pas disponibles dans toutes les sous-régions.

Solution : vérifiez la disponibilité des services dans chaque sous-région avant de concevoir votre architecture. Utilisez l’API ReadSubregions d’Outscale pour obtenir les informations détaillées.

Checklist de décision : choisir sa géographie cloud Outscale

Utilisez cette checklist pour guider vos choix :

Choix de la région

• Où sont mes utilisateurs ? → eu-west-2 pour la France/Europe
• Ai-je des contraintes de souveraineté ? → cloudgouv-eu-west-1 pour les données sensibles
• Les services dont j’ai besoin sont-ils disponibles ? → Consulter la documentation Outscale
• Quel est mon budget ? → Comparer les prix entre régions candidates
• Ai-je besoin de régions secondaires pour le DR ? → Identifier une région de backup

Choix du nombre de sous-régions

• Environnement de dev/test → 1 sous-région peut suffire (coût minimal)
• Production non critique → Minimum 2 sous-régions
• Production critique → 3 sous-régions recommandées (eu-west-2a, 2b, 2c)
• Mon application supporte-t-elle le multi-sous-région ? → Vérifier la réplication des données

Architecture multi-région (si nécessaire)

• Quel est mon RTO acceptable ? → Détermine si active-passive suffit
• Quel est mon RPO acceptable ? → Détermine le type de réplication
• Ai-je budgété le transfert inter-région ? → Calculer le coût des données répliquées
• Mon équipe sait-elle gérer le multi-région ? → Formation et procédures nécessaires

À retenir

Les 7 points essentiels

1. Deux niveaux géographiques Outscale : Région (zone géographique large) → Sous-région (datacenter isolé dans la région)

2. 5 régions Outscale : eu-west-2 (France), cloudgouv-eu-west-1 (France SecNumCloud), us-east-2 (USA Est), us-west-1 (USA Ouest), ap-northeast-1 (Japon)

3. Choisir sa région selon 4 critères : proximité des utilisateurs, conformité/souveraineté, services disponibles, et coûts

4. Multi-sous-région = haute disponibilité : répartir sur 2-3 sous-régions protège contre les pannes locales avec une latence minimale (< 2 ms)

5. Cloud souverain : cloudgouv-eu-west-1 est certifié SecNumCloud par l’ANSSI — idéal pour les données sensibles et gouvernementales

6. Multi-région = résilience ultime : pour le DR ou la présence mondiale, mais attention aux coûts de transfert inter-région

7. Mapping aléatoire : chez Outscale, le mapping sous-région → zone physique est aléatoire par compte — utilisez l’API ReadSubregions pour connaître le vôtre

Prochaines étapes

Voilà qui conclue la permière partie. On passe à la suite qui porte à la sécurité avec IAM

IAM: Identité et Gestion des Accès Apprenez à gérer les utilisateurs, rôles et permissions dans Outscale avec IAM pour sécuriser vos ressources cloud.

×

📖 Voir la documentation →