Pilier Cost Optimization sur OUTSCALE

Le pilier Cost Optimization couvre le right-sizing, le lifecycle OOS, le tagging à fin de répartition et plus largement la discipline FinOps. Sur OUTSCALE, les leviers principaux sont le format TINA (tinavW.cXrYpZ) ajusté au profil de charge, les lifecycle policies sur OOS (suppression différée des objets via Expiration), l’API ReadConsumptionAccount pour le suivi mensuel, et un tagging discipliné qui permet de répartir les coûts par projet ou par équipe. Cette page formule les questions clés, propose une checklist actionnable, deux ADR types et les points d’audit correspondants.

Le pilier en deux phrases

Cost Optimization évalue la capacité d’une organisation à payer le juste prix pour ses ressources cloud, à savoir où va l’argent et à éliminer le gaspillage sans sacrifier la qualité de service. Sur OUTSCALE, il se matérialise par un right-sizing TINA ajusté à la consommation réelle, une discipline lifecycle sur les buckets OOS, un tagging cost-center systématique, et une revue mensuelle des coûts par projet.

Les questions clés

Une architecture qui revendique une posture Cost doit pouvoir répondre aux questions suivantes :

Visibilité — l’équipe sait-elle, par projet et par environnement, combien coûte chaque mois son infrastructure OUTSCALE ?
Tag cost-center — chaque ressource porte-t-elle un tag cost-center (ou équivalent) qui permet la refacturation interne ?
Right-sizing actif — les instances TINA surdimensionnées (CPU < 30 % en p95 sur 7 jours) sont-elles identifiées et redimensionnées trimestriellement ?
Lifecycle OOS — les buckets OOS ont-ils une politique d’expiration appliquée selon la nature des données (logs, archives, sauvegardes) ?
Volumes orphelins — les volumes BSU détachés depuis plus de 30 jours sont-ils identifiés et soit rattachés, soit supprimés ?
Snapshots accumulés — les snapshots BSU plus anciens que la politique de rétention sont-ils nettoyés automatiquement, ou s’accumulent-ils silencieusement ?
Type de volume adapté — les volumes en io1 (le plus cher) sont-ils justifiés par une mesure d’IOPS, ou utilisés par confort sur des workloads qui n’en ont pas besoin ?
Suivi des EIP — les EIP allouées mais non attachées à une VM (facturées même non utilisées) sont-elles identifiées et libérées ?
Suivi mensuel — l’équipe consomme-t-elle l’API ReadConsumptionAccount chaque mois, croise-t-elle avec les tags pour produire un dashboard de coûts par projet ?

Une organisation qui répond « non » à plus de quatre questions a typiquement 20 à 40 % de gaspillage dans sa facture mensuelle.

Application sur OUTSCALE

Right-sizing TINA

Le right-sizing consiste à ajuster les ressources allouées à la consommation réelle. Sur OUTSCALE :

Compute — choisir la famille tinavW.cXrYpZ qui correspond au profil de charge mesuré. Démarrer petit (c2r4p2), mesurer 7 à 14 jours, ajuster.
Mémoire — éviter les familles riches en RAM (r16, r32) sur des workloads qui consomment moins de 50 % de la RAM allouée.
Performance flag — p3 (medium) suffit pour les environnements de dev / staging et les batchs peu sensibles, p2 (high) pour la production standard, p1 (highest) réservé aux workloads exigeants en SLA.

Le right-sizing actif trimestriel sur un parc de 50 à 100 instances libère typiquement 15 à 30 % du budget compute. Le détail sizing est traité dans Calcul — instances TINA et sizing.

Lifecycle OOS

Les buckets OOS hébergent souvent des objets durables dont la valeur d’accès décroît avec le temps : exports applicatifs, archives de logs, sauvegardes anciennes. La politique de cycle de vie OOS Outscale, configurée en JSON via une règle Rules avec Expiration, automatise la suppression des objets après une durée définie (paramètre Days) ou à une date donnée (Date), avec un filtrage optionnel par préfixe ou par tag.

