Aller au contenu
Cloud high

Egress et data transfer cloud : le piège tarifaire à anticiper

16 min de lecture

L’egress est le piège tarifaire le plus coûteux du cloud — et le plus invisible. Vous ne le voyez pas en concevant votre architecture, vous le voyez sur la facture du mois suivant, et il vaut souvent plusieurs milliers d’euros que personne n’avait budgétisés. Cette page explique pourquoi les fournisseurs facturent l’egress alors que l’ingress est gratuit, combien ça coûte vraiment chez chaque acteur en 2026, les patterns d’architecture qui font exploser la facture, et ceux qui la divisent par 10.

  • Le modèle économique de l’egress : pourquoi pas d’ingress facturé, et ce que ça implique
  • Les tarifs comparatifs 2026 entre AWS, Azure, GCP, Outscale, OVHcloud
  • Trois cas chiffrés qui rendent l’impact tangible
  • Les 5 patterns à éviter dans une architecture cloud
  • Les 5 patterns à privilégier dès la conception

Prérequis : avoir compris la structure de facturation cloud. Si besoin, lisez d’abord Pay-as-you-go : modèles tarifaires.

1. Pourquoi l’egress est facturé (et pas l’ingress)

Section intitulée « 1. Pourquoi l’egress est facturé (et pas l’ingress) »

Le premier réflexe d’un débutant face à la facture egress est de protester contre l’asymétrie : pourquoi les données qui entrent dans le cloud sont gratuites alors que celles qui sortent sont facturées ? Cette asymétrie n’est pas une distorsion technique, c’est un choix économique délibéré des fournisseurs.

L’ingress gratuit facilite le verrouillage. Migrer 50 To de données vers AWS ne coûte rien — c’est le ticket d’entrée gratuit du parc. Une fois ces données stockées et traitées dans des services AWS spécifiques (S3, RDS, DynamoDB), elles deviennent dépendantes de l’écosystème : changer de fournisseur impose de les ressortir, et là, l’egress facturé sert de frein structurel à la migration. C’est une mécanique de vendor lock-in indirect, formalisée dans la grille tarifaire.

L’egress payant finance les coûts réels. Au-delà du verrouillage, l’egress vers Internet a un vrai coût d’infrastructure : transit IP avec les opérateurs Tier 1, peering, capacité réseau dimensionnée pour les pics. Ces coûts existent côté on-prem aussi, mais sont mutualisés différemment. Côté cloud, le fournisseur les facture explicitement à l’usage, à un tarif qui couvre largement le coût réel — typiquement 5 à 10 fois.

Les écarts entre fournisseurs sont considérables sur l’egress, bien plus marqués que sur le compute. Voici les grilles de référence en avril 2026, hors remises négociées.

Tarifs egress vers Internet (premier To/mois après quotas gratuits)

Section intitulée « Tarifs egress vers Internet (premier To/mois après quotas gratuits) »
FournisseurTarif egress vers InternetQuota gratuit
AWS0,090 €/Go (régions Europe)100 Go/mois
Azure0,083 €/Go (régions Europe)100 Go/mois
GCP0,108 €/Go (régions Europe)0 Go (jusqu’en oct 2024, supprimé depuis)
Outscale0,010 €/Go0 Go
OVHcloud Public Cloud0,010 €/Go0 Go
Scaleway0,010 €/Go75 Go/mois
Hetzner Cloudinclus20 To/mois inclus dans la VM

Le différentiel est massif entre les hyperscalers (entre 0,083 et 0,108 €/Go) et les fournisseurs européens souverains (autour de 0,010 €/Go), soit un facteur d’environ 10. Pour un volume sortant de 10 To/mois, la fourchette annuelle se situe ainsi entre quelques centaines et plus de 10 000 € selon le fournisseur — pour le même service rendu. Cet écart structurel rend l’analyse egress critique dès qu’une application présente du trafic sortant régulier.

