Faites passer le trafic S3 et DynamoDB par des Gateway endpoints gratuits, placez les appels d'API AWS volumineux derrière des Interface endpoints, et réservez la NAT Gateway au trafic qui sort réellement d'AWS : c'est la répartition correcte côté coûts. Une NAT Gateway facture à l'heure, puis à nouveau chaque gigaoctet traité : le trafic AWS vers AWS qui la traverse paie un détour inutile. Les endpoints VPC gardent ce trafic sur le réseau AWS, souvent pour bien moins cher, parfois pour rien.
Pourquoi la ligne NAT Gateway grossit-elle si vite ?
Une NAT Gateway a une double forme de coût : un montant horaire fixe pour exister, plus un coût de traitement sur chaque gigaoctet qui la traverse. La partie horaire est prévisible et modeste. La partie au gigaoctet suit le trafic : la ligne grossit donc avec votre charge de travail, pas avec votre architecture.
Multipliez par une passerelle par zone de disponibilité pour la haute disponibilité, et ajoutez que le traitement se facture dans les deux sens. Les tarifs exacts figurent sur la page de tarification VPC officielle ; c'est la forme qui compte ici. Tout ce qui déplace du volume à travers la NAT Gateway (sauvegardes, lectures analytiques, pulls d'images de conteneurs) est compté gigaoctet par gigaoctet.
Le piège classique : des sous-réseaux privés qui appellent S3 via NAT
Le piège ressemble à ceci : une fonction Lambda ou une tâche ECS dans un sous-réseau privé lit depuis S3 ou DynamoDB, et la table de routage envoie ce trafic à travers la NAT Gateway. Chaque gigaoctet est compté, alors que la destination est un service AWS qui n'a jamais eu besoin de NAT.
Cela s'installe sans bruit. Un module Terraform copié câble les sous-réseaux privés vers une NAT Gateway, les charges de travail s'y déploient, et le trafic S3 suit la route par défaut. Rien ne casse, la latence reste bonne, et le seul symptôme est une ligne de facture. Les pipelines gourmands en données aggravent le tout : un job analytique qui lit des téraoctets depuis S3 via NAT paie le traitement sur chaque octet, sans aucun bénéfice fonctionnel.
Quel endpoint VPC remplace quel trafic ?
Les Gateway endpoints couvrent exactement deux services, S3 et DynamoDB, et ne coûtent rien : pas de montant horaire, pas de coût au gigaoctet, juste une entrée dans vos tables de routage. Les Interface endpoints (AWS PrivateLink) couvrent la plupart des autres API AWS, avec un coût horaire par endpoint et par zone de disponibilité, plus un tarif au gigaoctet bien inférieur au traitement NAT.
Un Gateway endpoint s'ajoute en quelques minutes et ne mérite aucun débat : pour S3 et DynamoDB, il devrait être le réflexe dans chaque VPC. Les Interface endpoints méritent un rapide calcul. Pour les services bavards ou volumineux (ECR, CloudWatch Logs, SQS, Secrets Manager), l'économie au gigaoctet écrase le coût horaire ; pour un service appelé rarement, le montant horaire par AZ peut dépasser ce que la NAT aurait facturé. Vérifiez les volumes avant d'en ajouter un par service.
Vous vous demandez quelle part de votre facture NAT n'est que du trafic S3 ? Décrivez votre système : diagnostic d'une page sous 48 h.
Recevoir mon diagnostic →NAT Gateway vs VPC endpoints : le face-à-face
La décision n'est pas exclusive. Un VPC de production bien construit finit généralement avec des Gateway endpoints pour S3 et DynamoDB, une courte liste d'Interface endpoints pour ses API AWS les plus sollicitées, et un chemin NAT conservé pour la vraie sortie internet. Voici où chaque option gagne.
| NAT Gateway | Gateway endpoint | Interface endpoint | |
|---|---|---|---|
| Quel trafic | Tout le sortant : internet, API tierces, endpoints publics AWS | S3 et DynamoDB uniquement | La plupart des API AWS (ECR, SQS, CloudWatch, Secrets Manager...) |
| Forme de coût | Horaire par passerelle + au Go traité | Gratuit | Horaire par endpoint et par AZ + au Go, sous le tarif NAT |
| Effort de mise en place | Une passerelle par AZ, routes par défaut | Une entrée de table de routage | Une ENI par AZ et par service, DNS privé |
| Quand il gagne | Vraie sortie internet sans alternative AWS | Toujours, pour ces deux services | Volume d'API AWS soutenu, ou exigence de connectivité privée |
Quand la NAT Gateway reste-t-elle nécessaire ?
Gardez une NAT Gateway quand des charges privées ont vraiment besoin d'internet : API tierces, prestataires de paiement, webhooks sortants, miroirs de paquets, SaaS externes. Les endpoints VPC n'atteignent que des services AWS et les offres PrivateLink publiées explicitement par un fournisseur ; ce trafic n'a donc pas d'alternative.
L'objectif est de réduire la NAT Gateway, pas de la supprimer. Une fois que les endpoints absorbent le trafic à destination d'AWS, il ne reste en général qu'un mince filet d'appels d'API, et le coût au gigaoctet cesse de peser. Certaines équipes gardent aussi la NAT pour des services AWS encore sans endpoint ; cette liste rétrécit chaque année, cela vaut la peine de revérifier avant de s'y résigner.
Vos Lambdas ont-elles seulement besoin d'un VPC ?
Souvent, non. Une fonction Lambda n'a besoin d'être rattachée à un VPC que pour joindre des ressources qui y vivent : RDS, ElastiCache, load balancers internes. Une fonction qui ne parle qu'à S3, DynamoDB et des API HTTPS externes tourne sans aucune configuration VPC et les joint directement : pas de tables de routage, pas de NAT, pas d'endpoints.
Nous voyons régulièrement des fonctions rattachées à un VPC « pour la sécurité » alors que rien de ce qu'elles appellent n'y vit : elles héritent d'une dépendance NAT et la paient sur le trafic de chaque invocation. La documentation Lambda sur les VPC est explicite : le rattachement sert à joindre des ressources privées, ce n'est pas une mesure de durcissement. Avant d'acheter des endpoints pour une stack pleine de Lambdas, posez cette question préalable, et consultez nos bonnes pratiques Lambda pour le reste de la liste.
Comment voir les dégâts dans Cost Explorer ?
Ouvrez Cost Explorer, groupez par type d'usage et cherchez NatGateway-Bytes : c'est le compteur de traitement de données. Son jumeau NatGateway-Hours est la partie fixe. Quand Bytes écrase Hours, votre argent part dans le trafic, et les endpoints sont en général le remède.
Deux choses masquent le signal. Les coûts NAT apparaissent sous le service « EC2-Other » dans Cost Explorer : une vue par service les enterre. Et le type d'usage dit combien, pas quoi : activez les VPC Flow Logs sur l'interface réseau de la NAT Gateway et vérifiez si les principales destinations correspondent aux listes de préfixes S3 ou DynamoDB. Si oui, le correctif est une entrée de table de routage gratuite. C'est la première vérification que nous menons dans une revue d'architecture.
Check-list de décision
- Des sous-réseaux privés qui joignent S3 ou DynamoDB ? Ajoutez les Gateway endpoints maintenant : gratuit, fait en quelques minutes.
NatGateway-Bytesqui domineNatGateway-Hours? Tracez les principales destinations avec les VPC Flow Logs.- Gros trafic d'API AWS (ECR, CloudWatch Logs, SQS) ? Comparez un Interface endpoint au coût NAT au gigaoctet.
- Des Lambdas dans un VPC sans dépendance interne au VPC ? Détachez-les.
- Une vraie sortie internet subsiste ? Gardez la NAT Gateway pour cela, dimensionnée délibérément.