Honnêtement, s'il y a un poste de facture qui fait grincer des dents en réunion FinOps, c'est bien celui-là : les frais de transfert de données sortantes — les fameux coûts d'egress — représentent désormais entre 10 % et 25 % de la facture cloud moyenne des entreprises européennes. Le pire ? Contrairement aux instances de calcul ou au stockage, ces frais sont totalement invisibles avant la facture, et ils varient selon la destination, le fournisseur, et même la région. Ce guide 2026 détaille comment réduire jusqu'à 70 % vos coûts d'egress sur AWS, Azure et GCP grâce à l'architecture, à la mise en cache, et aux nouvelles réglementations européennes.
Comprendre les frais d'egress cloud en 2026
L'egress, c'est tout simplement toute donnée qui sort d'un fournisseur cloud : vers Internet, vers une autre région, vers un autre cloud, ou vers votre datacenter on-premise. L'ingress (l'entrée), lui, est quasi-systématiquement gratuit. Pratique, non ? Sauf que ça crée un effet de « captivité » qu'on qualifie souvent de lock-in tarifaire — et c'est exactement le but recherché.
L'impact du Data Act européen sur les frais d'egress
Depuis le 12 janvier 2024, le Data Act (Règlement UE 2023/2854) impose aux fournisseurs de services cloud de supprimer progressivement les frais de changement de fournisseur. À partir du 12 janvier 2027, ces frais de « switching » deviennent totalement interdits pour les clients européens. En anticipation, AWS, Google Cloud et Microsoft Azure ont déjà revu leurs politiques en 2024 et 2025 pour offrir l'egress gratuit lors d'une migration complète hors de leur plateforme.
Attention quand même : cette gratuité ne s'applique qu'en cas de sortie définitive. L'egress opérationnel quotidien, lui, reste facturé au tarif standard. Pas de cadeau sur le trafic du lundi matin.
Tarifs d'egress Internet standards (Europe, 2026)
- AWS (eu-west-3 Paris) : 0,085 €/Go pour les 10 premiers To/mois, dégressif jusqu'à 0,045 €/Go au-delà de 150 To. Les 100 premiers Go/mois sont gratuits depuis février 2024.
- Azure (France Central) : 0,075 €/Go pour les 10 premiers To/mois, dégressif jusqu'à 0,040 €/Go au-delà de 150 To. 100 Go/mois gratuits également.
- Google Cloud (europe-west9 Paris) : 0,095 €/Go pour la première tranche, dégressif jusqu'à 0,06 €/Go. Le tier « Standard Network » descend à 0,070 €/Go — en échange d'une qualité de routage moindre.
Identifier les sources d'egress dans votre architecture
Avant d'optimiser, il faut mesurer. Point. Les trois sources principales de coûts cachés que je vois revenir dans presque tous les audits : le trafic inter-AZ, le trafic inter-région, et les flux vers des endpoints externes mal optimisés (CDN absent ou mal configuré, CI/CD qui pull sans arrêt depuis S3, logs envoyés hors cloud).
Audit d'egress sur AWS avec Cost and Usage Reports
-- Requête Athena sur un CUR 2.0 pour isoler les coûts d'egress
SELECT
line_item_product_code,
line_item_usage_type,
product_region_code,
SUM(line_item_unblended_cost) AS cost_eur,
SUM(line_item_usage_amount) AS gb_transferred
FROM "cur2_parquet"."data"
WHERE bill_billing_period_start_date = DATE '2026-03-01'
AND line_item_usage_type LIKE '%DataTransfer-Out%'
GROUP BY 1, 2, 3
ORDER BY cost_eur DESC
LIMIT 50;
Les types d'usage les plus coûteux à surveiller de près : EU-DataTransfer-Out-Bytes (Internet), EU-EUW3-AWS-Out-Bytes (inter-région), et EUW3-DataTransfer-Regional-Bytes (inter-AZ à 0,01 €/Go — dans chaque sens, et c'est là que ça fait mal).
Audit sur Azure via Cost Management Query API
{
"type": "ActualCost",
"timeframe": "MonthToDate",
"dataset": {
"granularity": "Daily",
"filter": {
"dimensions": {
"name": "MeterCategory",
"operator": "In",
"values": ["Bandwidth"]
}
},
"grouping": [
{ "type": "Dimension", "name": "MeterSubCategory" },
{ "type": "Dimension", "name": "ResourceLocation" }
],
"aggregation": {
"totalCost": { "name": "Cost", "function": "Sum" }
}
}
}
Audit sur GCP via BigQuery Billing Export
SELECT
service.description AS service,
sku.description AS sku,
location.region AS region,
SUM(cost) AS cost_eur,
SUM(usage.amount) / POW(1024, 3) AS gb_transferred
FROM `billing.gcp_billing_export_v1_XXXXXX`
WHERE _PARTITIONTIME >= TIMESTAMP("2026-04-01")
AND LOWER(sku.description) LIKE '%egress%'
GROUP BY 1, 2, 3
ORDER BY cost_eur DESC;
10 stratégies pour réduire vos coûts d'egress en 2026
1. Utiliser un CDN pour le trafic utilisateur final
Servir des assets statiques directement depuis S3, Blob Storage ou GCS, ça coûte le plein tarif d'egress. Aïe. Un CDN comme CloudFront, Azure Front Door, Cloud CDN, ou un acteur tiers type Bunny.net (0,01 €/Go en Europe) ou Cloudflare R2 (egress gratuit) réduit drastiquement la facture. CloudFront facture à peu près 0,075 €/Go en Europe, mais avec un taux de cache hit de 90 % — ce qui est tout à fait atteignable — vous divisez les coûts d'origine par dix.
# Terraform : distribution CloudFront avec origine S3 privée (OAC)
resource "aws_cloudfront_distribution" "assets" {
enabled = true
default_root_object = "index.html"
price_class = "PriceClass_100" # Europe + US uniquement
origin {
domain_name = aws_s3_bucket.assets.bucket_regional_domain_name
origin_id = "s3-assets"
origin_access_control_id = aws_cloudfront_origin_access_control.oac.id
}
default_cache_behavior {
target_origin_id = "s3-assets"
viewer_protocol_policy = "redirect-to-https"
allowed_methods = ["GET", "HEAD"]
cached_methods = ["GET", "HEAD"]
compress = true
cache_policy_id = data.aws_cloudfront_cache_policy.optimized.id
min_ttl = 0
default_ttl = 86400
max_ttl = 31536000
}
restrictions {
geo_restriction { restriction_type = "none" }
}
viewer_certificate { cloudfront_default_certificate = true }
}
2. Activer les VPC Endpoints (AWS PrivateLink)
Par défaut, un appel depuis EC2 vers S3 ou DynamoDB transite par la passerelle NAT et génère des frais de traitement (0,052 €/Go) plus des frais de DataTransfer-Out. Double peine. Un VPC Gateway Endpoint pour S3 et DynamoDB est gratuit et élimine totalement ces coûts — c'est probablement le gain le plus facile de toute cette liste.
resource "aws_vpc_endpoint" "s3" {
vpc_id = aws_vpc.main.id
service_name = "com.amazonaws.eu-west-3.s3"
vpc_endpoint_type = "Gateway"
route_table_ids = aws_route_table.private[*].id
}
resource "aws_vpc_endpoint" "dynamodb" {
vpc_id = aws_vpc.main.id
service_name = "com.amazonaws.eu-west-3.dynamodb"
vpc_endpoint_type = "Gateway"
route_table_ids = aws_route_table.private[*].id
}
Pour les autres services (ECR, Secrets Manager, STS), il faut passer par des Interface Endpoints (PrivateLink) — 0,01 €/heure par endpoint par AZ, mais 0,01 €/Go traité contre 0,085 €/Go en egress Internet. Le calcul est vite fait.
3. Consolider les workloads dans la même AZ
Sur AWS, le trafic entre deux AZ de la même région coûte 0,01 €/Go dans chaque sens, soit 0,02 €/Go aller-retour. Pour des workloads bavards (microservices, bases de données répliquées, vous voyez le tableau), la colocalisation en Single-AZ peut économiser jusqu'à 40 % du trafic interne — au prix d'une disponibilité réduite, évidemment. Pensez à utiliser les Availability Zone IDs pour garantir la colocalisation entre comptes AWS (sinon us-east-1a chez vous n'est pas us-east-1a chez votre voisin, et c'est le genre de surprise qui fait perdre du temps).
4. Optimiser les Multi-AZ NAT Gateways
Une architecture Multi-AZ avec NAT Gateway dans chaque AZ évite les frais de cross-AZ sortants. Le coût du NAT Gateway (0,052 €/heure) est souvent compensé dès 500 Go/mois de trafic cross-AZ évité. Alternative intéressante : des NAT Instances sur Graviton t4g.nano, 5× moins chères pour des petits volumes.
5. Mettre en cache les pulls Docker et packages
Un cluster Kubernetes qui pull ses images depuis Docker Hub ou ghcr.io génère de l'egress à chaque déploiement. Et quand on déploie 30 fois par jour… ça chiffre vite. Quelques solutions :
- ECR Pull-through cache (AWS) : 0,10 $/Go pour la première mise en cache, gratuit ensuite.
- Artifact Registry Remote Repositories (GCP) : cache régional de Docker Hub, PyPI, npm.
- Azure Container Registry avec Artifact Cache : idem, mais côté Microsoft.
- Proxy Harbor ou Nexus auto-hébergé pour les équipes ayant des dizaines de clusters (à partir de cette échelle, l'auto-hébergement devient plus économique).
6. Activer la compression HTTP et les formats modernes
Servir des réponses JSON non compressées, ça coûte 3 à 5× plus cher qu'avec Brotli ou gzip. Vérifiez vraiment — je ne saurais trop insister — que votre load balancer active bien la compression :
# Nginx : activer Brotli en plus de gzip
http {
brotli on;
brotli_comp_level 6;
brotli_types text/plain text/css application/json
application/javascript text/xml application/xml
application/xml+rss text/javascript image/svg+xml;
gzip on;
gzip_vary on;
gzip_comp_level 6;
gzip_types text/plain text/css application/json
application/javascript text/xml application/xml
application/xml+rss text/javascript;
}
Pour les images, migrer vers AVIF ou WebP réduit la taille de 30 à 70 % par rapport à JPEG. Sur CloudFront, vous pouvez utiliser CloudFront Functions pour servir dynamiquement la meilleure variante selon l'header Accept du client. Un petit effort, un gros impact.
7. Privilégier Cloudflare R2 ou Backblaze B2 pour le stockage public
Cloudflare R2 propose zéro frais d'egress à 0,015 $/Go/mois de stockage, contre 0,021 €/Go sur S3 Standard + l'egress par-dessus. Concrètement : pour un bucket de 10 To servant 50 To/mois en egress, l'économie atteint environ 3 500 €/mois. Pas anodin. Backblaze B2 propose un modèle similaire grâce à la Bandwidth Alliance (egress gratuit vers Cloudflare, Vercel, etc.).
8. Utiliser les Private Connections pour le multicloud
Si votre architecture est répartie entre AWS et Azure (ce qui est de plus en plus courant), le trafic via Internet public vous coûte le plein egress. Les options :
- AWS Direct Connect + Azure ExpressRoute via un partenaire type Equinix ou Megaport : environ 0,02 €/Go.
- Google Cloud Interconnect à 0,02 €/Go (Europe).
- Pour les très gros volumes, un Dedicated Interconnect à 10 Gbps amortit le coût fixe dès 40 To/mois.
9. Déplacer (ou supprimer) le stockage d'objets froid
Avant de payer pour l'egress, posez-vous la vraie question : cette donnée doit-elle vraiment sortir ? S3 Intelligent-Tiering déplace automatiquement les objets non accédés vers des classes moins chères. Ça n'économise pas directement l'egress, mais ça révèle souvent que 60 % des données ne sont tout simplement jamais lues. Supprimer ou archiver ces objets élimine l'egress futur lié à un accès accidentel (typiquement, un script d'indexation oublié qui tourne une fois par mois depuis trois ans).
10. Monitorer et alerter sur les anomalies d'egress
Un script malveillant, une boucle de log mal configurée, un crawler un peu trop gourmand : tout ça peut générer plusieurs To en quelques heures. Mettez en place des alertes CloudWatch / Azure Monitor / Cloud Monitoring sur le volume d'egress — vraiment, ne sautez pas cette étape :
# Alerte CloudWatch : egress Internet > 500 Go/jour sur un VPC
resource "aws_cloudwatch_metric_alarm" "egress_spike" {
alarm_name = "vpc-egress-spike"
comparison_operator = "GreaterThanThreshold"
evaluation_periods = 1
metric_name = "BytesOut"
namespace = "AWS/NATGateway"
period = 86400
statistic = "Sum"
threshold = 500000000000 # 500 Go
alarm_description = "Egress anormalement eleve sur NAT Gateway"
alarm_actions = [aws_sns_topic.finops_alerts.arn]
dimensions = {
NatGatewayId = aws_nat_gateway.main.id
}
}
Cas d'étude : une plateforme SaaS réduit ses coûts d'egress de 68 %
Voici un cas concret sur lequel j'ai travaillé récemment. Une scale-up française de 120 ingénieurs opérant sur AWS eu-west-3 avait une facture d'egress mensuelle de 18 400 € en janvier 2026. Après audit, les postes se répartissaient ainsi :
- 52 % — API publique servie directement depuis des ALB (sans CDN, oui oui, en 2026).
- 23 % — Pulls d'images depuis GitHub Container Registry (CI/CD × 400 builds/jour, soit l'équivalent d'une petite PME industrielle).
- 14 % — Réplication cross-region Postgres (eu-west-3 → eu-west-1).
- 11 % — Divers (logs vers Datadog, backups vers Backblaze).
Actions menées, dans l'ordre de priorité :
- Mise en place de CloudFront devant l'ALB avec des cache policies adaptées (−4 200 €/mois).
- ECR pull-through cache activé (−3 100 €/mois).
- Bascule de la réplication vers un VPC peering avec endpoint (−1 800 €/mois).
- Agent Datadog reconfiguré en mode compression avancée (−800 €/mois).
- VPC Endpoints pour S3 et DynamoDB (−2 600 €/mois, avec bonus sur la NAT Gateway).
Nouvelle facture : 5 900 €/mois, soit 12 500 € d'économies mensuelles (68 % de réduction). ROI de l'audit (5 jours d'ingénieur) atteint en moins d'une semaine. Difficile de trouver un meilleur ratio effort/impact dans le FinOps.
Outils FinOps recommandés pour suivre l'egress en 2026
- Vantage — tableaux de bord natifs pour egress AWS, Azure, GCP, Cloudflare. Mon préféré pour les équipes qui débutent.
- CloudZero — allocation de l'egress par feature ou par customer (unit economics).
- Kubecost / OpenCost — egress par namespace / workload Kubernetes.
- Finout — alertes d'anomalies basées sur du ML.
- AWS Cost Anomaly Detection (gratuit) — détection automatique des pics d'egress, parfait pour commencer sans budget.
FAQ : questions fréquentes sur les coûts d'egress cloud
L'egress sera-t-il vraiment gratuit en 2027 avec le Data Act ?
Uniquement lors d'une migration complète vers un autre fournisseur (le fameux « switching »). L'egress opérationnel quotidien, lui, reste facturé au tarif standard — ne vous faites pas d'illusions. Le Data Act impose aussi une transparence accrue sur les tarifs et interdit les clauses contractuelles empêchant la portabilité, ce qui est déjà une avancée majeure.
Quelle est la différence entre egress Internet et egress inter-région ?
L'egress Internet (vers un client externe) coûte 0,075 à 0,095 €/Go en Europe. L'egress inter-région (entre deux régions du même fournisseur) tombe à 0,02 €/Go, tandis que l'egress cross-AZ à l'intérieur d'une même région coûte 0,01 €/Go dans chaque sens. L'egress entre clouds différents, lui, est toujours facturé au tarif Internet — c'est là que le lock-in est le plus douloureux.
Un VPC Endpoint est-il toujours plus économique qu'une NAT Gateway ?
Pour les services supportant les Gateway Endpoints (S3, DynamoDB), oui, clairement : ils sont gratuits. Pour les Interface Endpoints (PrivateLink), le calcul mérite d'être posé : 0,01 €/heure × 24 × 30 × nombre d'AZ = environ 21 €/mois fixe par service. Rentable dès 250 Go/mois traités, comparé à une NAT Gateway.
CloudFront réduit-il vraiment mes coûts ou simplement les déplace-t-il ?
Excellente question, et c'est un piège dans lequel beaucoup d'équipes tombent. CloudFront en Europe coûte 0,075 €/Go, soit quasiment le même tarif que l'egress S3 direct. L'économie vient du cache hit ratio : avec 90 % de cache hit, seuls 10 % du trafic atteint l'origine. Plus le contenu est cachable (CSS, JS, images), plus CloudFront est rentable. Pour du trafic API 100 % dynamique, l'intérêt est effectivement nul — voire négatif si vous empilez les couches.
Cloudflare R2 est-il compatible avec les applications existantes utilisant S3 ?
Oui, R2 expose une API S3-compatible. Il suffit généralement de changer l'endpoint (https://ACCOUNT_ID.r2.cloudflarestorage.com) et les credentials, et ça roule. Les SDK AWS officiels fonctionnent avec R2 sans modification. Attention toutefois aux fonctionnalités avancées (S3 Object Lambda, Event Notifications spécifiques, certains paramètres de lifecycle) qui ne sont pas toutes répliquées. Testez sur un environnement non-critique avant de basculer la prod.
Conclusion
Les frais d'egress restent, en 2026, l'un des postes les plus opaques et les plus sous-optimisés de la facture cloud. L'approche gagnante combine trois axes : l'architecture (VPC Endpoints, colocalisation, CDN), le stockage intelligent (R2, Intelligent-Tiering, cache de registry), et l'observabilité (alertes d'anomalie, allocation par feature). En appliquant ces leviers sans radicalisme excessif, la plupart des organisations peuvent viser 40 à 70 % de réduction sans compromis sur la performance. Et avec l'entrée en vigueur complète du Data Act en 2027, le paysage tarifaire va encore bouger : autant anticiper dès maintenant votre stratégie multicloud plutôt que de subir la prochaine vague de changements.