Le Volet 2 est le bloc structurant de la formation OUTSCALE. Il couvre toutes les fondations transverses d’une infrastructure cloud : identité et accès (EIM), réseau (Net, Subnets, Security Groups, IGW, NAT), calcul (instances TINA, sizing), stockage (BSU, OOS, snapshots), sauvegardes (RPO/RTO, plan de reprise). Ces fondations sont mobilisées en lecture transverse depuis le Volet 5 Well-Architected — chaque page est tagguée par les piliers WAF qu’elle adresse pour faciliter cette articulation. Comptez 8 à 10 heures cumulées de lecture et manipulation pour parcourir l’ensemble.
Ce que vous allez apprendre
Section intitulée « Ce que vous allez apprendre »- Structurer EIM avec moindre privilège, MFA, federation SSO, et architecture multi-comptes pour l’isolation des environnements.
- Concevoir un Net multi-AZ avec un plan d’adressage CIDR maîtrisé et trois tiers logiques (public, privé, data).
- Filtrer les flux réseau via des Security Groups stateful et le pattern SG-to-SG.
- Connecter le Net à Internet proprement (IGW, NAT, EIP) et organiser les accès humains via un bastion.
- Choisir les bons types d’instances TINA et dimensionner les volumes BSU avec la bonne classe de stockage.
- Articuler snapshots BSU et exports OOS au sein d’une stratégie 3-2-1 testée trimestriellement.
Pré-requis
Section intitulée « Pré-requis »- Avoir terminé le Volet 1 — Découvrir OUTSCALE (ou au moins lu le Vocabulaire OUTSCALE ↔ AWS).
- Bases du réseau IP (CIDR, subnets, routes), du stockage (block / objet) et de l’identité cloud (IAM-like).
- Un compte OUTSCALE actif avec permissions admin pour pratiquer.
oapi-cliconfiguré sur votre poste (cf. Outils CLI OUTSCALE) — toutes les manipulations passent par la CLI.
Pourquoi ce volet est central
Section intitulée « Pourquoi ce volet est central »OUTSCALE est mature côté primitives techniques, mais l’architecture par défaut est minimaliste. Sans discipline structurante sur les fondations, on se retrouve avec :
- Des comptes EIM mal segmentés où une fuite d’AK/SK donne accès à tout.
- Un Net unique avec tous les services dans le même Subnet, sans tier de sécurité.
- Des Security Groups ouverts sur
0.0.0.0/0parce que « ça marche comme ça ». - Des VMs sur-dimensionnées par sécurité, avec une facture multipliée par 2 ou 3.
- Des sauvegardes non testées dont on découvre l’inefficacité le jour d’un incident.
Ce volet pose la discipline qui transforme une infrastructure approximative en infrastructure défendable, performante et maîtrisée en coût. Chaque page propose des bonnes pratiques tagguées par pilier Well-Architected, des antipatterns à éviter et des exemples oapi-cli validés contre la spécification OpenAPI officielle.
Pages du volet — état au 2026-04-28
Section intitulée « Pages du volet — état au 2026-04-28 »Le Volet 2 cible 10 pages au total ; 9 sont publiées à ce stade, la dernière (Observabilité) se complète au fil des semaines.
Identité et accès — 2 pages
Section intitulée « Identité et accès — 2 pages »-
EIM — identité et accès — root user, EIM users, groups, policies (managed et inline), MFA, API Access Rules. Pilier Security principalement, avec contributions à Operational Excellence et Sovereignty.
-
EIM — patterns multi-comptes / projets — paying account et linked accounts, patterns de séparation par environnement / projet / équipe, compte audit transversal, tagging unifié. Piliers Security, Operational Excellence, Cost.
Réseau — 3 pages
Section intitulée « Réseau — 3 pages »-
Réseau — design Net + Subnets — choix du CIDR (RFC 1918, /16 par défaut), découpage public / privé / data, multi-AZ, allocation des sous-régions par compte. Piliers Reliability, Security, Performance.
-
Réseau — Security Groups — pare-feu virtuel stateful, règles inbound et outbound, pattern SG-to-SG, antipatterns (SSH ouvert sur
0.0.0.0/0). Pilier Security. -
Réseau — IGW, NAT, EIP, bastion — Internet Service, NAT Service par sous-région, EIP transférables, pattern bastion pour les accès humains, route tables par tier. Piliers Security, Reliability.
Calcul et stockage — 4 pages
Section intitulée « Calcul et stockage — 4 pages »-
Calcul — instances TINA et sizing — format
tinavW.cXrYpZ, choix de la génération CPU et du flag de performance, méthode de sizing (démarrer petit, mesurer, ajuster), familles par profil de charge. Piliers Performance, Cost. -
fGPU — GPU NVIDIA à la demande — allocation et attachement dynamique de Flexible GPU (NVIDIA A100, V100, P100, P6, K2) à des VMs pour les charges IA et calcul intensif. Piliers Performance, Cost.
-
Stockage — BSU, volumes, IOPS — types de volumes (
standard,gp2,io1), calcul des IOPS, snapshots BSU, attachement aux VMs, séparation root / data. Piliers Reliability, Performance, Cost. -
Stockage — OOS, versioning, lifecycle — stockage objet S3-compatible, buckets et objets, versioning, lifecycle automatisé, object lock pour l’immutabilité, limites documentées. Piliers Reliability, Cost, Security.
Continuité — 1 page
Section intitulée « Continuité — 1 page »- Sauvegardes — RPO/RTO/PRA — définir RPO et RTO avec le métier, règle 3-2-1 sur OUTSCALE, articulation snapshots BSU + exports OOS, test de restauration trimestriel, runbook PRA. Piliers Reliability, Operational Excellence.
À venir dans ce volet
Section intitulée « À venir dans ce volet »- Observabilité — OMS et monitoring applicatif — traçage des appels API via OMS (équivalent CloudTrail), métriques applicatives via Prometheus / Grafana ou OTel collector, gestion des logs et de la rétention. Page en construction.
Concepts clés que vous allez croiser
Section intitulée « Concepts clés que vous allez croiser »Ces concepts reviennent dans toutes les pages du volet et de la formation entière.
| Concept | Définition courte |
|---|---|
| EIM | Service d’identité et accès OUTSCALE, compatible IAM |
| Root user | Identité par défaut, permissions illimitées — à protéger, pas à utiliser |
| AK/SK | Access Key + Secret Key pour l’authentification API |
| Net | Réseau privé virtuel (équivalent VPC) |
| Subnet | Sous-réseau attaché à une sous-région précise |
| Security Group | Pare-feu virtuel stateful (une règle suffit pour les deux sens) |
| Internet Service | Passerelle Internet bidirectionnelle (équivalent IGW) |
| NAT Service | Passerelle de sortie pour le tier privé |
| EIP / Public IP | IP publique transférable entre ressources |
| VmType | Format tinavW.cXrYpZ — génération CPU, vCores, RAM, performance flag |
| BSU | Stockage bloc, types standard / gp2 / io1 |
| OOS | Stockage objet S3-compatible |
| Snapshot | Image d’un volume à un instant T, incrémental |
| Object lock | Immutabilité d’un objet OOS pendant une durée |
| RPO | Recovery Point Objective — données maximum perdues acceptable |
| RTO | Recovery Time Objective — temps maximum d’indisponibilité acceptable |
| 3-2-1 | Règle de sauvegarde : 3 copies, 2 supports, 1 hors-site |
Combien de temps prévoir
Section intitulée « Combien de temps prévoir »Ventilation indicative par chapitre, lecture + manipulations de base sur un compte de pratique :
| Chapitre | Lecture seule | Avec manipulation |
|---|---|---|
| EIM identité et accès | ~25 min | ~45 min |
| EIM patterns multi-comptes | ~20 min | ~30 min |
| Réseau — Net + Subnets | ~25 min | ~45 min |
| Réseau — Security Groups | ~20 min | ~35 min |
| Réseau — IGW, NAT, EIP, bastion | ~25 min | ~50 min |
| Calcul — instances TINA | ~20 min | ~40 min |
| Stockage — BSU | ~20 min | ~35 min |
| Stockage — OOS | ~20 min | ~35 min |
| Sauvegardes — RPO/RTO/PRA | ~25 min | ~45 min |
| Total publié | ~3 h 20 | ~5 h 40 |
L’effort total incluant un lab d’application sur un projet réel se rapproche de 8 à 10 heures.
Profils concernés
Section intitulée « Profils concernés »Le Volet 2 est structurant pour plusieurs profils, avec des priorités différentes selon le rôle.
| Profil | Pages prioritaires | Pourquoi |
|---|---|---|
| Sysadmin / Opérateur | Toutes les 9 pages | Le quotidien opérationnel passe par toutes les fondations |
| Architecte cloud | EIM patterns multi-comptes, Net + Subnets, IGW NAT bastion, Sauvegardes | Les choix structurants pour la conception |
| Développeur backend | Net + Subnets, Security Groups, BSU, OOS | Comprendre où vit son code et comment il communique |
| RSSI / Sécurité | EIM (2 pages), Security Groups, OOS, Sauvegardes | Le périmètre Security du Volet 2 |
| FinOps | EIM multi-comptes, TINA / sizing, BSU, OOS, Sauvegardes | Les leviers de coût principaux |
Pour le détail global du parcours, consultez Choisir son parcours selon votre profil.
Discipline transverse — la philosophie du volet
Section intitulée « Discipline transverse — la philosophie du volet »Trois disciplines reviennent en filigrane dans toutes les pages du Volet 2.
CLI-first pour les manipulations
Section intitulée « CLI-first pour les manipulations »Toutes les manipulations passent par oapi-cli (recommandé) ou aws-cli sur les API compatibles AWS (FCU, LBU, EIM, OOS). Justifications :
- Reproductibilité — une commande peut être rejouée à l’identique.
- Scriptabilité — intégration facile dans pipelines CI/CD et runbooks.
- Versionnable en Git — historique tracé, review possible.
- Pas à pas vers l’IaC — passer de la CLI à Terraform (Volet 3) est un pas naturel.
Format TINA natif uniquement
Section intitulée « Format TINA natif uniquement »Pour les types d’instances, toujours utiliser le format tinavW.cXrYpZ plutôt que les noms AWS-style (t2.small, m5.large). Le format TINA est plus précis, plus lisible et exploite la flexibilité native d’OUTSCALE.
Tagging discipliné dès la création
Section intitulée « Tagging discipliné dès la création »Chaque ressource (Net, Subnet, VM, volume, snapshot, bucket, security group) doit porter dès sa création les tags structurants :
env(prod,staging,dev)project(nom du projet)owner(équipe responsable)cost-center(imputation FinOps)tierquand pertinent (public,private,data)
Sans tagging, pas de FinOps par projet, pas d’audit par responsable, pas de cleanup automatisé.
Questions fréquentes
Section intitulée « Questions fréquentes »Pourquoi tout faire en CLI plutôt qu’au Cockpit ?
Section intitulée « Pourquoi tout faire en CLI plutôt qu’au Cockpit ? »La CLI offre reproductibilité, scriptabilité et versionning Git que le Cockpit ne permet pas. Pour les opérations courantes en équipe, ces propriétés sont structurantes. Le Cockpit reste utile pour explorer et diagnostiquer (cf. page Cockpit du Volet 1).
Faut-il déployer en Terraform dès le début ?
Section intitulée « Faut-il déployer en Terraform dès le début ? »Pas obligatoirement au stade de l’apprentissage : la CLI suffit pour comprendre les concepts. Mais dès qu’on entre dans une équipe ou un projet en production, Terraform devient essentiel — sujet du Volet 3 — Industrialiser (IaC). La CLI sert alors à diagnostiquer et à scripter des opérations ponctuelles.
Quelle est la différence entre BSU et OOS ?
Section intitulée « Quelle est la différence entre BSU et OOS ? »BSU = stockage bloc (disque virtuel attaché à une VM), pour le système, les bases de données, les fichiers applicatifs chauds. OOS = stockage objet (S3-compatible, accès HTTP), pour les sauvegardes, archives, exports, médias. Les deux sont complémentaires, pas concurrents — détails dans BSU et OOS.
Comment savoir si je dois utiliser gp2 ou io1 ?
Section intitulée « Comment savoir si je dois utiliser gp2 ou io1 ? »gp2 est le bon défaut moderne pour la majorité des charges. io1 se justifie quand vous avez mesuré un besoin d’IOPS qui dépasse gp2, ou que la latence p99 doit rester stable sous charge variable. Détails et calcul des IOPS dans Stockage BSU.
Comment décider du RPO et du RTO d’une application ?
Section intitulée « Comment décider du RPO et du RTO d’une application ? »C’est une décision métier, pas technique. Le métier répond aux questions « combien de données peut-on perdre dans le pire cas ? » et « combien de temps sans service est acceptable ? ». La technique en déduit la stratégie de sauvegarde et le coût associé. Méthodologie complète dans Sauvegardes — RPO/RTO/PRA.
Pourquoi toujours dans un Net (pas en Public Cloud) ?
Section intitulée « Pourquoi toujours dans un Net (pas en Public Cloud) ? »Le mode Public Cloud (sans Net) limite drastiquement la posture Well-Architected — pas d’outbound filtering, pas de séparation par tiers, pas de plan d’adressage maîtrisé, pas de peering propre, pas de multi-AZ explicite. Le détail dans l’Aside dédié de Réseau — design Net + Subnets.
Le Volet 2 prépare à quoi dans la suite ?
Section intitulée « Le Volet 2 prépare à quoi dans la suite ? »Les fondations du Volet 2 sont mobilisées partout dans la formation :
- Volet 3 (IaC) — industrialise tout ce que le Volet 2 décrit conceptuellement.
- Volet 4 (services managés) — déploie OKS, LBU et fGPU sur les fondations posées.
- Volet 5 (Well-Architected) — agrège les pages du Volet 2 par pilier WAF.
- Volet 6 (Capstone) — applique l’ensemble dans un projet 3-tiers complet.
À retenir
Section intitulée « À retenir »- Le Volet 2 est le bloc structurant de la formation — 9 pages publiées sur 10 prévues, 8-10 heures d’effort cumulé.
- Il couvre identité et accès, réseau, calcul, stockage, sauvegardes — les fondations transverses de toute infrastructure OUTSCALE.
- Chaque page est tagguée par pilier Well-Architected pour faciliter la lecture transverse depuis le Volet 5.
- Trois disciplines transverses : CLI-first, format TINA natif pour les VmType, tagging discipliné dès la création.
- Le Volet 2 prépare directement le Volet 3 (IaC) et le Volet 6 (Capstone) — l’apprentissage opérationnel central de la formation.