Comment maîtriser l’évolution de sa facture Cloud au-delà de la mise en place de bonnes pratiques ? Nous avons vu dans les articles précédents les grandes lignes du FinOps et l’apport de ce concept dans la maîtrise de sa facture Cloud, puis les parties prenantes du FinOps dans l’entreprise. Dans ce troisième article, nous allons voir en détail les différents modèles de facturation proposés par les fournisseurs Cloud, ainsi que les avantages et inconvénients de chacun de ces modèles.

Le mode à la demande ( “On Demand”)

Le modèle de prix de base du cloud public est le “pay per use” : paiement à la consommation. J’active une machine virtuelle d’une certaine puissance, je paye pour cette machine jusqu’à ce qu’elle soit arrêtée. Ce qui veut dire que quand j’utilise une machine en heures ouvrées (8 x 5), je paye 4,2 fois moins cher qu’une machine qui est allumée en 24×7. 

Ce modèle de paiement à la consommation, se décline sur les différents services IaaS et PaaS. Ainsi pour une base NoSQL (DynamoDB), je vais payer principalement selon le nombre de requêtes en lecture et en écriture, l’espace de stockage requis, la volumétrie des sauvegardes et des restaurations, les replicas de tables, les flux de données avec ma base. 

L’implication principale du paiement à la consommation est que la valorisation du budget prévisionnel pour une application nécessite une connaissance très précise de ce workload. L’autre implication est qu’en général mes coûts vont varier tous les mois… en fonction de mon usage.

Autour de ce modèle de base, les fournisseurs de cloud développent des alternatives en fonction de vos exigences et de votre capacité à vous engager sur le long terme.

Si vous souhaitez avoir du matériel qui vous soit dédié (“dedicated hosts”) pour héberger vos workloads, vous allez payer plus cher que le modèle standard qui est partagé.

Le mode réservation de capacité (reserved capacity)

Si vous utilisez une capacité en 24×7 pendant plusieurs années, les fournisseurs vous proposent un modèle de “capacité réservée” (reserved capacity) qui va vous apporter des réductions significatives par rapport au modèle “à la demande” (on demand) surtout si vous ne souhaitez pas faire varier les caractéristiques de votre capacité : régions, famille, taille d’instances. 

Si vous n’avez pas une utilisation 24×7 de vos instances, mais une utilisation régulière qui se reproduit tous les jours, toutes les semaines ou tous les mois, le mode “instance réservée planifiée” (“scheduled reserved instance” ou “scheduled instance (SI)”) peut être utilisé. Attention ce mode est disponible dans un nombre de régions limité (en Irlande pour l’Europe) et il nécessite une utilisation minimum de 1 200 heures par an (la réservation se fait uniquement sur 1 an). Le gain par rapport à une facturation à la demande est compris entre 5 et 10%.

Ce modèle de réservation de capacité existe pour des services de machines virtuelles (EC2) mais également pour des services de bases de données SQL (RDS) et noSQL (DynamoDB) mais aussi pour des services de cache (Elasticache, CloudFront) ou le service d’entrepôt de données Redshift. Il implique un engagement sur 1 an ou 3 ans avec la possibilité d’effectuer un paiement en amont total, partiel ou nul.

Ce mode existe également sur Azure (Reserved Instances, Reservations) et sur Google Cloud  (Committed Use Discount). Google Cloud introduit un modèle additionnel sans besoin de souscrire ni de payer en amont : Sustained Use Discount qui vous fournit une réduction automatique (jusqu’à 35%) quand Google détecte une utilisation intensive d’une ressource sur un mois.

Le mode spot (spot instances et flotte d’instances spot)

Si vous avez des charges facilement “interruptibles et sans contraintes majeures de durée”, vous pouvez utilisez des “instances spot”, qui sont des instances “libres” du fournisseur qui sont mises aux enchères (les dernières évolutions du modèle de pricing n’impliquent plus nécessairement la définition d’un prix maximal : les prix étant largement stabilisés). Ces instances vous sont affectées temporairement et peuvent être réquisitionnées à tout moment, puis vous être ré-attribuées. Vous pouvez également demander des instances spot pour une durée déterminée (1, 2, 3, 4 ou 5 heures) à un prix fixe. Ces instances ne seront pas interrompues.

Le site AWS : Spot Instance Advisor fournit des informations détaillées sur le niveau de prix auquel peuvent être acquises les instances spots avec un degré de confiance sur le fait qu’elles vont ne pas être interrompues.

Encore plus intéressants, les flottes SPOT (SPOT fleets)… Avec les instances SPOT standard vous placez une enchère pour un type spécifique d’instance dans une zone de disponibilité (AZ) spécifique. Avec les flottes, vous pouvez demander différents types d’instances qui répondent à votre besoin sur différentes zones de disponibilité. Cela accroît largement vos chances d’obtenir des instances au prix désiré. Pour chaque type d’instances demandées, il est possible d’affecter un poids, afin d’indiquer la capacité totale souhaitée pour la flotte. La flotte tentera de maintenir cette capacité dans le cas de la terminaison de certaines instances. Cela permet également de construire des architectures haute disponibilité avec des instances spot ou en mêlant des instances spots et des instances on demand.