Concrètement, la lifecycle OOS Outscale couvre l’expiration automatique — pas de transition entre classes de stockage. Sans politique d’expiration, un bucket de logs ou de sauvegardes accumule indéfiniment et la facture OOS croît mois après mois. Le détail opérationnel est traité dans Stockage — OOS, versioning, lifecycle.

Tagging cost-center

Le tag cost-center est l’instrument de la refacturation interne. Chaque ressource porte un identifiant analytique (code BU, code projet) qui permet d’agréger les coûts par bénéficiaire. Sans ce tag :

L’équipe FinOps ne peut pas répondre à « combien coûte le projet Marketing ce mois-ci ? ».
La direction perçoit le cloud comme un coût opaque, ce qui freine les arbitrages.
Aucun mécanisme d’incitation n’est possible — chaque équipe pousse sans frein.

Le tag cost-center se met en place sur toutes les ressources facturées (VMs, volumes BSU, EIP, buckets OOS, fGPU, snapshots…) et se contrôle dans le pipeline IaC.

Suivi mensuel via `ReadConsumptionAccount`

L’API ReadConsumptionAccount retourne la consommation détaillée d’un compte sur une période. Les paramètres clés (validés sur la spec OAPI) :

FromDate — date de début (format ISO 2026-04-01).
ToDate — date de fin (format ISO 2026-05-01).
ShowPrice — booléen pour inclure le prix.
ShowResourceDetails — booléen pour inclure le détail par ressource.

oapi-cli ReadConsumptionAccount \
  --FromDate 2026-04-01 \
  --ToDate 2026-05-01 \
  --ShowPrice true \
  --ShowResourceDetails true

L’équipe FinOps automatise ce script en tâche planifiée mensuelle, agrège par tag cost-center, et publie un dashboard. La revue mensuelle avec les responsables de projet permet d’identifier les dérives avant qu’elles ne deviennent significatives.

Volumes orphelins et snapshots accumulés

Deux gisements de gaspillage classiques :

Volumes BSU détachés — un volume créé pour un test, oublié après destruction de la VM, continue d’être facturé. Un script qui liste ReadVolumes et filtre les volumes en état available (non attachés) depuis plus de 30 jours identifie le gisement.
Snapshots accumulés — les snapshots ReadSnapshots s’accumulent sans politique de rétention. Sur un parc moyen, on découvre régulièrement plusieurs téraoctets de snapshots de plus de 12 mois.

La politique de rétention doit être documentée et appliquée par script automatisé : quotidien J-7, hebdomadaire S-4, mensuel M-12, par exemple.

EIP non attachées

Les EIP (Elastic Public IPs) sont facturées même quand elles ne sont pas attachées à une VM (c’est le comportement standard chez tous les fournisseurs cloud, pour éviter la rétention sans usage). Un audit régulier via ReadPublicIps identifie les EIP allouées sans LinkPublicIp, et les libère ou les justifie.

Checklist Definition of Done

Tag cost-center appliqué sur 100 % des ressources, contrôlé en CI.
Dashboard mensuel alimenté par ReadConsumptionAccount, agrégé par cost-center.
Revue right-sizing trimestrielle documentée, instances surdimensionnées corrigées.
Lifecycle OOS appliquée sur les buckets de logs, archives, sauvegardes.
Audit volumes orphelins mensuel, suppression ou justification documentée.
Politique de rétention snapshots appliquée par script automatisé.
Audit EIP non attachées mensuel.
Type de volume io1 justifié par une mesure d’IOPS pour chaque cas d’usage.
Performance flag p1 justifié par un SLA documenté pour chaque cas d’usage.

ADR types

ADR-COST-01 — Tag `cost-center` obligatoire

Contexte : la facture OUTSCALE mensuelle est globale, sans imputation par projet. La direction ne peut pas arbitrer sur les coûts cloud parce qu’elle ne sait pas où ils vont.

