Unité 2.4 : Architecture des coûts et FinOps

Introduction

Le coût du cloud sur IONOS CLOUD n'est pas un problème de facturation à résoudre a posteriori ; c'est une propriété architecturale déterminée au moment de la conception, lorsque vous choisissez une classe de calcul, un niveau de stockage, une stratégie de mise à l'échelle et une durée d'engagement. Chacun de ces éléments constitue un levier, et leur impact varie considérablement : le choix lié à la concurrence pour le calcul peut faire varier la facture davantage que l'ensemble des ajustements effectués dans les tableaux de bord combinés. FinOps est donc, dans ce contexte, principalement une question d'architecture, surmontée d'une fine couche opérationnelle d'allocation et d'alertes. Cette unité examine les leviers par ordre d'impact, explique comment les Savings Plans permettent d'engager correctement les dépenses, et se termine par la création d'une garde-fou bien documentée, une alerte de coût, dans Data Center Designer.

1. Concurrence de calcul : le premier levier de coût

La décision de coût la plus importante est la manière dont une charge de travail partage le CPU physique. Compute Engine propose deux classes d'utilisation du CPU : les serveurs à cœurs dédiés, où le cœur est exclusif à la VM, et les serveurs à vCPU, où le cœur est partagé avec d'autres locataires. Les cœurs partagés sont moins coûteux et sont adaptés aux charges de travail intermittentes, tolérantes à la latence, ou non de production. Les cœurs exclusifs coûtent plus cher et sont adaptés lorsque les performances doivent être prévisibles ou lorsque l'isolation est en soi une exigence, ce qui est souvent le cas pour un environnement réglementé.

C'est ici que le surdimensionnement délibéré devient un coût de contrôle justifié plutôt qu'un gaspillage. Pour les hôtes réglementés dans le périmètre de FinCorp, l'unicité de locataire et les performances prévisibles sont des entrées de conformité et de risque, de sorte que le paiement pour des cœurs dédiés (et le provisionnement d'une marge au-dessus de la ligne de base mesurée) achète une isolation et une stabilité qu'une économie sur les cœurs partagés compromettrait. La discipline consiste à être délibéré : surdimensionner les hôtes qui portent des obligations de conformité ou de performance, et utiliser des cœurs partagés partout où la charge de travail tolère la concurrence. Notez également que VM Auto Scaling crée de nouvelles répliques à partir d'un modèle de réplique défini au moment de la conception, de sorte qu'une couche qui doit mettre à l'échelle automatiquement a sa forme de calcul par réplique, et donc son coût par réplique, fixée au moment de la conception, ce qui intègre la décision d'élasticité dans la décision de coût.

2. Hiérarchisation du stockage selon le modèle d'accès

Le coût du stockage est déterminé par l'alignement de la couche sur le modèle d'accès, et les trois couches de stockage bloc présentent des niveaux de prix sensiblement différents. Les prix publiés par Go et par mois sont les suivants :

Deux contraintes influencent le choix au-delà du prix. Premièrement, le seuil de performance des SSD : les volumes SSD Standard et SSD Premium nécessitent une taille minimale de 100 Go pour atteindre leurs performances maximales. Un volume SSD sous-dimensionné paie donc le prix d'un SSD sans fournir les performances d'un SSD, ce qui constitue une source de gaspillage courante et évitable sur les disques de bases de données. Deuxièmement, le stockage bloc n'est pas adapté aux données en masse ou d'archivage ; Object Storage est la couche appropriée pour les sauvegardes, les archives d'audit, les jeux de données et les données froides, et c'est là que se trouve l'archive Object-Lock de l'Unité 2.3. Le modèle consiste à placer les données chaudes et sensibles à la latence sur des SSD de taille appropriée, les données de capacité sur des HDD, et toutes les données en masse ou d'archivage sur Object Storage.

3. Mise à l'échelle verticale par rapport à la mise à l'échelle horizontale basée sur la mise en cache pour la couche de données

La couche de données présente une structure de coûts distinctive, car la plateforme ne dispose pas de répliques de lecture (Unité 1.3 et Module 5). Les deux méthodes pour gérer l'augmentation de la charge de lecture ont des économies très différentes. La mise à l'échelle verticale consiste à acquérir une instance de base de données plus grande, ce qui augmente un coût prévisible et permanent, et finit par atteindre des limites. La mise à l'échelle horizontale des lectures consiste à placer une mise en cache en mémoire devant la couche relationnelle et à absorber le trafic de lecture à cet endroit, ce qui est généralement beaucoup moins cher par lecture servie et protège la base de données contre un dimensionnement excessif destiné uniquement à gérer les pics de lecture. Pour la plupart des charges de travail de FinCorp axées sur la lecture, une base de données correctement dimensionnée associée à une couche de mise en cache coûte moins cher qu'une base de données constamment mise à l'échelle verticalement, et c'est également le seul chemin de mise à l'échelle horizontale de la lecture offert par la plateforme. La leçon en matière de coûts est de dimensionner la base de données selon ses besoins en écriture et en jeu de travail actif, et de laisser la mise en cache, plutôt qu'une instance plus grande, absorber la croissance des lectures.