Certains services sont très propices pour l’utilisation d’instances Spot, par exemple SageMaker par rapport à l’apprentissage des modèles de Machine Learning au travers de la fonction “Managed Spot Training” mais aussi les charges containérisées ou des traitements Big Data ou des chaînes CI/CD…

Azure a un mode équivalent nommé “low priority VMs” qui est en cours de remplacement par les “Spot VMs” : le niveau de réduction est de l’ordre de 80%.

Côté Google, cette offre est nommée “Preemptible VM” et donne lieu à des économies jusqu’à 79% par rapport à des instances à la demande. 

Comparaison des différents modes

Le tableau ci-dessous synthétise ces différents modèles :

Le mode plan d’économies (Savings Plan)

AWS a développé un nouveau modèle depuis 2019 : les “plan d’économies” (Savings Plans). Ce modèle est du même type que la réservation de capacité mais beaucoup plus flexible et va donc vraisemblablement supplanter les réservations de capacité pour les services EC2. Il permet de s’engager sur un volume de ressources de calcul en $ par heure avec deux modes différents :

• Mode Compute Savings Plans qui permet d’être libre de la Région, de la famille, du type de système d’exploitation et de la tenancy sur lesquels on va dépenser notre volume de $.
• Mode EC2 Instance Savings Plans qui est plus spécifique d’une famille et d’une région.

La réduction va alors être définie en fonction de l’engagement et du niveau de paiement en amont (total, partiel ou aucun) et va s’appliquer sur le volume sur lequel on s’est engagé.

Le mode “réduction au volume” (volume discount)

Certains services comme AWS Data Transfer ou Amazon S3 donnent lieu à des prix dégressifs selon le volume. A noter, il est important d’utiliser une facturation consolidée (consolidated billing), car ainsi les volumes sur lesquels les réductions vont s’appliquer sont les volumes cumulés pour les différents comptes AWS de l’Organisation.

Le mode évaluation des services (Free Tier)

Le dernier modèle de facturation est le “Free Tier” : le principe général de ce modèle est de vous proposer gratuitement des services pendant une certaine durée pour que vous puissiez les évaluer :

• Ponctuellement (Trials) : par exemple, vous pouvez protégez vos comptes AWS et vos workloads avec Amazon Guard Duty pendant 30 jours.
• Pendant 12 mois après la création de votre Account AWS (12 months free) : par exemple, vous pouvez bénéficier de 750 heure d’ELB par mois.
• Continuellement (Always free) : par exemple, vous ne paierez pas le 1er million d’appel de vos lambdas.

Pour avoir plus de détail sur le Free Tier, on se référera à cette page. Ce modèle existe également sur Azure et Google Cloud.

Evolution des prix unitaires des services

Les prix unitaires des services (et les réductions via les plans d’économie ou les instances réservées) peuvent être différents selon les régions.

Pour les services EC2, il est important de basculer sur les nouveaux types d’instances afin de bénéficier de meilleurs rapport performances / prix.

Les prix unitaires peuvent évoluer de manière significative dans le temps (par exemple, le 21/01/2020, AWS a annoncé une réduction du prix unitaire du service EKS de 50%). On peut suivre l’évolution de ces prix en suivant le blog AWS.

Comparer un scénario cloud public par rapport à un scénario “on premise”

AWS propose un outil de TCO (Total Cost of Ownership) qui permet de comparer des coûts AWS par rapport à des solutions on premise. Cet outil est disponible sur la page : AWS Total Cost of Ownership (TCO) Calculators. Cet outil permet de générer un tableur qui peut être ensuite ajusté avec vos coûts unitaires “on premise”.

Les coûts des licences logicielles

Pour les licences logicielles, deux possibilités se présentent :

• Modèle Bring Your Own Licence (BYOL) : Utiliser des licences proposées par des contrats logiciels d’entreprise. Il faudra tout d’abord vérifier que vos contrats l’autorisent. Par exemple, Microsoft, fin 2019, a réduit drastiquement cette possibilité par rapport aux clouds Google, AWS afin de privilégier son modèle “Azure Hybrid Benefit”.
• Modèle “Licence Included” : Utiliser des licences fournies avec les services cloud AWS : par exemple l’utilisation d’images (AMI) Windows Server fournies par AWS pour vos EC2, ou les licences Microsoft SQL Server ou Oracle fournies avec RDS.

L’utilisation des contrats d’entreprise (mode BYOL) peut amener des réductions de coûts significatives mais doit être validée avec l’éditeur.

Dans le prochain article de notre série consacré au FinOps, nous verrons les différentes étapes du cycle de vie financier d’une application Cloud.