Décision : ajouter un tag cost-center obligatoire sur toutes les ressources facturées. Implémenter un contrôle bloquant dans le pipeline Terraform (rejet si le tag est absent). Migrer les ressources existantes par lots successifs.

Conséquences : effort initial de migration (1 à 2 sprints sur un parc moyen). Bénéfice durable : refacturation interne possible, dashboard de coûts par projet, arbitrages éclairés.

ADR-COST-02 — Lifecycle OOS standard sur les buckets de logs

Contexte : les buckets OOS de logs applicatifs et infrastructure n’ont pas de politique de cycle de vie. Leur taille croît indéfiniment, la facture OOS croît significativement chaque trimestre sans valeur métier proportionnelle.

Décision : appliquer une politique lifecycle standard sur tous les buckets de logs avec une règle Expiration à 13 mois (alignée avec la rétention métriques typique). Les buckets de sauvegardes critiques restent exclus de cette politique standard et suivent leur propre politique documentée alignée sur la conformité applicable.

Conséquences : économie immédiate sur les logs anciens supprimés automatiquement. Bénéfice durable : croissance maîtrisée, coût prévisible par mois.

Points d’audit correspondants

Sur un compte OUTSCALE réel, ces contrôles peuvent être menés via oapi-cli :

oapi-cli ReadConsumptionAccount \
  --FromDate 2026-04-01 \
  --ToDate 2026-05-01 \
  --ShowPrice true \
  --ShowResourceDetails true

Récupère la consommation détaillée du compte sur la période. Croiser avec les tags via un script post-traitement.

oapi-cli ReadVolumes

Identifier les volumes en état available depuis plus de 30 jours (volumes orphelins).

oapi-cli ReadSnapshots

Identifier les snapshots ne respectant pas la politique de rétention.

oapi-cli ReadPublicIps

Identifier les EIP sans attachement (LinkPublicIp absent).

L’audit complet est traité dans une page dédiée du Volet 5, à venir.

Antipatterns à éviter

Pas de tag cost-center. Considérer la facture cloud comme un coût opérationnel global. Conséquence : aucun arbitrage possible, croissance non maîtrisée, pas d’incitation par équipe.

Right-sizing une fois, jamais revu. Faire un audit de right-sizing au démarrage du projet et ne plus jamais y revenir. Les charges évoluent : un service qui consommait 60 % du CPU il y a 6 mois en consomme peut-être 15 % aujourd’hui (volumes utilisateurs en baisse, optimisations de code).

io1 par confort. Choisir io1 pour tous les volumes data « pour avoir de la marge ». Surcoût significatif sans bénéfice mesurable.

Snapshots éternels. Créer un snapshot quotidien sans politique d’expiration. Le coût explose après 12 à 18 mois.

Lifecycle OOS oubliée. Considérer que « le stockage objet ne coûte rien ». Sur 5 à 10 ans, les buckets de logs accumulent des centaines de gigaoctets (parfois téraoctets) qui ne sont jamais relus.

À retenir

Tag cost-center non négociable — contrôlé en CI.
Right-sizing trimestriel sur le compute — typiquement 15 à 30 % d’économie sur les parcs mal entretenus.
Lifecycle OOS sur les buckets de logs et archives — règle Expiration automatisée (transition entre classes non supportée par Outscale).
Suivi mensuel via ReadConsumptionAccount (paramètres FromDate / ToDate / ShowPrice / ShowResourceDetails).
Volumes orphelins, snapshots anciens, EIP non attachées — chasser ces gisements de gaspillage classiques.
Type de volume et performance flag justifiés par mesure ou SLA — pas par confort.

Prochaines étapes

Volet 5 — Vue d'ensemble Le sommaire des 7 piliers Well-Architected appliqués à OUTSCALE.

Calcul — instances TINA et sizing La méthode de sizing qui sert directement le pilier Cost.

Stockage — OOS, versioning, lifecycle Les politiques de cycle de vie sur OOS.

Sauvegardes — RPO/RTO/PRA La gestion des snapshots et exports OOS.