OOS OUTSCALE : stockage objet S3-compatible, versioning et lifecycle

Formation en cours de construction

Cette formation OUTSCALE est en cours de production. Plusieurs volets sont en construction (signalés « Bientôt » dans la sidebar) et se complètent progressivement. Les pages publiées sont stables et utilisables ; les vues d’ensemble en stub annoncent ce qui est à venir.

OOS (OUTSCALE Object Storage) est le stockage objet d’OUTSCALE — équivalent S3 chez AWS — utilisé pour les archives, sauvegardes, exports, médias statiques, ou comme cible d’export des snapshots BSU. Il est compatible avec l’API S3, ce qui permet d’utiliser aws-cli et tous les outils S3 existants en pointant simplement sur l’endpoint OOS. Cette page détaille les concepts (bucket, objet, versioning, lifecycle), les limites documentées et les bonnes pratiques Well-Architected. Page tagguée pour les piliers Reliability, Cost et Security.

Ce que vous allez apprendre

• Distinguer OOS et BSU — quand utiliser le stockage objet plutôt que le bloc.
• Créer un bucket OOS via aws-cli avec l’endpoint OUTSCALE.
• Activer le versioning pour conserver l’historique des objets.
• Configurer un lifecycle pour automatiser la rétention et la suppression.
• Connaître les limites documentées (5 TB par objet, 100 buckets par compte, débits).
• Appliquer les patterns de sécurité : chiffrement, ACL, blocage public.

Prérequis

• Avoir lu Stockage — BSU — utile pour comprendre la complémentarité bloc / objet.
• Connaître les notions S3 (bucket, objet, ACL) ou les fondamentaux du stockage cloud — sinon, voir Fondamentaux du cloud.
• aws-cli installé et configuré (cf. Outils CLI OUTSCALE) — OOS s’utilise via le client S3 standard.

OOS en deux phrases

OOS est un service de stockage objet — vous y stockez des objets (fichiers, blobs) regroupés dans des buckets (conteneurs nommés globalement). Contrairement au stockage bloc (BSU), un objet OOS n’est pas attaché à une VM : il est accessible via une API HTTP (S3-compatible) depuis n’importe où — VM, poste local, navigateur, application tierce.

Côté technique, OOS est basé sur la solution RING de Scality et expose une API compatible S3 (méthodes documentées dans la référence officielle). Vous utilisez aws-cli, boto3, le SDK AWS, ou n’importe quel client S3 en pointant simplement sur l’endpoint OOS de votre région.

OOS vs BSU — quand choisir lequel

Les deux services répondent à des besoins différents.

Critère	BSU (stockage bloc)	OOS (stockage objet)
Modèle d’accès	Disque attaché à une VM, vu comme système de fichiers	API HTTP S3-compatible, accès distant universel
Mutation	Lecture / écriture par bloc, modifications en place	Immutabilité par objet — pas de modification partielle
Latence	Quelques ms (SSD gp2/io1)	Plus élevée — non adapté à des appels intensifs en lecture/écriture
Capacité par unité	Jusqu’à 14 901 GiB par volume	Jusqu’à 5 TB par objet
Intégration applicative	Système de fichiers natif (POSIX)	API HTTP — l’application doit être conçue pour OOS
Cas d’usage typique	Système, base de données, fichiers applicatifs	Sauvegardes, archives, médias, exports, logs froids
Scalabilité	Volume unique limité, multiplier les volumes pour grossir	Scale horizontal par défaut, pas de limite de bucket

Glissez pour voir

Règle pratique : utiliser BSU pour ce qui est attaché à une VM (système et données applicatives chaudes), utiliser OOS pour ce qui est consulté ponctuellement, archivé ou partagé entre services.

Compatibilité S3 — utilisable avec aws-cli

OOS expose une API compatible avec S3 d’AWS. Tous les outils S3 standards fonctionnent en pointant sur l’endpoint OOS :

• aws-cli : commandes aws s3 et aws s3api directement utilisables.
• SDK AWS (boto3, AWS SDK for Go, etc.) : configuration de l’endpoint S3.
• Outils tiers S3 (rclone, s3cmd, MinIO Client, applications Backup-to-S3) : configuration similaire.

Endpoints OOS

Région	Endpoint OOS
eu-west-2 (commercial)	oos.eu-west-2.outscale.com
cloudgouv-eu-west-1 (SecNumCloud)	oos.cloudgouv-eu-west-1.outscale.com