4. Savings Plans : Engager le plancher correctement

Un Savings Plan est un engagement basé sur les ressources qui échange une durée fixe contre une réduction sur les serveurs Compute Engine Dedicated Core, les pools de nœuds Managed Kubernetes Dedicated Core et Nextcloud Workspace, couvrant les dimensions Cœurs et RAM (Go). L'économie est précise :

Plusieurs règles rendent cette approche sûre uniquement si vous les respectez. Un plan réserve de la facturation, pas de la capacité physique, il ne bloque donc jamais le provisionnement. Le dépassement est géré de manière fluide : l'utilisation au-delà de la quantité engagée est facturée au tarif standard PAYG, de sorte que le sur-engagement est le seul risque réel. Lorsque plusieurs plans couvrent le même produit, ils s'appliquent du plus ancien au plus récent (par ordre chronologique de création), et au sein d'un produit, la réduction s'applique d'abord à la VM la plus ancienne. La famille de CPU AMD Opteron est exclue. Un plan ne se renouvelle pas automatiquement, et seul le propriétaire du contrat peut en acheter un.

Le fait opérationnel le plus important est qu'un Savings Plan ne peut pas être modifié après activation ; le seul champ modifiable est le nom du plan, et il ne peut pas être annulé après l'achat. Cela fait de l'engagement une décision irréversible, et cela impose la discipline suivante : engager le plancher. N'engagez que la référence en régime permanent que vous êtes certain d'exécuter pendant toute la durée, prenez le dépassement PAYG pour tout ce qui est au-dessus, et allongez la durée uniquement pour la capacité dont vous êtes confiant qu'elle persistera pendant trois ans. S'engager de manière optimiste sur l'utilisation de pointe fige des dépenses que vous ne pouvez pas réduire ; engager le plancher capture la réduction sur l'utilisation garantie tout en laissant la charge variable sur le PAYG flexible.

5. Allocation, Showback et Chargeback

L'allocation des coûts s'appuie sur la structure décrite dans l'Unité 2.1. Comme chaque VDC génère déjà sa propre section sur la facture mensuelle, la hiérarchie contrat et VDC constitue l'axe principal d'allocation : un contrat regroupe un périmètre de gouvernance et de facturation, tandis que les VDC qui s'y trouvent séparent les environnements ou les projets en lignes de facture distinctes. La vue Cost & Usage dans le DCD est la surface d'analyse pour cela, et une API Cost & Usage existe pour alimenter les flux de facturation de manière programmatique.

