Stockage BSU sur Outscale : quand io1 cesse d'en valoir le coût

Vous provisionnez un volume io1 de 500 Gio avec 10 000 IOPS pour une base de données. Le volume lui-même coûte environ 65 €/mois. Les IOPS coûtent environ 100 €/mois. Votre "disque rapide" est maintenant à 165 €/mois pour 500 Gio.

Un volume gp2 des mêmes 500 Gio ? 55 €/mois, pas de surcharge IOPS, ~3 000 IOPS de baseline (burstable à 6 000+). Même disque, un tiers du coût, souvent assez de performance.

La leçon : la tarification BSU n'est pas un dégradé doux du moins cher au plus rapide. Il y a des falaises, et io1 a la plus raide.

Les trois types de BSU

Le BSU Outscale existe en trois variantes :

Magnétique (standard). Environ 0,04 €/Gio/mois. Disque rotatif, pas de garantie IOPS. Pas cher, lent. Cas d'usage réel : stockage froid, données archivées, snapshots-en-volume que personne ne sollicite souvent.

gp2 (performance). Environ 0,11 €/Gio/mois. Backed-SSD, IOPS de baseline qui scale avec la taille (~3 IOPS par Gio), bursts plus haut. Défaut pour la plupart des workloads. Base de données OK, serveurs d'app très bien, pas de surcharge par IOPS.

io1 (entreprise). Environ 0,13 €/Gio/mois, plus ~0,01 € par IOPS provisionnée par mois. Backed-SSD avec IOPS garanties jusqu'à ce que vous provisionnez. La ligne IOPS, c'est là où le coût s'envole.

Le piège de la tarification IOPS

Ce qui rend io1 cher, ce n'est pas le tarif Gio. C'est qu'on provisionne les IOPS comme une ligne séparée, et c'est facile de surprovisionner parce que les suggestions par défaut de l'UI sont agressives.

Configuration courante : 500 Gio io1 avec 10 000 IOPS.

• Coût Gio : 500 × 0,13 € = 65 €/mois
• Coût IOPS : 10 000 × 0,01 € = 100 €/mois
• Total : 165 €/mois

Même workload sur gp2 avec 500 Gio :

• Coût Gio : 500 × 0,11 € = 55 €/mois
• Coût IOPS : inclus (baseline ~1 500, burst à 3 000)
• Total : 55 €/mois

C'est une différence de coût de 3×, sur l'hypothèse que le workload a vraiment besoin de 10 000 IOPS soutenues. La plupart des workloads non. Ils y pointent occasionnellement, et le burst de gp2 le gère.

Quand io1 gagne vraiment

io1 est le bon choix quand ces deux conditions sont vraies :

1. La demande IOPS soutenue dépasse la baseline gp2. Si vous tournez vraiment 5 000 IOPS en continu, gp2 va throttler et io1 non.
2. La variance de latence compte. Les IOPS d'io1 sont garanties ; celles de gp2 dépendent du solde de burst credit. Pour un workload où le p99 sous charge est une exigence dure (systèmes financiers, OLTP critique), la prédictibilité d'io1 vaut le coût.

Pour tout le reste — workloads analytiques, serveurs d'app, bases de données normales, environnements dev, staging de snapshots — gp2 est correct. Le tier "performance" est largement assez performant.

L'arbre de décision

Évitez io1 sauf si vous pouvez répondre "oui" aux trois :

• Le workload soutient-il >3 000 IOPS pendant >15 minutes d'affilée, régulièrement ?
• Le p99 de latence disque sous charge impacte-t-il un SLO client-facing ?
• Le coût de la lenteur est-il clairement supérieur au coût de la surcharge IOPS ?

Si une réponse est non, prenez gp2. Si toutes les réponses sont oui, io1 est sincèrement le bon outil.

Pour les données froides et les volumes rarement accédés (vieux snapshots montés temporairement, espace de scratch dev), le magnétique va bien et coûte 3× moins cher que gp2. Ne mettez pas du performance par défaut sur chaque disque juste parce que c'est l'option évidente.

Le toggle IOPS de Vextnd

Pour les volumes io1 déjà en production, il y a une optimisation plus discrète : le pattern de réduction d'IOPS aux heures creuses. La plupart des volumes "haut IOPS" n'ont pas besoin de leur provision IOPS complète 24/7 — ils en ont besoin aux heures de bureau, aux fenêtres batch, ou à des événements de charge spécifiques. Le reste du temps, la provision IOPS, c'est de la capacité payée pour rien.

Le scheduler de volumes Vextnd peut baisser les IOPS provisionnées d'un volume io1 aux heures creuses et les remonter aux heures de travail. Les économies : typiquement 20 à 35 % sur la ligne IOPS. C'est un toggle manuel par volume — désactivé par défaut parce que baisser les IOPS pendant un moment write-heavy, c'est mauvais. Bien utilisé (sur dev/staging/batch), c'est de l'argent gratuit.

Un exemple à 3 volumes

Un environnement type a trois volumes significatifs. Voici une configuration réaliste et ce que chacun devrait être :

• Base de données prod (200 Gio, 4 000 IOPS soutenues) : io1 avec 5 000 IOPS provisionnées. ~76 €/mois. Justifié.
• Root du serveur d'application (50 Gio, IOPS faibles) : gp2. 5,50 €/mois. Aucune raison d'utiliser quelque chose de plus fancy.
• Base de données dev (200 Gio, accès occasionnel) : gp2 avec planification Vextnd. 22 €/mois, descend à 15 € si vous taguez et planifiez. Aucune raison d'utiliser io1.

Total : ~100 €/mois. Le même setup en tout-io1 avec provisioning IOPS par défaut tournerait à 280-350 €/mois pour aucun bénéfice perceptible sur les volumes 2 et 3. Le réflexe "toujours prendre le plus rapide" se cumule mal sur une flotte.