Glissez pour voir

Exemple de configuration aws-cli

# Identifiants OUTSCALE (mêmes AK/SK que pour oapi-cli)
export AWS_ACCESS_KEY_ID="<votre AK>"
export AWS_SECRET_ACCESS_KEY="<votre SK>"
export AWS_DEFAULT_REGION="eu-west-2"

# Lister les buckets via OOS
aws s3 ls --endpoint-url https://oos.eu-west-2.outscale.com

Pour un usage régulier, créer un profil dédié dans ~/.aws/config qui pointe par défaut sur l’endpoint OOS.

Bucket — le conteneur

Un bucket est un conteneur global identifié par un nom. C’est l’unité de gestion principale d’OOS.

Caractéristiques

• Nom unique au sein d’OUTSCALE (le namespace est partagé entre tous les comptes — choisir un nom spécifique pour éviter les collisions).
• Région définie à la création, non modifiable.
• Configuration par bucket : versioning, lifecycle, ACL, tags, object lock.
• Politique d’accès unique par bucket (Only one ACL per bucket).

Limites documentées

• 100 buckets par compte (extensible jusqu’à 1 000 sur demande au support).
• 10 millions d’objets par bucket (incluant les delete markers).
• 300 GET/HEAD par seconde et par bucket.
• 200 PUT/COPY/POST/DELETE par seconde et par bucket.

Pour les charges qui dépassent ces seuils en débit, partitionner sur plusieurs buckets ou contacter le support pour une augmentation.

Bonnes pratiques de nommage

• Préfixer avec le projet ou l’environnement : monprojet-prod-backups, monprojet-staging-exports.
• Éviter les caractères spéciaux : préférer lettres minuscules, chiffres, et tirets.
• Documenter le rôle de chaque bucket dans un wiki interne ou un README de projet.

Objet — l’unité de stockage

Un objet est l’unité élémentaire stockée dans un bucket. Chaque objet est identifié par sa clé (chemin logique au sein du bucket, par exemple backups/db-prod/2026-04-28.sql.gz).

Caractéristiques

• Taille maximale : 5 TB par objet.
• Immutable : une mise à jour d’un objet remplace entièrement la version précédente (sauf si le versioning est activé, voir plus bas).
• Tags : jusqu’à 10 tags par objet, clé max 128 caractères, valeur max 256 caractères.
• Métadonnées HTTP stockées avec l’objet (Content-Type, Content-Encoding, etc.).
• ACL héritée de la politique du bucket par défaut, modifiable individuellement.

Multipart upload pour les gros objets

Pour les objets de plusieurs centaines de MB ou plus, utiliser le multipart upload (l’objet est découpé en parties uploadées en parallèle, puis assemblées). aws s3 cp le fait automatiquement au-delà d’un seuil. Avantage : reprise possible en cas d’échec de transfert d’une partie.

Important : compléter les uploads dans les 3 minutes (limite OOS documentée) pour éviter les timeouts. Pour les très gros transferts, ajuster la taille des parties dans la configuration aws-cli.

Versioning — conserver les versions

Le versioning d’un bucket conserve chaque version successive d’un objet plutôt que de les écraser. Indispensable pour :

• Récupérer un fichier supprimé ou écrasé par erreur.
• Auditer les modifications historiques.
• Protéger contre les ransomwares qui chiffrent / écrasent les fichiers.

Activer le versioning sur un bucket

aws s3api put-bucket-versioning \
  --bucket monprojet-prod-backups \
  --versioning-configuration Status=Enabled \
  --endpoint-url https://oos.eu-west-2.outscale.com

Une fois activé :

• Chaque PUT sur une clé existante crée une nouvelle version ; l’ancienne reste accessible.
• Une suppression crée un delete marker ; l’objet reste récupérable en spécifiant la version précédente.
• Le stockage facturé inclut toutes les versions — d’où l’importance d’un lifecycle pour limiter l’accumulation.

Lister les versions d’un objet

aws s3api list-object-versions \
  --bucket monprojet-prod-backups \
  --prefix "backups/db-prod/" \
  --endpoint-url https://oos.eu-west-2.outscale.com

Restaurer une version supprimée

