Frais egress inattendus : d'où viennent les factures de bande passante

La facture arrive et elle est quatre fois plus élevée que prévu. La ligne du compute correspond à peu près à votre budget. Celle qui ne correspond pas est celle de l'egress — les octets qui quittent votre infrastructure — et il est fort possible que vous n'y ayez jamais réfléchi.

Les frais egress inattendus sont la surprise de facturation la plus courante dans l'hébergement d'applications, et la raison est structurelle : rien dans votre boucle de développement ne mesure les octets. Votre ordinateur portable ne vous les facture pas. La staging n'a pas d'utilisateurs. La première fois que la bande passante devient visible, c'est sur une facture — et à ce stade, vous avez déjà déployé l'habitude qui en est la cause.

Voici d'où ils viennent réellement, classés selon la fréquence à laquelle ils expliquent le problème.

1. Servir les médias depuis l'application

Ce cas éclipse tous les autres et il est presque toujours accidentel.

Vous placez une vidéo dans /public pour faire une démo. Elle fonctionne, alors vous la laissez en place. Chaque affichage de page diffuse désormais ce fichier depuis votre container. Une vidéo de 40 Mo sur une page visitée par mille personnes par mois représente 40 Go — pour un fichier que vous considériez comme un simple placeholder.

Le même problème concerne les images produit, les PDF, les uploads utilisateurs et les fichiers de police. Aucun de ces éléments ne semble relever d'une décision d'infrastructure au moment où vous les ajoutez.

La solution n'a rien de sophistiqué : les médias statiques doivent être stockés sur un object storage derrière un CDN, pas dans le système de fichiers de votre application. Votre app doit servir du HTML et du JSON. Dès qu'elle sert une image hero de 4 Mo à chaque visiteur, elle fait le travail d'un CDN sans bénéficier de son modèle économique.

2. Aucun header de cache

Si vos réponses ne contiennent aucun header de cache, chaque visiteur télécharge chaque asset à chaque chargement de page. Les visiteurs récurrents téléchargent tout à nouveau. Un crawler peut les télécharger des dizaines de fois par jour.

# Fingerprinted build assets never change — cache them for a year
Cache-Control: public, max-age=31536000, immutable

# HTML changes — revalidate but allow a short window
Cache-Control: public, max-age=0, must-revalidate

# Anything user-specific
Cache-Control: private, no-store

Il s'agit d'une modification d'une ligne par classe de réponse qui supprime régulièrement la majeure partie d'une facture de bande passante, car le trafic éliminé n'est que de la répétition.

3. Des APIs qui renvoient plus de données que le client n'en utilise

Un endpoint de liste qui renvoie des objets complets alors que l'UI n'affiche que trois champs envoie la différence à chaque requête, indéfiniment. Cela n'apparaît jamais dans le profiling parce que c'est rapide — c'est simplement volumineux.

Voici deux points à vérifier sur vos endpoints les plus sollicités :

• La compression est-elle activée ? Content-Encoding: gzip ou br sur du JSON réduit généralement le volume de 70 à 80 %. Il suffit d'une ligne de middleware et elle manque encore très souvent.
• Envoyez-vous des champs que personne ne lit ? Sérialiser toute la ligne parce que l'ORM le rend facile est le comportement par défaut de la plupart des codebases.

Un client qui effectue du polling aggrave ces deux problèmes d'un facteur égal au nombre de requêtes envoyées chaque minute.

4. Trafic interrégional et interservices

Si votre app se trouve dans une région et votre base de données dans une autre, chaque résultat de requête traverse une limite réseau payante. C'est facile à faire accidentellement : vous créez d'abord la base de données, choisissez une région sans y penser, puis placez l'application ailleurs quelques semaines plus tard.

Le trafic entre vos propres services peut également être considéré comme de l'egress s'il quitte le réseau privé avant de revenir via un hostname public. Deux services du même workspace qui communiquent par leurs URLs publiques paient deux fois pour une conversation qui n'avait jamais besoin de sortir du réseau.

Sur Dockup, cette erreur précise est difficile à commettre, car les services s'adressent les uns aux autres par leur nom interne. Un service atteint main-db.internal:5432 et un autre service via son alias <slug>.internal — le trafic qui reste dans le réseau du workspace ne passe jamais par un listener public. C'est également la raison pour laquelle la base de données n'a pas de hostname public par défaut : rien ne peut être accidentellement routé par ce biais.

