Distribuée
AWS Advisory
← Tous les insights

FinOps

Frais de sortie AWS : cartographier et réduire vos coûts de data transfer avant janvier 2027

Egress internet, cross-AZ, NAT Gateway : la méthode pour cartographier vos frais de sortie AWS et les réduire, avant l'interdiction totale des frais de switching au 12 janvier 2027 (Data Act européen).

· 7 min · #finops#aws#data-transfer#egress#reseau#data-act

La ligne « EC2-Other » ou « Data Transfer » de la facture AWS est presque toujours la moins comprise. Elle n’a pas de tableau de bord dédié dans la console, elle est répartie sur des dizaines de types d’usage (DataTransfer-Out-Bytes, DataTransfer-Regional-Bytes, NatGateway-Bytes…), et personne dans l’équipe ne sait dire avec certitude quel flux paie quoi. En mission Distribuée, c’est la ligne qui provoque le plus de « ah bon, ça coûte ça ? » lors d’un audit FinOps.

Le sujet devient plus pressant en 2026 : le Data Act européen impose la suppression totale des frais de sortie facturés lors d’un changement de fournisseur cloud à partir du 12 janvier 2027 — dans un peu moins de cinq mois. AWS a anticipé une partie du sujet dès mars 2024 en supprimant les frais de sortie pour les clients qui quittent intégralement la plateforme, mais ce n’est ni automatique, ni total, et ça ne change rien à l’essentiel : le trafic de sortie « opérationnel » (celui qui fait tourner votre prod au quotidien) reste facturé exactement comme avant, et c’est lui qui pèse dans la facture d’une PME.

Pourquoi cette ligne de facture reste invisible

Trois raisons reviennent systématiquement en audit :

  1. Le trafic sortant n’a pas de propriétaire. Contrairement à EC2 ou RDS, rattachés à une équipe ou un projet, le data transfer traverse toutes les couches — personne ne le regarde en premier.
  2. Cost Explorer le fragmente par défaut. Sans filtre explicite sur usage_type, les coûts réseau sont noyés dans les coûts de calcul du service qui les génère.
  3. Les architectures multi-AZ et les microservices bavards multiplient les flux internes, qui semblent gratuits parce qu’ils ne quittent jamais le VPC — sauf qu’un flux entre deux AZ reste facturé.

Première étape avant tout levier d’optimisation : isoler ce que vous payez réellement.

aws ce get-cost-and-usage \
  --time-period Start=2026-07-01,End=2026-08-01 \
  --granularity MONTHLY \
  --metrics "UnblendedCost" \
  --group-by Type=DIMENSION,Key=USAGE_TYPE \
  --filter '{
    "Dimensions": {
      "Key": "SERVICE",
      "Values": ["EC2 - Other", "Amazon Virtual Private Cloud", "Amazon CloudFront"]
    }
  }' \
  --query "ResultsByTime[0].Groups[?contains(Keys[0], 'DataTransfer') || contains(Keys[0], 'NatGateway')]"

Cette requête isole les usage_type liés au transfert de données et au NAT Gateway sur le mois écoulé — c’est le point de départ de tout audit réseau chez Distribuée.

Cartographie des flux de data transfer AWS et leur coût

Les 4 postes de coût qui composent la facture

Egress internet (DataTransfer-Out-Bytes). 100 Go gratuits par mois et par compte (cumulés tous services), puis 0,09 $/Go jusqu’à 10 To, 0,085 $/Go jusqu’à 40 To supplémentaires, 0,07 $/Go jusqu’à 100 To, 0,05 $/Go au-delà de 150 To. Les tarifs sont plus élevés dans certaines régions Asie-Pacifique (jusqu’à 0,12 $/Go à Singapour) — un point à vérifier si vous servez du trafic depuis l’Asie.

Transfert inter-AZ (RegionalDataTransfer-*). 0,01 $/Go dans chaque sens dès qu’un paquet traverse deux zones de disponibilité — y compris entre deux instances EC2 du même VPC, entre une app et sa base RDS Multi-AZ, ou entre microservices répartis pour la résilience. C’est le coût le plus sournois : il grandit avec le découplage de l’architecture, pas avec le trafic externe.

NAT Gateway (NatGateway-Bytes). 0,045 $/Go traité, en plus de 0,045 $/heure par NAT Gateway déployé — et ce coût s’ajoute à l’egress internet sous-jacent si le flux sort ensuite vers Internet. Une architecture avec un NAT Gateway par AZ (bonne pratique de résilience) multiplie mécaniquement l’heure facturée par le nombre d’AZ, indépendamment du trafic.

CloudFront et Direct Connect. Exclus de la suppression de frais de sortie de mars 2024 — ce sont les deux services qu’AWS a explicitement laissés hors du périmètre de l’offre. CloudFront a en revanche son propre tarif, structurellement avantageux (voir plus bas).

5 leviers concrets, classés par facilité de mise en œuvre