# Identifier le VersionId à restaurer (via list-object-versions)
# Puis le copier vers la même clé pour qu'il devienne la version courante
aws s3api copy-object \
  --bucket monprojet-prod-backups \
  --copy-source "monprojet-prod-backups/backups/db-prod/2026-04-28.sql.gz?versionId=<VersionId>" \
  --key "backups/db-prod/2026-04-28.sql.gz" \
  --endpoint-url https://oos.eu-west-2.outscale.com

Lifecycle — automatiser la rétention

Une lifecycle policy définit des règles automatiques appliquées aux objets d’un bucket : suppression après X jours, transition vers une classe différente, expiration des versions anciennes.

Cas d’usage classiques

• Suppression des sauvegardes anciennes : conserver 90 jours, supprimer ensuite.
• Suppression des delete markers orphelins après 30 jours.
• Suppression des versions non courantes anciennes pour limiter le coût du versioning.
• Suppression des uploads multipart incomplets après 7 jours.

Exemple de lifecycle policy

{
  "Rules": [
    {
      "ID": "supprimer-backups-anciens",
      "Status": "Enabled",
      "Filter": {
        "Prefix": "backups/db-prod/"
      },
      "Expiration": {
        "Days": 90
      }
    },
    {
      "ID": "purger-versions-anciennes",
      "Status": "Enabled",
      "Filter": {
        "Prefix": ""
      },
      "NoncurrentVersionExpiration": {
        "NoncurrentDays": 30
      }
    }
  ]
}

Appliquer la policy

aws s3api put-bucket-lifecycle-configuration \
  --bucket monprojet-prod-backups \
  --lifecycle-configuration file://lifecycle.json \
  --endpoint-url https://oos.eu-west-2.outscale.com

Les règles sont évaluées quotidiennement par OOS — pas instantanément, mais avec une régularité fiable.

Object Lock — protection forte

L’object lock permet de marquer des objets comme non modifiables et non supprimables pendant une durée définie. Utile pour :

• Conformité réglementaire (rétention légale, RGPD, données comptables).
• Sauvegardes immuables — protection contre les ransomwares qui chiffrent même les sauvegardes.
• Logs d’audit — preuves d’audit qui ne peuvent pas être altérées.

L’object lock se configure au niveau bucket (à activer à la création), puis s’applique sur les objets individuels avec une durée ou une date d’expiration de la rétention.

Patterns de sécurité

Chiffrement at-rest

OOS chiffre les données at-rest par défaut (chiffrement de la plateforme). Pour aller plus loin avec une clé gérée côté client (SSE-C), c’est possible via les paramètres standard S3.

Chiffrement in-transit

Tout trafic vers les endpoints OOS passe par HTTPS / TLS — pas d’option en clair.

ACL et blocage public

Par défaut, les buckets OUTSCALE ne sont pas en accès public. Vérifier explicitement l’ACL de chaque bucket et éviter les politiques permissives. Toute exposition publique d’un bucket doit être explicitement justifiée et documentée.

Tagging et audit

• Tags structurants sur chaque bucket (env, project, owner, cost-center, compliance).
• Logs OMS activés sur le compte pour tracer toutes les opérations API (page « Observabilité OMS » à venir dans les fondations).

Bonnes pratiques (par pilier Well-Architected)

1. Versioning sur les buckets critiques — pilier Reliability

Tout bucket qui contient des données critiques (sauvegardes, archives, documents légaux) doit avoir le versioning activé. Sans versioning, une opération de suppression accidentelle ou une attaque de ransomware peut détruire les données de manière définitive.

2. Lifecycle systématique — pilier Cost

Sans lifecycle, le stockage s’accumule sans limite — versions anciennes, sauvegardes obsolètes, uploads multipart incomplets. Discipline minimale :

• Suppression des uploads multipart incomplets après 7 jours.
• Suppression des versions non courantes après 30-90 jours selon la criticité.
• Expiration des objets dans les buckets de logs / sauvegardes selon la politique de rétention.

3. Object Lock pour la sauvegarde immuable — pilier Reliability

Pour les sauvegardes de production critiques, activer object lock lors de la création du bucket. Cela protège contre :

• Les ransomwares qui chiffreraient les sauvegardes accessibles via les mêmes credentials.
• Les erreurs humaines qui supprimeraient accidentellement la sauvegarde.

4. Pas d’accès public par défaut — pilier Security

