La Facturation chez AWS - Part II : L'administration

Part 2: Administration

Après avoir présenté dans le premier article la facturation chez AWS, j'aborde dans cet article la deuxième partie concernant les coûts d'administration d'une infrastructure, en utilisant les outils proposés par AWS.

Dans le premier article je prenais comme exemple la mise en place d'une plateforme WordPress sur AWS, en expliquant les différentes étapes pour déployer l'infrastructure de base ainsi que les éléments qui entrent en jeu pour estimer le coût mensuel de cette plateforme.

Dans cet article sous le thème "Administration" je présente d'autres bases fondamentales pour comprendre la facturation chez AWS. Je reprends le même exemple (architecture WordPress) que je fais évoluer au fur et à mesure, en vous expliquant les différents choix technologiques et en vous donnant quelques astuces et bonnes pratiques.

Je note que les préliminaires sont les mêmes que ceux présentés dans le premier article. Et les coûts sont estimés sur la région eu-west-1 (Irlande).

Les évolutions proposées comprennent/respectent les aspects suivants :

• Accès à la plateforme pour les admins : une instances EC2 avec une EIP.
• Installation et configuration de l'application : Amazon EFS.
• Chiffrement de données : KMS et VPC KMS endpoint.
• Sauvegarde de la configuration et des données : AMI et Snapshots.
• Supervision et logs : CloudWatch.
• Automatisation : CloudFormation.

                             Architecture proposée

Accès administrateur :

AMAZON EIP (Elastic IP) :
J'ai besoin de sécuriser mon infrastructure en limitant les accès (SSH) directs depuis l'extérieur. Pour cela, je mets en place un bastion qui constitue le point d'entrée à l'infra et j'autorise seulement certaines adresses ip publiques spécifiques. Le bastion forward les connexions SSH vers le réseau privé. Ce dernier est configuré de manière à accepter seulement les flux venant du bastion. De cette façon, je contrôle mieux les accès à la plateforme. Il existe bien évidemment d'autres façon plus fiables et aussi plus complexe pour sécuriser les accès, comme la mise en oeuvre d'un serveur VPN qui fait le relai SSH.

Je lance une instance EC2 t2.nano On-Demand. Je ne gère pas sa résilience dans le cadre de cet article, c'est pour cela que je suis resté sur une instance à faible coût. Puis je lui attache une EIP pour l'accès depuis l'extérieur. L'instance a les paramètres suivants :

• Le premier subnet public.
• L'adresse IP publique EIP (Elastic IP).
• Un SG qui accepte les connexions SSH venant de certaines adresses IP depuis l'extérieur.

Pour la facturation EC2, j'ai expliqué précédemment comment ça marche ici, je vais calculer le coût mensuel directement:

FactureInstanceEC2=  4.62$/Mois
Pour les EIP, elles ne sont facturées que si :

• Elles ne sont attachées à aucune instance.
• Elles sont attachées à une instance qui n'est pas démarrée.
• Pour chaque EIP supplémentaire attachée à une même instance.

Dans mon cas, l'EIP est attachée et utilisée par le bastion. Il n'y a pas eu un événement de réassociation (re-map) à une autre instance. Donc je ne paie aucun frais supplémentaire.  Je paie seulement l'instance EC2 que j'ai lancé.

FacutreEIP = 0$

FactureBastion = FactureInstanceEC2 = 4.62$/Mois

Bonus pour les curieux :

• Les opérations allocate/deallocate address ne sont pas facturées chez AWS.
• Les 100 premières opérations de réassociation sont gratuites sur AWS. En revanche, au-delà de 100, vous serez facturés.
• Il est préférable pour le bastion d'utiliser une EIP au lieu d'une IP classique. Cela vous permet de garder une adresse IP et un DNS fixe. En cas de remplacement ou perte de la VM, vous pouvez les ré-attacher à nouveau sans changer votre configuration.

Installation et Configuration de l'application 

Amazon EFS (Elastic File System)

Je rajoute un partage EFS entre les serveurs web pour ne pas dupliquer l'application et sa configuration sur chaque instance. Je fais le montage en suivant la procédure Amazon et je crée l'entrée dans fstab. J'utilise aussi le chiffrement KMS afin de protéger les secrets qui sont présents dans les fichiers de configuration.

J'installe ensuite les prérequis pour que l'application tourne, et enfin je customise la configuration du serveur avant de créer l'AMI.

