Les coûts de transfert de données AWS expliqués : NAT Gateway, inter-AZ et sortie

Ce guide explique d’où viennent les coûts de transfert de données AWS et comment les faire baisser, pour vous qui avez une ligne de bande passante que personne dans l’équipe n’explique. L’essentiel vient de trois compteurs, et le plus bruyant est le NAT Gateway, la passerelle gérée qui permet aux serveurs privés de joindre Internet, facturée au gigaoctet dans les deux sens. Les deux autres sont le trafic inter-AZ, soit les données qui passent d’une zone de disponibilité (AZ) à l’autre, et la sortie vers Internet, soit les données qui quittent votre réseau. Le remède consiste rarement à envoyer moins de données, mais à emprunter des chemins qu’AWS ne facture pas, d’abord un point de terminaison VPC vers S3, qui contourne le NAT Gateway. À la fin, vous saurez lequel des trois compteurs avale votre budget et quoi corriger en premier.

Ce qui se passe

AWS mesure le trafic par chemin, pas seulement par volume, et les chemins ont des tarifs très différents. Le trafic entrant depuis Internet est gratuit. Le trafic sortant vers Internet se facture au Go, avec des tarifs dégressifs par palier de volume et variables selon la région (et une modeste franchise mensuelle gratuite à l’échelle du compte). Le trafic entre AZ de la même région se facture au Go dans chaque direction — un Go échangé entre un serveur d’application dans ca-central-1a et une base de données dans ca-central-1b est donc compté deux fois. Le trafic dans la même AZ sur IP privées est gratuit; les mêmes paquets entre les mêmes instances via leurs IP publiques se facturent au tarif régional.

Puis il y a le multiplicateur : un NAT Gateway facture des frais horaires plus des frais de traitement au Go sur tout ce qui le traverse, dans les deux sens, en plus de ce que le trafic coûte de l’autre côté. Le motif qui fait mal : des instances en sous-réseau privé qui tirent de S3 ou d’ECR à travers un NAT Gateway. Le transfert S3 dans la région serait gratuit — mais chaque octet paie le péage de traitement NAT. Savoir si le NAT lui-même convient à votre échelle est une autre question, couverte dans NAT Gateway vs instance NAT; cet article-ci sert à trouver lequel de ces compteurs tourne sur votre facture.

Quoi vérifier d’abord

Cost Explorer, groupé par type d’utilisation, filtré sur les services EC2 et VPC : les lignes à reconnaître sont NatGateway-Bytes (traitement), DataTransfer-Regional-Bytes (inter-AZ/IP publique régional) et DataTransfer-Out-Bytes (sortie Internet).
Si des points de terminaison passerelle existent. VPC > Endpoints — pas de point de terminaison passerelle S3/DynamoDB plus un NAT Gateway : le constat le plus fréquent qui soit.
Où vivent vos paires bavardes. Application-base de données, application-cache, service-service : même AZ ou traversée?
Tout ce qui parle à un service régional via un nom d’hôte public depuis un sous-réseau public par IP publique — le chemin privé gratuit ne s’applique que si le trafic roule vraiment sur l’adressage privé.
La réplication inter-régions et les lectures multi-régions, facturées au tarif inter-régions et faciles à oublier après un projet de relève.

Comment vérifier

# Quels types d'utilisation de transfert coûtent quoi, dernier mois complet.
# Les dates sont calculées, donc la commande reste juste peu importe quand vous la lancez.
# date GNU (Amazon Linux, Ubuntu). Sur macOS : date -u -v-1m +%Y-%m-01
MONTH_START=$(date -u -d "$(date -u +%Y-%m-01) -1 month" +%Y-%m-01)
MONTH_END=$(date -u +%Y-%m-01)

aws ce get-cost-and-usage \
  --time-period Start=$MONTH_START,End=$MONTH_END \
  --granularity MONTHLY \
  --metrics UnblendedCost \
  --group-by Type=DIMENSION,Key=USAGE_TYPE \
  --filter '{"Dimensions":{"Key":"SERVICE","Values":["Amazon Elastic Compute Cloud - Compute","Amazon Virtual Private Cloud"]}}'

# Combien chaque NAT Gateway traite, sur les 7 derniers jours
WINDOW_START=$(date -u -d '7 days ago' +%Y-%m-%dT%H:%M:%SZ)
WINDOW_END=$(date -u +%Y-%m-%dT%H:%M:%SZ)

aws cloudwatch get-metric-statistics --namespace AWS/NATGateway \
  --metric-name BytesOutToDestination \
  --dimensions Name=NatGatewayId,Value=nat-0123456789abcdef0 \
  --start-time $WINDOW_START --end-time $WINDOW_END \
  --period 86400 --statistics Sum

Pour voir qui se cache derrière le trafic NAT, activez les VPC Flow Logs et interrogez les gros parleurs dans CloudWatch Logs Insights :

