Si on met à part les services managés facturés à l'usage, aujourd'hui le marché du Cloud computing propose trois types de facturation : à l'heure (OVH, AWS hors services IaaS et les instances Windows), à la minute (GCP hors services IaaS , Microsoft Azure), et à la seconde (AWS, GCP, Outscale depuis 2016).
Cet article a pour but d'introduire certaines bases fondamentales pour comprendre la facturation sur AWS. Pour simplifier la compréhension, je prends l'exemple d'une architecture Wordpress hébergée chez AWS, en vous expliquant les différents choix technologiques, leurs impacts respectifs, et quelques bonnes pratiques pour l'utilisation des fonctionnalités AWS.
Afin de mieux comprendre, il est nécessaire d'avoir les notions de bases AWS (VPC, EC2, EBS, S3, IAM), que vous trouverez en détails dans chaque étape de construction suivante :
L'architecture proposée est composée de :
1- Architecture proposée
Dans le cadre de cet article, la facture est calculée pour un mois d'utilisation des services AWS, sans prise en compte du niveau d'offres gratuites (à retrouver en détail ici). Il s'agit d'un environnement de production. La plateforme est localisée sur la région eu-west-1 (Irlande). Le VPC est divisé en deux sous-réseaux situés sur deux zones de disponibilités, A et B. Par la suite, je vous expliquerai chaque étape de construction ainsi que les frais appliqués pour chaque service consommé. Pour ce faire, je définis comme suit un ensemble de variables afin de faciliter le calcul de la facture finale : FactureFinale=0, FactureVPC=0, FactureEC2=0, etc.
Chaque section suivra le plan suivant : une introduction expliquant le choix technique de chaque composant, un rappel sur la facturation de chaque service, et enfin des infos complémentaires pour les curieux.
Commençant par créer notre VPC qui a :
Tout ce qu'on a créé pour l'instant a l'avantage d'être gratuit. AWS ne facture pas la création d'un VPC, mais les autres services qui se basent dessus sont payants. Exemple : NatGateway, connexion VPN, Direct connect.
Pour calculer FactureVPC = 0 dollars/mois.
Afin de mettre en place l'application, les instances EC2 ont besoin d'accéder à internet sans être exposées au public. Je crée une NatGateway dans le VPC, et je l'attache aux sous-réseaux publics. Je crée également les règles de routage qui vont avec (pour indiquer la sortie internet en passant par la NatGateway) pour les deux sous-réseaux privés EC2.
Pour la facturation, selon les prix de chaque région, vous payez :
Je précise que dans la configuration précédente, la NatGateway est utilisée seulement pour les opérations effectuées sur les serveurs EC2 (installer les différents services, les mises à jours). Je pose le postulat qu'elle est, en moyenne, utilisée 24 heures/mois pour transférer environ 10 Go de données sortantes.
Pour calculer FactureNatGateway = 2,45$ par mois.
Je lance deux instances (une instance dans chaque sous réseau privé) de type m4.large ayant Amazon Linux comme OS. Pour rappel, AWS propose principalement quatre méthodes de paiement pour ce service : les instances à la demande, les instances spot (système d'enchères), les instances réservées (les RI) et les hôtes dédiés.
La formule de facturation varie selon : la région AWS (eu-west-1, us-east-1...), la méthode de paiement, le type d'instance choisi (t2, m4...), et le système d'exploitation utilisé (Amazon Linux, redhat, Windows...).
Pour optimiser les coûts de l'infrastructure, je prends des RI (Reserved Instances). Ces instances sont payées à l'avance et ont l'avantage d'être moins chères dans la durée (1 ou 3 ans d'engagement minimum) par rapport aux instances à la demande. De plus, on a la garantie d'avoir toujours la capacité demandée disponible, contrairement aux instances spot qui sont adaptées plutôt aux environnements de développement et de tests. Je ne prends pas non plus d'hôtes dédiés, car mon application n'est pas critique et je n'ai pas besoin d'avoir une isolation physique par rapport aux autres clients. Cela peut être plus intéressant pour des environnements critiques comme les banques, assurances par exemple.
Amazon Linux est fourni par AWS à titre gratuit. Je paie seulement les frais d'utilisation des deux instances RI m4.large appliqués pour la région eu-west-1 . Les instances RI sont payées de manière récurrente et je considère seulement un mois d'utilisation.
Pour calculer FactureEC2 = Prix d'une m4.large/mois x 2 = 110.38$ par mois
Si j'avais pris des instances à la demande, pour la même configuration, je paierais 162.52$ par mois.
Si j'avais pris une instance m4.xlarge (4 cpu, 16gb), qui a la même capacité que mes deux instances ensemble, je paierais le même prix de 110.38$. Par contre, pour la haute disponibilité du service, je choisis la première solution.
Si vous arrêtez votre instance à la demande ou dédiée, vous continuez à payer le stockage (pour le boot disque et les disques attachés), et les frais d'allocations du serveur physique pour les hôtes dédiés.
Si vous lancez une instance Windows, vous êtes facturé à l'heure et pas la seconde comme les instances Linux. Cela veut dire qu'une heure partielle est considérée comme une heure complète sur votre facture.
Pour les RI et puisqu'il s'agit d'une ressource réservée et avec facturation récurrente, les actions Stop, start, terminate ne changent rien sur la facturation.
Quand vous achetez une RI, vous avez le choix entre trois options de paiement:
Si vous choisissez un engagement RI de trois ans, vous risquez de ne pas pouvoir bénéficier des baisses de tarifs réguliers pendant cette période.
Je crée deux volumes GP2 de 50 Go et je les attache aux deux instances EC2. Pour rappel, AWS propose deux grandes familles de volumes : les volumes basés sur SSD ( GP2, SSD à usage général et IO1, SSD avec des IOPS provisionnés) et les volumes basés sur HDD ( ST1, HDD à débit optimisé et SC1, dit aussi Cold HDD).
Pour la facturation, sur l'ensemble des types mentionnés et en fonction de la région, vous payez les Giga-Octets de données consommés par mois (calculés au prorata du nombre de nombre de secondes, 60 secondes minimum). Et dans le cas d'un volume IO1, vous payez également le nombre d'IOPs réservés par mois.
Pour calculer FactureEBS = prix d'un Go de GP2 x 50Go x 2 = 11$ par mois.
Bonus pour les curieux :
Pour la base de données, j'utilise une instance AMAZON RDS multi-AZ, un master et un slave. En ce qui concerne la configuration de chaque instance, je prends une db.m4.large avec PostgreSQL comme moteur de données et un stockage SSD GP2 de 100 Go. Comme précédemment, cette instance est une RI et je considère seulement 1 mois de facturation.
AMAZON RDS est un service managé. Autrement dit, c'est un service qui se base sur les autres services AWS principalement EC2, EBS, plus le moteur de données géré par AWS. Vous payez selon la région le prix du type de l'instance RDS choisi, l'option (mono/multi-AZ), la taille et le type de stockage et potentiellement un coût relatif au licence du moteur DB.
Pour calculer FactureRDS = 125.40$ par mois.
Pour stocker les fichiers (documents, images ), j'utilise un bucket AWS S3 standard. Le service AWS S3 propose quatre classes pour le stockage d'objets :
L'analyse et le traitement de données sur S3 (coté serveur) est possible grâce à S3 Select , et aussi avec les services Athena et Redshift Spectrum. Le chiffrement de données est aussi possible via :
Il existe aussi d'autres services pour mieux gérer vos objets comme: le versionning, la gestion de cycle de vie de données et aussi le contrôle d'accès grâce aux ACL.
Vous payez, par mois et selon la région et la classe de stockage choisis :
Afin de pouvoir calculer la facture, je considère les valeurs de consommation moyennes suivantes : 100 Go de stockage consommés par mois et 2000 requêtes standard exécutées sur le bucket. Seules les instances EC2 ont l'accès au bucket S3. Cela veut dire, qu'il n'y a pas de transfert de données sortantes à partir du bucket, je reviendrai plus tard sur ce point.
Pour calculer FactureS3 = prix de l'espace consommé + prix de 2000 requêtes = 2.32$ par mois
Un load balancer applicatif (ALB) va me servir de point d'entrée de l'application pour les utilisateurs. Il répartit aussi le trafic entrant entre les deux serveurs EC2 pour plus de disponibilité du service.
Auparavant, AWS proposait uniquement le Classic load balancer , qui est un équilibreur de charge entre les instances EC2. Il fonctionne sur deux niveaux : requête (couche 7) et connexion (couche 4). Les deux autres types dérivant, Application load balancer (niveau requête) et Network load balancer (niveau connexion) fournissent une répartition de charge entre plusieurs destinations qui peuvent être des instances EC2, des conteneurs ou des adresses IP.
Selon le type et la région de ce dernier, vous êtes facturé à l'heure d'utilisation de l'ALB, et le nombre de LCU (unités de capacité d'équilibrage de charge) consommées. Une LCU contient quatre dimensions :
Pour plus de détails, je vous invite à regarder la documentation AWS ici https://aws.amazon.com/fr/elasticloadbalancing/pricing/.
Afin de calculer la facture FactureALB , je considère les consommations moyennes suivantes :
Pour calculer FactureALB = FactureALB unit + FactureLCU = 25.48 $ par mois
Pour que les utilisateurs puissent accéder à l'application, j'ai besoin d'exposer un nom de domaine public. AMAZON ROUTE 53 me permet de créer un nom DNS pour acheminer les utilisateurs vers l'application. J'attache ce DNS à mon load balancer, qui est le point d'entrée/sortie de l'application.
Pour la facturation, vous payez, à l'heure et par région, le nombre de zones couvertes par ROUTE 53, le nombre de requêtes traitées par lot de 1 million/mois, le nombre de healthcheck consommés, ainsi que le TLD choisi qui est facturé par an.
Prenant le nom de domaine : www.monapplication.fr. Selon la liste des prix Ici, pour un TLD ".fr" je payerai 12$ par an, 1$ par mois d'allocation. Pour le reste de la facture, je n'ai qu'une seule zone hébergée, en moyenne 1 million de requêtes standard par mois et dix health check basiques sur AWS.
Pour calculer FactureROUTE53 = FactureZONE + FactureDNS = 3.20$ par mois.
Je définis un groupe autoscaling qui permet, au besoin, de lancer d'autres instances EC2 afin de maintenir les performances de mon application en cas de fortes demandes.
La configuration des groupes AUTO SCALING est gratuite chez AWS. Seules les ressources qui sont lancées par le service sont payantes.
Pour simplifier le calcul de la facture, je considère que la configuration mise en place est suffisante pour maintenir le service. De ce fait, le groupe autoscaling ne démarre aucune nouvelle instance EC2. Pour l'instant, je me limite juste à sa configuration.
Pour calculer FactureAUTOSCALING = 0$ par mois
Je mets en place un rôle IAM avec deux policies attachées pour protéger les données de l'application. Une policy qui permet l'accès au bucket S3, et une deuxième pour permettre l'accès aux instances RDS. Seules les instances EC2 peuvent assumer ce rôle, et elles peuvent accéder au bucket S3 et aux instances RDS.
AMAZON IAM fait aussi partie des services gratuits chez AWS. Toute configuration de rôle et leur affectation est gratuite.
Pour calculer FactureIAM = 0$ par mois
Une fois que la plateforme est mise en service, les utilisateurs commencent à utiliser l'application. Sur la configuration précédemment définie, le load balancer est le seul point d'entrée et de sortie de données de l'application. Autrement dit, c'est le seul point où on peut avoir du trafic entrant/sortant.
Le transfert de données entrantes est gratuit sur l'ensemble des services Amazon Web Services. AWS ne facture que le transfert de données sortantes: vers internet, vers un autre service AWS, ou vers une autre zone de disponibilité/région AWS. Selon la région, le service et la cible, vous payez les Giga-Octets transférés par mois.
Pour simplifier le calcul de la FactureTRAFIC, je considère la valeur moyenne de 100Go de données sortantes par mois. Pour l'instant, il n'y a que les instances EC2 qui génèrent ce trafic en passant par l'ALB. Aussi, je ne prends pas en considération le trafic entre les deux AZ (A et B) vu qu'il n'est pas important dans l'exemple précédent (au pire ça rajoute quelques centimes sur la facture).
Pour calculer FactureTRAFIC = 8.91 $ par mois
Calculons maintenant le coût mensuelle de cette infrastructure :
FactureFINALE = FactureEC2 + FactureNatGateway + FactureEBS + FactureRDS + FactureS3 + FactureALB + FactureROUTE53 + FactureTRAFFIC = 289.14$ par mois.
Les prix sont calculés à l'aide de l'outil AWS Calculateur. Pour plus de détails sur les prix, je vous invite à regarder la documentation officielle AWS.
Dans cet article, l'objectif était de vous présenter une introduction pour comprendre les bases de fonctionnement du système de facturation AWS. J'ai donné l'exemple d'une architecture Wordpress simplifiée pour expliquer les différents points-clés qui jouent sur la facture. Les montants mentionnés et les calculs restent approximatifs et relatifs à la volumétrie consommée.
Le coût total peut paraître plus cher par rapport à une solution on-premise. Cette dernière a l'avantage de vous permettre de garder le contrôle intégral de vos données. Cependant, le coût de la gestion n'est pas négligeable. Il faut assurer la disponibilité de la plateforme, fiabiliser son réseau, la sécuriser et la faire évoluer dans le temps. Il faut aussi compter le temps nécessaire pour mettre en place la configuration précédente (Wordpress en l'occurrence) ainsi que le personnel impliqué.
Dans une solution cloud public, la gestion de l'infrastructure est la responsabilité du cloud provider. Il s'engage à assurer la disponibilité de son service et de le faire évoluer. Ainsi, vous vous focalisez sur l'optimisation de votre architecture applicative et son administration.
Finalement, une solution on premise ou cloud public, il n'y a pas qu'une seule réponse, c'est à l'entreprise de se poser les bonnes questions pour choisir sa meilleure solution en fonction de ses besoins.