Amazon par défaut propose des EFS avec un débit de base de 50 Ko/s par Go inclus dans le prix du stockage. Il existe aussi Amazon EFS à débit alloué, qui vous permet d'allouer plus de capacité.

Selon la région, vous payez les giga octets consommés par mois *(60 secondes minimum)*, plus le débit alloué si vous l'avez réservé.

Mon EFS fait 40 Mo de taille et je suppose que sa taille reste fixe tout le mois. Pour calculer son coût, je suis la formule suivante:

FactureEFS = 40Mo * 0,33$ /1024 = 0.012$/mois

Sauvegarde

Snapshots RDS :

Quand vous créez une base de données RDS, Amazon vous propose par défaut une sauvegarde automatique par jour. Vous pouvez toujours modifier cette configuration et l'adapter à vos besoins. Amazon RDS repose sur des volumes EBS pour la base de données et le stockage de journal.

Le snapshot RDS sauvegarde l'intégralité des données réelles de la base ainsi que ses métadonnées (ce n'est pas un simple dump). Cela vous permet de lancer une nouvelle instance RDS à partir du snapshot. En revanche, dans les  snapshots EBS, seules les données réelles de votre volume EBS sont sauvegardées. Notons que ces derniers sont stockés sur Amazon S3, vous nn'y avez accès directement.

Dans le cas général, Amazon vous facture sur la taille réelle des données sauvegardées. Pour les snapshots incrémentaux, seuls les blocs modifiés après le dernier snapshot sont pris en compte et facturés.

En fonction de la région, vous payez les gigaoctets de données consommés par mois (quel que soit le nombre de snapshots).

Pour les snapshots RDS, quel que soit le type du moteur de données (mono ou multi-AZ), si la taille des sauvegardes ne dépasse pas la capacité allouée dans la région, vous n'êtes pas facturés, c'est le cas de la plupart des clients selon AWS. Sinon, vous êtes facturés à 0,095$ Go/mois pour les sauvegardes supplémentaires (qui dépassent la taille de la capacité allouée), ou pour les sauvegardes qui restent sur votre compte après la suppression de l'instance.

J'ai 100Mo d'entrées en moyenne par jour, sur 30 jours j'aurais environ 3Go, qui ne dépasse pas les 100Go de disques que j'ai alloué précédemment (db.m4.large).

FactureSnapshotRDS = 0$/mois

Bonus :

• Si vous supprimez le snapshot référant, les données seront transférées sur le

suivant, et vous payez le même prix qu'avant la suppression.

• Les snapshots partagés sont facturés sur le compte source.
• La copie de snapshot dans la même région, pour le même compte n'entraîne pas de frais supplémentaires.
• Quand vous copiez des snapshots chiffrés, et si vous changez la clé KMS, cela recopie intégralement le snapshot et implique des nouveaux coûts de stockage.
• Les calls API de création, de partage ou de suppression de snapshot ne sont pas facturés.

AMAZON AMI (Amazon Machine Image)

Je crée une image AMI basée sur un volume EBS. J'utilise cette AMI dans la configuration de lancement pour le groupe auto-scaling et aussi dans le script de déploiement automatique de l'infrastructure avec CloudFormation *(infra-as-code)*.  Cela permet d'avoir un déploiement rapide et sécurisé.

Amazon vous propose deux types d'images :

• Basée sur Amazon EBS : (CreateImage): lors de la création, Amazon EC2 créé des snapshots sur le volume racine ainsi que les volumes EBS attachés à cette instance. Vous obtenez une AMI et un snapshot du volume racine. L'image AMI sera utilisée pour démarrer d'autres nouvelles instances.
• Basé sur le stockage d'instance : (RegisterImage): en utilisant les outils AWS, vous créez d'abord un bundle qui contient un groupe de fichiers, un manifeste d'image (image.manifest.xml) et des fichiers (image.part.xx) contenant un modèle pour le volume racine ainsi que les volumes attachés. Après, vous chargez le bundle dans un bucket Amazon S3, puis vous enregistrez votre AMI.

Il y a une différence significative entre les deux types d'AMI, je vous invite à regarder ici pour plus de détails.

Pour la facturation, selon le type de l'AMI et la région, vous payez là, sa taille en giga-octets de données consommés par mois.

