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 :
Architecture proposée
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 :
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 :
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 :
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
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 :
suivant, et vous payez le même prix qu'avant la suppression.
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 :
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 :
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 :
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 :
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 :
FactureCloudWatch = 0
Bonus :
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 :
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
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
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.