Le tarif Internet n’est qu’un des quatre axes. Trois autres axes facturent du transfert qu’on oublie souvent :

Egress cross-AZ (entre zones de disponibilité d’une même région). Tarifé typiquement 0,01 €/Go dans chaque sens chez AWS et GCP, gratuit chez Azure (depuis 2025). Une application 3-tier mal conçue peut générer un trafic cross-AZ massif sans que ça apparaisse comme « egress » dans les dashboards.

Egress cross-region (entre régions du même fournisseur). Tarifé 0,02 à 0,04 €/Go selon les régions. Une réplication continue de base de données 500 Go/jour entre eu-west-3 et us-east-1 représente 15 To/mois, soit 300 à 600 €/mois rien que pour la réplication.

Egress vers un autre cloud (peering inter-cloud). Tarifé au prix Internet plein tarif chez AWS et GCP, un peu moins cher avec Direct Connect / ExpressRoute mais avec engagement port. Une architecture multi-cloud naïve sans peering paye plein pot.

3. Trois cas chiffrés qui rendent l’impact tangible

Section intitulée « 3. Trois cas chiffrés qui rendent l’impact tangible »

Les chiffres bruts ne parlent qu’aux finance. Voici trois architectures concrètes que l’on rencontre fréquemment, avec le coût annuel d’egress qu’elles génèrent avant optimisation.

Une boutique en ligne mature qui sert des images produit, vidéos courtes et pages HTML. Trafic sortant moyen : 10 To/mois.

HébergeurCoût annuel egressOrdre de grandeur vs souverains européens
AWS sans CDN10 800 €environ × 9
AWS avec CloudFront (premier To 0,085 €)~9 800 €environ × 8
GCP sans CDN12 960 €environ × 11
Azure sans CDN9 960 €environ × 8
Fournisseur souverain européen (à 0,010 €/Go)1 200 €référence

Verdict : pour un site e-commerce stable, le seul poste egress peut justifier le choix d’un hébergeur européen souverain. Sur 5 ans, l’économie potentielle se chiffre en dizaines de milliers d’euros par rapport à un hyperscaler, sans rien changer d’autre dans l’architecture.

Une politique de backup qui exporte les données vers un stockage externe (autre fournisseur, NAS on-prem, S3-compatible chez un tiers) pour la résilience. Volume sortant : 5 To/mois.

ArchitectureCoût annuel egress
Hyperscaler → backup chez un fournisseur tiers (cas A)5 400 €/an
Hyperscaler → backup chez un fournisseur tiers (cas B)4 980 €/an
Hyperscaler → backup chez un hébergeur low-cost6 480 €/an
Fournisseur souverain européen → backup chez un autre fournisseur souverain600 €/an

Verdict : la stratégie de 3-2-1 backup (3 copies, 2 supports, 1 hors-site) est financièrement punitive si les données primaires vivent chez un hyperscaler américain. Le backup hors-cloud devient si cher qu’il dissuade la bonne pratique — ce qui est le but recherché par le fournisseur primaire.

Une application avec frontend chez AWS et base de données chez Azure (raison historique d’expertise interne ou d’audit). Trafic continu entre les deux : 3 To/mois dans chaque sens.

Coût mensuelDétail
Egress AWS → Azure3 To × 0,090 €/Go = 270 €/mois
Egress Azure → AWS3 To × 0,083 €/Go = 249 €/mois
Total mensuel519 €/mois
Total annuel6 228 €/an

Verdict : multi-cloud naïf sans peering coûte autant qu’un développeur junior à temps plein. Le peering Direct Connect / ExpressRoute (~200 €/mois minimum) reste rentable au-dessus de ~2 To/mois cross-cloud. En dessous, accepter de tout regrouper sur un seul fournisseur économise plus que ça ne coûte en dépendance.

4. Anatomie d’une facture egress — quatre zones de facturation

Section intitulée « 4. Anatomie d’une facture egress — quatre zones de facturation »

