OUTSCALE expose son cloud à travers deux régions européennes : eu-west-2 (région publique commerciale en France) et cloudgouv-eu-west-1 (région française qualifiée SecNumCloud 3.2). Chaque région se subdivise en plusieurs sous-régions (l’équivalent des « Availability Zones » d’AWS) — des datacenters physiquement distincts mais reliés par une latence très faible. Cette page explique comment choisir entre les deux régions et comment exploiter les sous-régions pour bâtir une architecture résiliente.
Ce que vous allez apprendre
Section intitulée « Ce que vous allez apprendre »- La différence entre une région et une sous-région OUTSCALE.
- Les caractéristiques des deux régions européennes —
eu-west-2etcloudgouv-eu-west-1. - Quand choisir la région SecNumCloud
cloudgouv-eu-west-1vs la région commercialeeu-west-2. - L’isolation entre régions — pourquoi une ressource créée dans l’une n’existe pas dans l’autre.
- Les patterns multi-AZ pour la haute disponibilité, avec les contraintes et la latence inter-AZ.
Prérequis
Section intitulée « Prérequis »- Connaître le vocabulaire de base (région, sous-région, ressource cloud) — sinon, voir Régions et zones de disponibilité côté fondamentaux.
- Une lecture préalable du Vocabulaire OUTSCALE ↔ AWS facilite la mise en correspondance avec les concepts AWS.
Région et sous-région — la mécanique
Section intitulée « Région et sous-région — la mécanique »Une région est une zone géographique correspondant à une localisation physique (par exemple, la France pour eu-west-2). Chaque région contient plusieurs sous-régions (eu-west-2a, eu-west-2b, eu-west-2c), qui sont des datacenters distincts au sein de cette zone géographique. Cette structure permet deux choses :
- Isolation des défaillances — si un datacenter physique perd le courant ou le réseau, les autres sous-régions de la même région continuent de fonctionner. C’est la base de toute architecture haute disponibilité sur OUTSCALE.
- Latence faible inter-AZ — les sous-régions d’une même région sont reliées par un réseau privé à moins de 2 ms de latence, ce qui rend possible les bases de données répliquées multi-AZ et les load balancers cross-AZ sans pénalité notable.
À l’inverse, deux régions différentes (par exemple eu-west-2 et cloudgouv-eu-west-1) sont complètement isolées : pas de réseau privé entre elles, pas de mécanisme de réplication automatique, et aucune ressource créée dans l’une n’est visible dans l’autre. La latence inter-région passe sur Internet public ou un lien dédié facturé séparément.
Région eu-west-2 — France, publique commerciale
Section intitulée « Région eu-west-2 — France, publique commerciale »La région eu-west-2 est située en France (région parisienne). Elle est commerciale publique : disponible sans qualification particulière, elle convient à la majorité des projets qui ne sont pas soumis à une exigence de souveraineté forte.
| Caractéristique | Valeur |
|---|---|
| Localisation | France (région parisienne) |
| Sous-régions | eu-west-2a, eu-west-2b, eu-west-2c |
| Qualification | Certifications standards (ISO 27001, ISO 27017, ISO 27018, HDS, SOC 2, CISPE, TISAX) |
| Public cible | Projets commerciaux, applications métier, charges sans contrainte SecNumCloud |
| Endpoint OAPI | https://api.eu-west-2.outscale.com/api/v1 |
La région eu-west-2 couvre la majorité des certifications sectorielles (HDS pour la santé, TISAX pour l’automobile) et reste éligible RGPD puisque les données sont hébergées sur le territoire français. C’est la région par défaut pour démarrer un projet OUTSCALE.
Région cloudgouv-eu-west-1 — cloud souverain SecNumCloud
Section intitulée « Région cloudgouv-eu-west-1 — cloud souverain SecNumCloud »La région cloudgouv-eu-west-1 est la région souveraine d’OUTSCALE, qualifiée SecNumCloud 3.2 par l’ANSSI depuis décembre 2023. Elle s’adresse aux organisations soumises à des exigences fortes de souveraineté ou de conformité.
| Caractéristique | Valeur |
|---|---|
| Localisation | France |
| Sous-régions | cloudgouv-eu-west-1a, cloudgouv-eu-west-1b, cloudgouv-eu-west-1c |
| Qualification | SecNumCloud 3.2 (ANSSI), HDS, ISO 27001 |
| Public cible | OIV, OSE, secteur public sensible, données de santé sensibles, défense, finance régulée |
| Endpoint OAPI | https://api.cloudgouv-eu-west-1.outscale.com/api/v1 |
Une sous-région complémentaire cloudgouv-eu-west-1c a été ouverte récemment ; toutes les sous-régions de cette région sont qualifiées SecNumCloud, et tous les services OUTSCALE y sont disponibles, y compris le stockage objet OOS et les fGPU NVIDIA pour les charges IA souveraines.
L’usage de cette région est obligatoire pour les organisations qui doivent appliquer la doctrine « Cloud au centre » du gouvernement français pour leurs données sensibles. Elle est également pertinente pour toute organisation qui souhaite réduire au maximum son exposition aux lois extraterritoriales (Cloud Act, FISA).
Choisir entre les deux régions
Section intitulée « Choisir entre les deux régions »Le choix se fait sur la base de trois critères principaux : exigences réglementaires, type de données traitées, profil des utilisateurs.
| Critère | eu-west-2 | cloudgouv-eu-west-1 |
|---|---|---|
| Exigence SecNumCloud explicite | Non requise | Obligatoire ou fortement recommandée |
| Données de santé courantes | OK (HDS) | OK (HDS + SecNumCloud) |
| Données classifiées / défense | Insuffisant | Adapté |
| Données OIV / OSE | Insuffisant pour les charges sensibles | Adapté |
| Coût | Tarification standard | Tarification spécifique (cf. commercial OUTSCALE) |
| Catalogue de services | Complet | Complet (tous les services OUTSCALE disponibles) |
| Onboarding | Standard, immédiat | Process spécifique (vérification, contractualisation) |
Arbre de décision simplifié :
- Vous traitez des données classifiées, ou vous êtes OIV/OSE soumis à NIS2 sur des charges sensibles ? →
cloudgouv-eu-west-1. - Votre client public exige SecNumCloud (doctrine Cloud au centre) pour ce projet ? →
cloudgouv-eu-west-1. - Vous traitez des données de santé courantes, soumises à HDS ? →
eu-west-2oucloudgouv-eu-west-1(les deux sont HDS). - Vous démarrez un projet sans exigence réglementaire forte ? →
eu-west-2par défaut. - Vous hésitez et voulez maximiser l’isolation juridique pour des données sensibles non-classifiées ? →
cloudgouv-eu-west-1est généralement le bon choix.
Architecture multi-AZ — la base de la haute disponibilité
Section intitulée « Architecture multi-AZ — la base de la haute disponibilité »À l’intérieur d’une région, répartir vos ressources sur plusieurs sous-régions (au moins deux) protège contre les pannes d’un datacenter physique. C’est le socle de la fiabilité (pilier Reliability du Well-Architected).
Un pattern minimal multi-AZ
Section intitulée « Un pattern minimal multi-AZ »Un déploiement multi-AZ typique comprend :
- Un Net étendu sur la région.
- Un Subnet par sous-région (par exemple
subnet-adanseu-west-2a,subnet-bdanseu-west-2b). - Des VMs déployées dans les deux subnets.
- Un Load Balancer (LBU) qui répartit le trafic entre les VMs des deux sous-régions.
- Une base de données répliquée entre les sous-régions (réplication synchrone si la latence < 2 ms le permet).
Si une sous-région entière tombe en panne (incident électrique, défaillance réseau localisée), le load balancer route automatiquement le trafic vers les VMs restantes dans l’autre sous-région. L’application reste disponible.
Latence inter-AZ
Section intitulée « Latence inter-AZ »La latence entre deux sous-régions de la même région est typiquement inférieure à 2 ms, ce qui rend possible :
- La réplication synchrone d’une base de données (PostgreSQL streaming replication, MySQL group replication).
- L’utilisation d’un stockage partagé entre VMs de sous-régions différentes via OOS.
- L’orchestration Kubernetes (OKS) avec des nœuds répartis sur plusieurs sous-régions.
Cette latence est suffisamment faible pour ne pas dégrader significativement les performances applicatives.
BSU est lié à une sous-région
Section intitulée « BSU est lié à une sous-région »Un volume BSU (Block Storage Unit) est attaché à une sous-région précise. Pour utiliser un volume avec une VM, les deux doivent être dans la même sous-région. Pour répliquer un volume entre sous-régions, on passe par un snapshot (qui peut, lui, être copié vers une autre sous-région ou utilisé pour créer un nouveau volume ailleurs).
Cohérence multi-régions et plan de reprise
Section intitulée « Cohérence multi-régions et plan de reprise »Pour une architecture qui doit survivre à la perte d’une région entière (cas extrême), la stratégie habituelle est :
- Production primaire dans une région (par exemple
eu-west-2). - Sauvegardes asynchrones vers une seconde région (par exemple
cloudgouv-eu-west-1si une exigence souveraine apparaît). - Plan de reprise documenté qui décrit comment redéployer l’application dans la région secondaire à partir des sauvegardes.
Attention : la copie de données d’une région à l’autre passe sur Internet public ou via un lien DirectLink dédié. Elle est facturée comme du trafic sortant et doit être prise en compte dans le budget. Le sujet du DR multi-régions est traité plus en détail dans le Volet 2 (sauvegardes, RPO/RTO).
À retenir
Section intitulée « À retenir »- OUTSCALE expose deux régions européennes :
eu-west-2(commercial) etcloudgouv-eu-west-1(SecNumCloud 3.2). - Chaque région contient 3 sous-régions (a, b, c), des datacenters distincts reliés par une latence inférieure à 2 ms.
- Les régions sont isolées : aucune ressource n’est visible d’une région à l’autre, toute réplication est explicite.
- Choisir
cloudgouv-eu-west-1dès qu’une exigence SecNumCloud explicite, OIV/OSE, ou doctrine « Cloud au centre » s’applique.eu-west-2est le défaut pour les projets sans exigence souveraine forte. - Un déploiement multi-AZ au sein d’une région (Subnets sur plusieurs sous-régions, LBU + base répliquée) est la base de la haute disponibilité.
- Un volume BSU est lié à une sous-région — penser au snapshot pour transférer entre sous-régions.