L'allocation prend en charge deux modèles opérationnels. Showback signale à chaque équipe ou projet sa part des coûts, afin d'assurer la visibilité et la responsabilisation, sans mouvement de fonds. Chargeback facture effectivement les coûts à l'unité consommatrice. Showback est le point de départ le plus léger et est généralement suffisant pour modifier les comportements ; chargeback ajoute une contrainte financière, au prix d'un mécanisme de facturation plus complexe. Pour FinCorp, associer les VDC à des projets afin que chacun apparaisse sur sa propre ligne de facture permet d'obtenir immédiatement un showback propre, avec un chargeback ajouté ultérieurement si le service financier l'exige. (Considérez le tableau de bord et la navigation d'allocation comme la couche d'analyse ; la construction décrite ci-dessous est le garde-fou d'alerte sur les coûts, qui est le chemin de création bien documenté.)

Déroulement de la mise en œuvre de DCD

Vous allez créer une alerte de coût qui envoie un courriel à un destinataire lorsque les dépenses contractuelles dépassent un seuil budgétaire. Il s'agit de la seule configuration de coûts bien documentée ; c'est la garde-fou opérationnelle qui soutient les leviers architecturaux mentionnés précédemment. Le prérequis est l'accès en tant que propriétaire du contrat ou administrateur, car seuls ces rôles peuvent créer des alertes de coûts. Notez que l'alerte est définie au niveau du contrat (un montant et un courriel), de sorte que l'allocation entre les VDC relève d'une préoccupation de reporting gérée dans la vue Cost & Usage, et non dans l'alerte elle-même.

Objectif de la configuration : Créer une alerte de coûts par rapport à un seuil budgétaire.

Étapes (dans Data Center Designer) :

1. Accédez à Menu > Management > Cost alert. La fenêtre Cost alert s'ouvre ; cette vue liste également les alertes existantes.
2. Sélectionnez Create cost alert.
3. Dans la boîte de dialogue, saisissez le montant (le seuil de dépenses pour le contrat) et l'adresse courriel qui doit être notifiée.
4. Sélectionnez Create cost alert pour confirmer. L'alerte est désormais active et enverra un courriel au destinataire dès que les dépenses contractuelles dépasseront le seuil.

Erreurs courantes :

• S'attendre à ce que l'alerte limite ou arrête les dépenses. Elle ne fait que notifier ; c'est un déclencheur, et non une application stricte du budget. Les dépenses continuent au-delà du seuil.
• La configurer par VDC. L'alerte de coûts est au niveau du contrat (montant plus courriel) ; utilisez la vue Cost & Usage pour l'analyse et l'allocation par VDC.
• S'appuyer sur les alertes au lieu de l'architecture. L'alerte détecte les dérives ; ce sont les décisions relatives à la classe de calcul, à la couche de stockage et aux Savings Plan qui déterminent réellement la facture.
• Diriger l'alerte vers une boîte mail personnelle. Envoyez-la à une adresse finance ou opérations surveillée afin que la notification soit vue et traitée.

Modèle d'architecture

Une architecture de coûts FinCorp défendable hiérarchise les leviers selon leur impact. À la base, la classe de calcul est choisie par niveau : des cœurs dédiés pour les niveaux réglementés et à mise à l'échelle automatique (avec une marge de manœuvre délibérée en tant que coût de contrôle justifié), et des cœurs partagés pour les charges de travail tolérantes et non de production. Le stockage est hiérarchisé selon le motif d'accès, avec les volumes SSD maintenus à au moins 100 Go et les données en masse ou d'archivage sur Object Storage. La couche de données est dimensionnée pour les écritures et le jeu de travail, avec un cache en mémoire qui absorbe la croissance des lectures au lieu d'une base de données surdimensionnée. Au-dessus, un Savings Plan engage uniquement le plancher d'état stable des cœurs dédiés et de la RAM, sur une durée adaptée à la persistance réelle, en laissant le dépassement au-delà de ce plancher facturé au tarif PAYG. Au sommet, l'allocation associe les VDCs aux projets pour le showback, et une alerte de coûts au niveau du contrat fournit le déclencheur de dérive. À titre d'exemple chiffré, un niveau fonctionnant avec 32 cœurs dédiés stables coûterait environ 1,28 EUR par heure au tarif PAYG (32 x 0,04) ; l'engagement de ce plancher sur un plan de 3 ans ramène le coût des cœurs à environ 0,77 EUR par heure (32 x 0,024), soit une réduction de 40 % sur la ligne de base garantie, tandis que tout dépassement au-delà de 32 cœurs reste facturé au tarif PAYG.

Résumé

Le coût du cloud sur IONOS CLOUD est architecturé, et non simplement surveillé. La classe de concurrence de calcul est le levier le plus important, avec un surdimensionnement délibéré des hôtes concernés, justifié comme un coût de contrôle ; le stockage est hiérarchisé selon le modèle d'accès au sein du seuil de performance des SSD ; et la couche de données met à l'échelle les lectures via un cache plutôt qu'une instance surdimensionnée. Les Savings Plans capturent des remises de durée de 15 % (1 an) et 40 % (3 ans) sur les cœurs et la RAM dédiés, mais ne peuvent pas être modifiés après activation, ce qui impose de n'engager que le plancher certain et de prendre en charge le dépassement en mode PAYG. L'allocation s'appuie sur la structure contrat et VDC pour le showback ou le chargeback, et une alerte de coût au niveau du contrat fournit le déclencheur opérationnel intégré dans le DCD.

Points clés :

• La concurrence de calcul est le premier levier de coût : les cœurs partagés sont moins chers, les cœurs exclusifs (dédiés) achètent la prévisibilité et l'isolation ; la mise à l'échelle automatique fixe la forme de calcul de chaque réplique au moment de la conception, intégrant l'élasticité dans la décision de coût.
• Hiérarchiser le stockage selon le modèle d'accès : HDD 0,04, SSD Standard 0,07, SSD Premium 0,15 EUR/GB/mois ; maintenir les volumes SSD au ou au-dessus du seuil de pleine performance de 100 Go ; placer les données volumineuses et les archives sur Object Storage.
• Mettre à l'échelle les lectures de la couche de données avec un cache en mémoire, et non avec une base de données surdimensionnée, car il n'y a pas de répliques de lecture.
• Les Savings Plans offrent des remises de 15 % (1 an) et 40 % (3 ans) sur les cœurs et la RAM dédiés, le dépassement est facturé en mode PAYG, les plans s'appliquent du plus ancien au plus récent, et ils ne peuvent pas être modifiés après activation, il faut donc n'engager que le plancher certain.
• Allouer par contrat et par VDC (chaque VDC est déjà facturé comme une ligne distincte) ; choisir le showback ou le chargeback ; une alerte de coût au niveau du contrat (montant plus e-mail) est la garde-fou au moment de la construction et ne fait que notifier, elle ne limite pas les dépenses.

Terminologie importante :

• Classe d'utilisation du CPU : Indique si les cœurs d'un serveur sont exclusifs (Dedicated Core) ou partagés (vCPU) ; le levier principal de coût et de performance de calcul.
• Savings Plan : Un engagement de facturation de 1 an ou 3 ans basé sur les ressources pour les cœurs et la RAM dédiés, avec dépassement en mode PAYG, non modifiable après activation, et achetable uniquement par le propriétaire du contrat.
• Showback / Chargeback : Signaler à une équipe sa part de coût pour la responsabilisation (showback) par opposition à la facturation effective du coût à son encontre (chargeback).
• Alerte de coût : Un seuil au niveau du contrat (montant plus e-mail) qui notifie en cas de dépassement des dépenses ; il avertit mais ne limite pas.