Pour bien comprendre où l’argent part, il faut visualiser les quatre zones où l’egress est facturé sur une architecture web typique en production. Une appli front + back + DB + CDN génère des flux dans chacune des quatre zones simultanément.

Zone 1 — Egress vers Internet : utilisateurs finaux qui chargent les pages, téléchargements de médias, API publique exposée. C’est la zone la plus visible et la plus directement liée au business.

Zone 2 — Egress cross-AZ : traffic entre tiers applicatifs déployés dans des AZ différentes. Frontend en AZ-1a, backend en AZ-1b, DB en AZ-1c — chaque appel HTTP traverse les AZ et facture dans chaque sens. Invisible dans les dashboards classiques.

Zone 3 — Egress cross-region : réplication de base de données pour DR, synchronisation de buckets S3 entre régions, distribution de containers depuis un registry central. Le DR distant coûte cher en continu.

Zone 4 — Egress inter-cloud : si vous mélangez plusieurs fournisseurs (par exemple un hyperscaler pour le compute, un fournisseur tiers pour l’identité, un autre pour des services ML), chaque appel franchit la frontière fournisseur au tarif plein.

Une architecture mal conçue facture dans les quatre zones simultanément, et le total peut représenter 30 à 50 % de la facture mensuelle rien qu’en réseau. Ce ratio est le signal d’alarme d’une architecture à revoir.

Voici les architectures que je vois exploser systématiquement la facture egress. Si vous reconnaissez l’une de ces situations dans votre infrastructure, c’est de l’argent posé sur la table.

🔥 Architecture multi-cloud naïve

Le piège : frontend chez un fournisseur, DB chez un autre, identité chez un troisième, sans peering ni stratégie de regroupement.

Symptôme : facture egress inter-cloud qui dépasse 30 % de la facture totale.

Mitigation : regrouper les services qui se parlent fort sur le même fournisseur, mettre en place du peering Direct Connect au-delà de 2 To/mois cross-cloud.

📦 Backup vers stockage externe sans optimisation

Le piège : sauvegarde quotidienne intégrale exportée hors-cloud sans delta sync ni compression.

Symptôme : 5 To/mois sortants pour 50 Go de données changées réellement.

Mitigation : delta sync (rclone, restic, borgbackup), compression côté source, fréquence adaptée (delta horaire, full mensuel).

🌐 Diffusion média sans CDN

Le piège : un site qui sert des images et vidéos directement depuis S3 ou Blob Storage, sans CDN devant.

Symptôme : egress qui scale linéairement avec le trafic visiteur, alors que 80 % du contenu est statique cacheable.

Mitigation : CloudFront, Front Door, Cloud CDN, Cloudflare devant tous les assets statiques. Économie typique : 70 à 90 % de l’egress média.

🔄 Réplication continue cross-region pour faux DR

Le piège : réplication continue d’une base de données 500 Go vers une région secondaire « pour le DR » alors qu’un RPO de 24 h suffirait largement.

Symptôme : 15 To/mois de réplication, ~300 €/mois en cross-region.

Mitigation : snapshots quotidiens transférés async, RPO 24 h documenté et accepté par le métier au lieu de réplication temps réel par défaut.

📊 Pipelines analytics sortant les données brutes

Le piège : pipeline qui exporte les logs bruts vers un outil externe (Datadog, Splunk Cloud, Sumologic) sans filtre ni agrégation.

Symptôme : 100 % des logs verbeux sortent du cloud, l’outil tiers facture l’ingestion et l’egress du cloud d’origine.

Mitigation : filtrage par sévérité avant export (DEBUG hors prod), agrégation locale, échantillonnage statistique pour les logs verbeux.

Inverse miroir : voici les architectures qui réduisent structurellement l’egress, sans dégrader le service.

CDN devant tous les assets statiques. Image, vidéo, JS/CSS, font — tout ce qui est cacheable doit passer par un CDN. Le tarif CloudFront/Front Door/Cloud CDN est ~30 % moins cher que l’egress S3/Blob direct, et il réduit le volume servi grâce au cache. L’économie cumulée dépasse souvent 80 %.

