Dans les modèles d'architectures composés de plusieurs comptes/VPC, la mise en place d'un compte dédié aux services partagés est une pratique courante.
Une des ressources que l'on mutualise souvent en suivant ce modèle est la NAT Gateway. Cela permet aux serveurs EC2 hébergés dans les subnets privés des autres comptes d'accéder à internet via un point de sortie unique.
Mais est-ce toujours une bonne idée d'un point de vue financier? Ne vaut-il pas mieux déployer la ou les NAT Gateway directement sur le compte où se trouvent les EC2? Nous allons calculer tout ça.
Un peu d'architecture pour commencer
Il s'agit de comparer les coûts de deux architectures.
La première n'implique qu'un seul compte AWS dans lequel sont déployés les EC2 et les Nat Gateway.
La seconde implique deux comptes AWS, un compte "source" dans lequel se trouvent les EC2 et un compte partagé dans lequel sont déployées les Nat Gateway.
Pour connecter des VPC entre eux, il est nécessaire de déployer une Transit Gateway. Cela entraîne des coûts supplémentaires fixes (dû au déploiement d'un attachement par VPC) et variables (en fonction du volume de données passant à travers la Transit Gateway).
L'objectif est donc de savoir si le montant à payer pour atteindre notre Nat Gateway partagée est plus élevé que le coût de notre Nat Gateway elle même si elle était déployée sur le compte source.
Données de départ
Tous les coûts sont ceux de la région Paris
Coût fixe d'une Nat Gateway: 36$/mois
Coût fixe d'un rattachement à une Transit Gateway: 43$/mois
Coût du transit à travers une Transit Gateway: 0.02$/GB
On néglige le coût fixe de la Nat Gateway du compte de services partagés car il serait répartit entre plusieurs comptes
En cas de déploiement d'une ou plusieurs Nat Gateway dans le compte source on suppose que le routage permet d'éviter le trafic inter AZ.
On suppose que si on héberge les Nat Gateway dans le compte source, il n'y a pas besoin de rattachement à la Transit Gateway pour un autre besoin.
Scénario 1: Nous sommes sur une seule AZ
C'est un cas de figure assez rare sur le cloud mais si nous n'utilisons qu'une seule AZ, le calcul est très simple car le coût fixe d'une Nat Gateway est inférieur au coût d'un attachement à une Transit Gateway. Il est donc toujours plus intéressant financièrement d'avoir une Nat Gateway directement dans le compte source.
Scénario 2: Nous sommes sur 2 AZs
Afin d'éviter le traffic inter AZ, c'est une bonne pratique de déployer une Nat Gateway par AZ. A partir de 2 Nat Gateway déployées le coût est supérieur à l'attachement à la Transit Gateway.
Dans ce cas de figure, on cherche à déterminer à partir de quel volume de données à destination de la Nat Gateway, il vaut mieux rester sur le compte source.
Ainsi nous prenons le coût total de nos 2 Nat Gateway ( 2 x 36$ ) auquel on soustrait le coût du rattachement à la Transit Gateway ( 43$ ) car on suppose qu'il ne sera pas nécessaire.
Enfin on divise le tout par le coût du transit à travers la Transit Gateway ( 0,02$/GB ). Ce qui donne:
En conclusion, d'un point de vue financier et pour un déploiement sur 2 AZs, si le volume de données passant à travers la Nat Gateway est:
inférieur à 1,45 To / mois il est plus intéressant de déployer la Nat Gateway dans le compte partagé
supérieur à 1,45 To / mois il vaut mieux déployer la Nat Gateway dans le compte source
Ce n'est pas forcément qu'une question de coûts
Quelques soient les coûts, avoir les Nat Gateway dans un compte partagé apporte d'autres avantages:
Un point de sortie central permet de simplifier le contrôle des flux sortant en déployant un Network Firewall en amont par exemple.
Cela permet d'éviter de déployer des subnets publiques dans les comptes sources si ce n'est pas nécessaire et donc de réduire la surface d'attaque.
Cela peut également simplifier la gestion opérationnelle en réduisant le nombre de ressources déployées.
Comments