La Facturation chez AWS - Part I : Le déploiement

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.

Les notions de base 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. VPC avec :
2. Deux sous-réseaux publics dans les zones de disponibilité A et B,
3. Quatre sous-réseaux privés dans la zone A et B,
4. Des tables de routage,
5. Des groupes de sécurité,
6. Une internet Gateway attachée au VPC,
7. Une NatGateway attachée au VPC,
8. Deux instances EC2,
9. Deux Volumes EBS attachés à nos instances EC2,
10. Une instance RDS multi zones pour la réplication Master/Slave et la haute disponibilité,
11. Un load balancer applicatif ALB,
12. Un DNS route 53 pour notre application,
13. Un groupe Amazon AutoScaling,
14. Un bucket S3 pour le stockage objets,
15. Et enfin, des rôles IAM qui gèrent les accès aux différents services AWS. ici

1- Architecture proposée

Préliminaires

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.

Amazon VPC

Commençant par créer notre VPC qui a :

• Une internet gateway,
• Deux sous-réseaux privés pour les instances EC2,
• Deux sous-réseaux privés pour les instances RDS,
• Deux  sous-réseaux publics pour le load balancer,
• Des tables de routages et leurs règles pour router le trafic entre les deux sous-réseaux  et vers l'extérieur de notre VPC,
• Ainsi, des groupes de sécurité et leurs règles pour gérer l'accès aux bases de données, aux serveurs EC2, et au load balancer,
• Et enfin un point de terminaison VPC qui me permet d'accéder directement au bucket S3, à partir de mon VPC sans passer par la NatGateway ou internet.

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 :

• Le coût horaire de la NatGateway,
• Les Frais de traitement de données par la NatGateway,
• Les Frais de transfert de données sortantes.

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.

Amazon EC2

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

Bonus pour les curieux :

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:

• Tous les frais initiaux: vous payez en une seule fois pour toute la durée de la réservation.
• Frais initiaux partiels: vous payez un premier coût initial, puis vous payez un tarif horaire réduit pour la durée de la réservation.
• Aucuns frais initiaux: vous payez un tarif horaire réduit (moins important) pour la durée de la réservation.

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.

Amazon EBS

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 :

• Le chiffrement de données stockées sur les volumes n'a pas d'impact sur le prix de base. Que ce soit un disque chiffré ou pas, vous payez le même prix.
• En cas de chiffrement avec une clé KMS, vous payez la clé si et seulement si vous choisissez de la créer.

Amazon RDS

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.

Bonus pour les curieux :

• Si j'avais pris une instance RDS mono AZ ayant la même configuration, je paierais environ 110.37$ par mois. En revanche, mon choix permet d'avoir une haute disponibilité de ma base de données,
• Si j'avais pris une instance RDS à la demande je paierais 319.67$ par mois, à configuration identique.
• Pour les RDS RI, vous avez aussi trois options de paiement comme les instances EC2 RI.

Amazon S3

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 :

• S3 Standard : idéale pour les données fréquemment consultées en multi-zones,
• S3 Standard Infrequent Access : idéale pour stocker les données non fréquemment consultées en multi-zones aussi,
• S3 One Zone Infrequent access : comme le précédent mais pour une seule zone.
• Amazon Glacier : est conçu pour l'archivage de données en multi-zones.

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 :

• SSE-S3 : Amazon S3 gère vos clés,
• SSE-C : vous gérez vos clés,
• KMS (Key Management System).

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 :

• le nombre de Giga-Octets consommés sur AMAZON S3,
• les opérations effectuées sur vos données (par tranche de 1000) : Demandes PUT, COPY, POST, GET.
• vos opérations S3 Select,
• le volume de données extraites,
• le transfert de données sortantes depuis le bucket S3 vers internet.

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

Bonus pour les curieux :

• AWS S3 est facturé à l'heure. Une heure partielle est facturée comme une heure complète.
• Pour S3 Standard/ S3 One Zone – Accès peu fréquent la taille minimale de facturation est de 128 ko. Un objet fait moins que ça, sera facturé pour 128 ko de stockage.
• Pour S3 Standard – Infrequent Access, l'extraction de données est facturés pour le nombre de  Giga-Octets extrait.
• Le chiffrement de données stockées sur S3 n'a pas d'impact, vous payez le même prix de base pour les données non chiffrées.
• Pour AWS S3 standard ou AWS Glacier, les objets supprimés avant 30 ou 90 jours respectivement de leurs création, impliquent des frais pour le nombre de jours restants.
• Les requêtes de type DELETE sont gratuites sur AWS.

Amazon Load Balancing

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 :

• Nouvelles connexions par seconde,
• Connexions actives par minute,
• Bande passante Mbit/sec,
• Évaluations de règles.

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 :

• 30 nouvelles connexions par seconde.
• Durée de connexion 1 minute.
• 100 requêtes par seconde.
• 50 Go de data traités par mois.
• 10 Règles appliquées

Pour calculer FactureALB = FactureALB unit + FactureLCU = 25.48 $ par mois

Bonus pour les curieux :

• Les load balancers sont facturés à l'heure. Une heure d'utilisation partielle est facturée comme une heure entière,
• Les load balancers classiques sont facturés en fonction de la bande passante et de l'utilisation horaire. Il n'y a pas de notion de LCU,
• Pour les LCU, seule la dimension la plus utilisée est facturée pour chaque unité consommée.

Amazon Route 53

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.

Bonus pour les curieux :

• Le health-check pour le load balancer est gratuit chez AWS. Si mon point de terminaison est une instance EC2, je paierais 0.5$ par mois en plus,
• Une zone hébergée est facturée au moment de son installation, puis vous continuez à payer au début des mois suivants.

Amazon Auto Sacling

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

Bonus pour les curieux:

• AMAZON AUTOSCALING par défaut, démarre des instances à la demande, vous pouvez le configurer pour lancer des instances Spot afin de réduire les coûts.

Amazon IAM

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

Trafic Réseau

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

Bonus pour les curieux :

• Dans l'application, si j'avais permis aux utilisateurs de télécharger les fichiers directement à partir du bucket S3, je paierais le volume de données sortantes pour ce service aussi,
• Le transfert de données entre deux instances EC2 de la méme AZ est gratuit. Cependant, il est facturé entre deux AZ différentes.

Et au Final, combien ça me coûte ?

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.

Conclusion

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.