Agrégation et filtrage locaux avant export. Toute donnée destinée à un outil externe (monitoring, analytics, backup) doit passer par une étape d’agrégation dans le cloud d’origine — réduction du volume par 5 à 50 selon le cas. Outils typiques : Vector, Fluent Bit pour les logs, AWS Glue ou Spark pour les batchs analytiques.

Stockage sur le même fournisseur que le compute principal. Tant que possible, garder données et traitement chez un seul fournisseur cloud. Les architectures multi-cloud séduisantes sur le papier deviennent ruineuses en pratique sans peering. Si l’argument multi-cloud est la résilience, mettre en place le DR cross-cloud pour les données critiques uniquement, pas pour tout le système.

Peering / Direct Connect au-delà du seuil de rentabilité. Si vous avez un besoin avéré de transit cross-cloud ou cloud-to-on-prem, le peering devient rentable au-delà de ~2 To/mois sortant, avec un seuil exact qui dépend des engagements port. Ne pas le configurer en dessous, le payer plein pot s’imposer au-dessus.

Choix de fournisseur cohérent avec le profil egress. Le marché présente des écarts tarifaires significatifs sur l’egress entre les fournisseurs. Pour une application à très forte bande passante sortante (vidéo, jeux, streaming, gros téléchargements), comparer les grilles tarifaires des différents fournisseurs avant de figer le choix peut représenter une économie substantielle sur le TCO. C’est un cas où le coût egress devient un critère structurant du choix d’hébergeur.

Pour conclure, un éclairage sur la logique économique des tarifs egress observés sur le marché.

Côté fournisseurs avec egress élevé, la tarification s’intègre dans une stratégie d’écosystème : elle finance les services managés disponibles, elle valorise la rétention des données dans l’écosystème, et elle introduit un coût de sortie pour les transferts vers d’autres plateformes. Cette mécanique fait partie intégrante du modèle économique de ces fournisseurs.

Côté fournisseurs avec egress faible ou inclus, la tarification reflète plus directement le coût d’infrastructure réel (transit IP, peering). Ces fournisseurs se positionnent sur un modèle de fournisseur d’infrastructure plutôt que de plateforme avec services managés étendus. C’est un compromis : moins de services managés très spécialisés, mais un coût de sortie de données quasi-nul.

Ces deux logiques coexistent sur le marché et répondent à des besoins clients différents. Pour un projet à fort egress, la grille tarifaire egress fait partie des critères principaux du choix de fournisseur, au même titre que la maturité des services managés ou la couverture géographique.

  • L’egress payant et l’ingress gratuit ne sont pas une asymétrie technique mais un choix économique de verrouillage.
  • Le différentiel tarifaire atteint un facteur 10 entre GCP (0,108 €/Go) et les souverains européens (0,01 €/Go).
  • Quatre zones de facturation se cumulent : Internet, cross-AZ, cross-region, inter-cloud.
  • Cinq patterns à éviter : multi-cloud naïf, backup brut, diffusion sans CDN, réplication continue inutile, logs sortant non filtrés.
  • Cinq patterns à privilégier : CDN systématique, agrégation locale, regroupement chez un fournisseur, peering au-delà du seuil, choix de fournisseur cohérent avec le profil de charge.
  • Pour les applications très consommatrices de bande passante, le choix du fournisseur est l’optimisation principale.

Ce site vous est utile ?

Sachez que moins de 1% des lecteurs soutiennent ce site.

Je maintiens +700 guides gratuits, sans pub ni tracing. Aujourd'hui, ce site ne couvre même pas mes frais d'hébergement, d'électricité, de matériel, de logiciels, mais surtout de cafés.

Un soutien régulier, même symbolique, m'aide à garder ces ressources gratuites et à continuer de produire des guides de qualité. Merci pour votre appui.

Abonnez-vous et suivez mon actualité DevSecOps sur LinkedIn