1. VPC Gateway Endpoints pour S3 et DynamoDB — gratuit, à activer partout

Les Gateway Endpoints vers S3 et DynamoDB sont gratuits : pas de coût horaire, pas de coût au Go. Sans eux, un accès S3 depuis un subnet privé passe par le NAT Gateway — vous payez à la fois le traitement NAT (0,045 $/Go) et potentiellement l’egress. C’est le levier au meilleur ratio effort/gain de cet article : quelques minutes de Terraform, zéro risque.

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]
}

2. CloudFront devant vos assets statiques — 1 To gratuit par mois, définitivement

Le free tier CloudFront (1 To de sortie + 10 millions de requêtes HTTP/HTTPS par mois) est permanent, pas limité à 12 mois comme le reste du free tier AWS. Pour une PME qui sert des assets statiques, des exports, ou une API à trafic modéré directement depuis EC2 ou S3, router ce trafic par CloudFront transforme souvent une ligne d’egress payante en ligne à 0 €. C’est exactement le mécanisme qui héberge ce site : S3 + CloudFront, quelques euros par mois.

Contrairement aux Gateway Endpoints, les Interface Endpoints (PrivateLink) vers les autres services AWS (ECR, Secrets Manager, CloudWatch Logs…) coûtent 0,01 $/heure par AZ plus 0,01 $/Go traité. Ils ne sont rentables que si le volume évité en NAT Gateway (0,045 $/Go) dépasse ce coût fixe — typiquement au-delà de quelques centaines de Go/mois par endpoint. Auditez le volume réel avant de les déployer partout : un PrivateLink sous-utilisé coûte plus cher que le NAT qu’il remplace.

4. Regrouper les ressources bavardes dans la même AZ

Pour les flux internes à très haut débit (réplication de cache, pipelines de données, clusters Kafka/EKS), le placement en une seule AZ élimine le coût inter-AZ — au prix d’un compromis sur la résilience. Ce n’est pas un choix par défaut : à réserver aux flux dont le volume justifie le risque, avec un plan de bascule documenté en cas de panne d’AZ.

5. Compression et formats binaires avant l’egress

Simple et souvent négligé : activer la compression (gzip/brotli) sur les réponses API et privilégier des formats binaires (Parquet plutôt que CSV/JSON pour les exports volumineux) réduit directement le volume facturé — sans toucher à l’architecture.

L’échéance du 12 janvier 2027 : ce qui change vraiment

Le Data Act européen (règlement 2023/2854) impose un calendrier en deux temps aux fournisseurs cloud servant des clients européens :

  • Depuis janvier 2024 : les frais de switching (dont l’egress facturé lors d’un changement de fournisseur) doivent être réduits à un tarif « couvrant les coûts » — plus de marge dessus.
  • À partir du 12 janvier 2027 : interdiction totale de facturer des frais de switching, egress inclus, pour tout client qui change de fournisseur ou rapatrie ses données en interne.

Ce que ça ne change pas : le trafic de sortie opérationnel — celui qui sert vos utilisateurs au quotidien, hors migration de sortie — reste facturé selon la grille tarifaire standard. L’offre de mars 2024 d’AWS ne s’applique qu’aux sorties complètes de la plateforme, sur demande explicite au support, et exclut CloudFront et Direct Connect. Pour une PME qui n’a pas de projet de migration, l’échéance 2027 ne réduit donc pas la facture d’un centime — elle sécurise seulement la sortie si elle devient nécessaire un jour.

Concrètement, ça veut dire deux choses à préparer d’ici janvier 2027 si le multicloud ou une migration future fait partie de votre feuille de route : documenter précisément le volume de données à migrer (pour dimensionner la fenêtre de transfert), et vérifier contractuellement que votre fournisseur cible n’a pas de frais d’entrée équivalents qui annuleraient le bénéfice.

Ce qu’on regarde en priorité en audit

Sur les audits FinOps menés cette année chez Distribuée, l’ordre de priorité est presque toujours le même : Gateway Endpoints S3/DynamoDB manquants (gain immédiat, zéro risque), trafic inter-AZ non anticipé dans une architecture microservices récente, puis CloudFront sous-exploité pour du contenu qui pourrait transiter par le free tier permanent. Ces trois leviers, cumulés, représentent en moyenne 15 à 30 % de la ligne data transfer sur les architectures qu’on audite — sans toucher à la résilience ni à la performance.

Si votre facture réseau vous semble opaque ou a grimpé sans explication claire, c’est typiquement le genre de sujet traité dans un audit DevSecOps : cartographie complète des flux, priorisation des leviers, et mise en œuvre si besoin en mode retainer.

Cet article vous a été utile ? Partagez-le.

Aller plus loin

Un sujet, une mission, une question ?

Distribuée accompagne des PME exigeantes sur l'audit, le FinOps et la sécurité AWS.

Réserver 15 min