Le Net est le socle réseau d’une infrastructure OUTSCALE — l’équivalent du VPC d’AWS. Sa conception touche directement trois piliers du Well-Architected Framework : Reliability (multi-AZ), Security (isolation des tiers et des flux), Performance (latence inter-AZ < 2 ms). Une fois créé, le bloc CIDR d’un Net ne peut plus être modifié — autant le poser correctement dès le J1, en anticipant la croissance et les futurs besoins de peering. Cette page détaille les choix structurants, les patterns courants (public / privé / data), et la mécanique multi-sous-régions qui rend une infrastructure OUTSCALE réellement résiliente.
Ce que vous allez apprendre
Section intitulée « Ce que vous allez apprendre »- Ce qu’est un Net OUTSCALE et ses ressources associées par défaut.
- Choisir un bloc CIDR RFC 1918 adapté à votre projet, avec une marge pour la croissance.
- Découper en Subnets multi-AZ avec les tiers public, privé et data.
- Calculer la capacité réelle de chaque Subnet (IPs réservées par OUTSCALE).
- Créer un Net et ses Subnets via
oapi-cliou Terraform. - Anticiper le peering entre Nets, sans tomber dans les chevauchements de CIDR.
Prérequis
Section intitulée « Prérequis »- Bases du réseau IP : CIDR, masques, blocs RFC 1918, routage. Sinon, voir Réseau cloud — fondamentaux côté fondamentaux.
- Connaître le vocabulaire OUTSCALE ↔ AWS, notamment Net ↔ VPC, Subnet ↔ Subnet.
- Avoir lu la page Régions et sous-régions OUTSCALE pour la mécanique multi-AZ.
- Un compte OUTSCALE actif avec
oapi-cliconfiguré (cf. Outils CLI).
Le Net en deux phrases
Section intitulée « Le Net en deux phrases »Un Net est un réseau privé virtuel isolé dans une région OUTSCALE. Il définit une plage d’adresses IP privées (en notation CIDR), à l’intérieur de laquelle vous créez des Subnets rattachés à des sous-régions précises pour répartir vos ressources sur plusieurs datacenters physiques.
Le Net est isolé par défaut des autres Nets, du réseau Internet, et des autres comptes OUTSCALE. Pour communiquer avec l’extérieur, il faut explicitement ajouter des passerelles (Internet Service, NAT Service) ou établir des peerings vers d’autres Nets.
Caractéristiques techniques d’un Net
Section intitulée « Caractéristiques techniques d’un Net »Bloc CIDR — la décision structurante
Section intitulée « Bloc CIDR — la décision structurante »Le CIDR du Net est défini à la création et ne peut plus être modifié ensuite. Trois contraintes à connaître :
-
Masque entre
/16(65 536 IPs) et/28(16 IPs). -
Blocs RFC 1918 uniquement — les plages réservées au privé :
Bloc Plage Capacité maximum 10.0.0.0/810.0.0.0 → 10.255.255.255 16 777 216 IPs 172.16.0.0/12172.16.0.0 → 172.31.255.255 1 048 576 IPs 192.168.0.0/16192.168.0.0 → 192.168.255.255 65 536 IPs -
Pas de chevauchement possible avec les Nets déjà existants si vous comptez établir un peering, et pas avec les réseaux de votre datacenter on-premise si vous prévoyez un VPN ou un DirectLink.
Ressources créées automatiquement avec le Net
Section intitulée « Ressources créées automatiquement avec le Net »À la création d’un Net, OUTSCALE provisionne automatiquement deux ressources :
- Une route table principale (main route table), associée par défaut à tout Subnet créé dans le Net.
- Un security group par défaut, qui n’autorise par défaut qu’un certain trafic interne (à examiner pour vos besoins — détails dans Security Groups et ACL).
Ces ressources servent de base que vous pouvez compléter ou remplacer par vos propres définitions selon vos besoins.
Résolution DNS interne
Section intitulée « Résolution DNS interne »Les VMs créées dans un Net bénéficient d’une résolution DNS interne : elles peuvent se résoudre entre elles via un nom de domaine OUTSCALE préconfiguré, sans avoir à mettre en place un DNS applicatif. Ce point est utile pour la phase initiale d’un projet ; pour des besoins avancés (DNS interne nommé, Service Discovery), une solution dédiée se déploie en plus.
Caractéristiques techniques d’un Subnet
Section intitulée « Caractéristiques techniques d’un Subnet »Hiérarchie CIDR
Section intitulée « Hiérarchie CIDR »Le bloc CIDR de chaque Subnet est un sous-bloc du CIDR du Net. Par exemple, pour un Net en 10.0.0.0/16, vous pouvez créer des Subnets en 10.0.1.0/24, 10.0.2.0/24, 10.0.3.0/24, etc. Les Subnets ne peuvent pas se chevaucher entre eux.
Capacité réelle d’un Subnet
Section intitulée « Capacité réelle d’un Subnet »OUTSCALE réserve 5 adresses IP par Subnet :
- Les 4 premières : adresse réseau, routeur du Net, serveur DNS, et une adresse réservée pour usage futur.
- La dernière : adresse de broadcast.
Donc un Subnet en /24 (256 IPs théoriques) offre 251 IPs utilisables pour vos ressources. Un Subnet en /29 (8 IPs théoriques) offre seulement 3 IPs utilisables — taille minimale autorisée mais peu pratique.
Rattachement à une sous-région
Section intitulée « Rattachement à une sous-région »Un Subnet est rattaché à une sous-région précise au moment de sa création (par exemple, eu-west-2a). Les VMs créées dans ce Subnet vivent physiquement dans cette sous-région — c’est la mécanique qui rend la haute disponibilité multi-AZ possible.
Pour répartir les ressources sur plusieurs sous-régions, créer un Subnet par sous-région dans le même Net.
Pattern public / privé / data — le découpage canonique
Section intitulée « Pattern public / privé / data — le découpage canonique »Le pattern le plus répandu sépare les ressources en trois tiers logiques, chacun dans son propre Subnet (et idéalement, dupliqué sur plusieurs sous-régions pour la résilience).
| Tier | Rôle | Accès Internet | Exemples de ressources |
|---|---|---|---|
| public | Frontaux exposés | Entrée + sortie via Internet Service | Load Balancers, bastions, frontaux web |
| privé | Couche applicative | Sortie uniquement via NAT Service | API backend, applications métier, runners CI/CD |
| data | Bases de données et stockage critique | Aucun (interne au Net) | PostgreSQL, MongoDB, Redis, fichiers chiffrés |
Pourquoi cette séparation
Section intitulée « Pourquoi cette séparation »- Limite l’exposition — seuls les frontaux du tier public sont joignables depuis Internet ; les bases de données du tier data ne sont jamais directement exposées.
- Clarifie les flux — chaque tier a sa route table explicite (vers Internet Service pour public, vers NAT Service pour privé, sans route Internet pour data).
- Facilite l’audit — il devient trivial de vérifier qu’aucune base de données n’est exposée par accident.
- Aligne sur les exigences réglementaires — beaucoup de référentiels (HDS, SecNumCloud, PCI-DSS) demandent cette séparation explicite.
Multi-AZ appliqué aux trois tiers
Section intitulée « Multi-AZ appliqué aux trois tiers »Pour la résilience, dupliquer chaque tier sur au moins deux sous-régions :
| Subnet | Sous-région | CIDR exemple | Tier |
|---|---|---|---|
subnet-public-a | eu-west-2a | 10.0.10.0/24 | public |
subnet-public-b | eu-west-2b | 10.0.11.0/24 | public |
subnet-private-a | eu-west-2a | 10.0.20.0/24 | privé |
subnet-private-b | eu-west-2b | 10.0.21.0/24 | privé |
subnet-data-a | eu-west-2a | 10.0.30.0/24 | data |
subnet-data-b | eu-west-2b | 10.0.31.0/24 | data |
La convention de nommage (suffixe -a / -b) facilite l’identification visuelle et l’automation.
Plan d’adressage CIDR — exemple détaillé
Section intitulée « Plan d’adressage CIDR — exemple détaillé »Voici un plan complet pour un Net en 10.0.0.0/16 (65 536 IPs disponibles), avec une réserve large pour la croissance.
10.0.0.0/16 — Net├── 10.0.0.0/20 — RÉSERVÉ (futurs Subnets, services managés OUTSCALE, peering)├── 10.0.16.0/20 — Tier public (16 sous-régions × /24)│ ├── 10.0.16.0/24 — subnet-public-a (eu-west-2a)│ ├── 10.0.17.0/24 — subnet-public-b (eu-west-2b)│ └── 10.0.18.0/24 — subnet-public-c (eu-west-2c)├── 10.0.32.0/20 — Tier privé (16 sous-régions × /24)│ ├── 10.0.32.0/24 — subnet-private-a (eu-west-2a)│ ├── 10.0.33.0/24 — subnet-private-b (eu-west-2b)│ └── 10.0.34.0/24 — subnet-private-c (eu-west-2c)├── 10.0.48.0/20 — Tier data (16 sous-régions × /24)│ ├── 10.0.48.0/24 — subnet-data-a (eu-west-2a)│ ├── 10.0.49.0/24 — subnet-data-b (eu-west-2b)│ └── 10.0.50.0/24 — subnet-data-c (eu-west-2c)└── 10.0.64.0/18 — RÉSERVÉ pour expansion futureCe découpage offre :
- 3 tiers clairement séparés.
- Multi-AZ opérationnel avec les 3 sous-régions de la région.
- 251 IPs utilisables par Subnet (suffisant pour la majorité des projets).
- Réserves d’adressage pour la croissance (nouveaux Subnets, services OUTSCALE qui consomment des IPs, intégration future avec d’autres Nets).
Anticiper les peerings et les VPNs
Section intitulée « Anticiper les peerings et les VPNs »Si vous prévoyez de faire du peering entre plusieurs Nets (par exemple un Net prod et un Net services-mutualisés), assurez-vous que leurs CIDR ne se chevauchent pas. Une convention courante :
| Compte / projet | Bloc CIDR |
|---|---|
prod | 10.0.0.0/16 |
staging | 10.1.0.0/16 |
dev | 10.2.0.0/16 |
services-mutualisés | 10.10.0.0/16 |
| (réservé futur) | 10.20.0.0/16+ |
De même, si vous prévoyez un VPN site-à-site ou un DirectLink vers un datacenter on-premise, le CIDR du Net ne doit pas chevaucher le réseau du datacenter. Coordonner ce point avec les équipes réseau internes avant de provisionner.
Créer un Net et ses Subnets via oapi-cli
Section intitulée « Créer un Net et ses Subnets via oapi-cli »L’approche CLI-first rend la création reproductible et versionnable. Voici un enchaînement minimal.
Créer le Net
Section intitulée « Créer le Net »CreateNet n’accepte que le bloc CIDR à la création. Les tags se posent séparément via CreateTags.
# 1. Créer le Netoapi-cli CreateNet --IpRange "10.0.0.0/16"# La réponse contient le NetId (par exemple "vpc-12345678")
# 2. Ajouter les tags séparémentoapi-cli CreateTags \ --ResourceIds '["vpc-12345678"]' \ --Tags '[ {"Key": "Name", "Value": "net-prod"}, {"Key": "env", "Value": "prod"}, {"Key": "project", "Value": "monprojet"} ]'Créer un Subnet par tier et par sous-région
Section intitulée « Créer un Subnet par tier et par sous-région »Même logique : créer le Subnet, puis le tagger.
# 1. Subnet public en eu-west-2aoapi-cli CreateSubnet \ --NetId "vpc-12345678" \ --SubregionName "eu-west-2a" \ --IpRange "10.0.16.0/24"# La réponse contient le SubnetId (par exemple "subnet-aaaa1111")
# 2. Tagger le Subnetoapi-cli CreateTags \ --ResourceIds '["subnet-aaaa1111"]' \ --Tags '[ {"Key": "Name", "Value": "subnet-public-a"}, {"Key": "tier", "Value": "public"} ]'
# Répéter la même séquence pour subnet-private-a, subnet-data-a,# puis pour eu-west-2b et eu-west-2c.L’enchaînement « créer puis tagger » est répétitif en CLI — c’est l’une des raisons de basculer en Terraform (Volet 3) où les tags sont appliqués déclarativement dans le même bloc que la création.
Vérifier la configuration
Section intitulée « Vérifier la configuration »# Lister les Netsoapi-cli ReadNets | jq '.Nets[] | {NetId, IpRange, State, Tags}'
# Lister les Subnets d'un Netoapi-cli ReadSubnets \ --Filters '{"NetIds": ["vpc-12345678"]}' \ | jq '.Subnets[] | {SubnetId, IpRange, SubregionName, Tags}'Bonnes pratiques (par pilier Well-Architected)
Section intitulée « Bonnes pratiques (par pilier Well-Architected) »1. CIDR /16 au minimum, RFC 1918, sans chevauchement — pilier Reliability
Section intitulée « 1. CIDR /16 au minimum, RFC 1918, sans chevauchement — pilier Reliability »Choisir un /16 (65 536 IPs) par défaut, même pour un petit projet. La réserve d’adressage évite de devoir recréer un Net si le projet grandit. Vérifier que le CIDR ne chevauche pas les Nets existants ni les réseaux on-premise — un peering ou VPN futur exigera cette propriété.
2. Trois tiers public / privé / data — pilier Security
Section intitulée « 2. Trois tiers public / privé / data — pilier Security »Séparer systématiquement les ressources en trois tiers logiques, chacun dans son propre Subnet. Cette discipline réduit drastiquement la surface d’attaque : aucune base de données n’est exposée à Internet par accident.
3. Multi-AZ dès la conception — pilier Reliability
Section intitulée « 3. Multi-AZ dès la conception — pilier Reliability »Au moins deux sous-régions par tier (idéalement trois si la région les expose), pour pouvoir résister à la perte d’un datacenter physique. La latence inter-AZ < 2 ms permet la réplication synchrone et le load balancing cross-AZ sans pénalité notable. Détails dans Régions et sous-régions OUTSCALE.
4. Convention de nommage et tagging — pilier Operational Excellence
Section intitulée « 4. Convention de nommage et tagging — pilier Operational Excellence »Nommer les ressources de manière prédictible (subnet-public-a, subnet-private-b, etc.) et appliquer les tags structurants (env, project, tier, cost-center) dès la création. Cela facilite le diagnostic, l’audit et le reporting FinOps.
5. Réserver de l’adressage pour la croissance — piliers Reliability + Performance
Section intitulée « 5. Réserver de l’adressage pour la croissance — piliers Reliability + Performance »Découper en /20 par tier (16 Subnets potentiels) plutôt qu’en /24, et garder des plages réservées dans le Net pour les futurs Subnets, services managés OUTSCALE et peerings. C’est plus simple d’avoir trop d’adresses que pas assez — recréer un Net coûte cher en migration.
6. Documenter le plan d’adressage — pilier Operational Excellence
Section intitulée « 6. Documenter le plan d’adressage — pilier Operational Excellence »Tenir un document interne (wiki, README dans un dépôt Git) qui liste tous les Nets, leurs CIDR, les peerings actifs et prévus, les liens VPN / DirectLink. Ce document est la source de vérité lors d’un nouveau peering ou d’un audit réseau.
Antipatterns à éviter
Section intitulée « Antipatterns à éviter »| Antipattern | Conséquence | Discipline correcte |
|---|---|---|
CIDR trop petit (/24 pour le Net) | Pas d’extension possible, recréation du Net obligatoire | /16 par défaut, /20 minimum |
| Subnets sans séparation de tiers | Bases de données exposées par mégarde, surface d’attaque inutile | 3 tiers public / privé / data systématiques |
| Un seul Subnet pour tout le Net | Pas de multi-AZ, perte d’une AZ = perte totale | Subnets répartis sur plusieurs sous-régions |
| CIDR qui chevauche un autre réseau | Peering impossible, VPN cassé, refonte complète à faire | Planifier le plan d’adressage global avant le premier Net |
| Pas de réserve d’adressage | Croissance bloquée, recréation forcée | Découper en /20 par tier, garder des plages libres |
Net + Subnets sous l’angle Well-Architected
Section intitulée « Net + Subnets sous l’angle Well-Architected »Reliability — multi-AZ et résilience
Section intitulée « Reliability — multi-AZ et résilience »La mécanique multi-AZ est ce qui rend une infrastructure OUTSCALE résistante à la perte d’un datacenter. Un Net avec au moins deux Subnets sur deux sous-régions différentes est la fondation de toute architecture haute disponibilité — load balancers cross-AZ, bases de données répliquées synchrones, applications stateless distribuées. Sans cette répartition, la plupart des patterns de résilience (multi-AZ, EIP flottante, chaos engineering) sont impossibles à mettre en place.
Security — isolation par tier
Section intitulée « Security — isolation par tier »La séparation public / privé / data matérialise dans le réseau les frontières de sécurité logiques. Un Security Group attaché à une ressource du tier data peut interdire toute communication entrante depuis Internet par construction — la défense en profondeur démarre au niveau réseau. C’est aussi cette séparation qui permet d’auditer rapidement la posture (« y a-t-il une ressource data accessible depuis le tier public ? »).
Performance — latence inter-AZ et plan d’adressage
Section intitulée « Performance — latence inter-AZ et plan d’adressage »La latence inter-AZ (< 2 ms) permet la réplication synchrone et le load balancing cross-AZ sans dégradation perceptible. Un plan d’adressage CIDR bien dimensionné évite la fragmentation et la nécessité de découpages supplémentaires qui complexifient les routes et les Security Groups.
Operational Excellence — convention et documentation
Section intitulée « Operational Excellence — convention et documentation »Une convention de nommage uniforme (subnet-<tier>-<az>), un tagging discipliné, une documentation du plan d’adressage : ces trois éléments transforment la gestion réseau d’une activité ad hoc en opération routinière. Ils facilitent aussi le diagnostic en cas d’incident — savoir immédiatement de quel tier provient une ressource sans avoir à investiguer.
À retenir
Section intitulée « À retenir »- Un Net est un réseau privé virtuel isolé dans une région OUTSCALE — équivalent VPC.
- Le CIDR du Net se choisit à la création (
/16à/28, RFC 1918) et ne peut plus être modifié. Un/16par défaut donne de la marge. - À la création, OUTSCALE provisionne automatiquement une route table principale et un security group par défaut.
- Un Subnet est un sous-bloc CIDR rattaché à une sous-région précise ; 5 IPs sont réservées par OUTSCALE (4 premières + dernière).
- Le pattern public / privé / data, dupliqué sur plusieurs sous-régions, est la base d’une architecture sécurisée et résiliente.
- Anticiper le peering et les VPNs en évitant les chevauchements de CIDR avec les autres Nets et les réseaux on-premise.
- La création se fait en
oapi-clipour l’exploration, en Terraform pour le déploiement reproductible.