J'utilise une AMI basée EBS, la taille de l'image fait environ 5Go. Elle est fixe pour le mois de calcul. Je rappel que 0.05 est le prix par Go-mois de données stockées pour les snapshots en région d'Irlande.

FactureAMI = 0,05$ * 5 = 0.25$/mois

Bonus :

• Les AMIs basées Amazon EBS sont créées à partir de snapshots EBS. Pour les mise-à-jour seuls les blocs modifiés, sont enregistrés et facturés.
• Par contre, pour les AMIs basées sur le stockage d'instance, pour chaque modification, tous les blocs sont recopiés et facturés intégralement.
• Quand vous lancez une instance à partir d'une AMI basée EBS, vous êtes facturés sur l'utilisation de l'instance, le volume racine EBS et l'AMI.
• En revanche, si vous lancez une instance à partir d'une AMI basée sur le stockage d'instance, vous êtes facturés seulement sur l'utilisation de l'instance et le stockage utilisé par l'AMI sur Amazon S3.
• Une AMI partagée est comme les snapshots, facturée sur le compte source.
• Les opérations API de création, de partage ou de suppression d'AMI ne sont pas facturées.
• Le chiffrement des AMI ou les snapshots n'as pas d'impacts sur le coût de stockage.

Chiffrement

AMAZON Key Management Service :

Je crée une clé CMK (Customer Master Key) sur KMS que j'utilise pour chiffrer le partage EFS comme indiqué précédemment. Je prends en option une rotation d'un an. Je crée le rôle IAM et je l'affecte aux deux serveurs web pour leur permettre d'utiliser cette clé.

AMAZON vous facture pour le nombre de CMK utilisés, créés directement sur KMS ou bien importés par vos soins, ainsi que pour la consommation de l'API KMS. Les prix sont les mêmes sur l'ensemble des régions AWS, sauf pour AWS GovCloud (USA).

Le chiffrement de données en général n'a pas d'impact sur le coût de stockage chez AWS (EFS, EBS, S3, RDS et autres). Reste à calculer le coût de l'utilisation du service KMS. Je prends en compte la clé CMK créée, plus le nombre d'opérations effectuées sur KMS, en prenant en compte l'utilisation du cache sur les VMs, j'ai environ 5.000.000 opérations de chiffrement/déchiffrement en moyenne par mois.

FactureKMS = 1 CMK + 5.000.000 opérations = 1$ + 15$ = 16$/mois

Bonus :

• Les clés CMK créées par AWS ne sont pas facturées. Ce sont des clés créées automatiquement quand vous chiffrer une ressource AWS dans un service pris en charge.
• Les clés CMK en cours de suppression ne sont pas facturées et vous avez 7 jours pour la période de réflexion avant que la clé soit supprimée définitivement.
• Si vous annulez la suppression de cette CMK pendant la période de réflexion, vous serez facturés comme si vous n'avez pas planifié sa résiliation.
• Les clés activées ou désactivées sont facturés dans les deux cas.
• La rotation KMS génère une nouvelle clé CMK et garde l'ancienne. Cette clé vous en sera facturée en plus de l'ancienne :).
• Il est préférable d'utiliser un point de terminaison VPC pour KMS. Cela évitera que vos instances dans votre VPC communiquent avec KMS sans passer par internet.
• L'utilisation du private link (VPC endpoint) implique des frais (par région) d'utilisation du service et de traitement de données; 0,011 $/heure d'utilisation, et 0,01$ Go/mois de données traitées sur la région d'Irlande. Si je considère 1 mois d'utilisation et 50Go de données traitées. Cela me rajoute environ 8.42$/mois par mois sur la FactureEndpointKMS.

Supervision et Logs

AMAZON CLOUDWATCH

Afin de superviser l'état de la plateforme, je crée des dashboards qui me donnent une vision globale sur l'état des ressources Cloud et les applications qui tournent, ainsi que des alarmes CloudWatch pour alerter en cas d'un comportement anormal. Les métriques me donnent une vision sur l'activité des utilisateurs et les alarmes me préviennent si une ressource est en incapacité de fonctionnement afin de réagir rapidement.

*pour des raisons de simplicité dans l'article, je considère que je n'ai pas eu besoin d'ajouter ou de remplacer des ressources dans mon scénario.*

Pour la facturation, selon la région, vous êtes facturés sur les services CloudWatch consommés :

La consommation de l'API CloudWatch :