filter dstAddr like /^10\.0\.0\./
| stats sum(bytes) as totalBytes by srcAddr
| sort totalBytes desc
| limit 20

(Remplacez le préfixe par l’IP privée de votre NAT Gateway.) Le chemin console pour le point de terminaison est VPC > Endpoints > Create endpoint, nom de service com.amazonaws.<region>.s3, type Gateway. La mécanique de prix chemin par chemin est dans la documentation VPC.

La solution

Ajoutez des points de terminaison passerelle pour S3 et DynamoDB. Gratuits, posés en quelques minutes, ils retirent ce trafic du chemin NAT entièrement — les entrées de table de routage font la redirection. Pour les comptes qui tirent des images de conteneurs ou des données S3 depuis des sous-réseaux privés, c’est régulièrement la plus grosse coupe individuelle. Les points de terminaison d’interface pour les autres services (ECR, CloudWatch, SSM) facturent à l’heure plus au Go, mais restent sous le traitement NAT à volume moyen — les compromis sont dans les points de terminaison VPC pour S3 et DynamoDB.
Co-localisez les paires bavardes. Mettez l’étage applicatif et son cache dans la même AZ; faites lire les services intensifs en lecture sur une réplique de base de données même-AZ quand le moteur le permet. N’écrasez pas une architecture Multi-AZ pour sauver du transfert — placez des conversations, pas la disponibilité, dans une seule AZ.
Vérifiez que le trafic intra-région utilise l’adressage privé. Les connexions vers l’IP publique d’un pair, ou vers un nom d’hôte public qui résout hors du VPC, se facturent en transfert régional. Le DNS privé sur les points de terminaison et le routage par appairage VPC ou Transit Gateway gardent tout sur le chemin gratuit ou bon marché.
Mettez CloudFront devant la sortie Internet quand le contenu se répète. Le transfert origine-vers-CloudFront est gratuit; les tarifs de sortie CloudFront et les succès de cache battent tous deux la sortie brute au Go pour le contenu statique et semi-statique.
Compressez et regroupez ce qui doit traverser un compteur. gzip sur les réponses d’API, flux de réplication compressés, expédition de journaux agrégée. Ennuyant, efficace, et ça se cumule avec tout ce qui précède.
Revisitez un NAT Gateway par AZ contre un par VPC. Un NAT partagé économise les frais horaires mais ajoute du traitement inter-AZ pour le trafic des autres AZ; des NAT par AZ coûtent plus d’heures mais gardent le trafic local. Les comptes à haut volume gagnent généralement avec un par AZ.

Quand c’est le mauvais choix

Ne poursuivez pas des cennes de transfert jusque dans la dette architecturale : écraser les AZ, retirer les répliques ou éteindre la réplication de relève inter-régions économise du transfert et vend la résilience. Si la ligne de bande passante est dominée par du vrai trafic produit — des clients qui téléchargent ce que vous leur vendez — c’est du coût des marchandises, et le travail relève de l’économie de CDN, pas de l’élimination. Et sous quelques centaines de dollars de transfert par mois, la prolifération de points de terminaison et la complexité de routage peuvent coûter plus en temps d’ingénierie qu’elles ne rapportent.

Erreurs courantes

Blâmer les « coûts S3 » pour ce qui est en fait du traitement NAT sur le chemin vers S3.
Ajouter un point de terminaison d’interface là où un point de terminaison passerelle gratuit existe (S3, DynamoDB) et le payer à l’heure.
Mesurer seulement DataTransfer-Out et manquer que les lignes régionales sont comptées dans les deux directions.
Tester depuis un sous-réseau public, ne voir aucuns frais NAT, et conclure que la production (en sous-réseaux privés) se comporte pareil.

Garder le contrôle

Une alarme CloudWatch sur les octets du NAT Gateway attrape les nouvelles charges bavardes en quelques jours plutôt qu’à la facture.
Des points de terminaison passerelle dans chaque gabarit de VPC par défaut — ça ne coûte rien et ça prévient la régression classique.
Une allocation de coûts par étiquettes pour que les lignes de transfert s’attribuent aux équipes; la bande passante anonyme ne se fait jamais corriger.
Revoyez les types d’utilisation de transfert chaque trimestre; les nouveaux services et les nouvelles AZ ajoutent des chemins en silence.
Mettez « quel compteur ce flux traverse-t-il? » dans la revue de conception de toute intégration service-à-service.

Les frais de bande passante sont l’exemple le plus clair d’AWS qui facture le chemin plutôt que le travail — une fois les trois compteurs nommés, la facture cesse d’être mystérieuse. Si personne dans votre équipe ne possède vraiment l’environnement AWS de bout en bout, c’est la racine de la plupart de ces problèmes — Stack Harbor opère des comptes AWS au quotidien sous Opérations AWS, et vous pouvez réserver une revue AWS.