Le piège de l'egress : la ligne de facture que personne ne budgète

Vous aviez budgété le compute. Vous aviez budgété le stockage. Puis la facture est tombée, avec une ligne que vous n’aviez jamais modélisée : le transfert de données. L’egress. Le tarif que vous payez pour relire vos propres données depuis le cloud.

Ce n’est presque jamais le chiffre qui saute aux yeux. C’est celui qui grimpe pendant que vous regardez ailleurs, jusqu’au mois où il représente un tiers de la facture sans que personne ne sache exactement pourquoi.

Ce qu’est vraiment l’egress, et pourquoi il est facturé ainsi

L’egress, c’est le trafic sortant : les octets qui quittent une zone, une région, ou carrément le réseau du fournisseur. L’entrée est généralement gratuite. La sortie est facturée au gigaoctet, et le tarif s’empile par couches — inter-AZ, inter-région, vers internet — chacune avec son propre prix.

Stocker des données coûte peu, et de moins en moins. C’est dans leur déplacement que se loge la marge. Facturer l’egress fait deux choses à la fois pour un hyperscaler : ça imprime de l’argent sur un trafic qui lui coûte très peu, et ça augmente le coût d’un éventuel départ. Les données que vous y mettez sont gratuites à l’entrée. Les ressortir, à grande échelle, ne l’est pas. Cette asymétrie n’a rien d’un accident. C’est le modèle économique.

Comment ça déforme votre architecture

Voici la partie qui devrait vous déranger en tant qu’ingénieur. La tarification de l’egress cesse d’être un simple détail de facturation et se met à prendre vos décisions de design à votre place.

• Vous arrêtez de déplacer les données. La conception propre dit : copie ce jeu de données là où se trouve le compute. La facture dit : non. Alors vous tordez la topologie pour garder les octets immobiles, même quand c’est le mauvais choix.
• Vous redoutez le multi-région. Répliquer vers une seconde région pour la résilience, c’est exactement ce que vous devriez faire. L’egress inter-région en fait une taxe récurrente, alors vous vous en dissuadez vous-même.
• Vous évitez le pipeline d’analytics évident parce que tirer les données vers l’outil censé les traiter coûte plus cher que le traitement lui-même.
• Vous vous retrouvez verrouillé. Une fois vos données volumineuses, le coût de leur extraction pour évaluer un autre fournisseur est en soi un facteur dissuasif. Le compteur d’egress est une douve, et vous êtes du mauvais côté.

Aucune de ces décisions n’est dictée par la justesse technique. Ce sont des décisions d’évitement de facture déguisées en architecture.

Le schéma du choc de facture

Ça ressemble toujours à la même chose. Un lancement se passe bien. Un batch devient plus bavard. Un client mal configuré relance ses requêtes à travers une frontière de région. Un nouveau dashboard interroge un object store depuis le mauvais endroit. Un trafic qui n’était qu’une erreur d’arrondi devient le poste de coût dominant, et le pire, c’est que vous ne pouvez pas le prévoir à l’avance — la grille tarifaire a tellement de paliers et de frontières que la seule façon de connaître le chiffre, c’est de le voir sur la facture. Vous architecturez sur la défensive autour d’un coût que vous ne savez pas modéliser. C’est ça, le piège.

Ce que nous faisons à la place

Nous pensons que vous devriez architecturer pour la justesse, pas pour la facture. Alors nous avons supprimé le levier.

Il n’y a aucun frais d’egress entre les ressources Kaligon d’une même région. Votre VM qui parle à votre volume block, votre object store, votre base de données, une autre VM — ce trafic est gratuit. Déplacez les données là où se trouve le compute. Répliquez à l’intérieur de la région pour la résilience. Construisez le pipeline comme dans le manuel. Les octets qui circulent entre vos propres ressources n’apparaissent pas sur la facture.

Le trafic sortant vers internet est à un tarif forfaitaire unique. Un seul chiffre. Pas de surcoût inter-AZ, pas d’échelle de paliers inter-région, pas de frontière surprise sur laquelle vous trébuchez à 2 h du matin. Vous pouvez le lire sur la page tarifs et le poser dans un tableur avant même de construire quoi que ce soit.

Ça colle à la façon dont tout le reste de Kaligon est tarifé : un prix forfaitaire unique par ressource, une facturation à la seconde plafonnée au mois, et un budget strict qui stoppe réellement la dépense. Pas de gymnastique d’instances réservées, pas de remises d’usage engagé à courir après. Et comme vos données restent dans la région que vous avez choisie, elles ne vont pas vagabonder discrètement vers un endroit plus coûteux à quitter.

L’egress devrait être une affaire de réseau, pas une contrainte de design. Architecturez la bonne chose. Et laissez la facture être ennuyeuse.