À quoi correspond le trafic egress
Dans le contexte cloud et Kubernetes, l'egress désigne tout trafic réseau qui sort d'un périmètre vers un destinataire externe : appel d'API tierce depuis un pod, téléchargement d'une image conteneur, export de données vers un client B2B, sauvegarde vers un autre cloud, requête DNS vers internet. L'inverse, l'ingress, désigne le trafic entrant.
Pour une équipe DevOps, l'egress se gère sous deux angles indépendants : le coût (facturé au gigaoctet par les fournisseurs cloud) et la sécurité (chaque flux sortant est un canal potentiel d'exfiltration de données).
L'impact financier chez les hyperscalers
L'egress est l'un des coûts les plus opaques et les plus volatiles chez AWS, Azure et GCP. Les ordres de grandeur typiques en 2026 :
- Egress depuis AWS vers internet : 0,09 USD/GB pour les premiers téraoctets, dégressif ensuite. Le 1er To est facturé environ 92 USD ; le 10e, environ 850 USD.
- Egress entre régions AWS : 0,02 USD/GB, soit 20 USD par téraoctet.
- Egress entre zones d'une même région : 0,01 USD/GB. Souvent oublié, mais 1 To de réplication inter-AZ coûte 10 USD par mois et par téraoctet répliqué.
L'effet cumulé peut surprendre : un service vidéo qui sert 50 To/mois aux utilisateurs paie typiquement 4 000 à 5 000 USD/mois uniquement pour l'egress, parfois plus que le coût de calcul lui-même.
C'est ce qui motive l'émergence d'alternatives sans frais d'egress : Cloudflare R2, Hetzner, OVH Storage, et plusieurs clouds suisses dont Hikube. Sur Hikube, l'egress vers internet est inclus dans les forfaits, ce qui rend les coûts prévisibles pour les workloads à forte sortie (médias, IoT, multi-cloud).
L'enjeu sécurité
Chaque flux egress sortant d'un cluster est un canal potentiel d'exfiltration. Un attaquant qui prend le contrôle d'un pod (via une faille applicative) peut exfiltrer la base de données accessible via un POST vers un serveur externe. Sans contrôle d'egress, cette exfiltration passe inaperçue.
Les bonnes pratiques observées chez Hidora :
Egress NetworkPolicies. Restreindre par défaut tout trafic sortant des pods, puis autoriser explicitement les destinations légitimes (API externe métier, registry d'images, DNS interne). Cilium et Calico supportent cette logique nativement.
Egress gateway. Forcer tout le trafic sortant à passer par un nœud dédié (Istio, Cilium Egress Gateway). Cela permet d'auditer, logger et appliquer des politiques L7 (autoriser seulement certains domaines, certains méthodes HTTP).
Filtrage DNS. Bloquer la résolution de domaines non autorisés. Un attaquant qui exfiltre vers evil.example.com est stoppé si le DNS interne refuse la résolution.
Inspection TLS. Pour les environnements les plus sensibles, déchiffrer le trafic egress et l'inspecter (DLP). Pratique invasive, réservée aux secteurs régulés.
Egress et architectures multi-cloud
Une stratégie multi-cloud (workloads répartis entre AWS, Hikube, Azure) implique un trafic egress entre clouds. Les coûts cumulés peuvent rendre une architecture multi-cloud économiquement défavorable si mal conçue. Recommandations pratiques :
- Garder les données proches du calcul : éviter de référencer une base PostgreSQL hébergée sur Hikube depuis un compute AWS.
- Réplication asynchrone et compressée entre clouds pour limiter le volume.
- Mesurer l'egress mensuellement avec des tags par projet/équipe, intégrer aux dashboards FinOps.
Services Hidora associés
- Consulting : audit FinOps de l'egress, conception de NetworkPolicies, architecture multi-cloud à coût maîtrisé.
- Hikube : cloud suisse avec egress inclus dans les forfaits, alternative économique aux hyperscalers pour workloads à forte sortie.
- Managed Services : exploitation des contrôles d'egress en production avec alerting sur les anomalies.
- FinOps, Cloud souverain, Cilium : briques associées.