• Le nombre de métriques demandées avec (GetMetricData).
• Le nombre de requêtes (GetMetricStatistics, ListMetrics, PutMetricData) et aussi pour les dashboards (GetDashboard, ListDashboards, PutDashboard et DeleteDashboards).

Les métriques (personnalisées incluses) utilisées par mois.

Le nombre de dashboards utilisé.

Le nombre d'alarmes configuré.

Le nombre d'événements déclenchés.

Et le volume des logs stockés par Go /mois.

Un autre élément important à prendre en considération, c'est les frais standards liés aux transfert de données sortantes depuis les journaux CloudWatch. Ils sont appliqués de la même façon qu' AMAZON EC2.

Vous payez par région, le prix de chaque sous service CloudWatch utilisé (dashboard, alarme,etc ...).Dans ma configuration de la supervision, je suis resté sur le niveau gratuit offert par AWS ici. Dans ce niveau, vous pouvez avoir par mois :

• 3 dashboards, 50 métriques au maximum chacun.
• 10 alarmes.
• 5 Go pour l'ingestion et le stockage des archives.
• 1 million de demandes d'API.
• Métriques de surveillance de base d'une fréquence de 5 min (pas de limites sur le nombre selon AWS).
• 10 métriques de surveillance de base d'une fréquence de 1 min.

FactureCloudWatch = 0

Bonus :

• Il est un peu compliqué de calculer le coût exact de CloudWatch vu le nombre de paramètres et de variables à prendre en considération. Je vous donne un exemple de calcul afin de comprendre le mécanisme.

En partant sur cette configuration :

Custom metric :

5 aws ressources.

5 custom metrics per ressource (quinze au total).

Fréquence des datas pour les métriques (5 secondes).

Type d'alarme : Standard.

5 alarmes par ressource (quinze au total).

Pour les logs :

• 10 go de log ingéré.
• 10 go de log archivé.
• 10 dashboards.

Et trois alarmes pour chaque ressources : EC2 instances, Elastic Load Balancers, EBS Volumes, RDS DB instances, AutoScaling service.

Cette configuration me coûtera environ 71.86 $/mois

Automatisation

CloudFormation

AWS propose un service qui vous permet de faire ce qu'on appelle infra as code. Il vous permet de décrire votre infrastructure sous forme de code, et de la déployer d'une manière automatisée et sécurisée. Vous pouvez aussi dupliquer ce déploiement rapidement sur plusieurs environnements (dev, test, prod), ou d'autres régions AWS.

Après avoir préparé le modèle d'infrastructure, le schéma, les configurations, les services AWS à utiliser, j'automatise le déploiement avec AWS CloudFormation. Il s'agit d'écrire le script qui me permet de mettre en place les ressources AWS demandées avec leurs configurations.

AWS CloudFormation est un service gratuit sur AWS, vous ne payez que les ressources AWS lancées par la recette.

FactureCloudFormation = 0

Et au Final, quel est le coût ?

Il s'agit de calculer le montant total de cette évolution, plus le coût de l'infrastructure que j'ai calculé précédemment.

FactureAdministration = FactureBastion + FactureEFS + FactureSnapshotRDS +  FactureAMI  + FactureKMS + FactureEndpointKMS + FactureCloudWatch + FactureCloudFormation =   29.302$/Mois

FactureTotale = FactureInfrastructure + FactureAdministration ~= 319 $/Mois

Conclusion

Cet article continue dans la même optique pour expliquer les bases de fonctionnement du système de facturation AWS. J'ai couvert dans cette deuxième partie; sous la thématique "administration"; d'autres services qui permettent d'administrer une plateforme sur AWS sur les aspects suivants : accès à la plateforme, installation et configuration, chiffrement des données, sauvegarde des données, supervisions et logs et automatisation.

La conclusion qu'on peut tirer de ces deux articles, est que "les bons plans" ça existe aussi dans le cloud computing. En effet, comprendre les points-clés autour de la facturation nous permettra de mieux adapter nos pratiques quotidiennes, les raffiner en terme d'analyse et réalisation, afin de proposer des solutions adaptées et optimisées sur les plans fonctionnel et budgétaire à nos clients. Ce rôle aujourd'hui s'appelle "finOps".

J'espère que ces deux articles sur la facturation chez AWS , vous ont apporté des connaissances qui vous aideront à mieux comprendre vos factures chez AWS, ainsi que customiser vos choix de solution pour vos infrastructures sur AWS.