Un bucket OUTSCALE doit rester privé sauf cas explicitement justifié. Les fuites de données via des buckets S3 publics sont une cause majeure d’incidents publics chez d’autres fournisseurs — la même rigueur s’applique sur OOS.

5. Buckets séparés par environnement — pilier Operational Excellence

Pas de partage de bucket entre environnements (dev / staging / prod). Cela rend impossible la fuite croisée de données et clarifie les permissions EIM associées.

6. Audit régulier des buckets et leur taille — pilier Cost

Audit trimestriel : taille de chaque bucket, taux de croissance, présence du versioning et du lifecycle. Repérer les buckets qui accumulent sans rotation et les nettoyer.

7. Tagging discipliné — piliers OpEx + Cost

Comme pour les autres ressources, chaque bucket doit porter les tags structurants (env, project, owner, cost-center, compliance) dès la création.

Antipatterns à éviter

Antipattern	Conséquence	Discipline correcte
Bucket sans versioning sur des sauvegardes	Suppression accidentelle ou ransomware = données perdues	Versioning systématique sur les buckets critiques
Pas de lifecycle policy	Stockage qui s’accumule, coût qui explose	Lifecycle systématique : versions anciennes, multipart, expiration
Bucket public par défaut	Fuite de données	Privé par défaut, exposition publique justifiée et documentée
Partage de bucket entre environnements	Risque de fuite croisée, permissions confuses	Un bucket par environnement
Multipart upload non terminé	Coût caché de stockage de fragments	Lifecycle qui supprime les multipart inachevés
Pas de chiffrement explicite vérifié	Fausse impression de sécurité	Vérifier le chiffrement at-rest, considérer SSE-C pour le sensible

Glissez pour voir

OOS sous l’angle Well-Architected

Reliability — durabilité native + versioning + object lock

OOS apporte une durabilité native par construction (réplication interne sur l’infrastructure RING Scality). À cela s’ajoutent les protections applicatives :

• Versioning pour récupérer un objet supprimé ou écrasé.
• Object lock pour les sauvegardes immuables.
• Cross-AZ par construction au sein d’une région — la perte d’un datacenter ne fait pas perdre les données.

Cost Optimization — lifecycle et tagging

Le pilier Cost sur OOS se joue principalement sur :

• Le lifecycle qui purge automatiquement ce qui n’a plus besoin d’être stocké.
• Le tagging qui permet la répartition par projet et l’analyse FinOps.
• Le dimensionnement : utiliser OOS pour ce qui n’a pas besoin du stockage bloc (qui coûte plus cher au GiB).

Security — chiffrement, ACL, audit

Le pilier Security sur OOS s’appuie sur :

• Chiffrement at-rest par défaut + TLS pour le transit.
• ACL privées par défaut, exposition publique explicitement justifiée.
• Logs OMS pour tracer les accès API.
• Object lock comme rempart contre les ransomwares.

À retenir

• OOS est le stockage objet d’OUTSCALE — équivalent S3, basé sur RING Scality, accessible via aws-cli ou tout client S3 en pointant l’endpoint OOS.
• Endpoints : oos.eu-west-2.outscale.com ou oos.cloudgouv-eu-west-1.outscale.com.
• Limites : 100 buckets par compte (extensible à 1 000), 5 TB par objet, 10 millions d’objets par bucket, 300 GET/HEAD et 200 PUT par seconde par bucket.
• Versioning indispensable sur les buckets critiques — protection contre la suppression et les ransomwares.
• Lifecycle policy systématique — purge des versions anciennes, des multipart inachevés, expiration des objets selon la rétention.
• Object lock pour les sauvegardes immuables et la conformité réglementaire.
• Privé par défaut, exposition publique explicitement justifiée et documentée.

Prochaines étapes

Sauvegardes — RPO/RTO/PRA Stratégie 3-2-1 qui combine snapshots BSU et exports OOS.

Stockage — BSU, volumes, IOPS Stockage bloc complémentaire d'OOS, attaché aux VMs.

Outils CLI OUTSCALE aws-cli avec endpoint OOS pour scripter les opérations.

EIM identité et accès EIM ne couvre pas OOS — la gestion des accès passe par les ACL et politiques de bucket.

Ressources externes

• About OOS — Documentation OUTSCALE
• OOS Recommendations and Limits
• OOS API Reference
• Creating a Bucket
• Référence des erreurs API OUTSCALE

×

📖 Voir la documentation →