Un des enjeux premiers en matière de FinOps, consiste à être en mesure de calculer, projeter, anticiper les coûts dans le cadre, par exemple, d’une migration ou du déploiement d’une nouvelle infrastructure ou application dans le Cloud. Cette première étape « budgétaire » est souvent essentielle à la validation même du projet, à la maîtrise des options qui sont prises dans la conception et l’architecture, et enfin à la maîtrise des coûts sur tout le cycle de vie du projet. Alors Certes, à petite échelle, vous avez toujours la possibilité d’utiliser « AWS Simple Monthly Calculator » qui sera progressivement remplacé par « AWS Pricing Calculator ». Cependant, cette démarche est limitée , et peut rapidement devenir longue, fastidieuse et source d’erreurs si vous devez établir une estimation non pas sur quelques éléments de service et d’infrastructure unitaires (quelques instances EC2, RDS, …), mais sur plusieurs centaines ou milliers d’entre-eux, et avec potentiellement le besoin de comparer plusieurs scenarii ou hypothèses. C’est là qu’il peut s’avérer utile de recourir notamment à l’AWS Price List API depuis une application, une lambda ou un script, pour réaliser ces opérations de calcul des coûts sur la base de données en masse. Je vous propose donc de découvrir les principes et le fonctionnement de cette API, au travers de l’exemple d’un projet de migration de bases de données vers les services AWS RDS (Relational Database Service).
Un rapide aperçu des outils web mis à disposition « en ligne » par AWS
Je vous invite à jeter un œil sur ces outils notamment si vous avez besoin de vous familiariser avec les éléments sur lesquels s’appuie la facturation des services AWS. C’est une méthode efficace pour s’approprier tous les éléments qui interviennent dans la facturation des différents services tels que les plans de souscription, les unités, les mécanismes et les éventuels seuils ou limites.
AWS Simple Monthly Calculator
Il s’agit de la calculette en ligne historique d’AWS. Elle dispose d’une interface assez intuitive bien qu’un peu désuète, et de quelques exemples.
AWS Pricing Calculator
AWS pricing calculator est le successeur officiel de l’AWS Simple Monthly Calculator. Il doit apporter une nouvelle ergonomie, de nouvelles fonctionnalités, plus de services et d’options.
Principe général de l’AWS Price List API
l’AWS Price List API permet de récupérer dynamiquement les informations tarifaires associées aux différents services AWS selon différentes options générales et d’autres propres à ces services. Cette API supporte différentes méthodes, nous allons explorer dans la suite de cet article la méthode « BULK ».
Dans notre cas, la Price List sera récupérée en 2 ou 3 étapes successives :
- une première étape qui consiste à récupérer le fichier d’index des offres AWS, « l’Offer Index File ». C’est un fichier JSON chapeau, qui décline pour chaque Offre AWS l’emplacement des fichiers propres à l’offre en question.
- une deuxième étape qui consiste donc, à partir de « l’Offer Index File » à récupérer soit le fichier de l’offre toutes régions AWS confondues (1 fichier de 111 Mo dans le cas de l’offre RDS à date, contre 7 Mo pour l’offre RDS sur eu-west-1(Irelande)), soit à récupérer le fichier d’index des régions de l’offre (toutes les offres n’étant pas forcément proposées sur toutes les régions) pour ensuite récupérer la « price list » de l’offre dans la région précise qui nous intéresse.
Fichier de l’offre RDS toutes régions confondues
Fichier d’index des régions de l’offre RDS pour notre exemple :
- Une éventuelle troisième étape qui consiste à récupérer le fichier de l’offre pour la région ciblée.
Une fois que nous avons récupéré la Price list précise recherchée, dans notre cas celle concernant l’offre AWS RDS sur la région Irlandaise (eu-west-1), il faut encore comprendre sa structure et comment l’exploiter.
La Price List est principalement composée de 2 parties :
- la description des produits introduits par la clé « products » et référencés par « SKU »
- la présentation des prix introduite par la clé « terms »
Dans cette partie tarifaire, les différents modes de souscription apparaissent et son regroupés avec des clés telles que :
- « OnDemand »
- « Reserved »
Chaque offre tarifaire est susceptible de comporter plusieurs dimensions de coûts, les « priceDimensions ».
La partie des prix « terms » décline ainsi toute la grille tarifaire de l’offre, par type d’engagement (OnDemand ou Reserved), en référence aux produits « products » décrits au début du fichier d’offre par voie de référence au « SKU » de l’offre.
Les différents plans de tarification comportent des prix unitaires « Upfront » et/ou des prix récurrents ex : « Hrs ». Les offres « réservées » comportent des informations importantes dans la clé « termAttributes » (ex : la durée d’engagement).
AWS met à disposition une documentation complète sur l’interprétation des fichiers d’Offre.
Comment Exploiter cette API ?
AWS met à disposition de très nombreux Outils, Kits, SDK pour permettre au plus grand nombre de concevoir ses propres outils pour répondre à ses besoins spécifiques. Je vous propose ici d’explorer le SDK pour Python qui est un excellent moyen de découvrir facilement et efficacement le fonctionnement et les possibilités offertes par les API AWS.
AWS SDK pour Python
Boto est le SDK AWS spécialement conçu pour le langage de script Python. L’utilisation de ce SDK simplifie énormément le développement des scripts qui peuvent dès lors s’affranchir des tâches de bas niveau telles que l’authentification, ou encore le formatage des requêtes.
Boto dispose d’une documentation complète et de modèles de scripts pour faciliter la prise en main du SDK.
Conception Générale du Script d’estimation budgétaire
La conception du script final peut dépendre de beaucoup de choses, et notamment du format et de l’origine des données qui sont fournies en entrée, ou encore de ce qui est attendu en sortie. Typiquement, les scripts susceptibles d’être utilisés dans les projets d’étude avant migration varient beaucoup en fonction des données à partir desquelles nous devons construire les scenarii de migration. Le script de pricing est susceptible d’intervenir après une succession d’autres traitements de données en provenance d’inventaires, d’outils de supervision et de métrologie, d’exports multiples. Ces données pour être complètes auront probablement besoin d’être croisées, enrichies et corrigées pour comporter les informations requises. Enfin les données entrantes devront être particulièrement adaptées aux services AWS visés. En effet les informations qui participent à choisir une offre RDS ou une offre EC2 sont différentes, même si certaines sont communes. Bref, difficile de parvenir à concevoir des scripts tout-terrain.
Néanmoins, dans le cadre de notre exemple, le principe général du script peut consister à :
- rechercher sur la base d’un fichier CSV en entrée, les offres RDS qui correspondent aux bases de données existantes (Moteur de base de données, version, sizing/gabarit de ressources, haute-disponibilité, licensing, type de stockage et capacité de stockage …)
- dans la région AWS choisie
- en s’appuyant sur les dernières informations « up-to-date » en termes d’offres RDS et de Prix
- et en proposant le cas échéants les différents choix et options se rapprochant le plus du besoin.
Un point essentiel est de bien pouvoir faire varier les paramètres du script sur la base des mêmes jeux de données afin de pouvoir comparer différentes options et hypothèses.
Le script devient à ce moment là un vrai outil d’aide à la décision.
Obtenir les résultats
Pour ma part, j’utilise un script qui s’inscrit dans une succession d’autres scripts qui produisent le format d’entrée standard dont j’ai besoin pour réaliser des estimations budgétaires spécifiques. En effet, nous avons besoin d’informations différentes selon que l’on souhaite projeter des coûts AWS RDS ou AWS EC2.
Pour rester conforme à notre exemple, ici le script est appelé avec un fichier d’entrées et des paramètres qui précisent l’offre, la région, le mode d’engagement et de licensing à appliquer. C’est un choix de conception pour optimiser le traitement. Quoi qu’il en soit, il y a d’autres façons de procéder. Enfin le résultat produit en sortie standard est redirigée vers un fichier CSV. C’est ce fichier CSV qui va ensuite être manipulé dans Excel, Calc ou PowerBI par exemple pour produire les scenarii et résultats attendus.
/usr/bin/python3 /home/sgautier/Nextcloud/DIGITNEOS/Scripting/AWS/Pricing/aws_pricing.py --offer AmazonRDS --region eu-west-1 --terms OnDemand --licenseModel 'License included' --input ../../Ligoj/list_server_db_inScope2.csv > results.csvExploitation des résultats
Les données produites par le script de pricing ont toutes les chances de devoir être revues et manipulées avant de parvenir au scénario définitif du projet.
Pour manipuler ces données, plusieurs options simples et efficaces à envisager en fonction notamment des besoins, du volume et des échéances :
- Tableaux croisés dynamiques (MS Excel, LibreOffice Calc, …)
- Business Intelligence (Pentaho, PowerBI, Tableau, BIRT, BO, …)
Ici, un simple tableau croisé dynamique fera l’affaire.
Estimation budgétaire mensuelle sur la base des choix établis
Sur la base d’arbitrages réalisés à partir des éléments proposés dans le fichier résultant de l’exécution du script, il convient d’établir un ou plusieurs scenarii. Ces scenarii permettent de se projeter efficacement sur les coûts mensuels à terme, comme dans l’exemple ici, d’un projet de migration et/ou de transformation.
Les hypothèses de coûts peuvent être manipulées ici en ajustant les tailles d’instances ou les choix de versions ou d’éditions des bases de données. D’autres choix, qui consistent par exemple à consolider plusieurs bases de données au sein d’instances mutualisées qu’on appelle alors « hotels de base de données », peuvent être envisagés. Bref, il y a d’autres critères susceptibles d’intervenir dans les hypothèses et scenarii de coûts, qui peuvent être d’ordre « opérationnel », liés aux règles de sécurité, à la conception des architectures ou encore à des contraintes de performance. Et à chaque projet, son jeu de contraintes et d’exigences.
Une fois ces réglages opérés nous sommes en mesure d’afficher les coûts du projet et leur décomposition. Dès lors, il est possible d’établir la baseline qui servira à suivre l’évolution de ces coûts, et de rentrer dans les étapes suivantes du cycle de vie FinOps, qui consisteront essentiellement à les optimiser.
Versatilité des hypothèses et des options
Tout l’intérêt d’adresser cette estimation budgétaire au travers de scripts ou d’outils interfacés avec les API AWS, c’est le fait de pouvoir les modifier, les ajuster et les rejouer autant que nécessaire, et mettre à jour systématiquement les données. Les hypothèses et les pistes ont toutes les chances d’être multiples en début de projet. De plus elles ont toutes les chances d’évoluer pendant le projet. C’est donc une vraie garantie d’efficacité pour faire face à ces variations et évolutions de manière sereine.