Elle n'est pas sur la facture. Pas en tant que « NAT Gateway », en tout cas. Elle est sous EC2-Other, un type d'usage appelé NatGateway-Hours à côté d'un autre appelé NatGateway-Bytes, et dans la vue par défaut de Cost Explorer elle est repliée dans la ligne EC2, ce qui explique qu'une équipe qui ne fait tourner aucune instance EC2 puisse regarder une charge EC2 de 100 $ et supposer que c'est une erreur.
Ce n'est pas une erreur. C'est 0,045 $ de l'heure, chaque heure, pour chaque NAT gateway que vous avez, avant qu'un seul octet ne la traverse, plus 0,045 $ pour chaque gigaoctet qui passe. Sur la facture à trois comptes que nous avons publiée, c'était 13 % du total, plus que Lambda, DynamoDB et WAF réunis, pour un composant qui ne fait rien d'autre que laisser les choses privées atteindre Internet. Cet article explique pourquoi vous l'avez, et comment nous sommes passés de trois à une.
Pourquoi vous avez une NAT gateway
Parce que quelque chose est dans un sous-réseau privé. Les sous-réseaux privés n'ont pas de route vers l'internet gateway, exprès : rien sur Internet ne peut les atteindre. Le prix, c'est qu'ils ne peuvent pas non plus atteindre Internet, et « Internet » inclut les points de terminaison des API AWS, donc une Lambda dans un sous-réseau privé ne peut pas appeler S3, Secrets Manager ou SQS sans une porte de sortie. La porte de sortie est une NAT gateway dans un sous-réseau public, avec une route depuis les sous-réseaux privés vers elle.
Notre raison, c'était Aurora. La base de données est dans un sous-réseau privé, correctement. Les Lambdas qui lui parlent doivent être dans le VPC pour l'atteindre. Une fois dans le VPC, elles ont besoin du NAT pour tout le reste de ce qu'elles font : récupérer un secret, poser un message dans une file, appeler une API tierce. Une seule exigence, l'accès à la base, a tiré une douzaine de fonctions dans le VPC et un NAT dans chaque compte.
Ce que ça nous a réellement coûté
Trois comptes, un NAT chacun, une zone de disponibilité chacun (nous avions délibérément évité un par AZ, ce qui aurait triplé le coût) :
| Heures | Octets | Mensuel | |
|---|---|---|---|
| prod | 33 $ | ~60 Go × 0,045 $ = 3 $ | 36 $ |
| staging | 33 $ | ~5 Go | 33 $ |
| dev | 33 $ | ~10 Go | 33 $ |
| Total | 102 $ |
Remarquez la forme. C'est presque entièrement la charge horaire. Les octets ne sont rien, parce que l'essentiel de ce qui passe par le NAT, ce sont de petits appels d'API. Donc le conseil habituel, « réduisez le traitement de données de votre NAT », nous aurait fait économiser trois dollars. Le levier, c'est le nombre.
Cinq façons d'en avoir besoin de moins
1. Des gateway endpoints pour S3 et DynamoDB. Gratuits. Un gateway endpoint est une entrée de table de routage qui envoie le trafic vers S3 ou DynamoDB par le réseau d'AWS au lieu de sortir et revenir. Ça ne coûte rien, c'est deux lignes de CDK, et ça devrait être dans chaque VPC dès le premier jour, NAT ou pas. Ça a retiré environ la moitié de nos octets NAT, ce qui valait 1,50 $. Faites-le quand même ; la raison, c'est la latence et le fait de ne pas payer d'egress pour le trafic S3, pas le NAT.
vpc.addGatewayEndpoint('S3', { service: ec2.GatewayVpcEndpointAwsService.S3 });
vpc.addGatewayEndpoint('DynamoDB', { service: ec2.GatewayVpcEndpointAwsService.DYNAMODB });
2. Des interface endpoints pour les services que vous appelez vraiment. 7,30 $ par mois chacun. Un interface endpoint est une interface réseau dans votre sous-réseau avec une IP privée pour un service AWS : Secrets Manager, SQS, ECR, CloudWatch Logs, STS. Chacun coûte environ 7,30 $ par mois plus 0,01 $ par gigaoctet. L'arithmétique : un endpoint ne se rentabilise que s'il vous permet de retirer un NAT, ou si vous poussez plus d'environ 700 Go par mois à travers. Cinq endpoints pour couvrir tout ce que nos Lambdas appellent, c'est 37 $, plus que le NAT qu'ils remplaceraient. Donc nous les utilisons à exactement un endroit, ci-dessous.
3. Sortez du VPC. C'est le gros levier. Une Lambda n'a besoin d'être dans le VPC que si elle parle à quelque chose qui n'est joignable que là. Nous avons audité la douzaine de fonctions : sept parlaient à Aurora, cinq non. Les cinq étaient dans le VPC parce que le construct CDK avait vpc: défini par défaut dans notre fabrique de fonctions. Les sortir du VPC a pris un drapeau et les a retirées complètement de la liste des clients du NAT. Une Lambda hors VPC atteint les API AWS directement, gratuitement, et démarre plus vite.
Pour les sept qui ont besoin d'Aurora, il y a une option supplémentaire que nous évaluons : RDS Data API, qui permet à une fonction hors VPC d'interroger un cluster Aurora en HTTPS. Ça change le pilote, donc ce n'est pas un drapeau, mais ça viderait entièrement le VPC de Lambdas.
4. N'en mettez pas en dev. Le NAT de l'environnement de dev existait pour que les Lambdas de dev puissent atteindre Internet. Après l'étape 3, les seules choses dans les sous-réseaux privés de dev qui avaient besoin d'Internet étaient les sept fonctions de base de données qui récupèrent des secrets et postent dans des files. Deux interface endpoints, Secrets Manager et SQS, à 15 $ par mois, ont remplacé un NAT à 33 $, et les appels d'API tierces en dev (il n'y en a pas ; ils sont simulés) n'ont plus eu besoin d'aucun chemin. Le staging a reçu le même traitement.
5. Une instance NAT là où vous avez vraiment besoin d'un egress bon marché. Si le dev avait eu besoin d'un accès Internet général, la réponse est une instance NAT plutôt qu'une NAT gateway : une t4g.nano faisant tourner l'image open source fck-nat coûte environ 3 $ par mois, gère quelques centaines de mégabits, et c'est un bon compromis pour un environnement hors production où un point de défaillance unique est acceptable. Nous n'en avions pas besoin, mais c'est le bon outil pour le cas « j'ai besoin d'un NAT mais pas d'un NAT à 33 $ ». Jamais en production.
Il y en a une sixième qui ne s'applique que si vous pouvez passer en IPv6 seul : une egress-only internet gateway est gratuite et fait pour IPv6 ce qu'un NAT fait pour IPv4. La plupart des API tierces ne sont pas encore joignables en IPv6, donc ce n'était pas une option pour nous.
Où nous avons fini
| Avant | Après | Mensuel | |
|---|---|---|---|
| prod | 1 NAT gateway | 1 NAT gateway + gateway endpoints S3/DynamoDB | 36 $ → 36 $ |
| staging | 1 NAT gateway | interface endpoints Secrets Manager + SQS, pas de NAT | 33 $ → 15 $ |
| dev | 1 NAT gateway | interface endpoints Secrets Manager + SQS, pas de NAT | 33 $ → 15 $ |
| Lambdas dans le VPC | 12 | 7 | |
| Total | 102 $ | 66 $ |
La production garde son NAT : elle appelle des API tierces, elle a besoin d'un vrai chemin, et 36 $ pour un composant managé, capable de multi-AZ, sans maintenance, c'est correct. L'économie est de 36 $ par mois, ce qui paraît peu jusqu'à ce qu'on remarque que c'est 5 % de toute la facture, que ça a pris un après-midi, et que le même après-midi a fait démarrer cinq Lambdas plus vite.
La règle pour les nouveautés
Avant qu'une nouvelle fonction ou un nouveau service n'entre dans un sous-réseau privé, il doit répondre à une question dans la pull request : à quoi, dans le sous-réseau privé, parle-t-il ? Si la réponse est « à rien », il n'y entre pas. Si la réponse est « à la base de données », il y entre et la liste des endpoints dont il a besoin est fournie. Si la réponse est « il a besoin d'Internet », alors soit c'est la production, soit c'est une discussion de conception.
La NAT gateway n'est pas un mauvais produit. C'est un produit dont il est facile d'avoir trois exemplaires sans l'avoir décidé. Comptez les vôtres.
Si votre ligne EC2-Other est plus grosse que votre ligne EC2, nous pouvons vous dire pourquoi en un après-midi.