Identifier la source au lieu de deviner

Deviner lequel de ces quatre problèmes est en cause fait perdre un cycle de facturation. Mesurez plutôt :

Lisez l'access log en fonction du volume, pas du nombre de requêtes. Triez vos réponses principales selon le nombre total d'octets servis plutôt que selon le nombre de requêtes. L'endpoint qui envoie le plus de données n'est généralement pas celui qui est appelé le plus souvent.

Vérifiez la taille de vos plus gros assets statiques. Si un fichier de plus d'un mégaoctet est servi depuis votre app, c'est la première chose à déplacer.

# What is the service actually doing right now
dockup metrics my-project/my-api --json

# And what is it logging
dockup logs my-project/my-api -n 1000

Surveillez les crawlers. Un bot mal configuré qui récupère de gros fichiers en boucle peut représenter la majeure partie de l'egress mensuel d'un site qui reçoit pourtant peu de trafic humain. Un robots.txt et un noindex sur les environnements de preview ne coûtent presque rien.

Les environnements que personne ne comptabilise

Deux habitudes génèrent de l'egress qui n'apparaît dans le modèle mental de personne :

Les environnements de preview. Un environnement de preview par pull request est réellement utile et multiplie discrètement votre empreinte. Cinq PR ouvertes, c'est cinq copies de votre stack, chacune avec son propre trafic — souvent généré par les mêmes crawlers, car les URLs de preview sont indexées si vous ne les en empêchez pas.

La staging qui dure dans le temps. Une staging qui fonctionne depuis huit mois, que personne ne consulte, continue de récupérer des images, d'être explorée par des crawlers et d'exécuter ses tâches cron.

Aucun de ces cas ne justifie d'arrêter de les utiliser. Ils justifient tous deux de les encadrer : supprimez les previews lorsque la PR est fermée et marquez-les noindex afin que les moteurs de recherche cessent de les télécharger à votre place.

dockup noindex my-project/my-api --on

À quoi ressemble une bonne facturation

Vous devriez pouvoir répondre à trois questions avant l'arrivée de la facture :

1. Qu'est-ce qui fonctionne actuellement ? Y compris les éléments que vous avez oubliés.
2. Qu'est-ce que chaque élément a consommé ? En séparant le compute et le transfert, plutôt qu'en affichant un seul chiffre.
3. Que se passe-t-il en cas de pic ? Une limite qui arrête les services est désagréable. Une limite qui n'existe pas est pire.

Dockup mesure séparément l'infrastructure et le plan, de sorte que le tarif du plan ne masque pas l'usage — et le crédit de 20 $ du plan Pro est déduit de cet usage plutôt que d'être appliqué comme une remise sur le tarif. L'objectif est de voir clairement quelle part correspond à quoi.

En bref

Déplacez les médias vers un object storage. Définissez des headers de cache. Activez la compression. Gardez les services et leurs bases de données dans une même région et faites-les communiquer via le réseau privé plutôt que par Internet public. Supprimez les environnements de preview à leur expiration et empêchez leur apparition dans les résultats de recherche.

Ces cinq habitudes répondent à presque toutes les factures de bande passante inattendues et aucune ne vous oblige à changer de plateforme d'hébergement.

Foire aux questions

Qu'est-ce que l'egress ? Les données qui quittent votre infrastructure pour rejoindre Internet. Réponses envoyées aux utilisateurs, fichiers téléchargés, payloads d'API. Le trafic entrant est généralement gratuit ; le trafic sortant ne l'est généralement pas.

Pourquoi ma facture d'egress est-elle plus élevée que ma facture de compute ? Presque toujours parce que l'application sert des fichiers qui devraient être placés sur un CDN. Un seul asset volumineux sur une page populaire peut coûter davantage que plusieurs semaines de traitement des requêtes.

Un CDN permet-il vraiment de réduire ces coûts ? Oui, lorsqu'il met les fichiers en cache. L'origine sert le fichier une fois par edge au lieu de le servir une fois par visiteur, et le prix par gigaoctet d'un CDN représente généralement une fraction de celui d'une plateforme applicative.

Les environnements de preview coûtent-ils autant que la production ? Ils coûtent ce qu'ils consomment, ce qui est souvent plus élevé que prévu, car chacun est une copie complète et les URLs de preview sont explorées par les crawlers si vous ne l'empêchez pas.