Le Volet 2 est le bloc structurant du parcours 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-07-23
Section intitulée « Pages du volet, état au 2026-07-23 »Le Volet 2 cible 11 pages au total ; 10 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 »Ces deux pages se lisent dans l'ordre : la première pose les objets EIM manipulables dans un seul compte, la seconde change d'échelle et raisonne en parc de comptes. Tant que vous travaillez sur un compte unique, la page multi-comptes reste théorique ; elle devient indispensable dès qu'un environnement de production doit être isolé d'un environnement de test.
-
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 »Le plan d'adressage se décide une fois et se corrige mal : un CIDR trop étroit ou qui chevauche celui d'un futur partenaire de peering impose de reconstruire le Net. Commencez donc par la page design, puis ajoutez le filtrage avec les Security Groups, et terminez par les passerelles (Internet Service, NAT, EIP) qui décident de ce qui sort et de ce qui entre.
-
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 »Ces quatre pages traitent la même question sous deux angles : ce que vous payez et ce que vous mesurez. Le sur-dimensionnement est la dérive la plus fréquente, côté vCores comme côté IOPS, parce qu'aucune alarme ne se déclenche quand une ressource est trop grande. Si vous ne lisez qu'une page ici, prenez celle sur les instances TINA : le format tinavW.cXrYpZ permet d'ajuster CPU et RAM indépendamment, ce que les gabarits AWS-style ne savent pas faire.
-
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 »Une seule page, mais celle qui décide de la survie du système d'information après un incident. Elle est volontairement placée après les pages stockage, parce qu'un plan de reprise se construit avec les briques réelles : snapshots BSU pour le point de reprise court, exports OOS pour la copie hors-site. Le point à ne pas survoler est le test de restauration : une sauvegarde jamais restaurée n'est qu'une hypothèse.
- 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 »Il reste un sujet non couvert, signalé ici pour que vous sachiez où chercher en attendant. Tant que la page n'existe pas, la traçabilité des appels API se consulte directement depuis OMS dans le Cockpit, et la supervision applicative se traite avec les guides génériques de la section observabilité du site.
- 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 du parcours entier. Deux lignes méritent une attention particulière : le Security Group est stateful, ce qui veut dire qu'autoriser un flux entrant autorise implicitement la réponse sortante, et le Snapshot BSU est incrémental, donc son coût de stockage ne se calcule pas en multipliant la taille du volume par le nombre de snapshots. Les autres entrées servent surtout de table de correspondance quand vous arrivez du vocabulaire AWS.
| 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 plus manipulations de base sur un compte de pratique. Le tableau couvre les neuf chapitres du socle ; la page fGPU, plus spécialisée, n'y figure pas et s'ajoute au budget si votre usage le justifie.
| 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 des neuf chapitres | ~3 h 20 | ~6 h 00 |
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 | Les dix 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 »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.- 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 du parcours, 10 pages publiées sur 11 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 du parcours.
Pour aller plus loin
Section intitulée « Pour aller plus loin »- Réseau, design Net et Subnets : Le second sujet structurant du volet, concevoir un plan d'adressage multi-AZ qui tienne dans la durée.
- Sauvegardes, RPO, RTO et PRA : La discipline qui transforme un environnement fonctionnel en environnement défendable.
- Volet 5, le Well-Architected appliqué : La grille de revue par pilier qui met à l'épreuve les fondations posées dans ce volet.