Optimisation des coûts cloud : une revue mensuelle des charges de travail

L’optimisation des coûts cloud consiste à réduire les dépenses évitables tout en maintenant les performances, la fiabilité et la sécurité requises. Pour un service déjà en production, elle commence par deux questions : qu’est-ce qui a changé sur la facture, et le travail fourni a-t-il changé lui aussi ?

Une revue mensuelle permet aux équipes techniques et financières de prendre des décisions ensemble. Elle doit déboucher sur quelques changements attribués à des responsables, avec une méthode pour en mesurer les résultats. Ce guide porte sur cette revue opérationnelle. Pour une première estimation ou une comparaison de devis, consultez notre guide de la tarification du calcul cloud.

Que faut-il mesurer dans une revue des coûts cloud ?

Suivez les dépenses cloud totales, le coût par unité de travail utile et le respect des exigences du service. Une facture moins élevée ne prouve pas, à elle seule, que le système est devenu plus efficace. Vous avez peut-être servi moins de clients, traité moins de fichiers ou reporté des tâches au mois suivant.

La gestion des coûts cloud comprend aussi les budgets, les prévisions et l’attribution des coûts aux équipes. L’optimisation utilise ces informations pour décider quoi changer. Les recommandations d’AWS sur l’optimisation des coûts présentent cette démarche comme un travail continu sur les ressources, la demande et le suivi des dépenses.

Pour la réunion mensuelle, préparez l’export de facturation, les mesures de fonctionnement, la liste des actions précédentes et les changements prévus dans les prochains mois. Faites participer une personne qui comprend la facture et une autre qui peut expliquer le comportement du service.

1. Rendre les coûts comparables avant de les expliquer

Précisez les comptes, abonnements, projets, régions et services inclus dans la revue. Conservez ce périmètre d’une période à l’autre. Si une base de données change de compte, son coût ne doit pas disparaître de la comparaison.

Choisissez ensuite la base de coût. Une facture indique les montants facturés sur une période. Une vue opérationnelle peut répartir un paiement initial sur la durée d’un engagement. AWS explique cette différence entre données de facturation et coûts amortis dans Cost Explorer. Gardez les deux vues lorsqu’elles répondent à des questions différentes, en indiquant celle que vous utilisez.

• Utilisez la même devise et précisez le traitement des variations de change.
• Identifiez séparément les crédits, remboursements, taxes, frais de support et dépenses ponctuelles.
• Affichez le nombre de jours de chaque période à côté du montant total.
• Signalez les données de facturation incomplètes au lieu de comparer un mois partiel à un mois terminé.
• Notez les changements de remises ou de conditions contractuelles qui affectent la comparaison.

Une explication utile est précise : « La capacité stockée a augmenté, mais le tarif unitaire est resté stable. » Dire que « les coûts cloud ont augmenté » aide peu la personne qui devra enquêter. Distinguez les variations de volume, de tarif et de répartition entre services lorsque les données le permettent.

2. Attribuer un responsable aux ressources et aux coûts partagés

Chaque coût significatif doit avoir un responsable capable d’en expliquer la raison. Utilisez la structure des comptes, les noms de projets ou les étiquettes pour relier les ressources cloud à un service et à un environnement. Les recommandations de la FinOps Foundation sur l’attribution des coûts prévoient aussi une méthode explicite pour les coûts partagés.

Gardez un montant « non attribué » visible. Le masquer dans le total d’une autre équipe rend le rapport apparemment complet sans expliquer l’utilité de la ressource. Une étiquette manquante doit déclencher une recherche de responsable, pas une suppression automatique.

Pour une base de données ou une plateforme de journaux partagée, documentez la répartition des coûts et la personne qui maintient cette règle. Si elle change, expliquez l’effet sur les totaux des équipes. Transférer une charge d’une équipe à l’autre ne réduit pas la facture de l’organisation.

3. Comparer les dépenses au travail accompli

Choisissez une unité pertinente : une tâche de traitement acceptée, une transaction terminée ou un compte client servi. Conservez une définition stable. Les recommandations de la FinOps Foundation sur les coûts unitaires relient les dépenses technologiques à la valeur ou au travail qu’elles permettent de produire.

Coût par tâche terminée = coût de la charge de travail sur la période ÷ nombre de tâches terminées et acceptées sur cette période.

Voici un exemple fictif, avec un périmètre de coût et des critères d’acceptation identiques :

• Avant : 2 400 $ pour 1 200 tâches acceptées, soit 2,00 $ par tâche.
• Après : 2 200 $ pour 1 000 tâches acceptées, soit 2,20 $ par tâche.
• La facture baisse d’environ 8,3 %, mais le coût par tâche acceptée augmente de 10 %.

Ce calcul n’explique pas la cause du changement. Il invite à examiner la taille des tâches, les échecs, les périodes d’inactivité et les autres différences avant d’annoncer des économies. Incluez le coût des tentatives échouées dans le total. Compter uniquement les tâches réussies au dénominateur ne doit pas effacer les ressources consommées par les échecs.

Pour les traitements sur GPU, comparez le même modèle, le même jeu de données, la même précision et le même objectif de qualité. Un tarif horaire plus faible peut être compensé par une exécution plus longue ou davantage de tentatives. Suivez le coût par résultat accepté, le délai d’exécution et la qualité.

4. Examiner les ressources inutilisées et le dimensionnement

Commencez par les ressources qui semblent inutilisées, puis vérifiez leur rôle avec leurs responsables. Une instance peu active peut servir à un traitement mensuel, à un service de secours ou à la reprise après incident. Pour chaque candidate, notez son rôle, ses dépendances, la période observée et les conséquences d’un arrêt.

Arrêter le calcul ne supprime pas nécessairement tous les frais associés. Dans Amazon EC2, par exemple, les volumes EBS et les adresses IP Elastic peuvent rester facturés lorsque l’instance est arrêtée. Examinez les ressources liées et les engagements avant de chiffrer l’économie attendue.

Le redimensionnement consiste à tester si une autre configuration peut répondre aux mêmes exigences à moindre coût. Les moyennes d’utilisation du processeur ne suffisent pas. Examinez la mémoire, les entrées-sorties du stockage, le réseau, les pics et la latence applicative. La documentation d’AWS Compute Optimizer décrit les mesures utilisées pour ses recommandations, notamment la nécessité de fournir les données de mémoire.

Testez un changement sur un traitement représentatif. Définissez des limites de latence, d’erreurs, de longueur de file ou de durée d’exécution, ainsi que les conditions de retour à la configuration précédente. Si vous utilisez une mise à l’échelle automatique, examinez la capacité minimale et les règles de variation, en plus du maximum. Une règle qui ajoute des ressources mais en retire rarement peut maintenir des dépenses évitables.

Les recommandations FinOps sur l’optimisation de l’usage insistent sur l’adaptation des ressources aux besoins et sur les compromis opérationnels. Les outils d’optimisation fournissent des éléments pour prendre une décision technique.

5. Examiner la croissance du stockage et les transferts

Distinguez les données actives des versions, instantanés, sauvegardes, journaux et résultats temporaires. Cherchez la cause de la croissance et la règle de conservation applicable. Le responsable doit confirmer qu’une suppression ou une durée de conservation plus courte respecte les besoins de reprise et les exigences métier.

Le choix d’un niveau de stockage demande aussi une comparaison fondée sur les usages. Un tarif de capacité plus faible peut s’accompagner d’autres frais d’accès ou de conditions de conservation. Notre guide Azure Blob Storage explique pourquoi le prix des gigaoctets stockés ne suffit pas pour choisir un niveau.

Avant de modifier la conservation des sauvegardes ou l’emplacement du stockage, vérifiez le processus de restauration et le délai de reprise requis. Notre guide des tests de restauration explique comment vérifier qu’une sauvegarde permet de reprendre l’activité.

Pour les coûts réseau, décrivez le trajet réel : source, destination, région, zone et éventuels services de passerelle ou de traitement intermédiaires. Repérez les transferts répétés, les exports en double et les traitements qui relisent sans cesse le même jeu de données distant. Chiffrez chaque changement selon les règles du fournisseur pour ce trajet. Rapprocher les données du calcul peut aider, mais les coûts de migration, de réplication et d’accès récurrents doivent figurer dans le calcul.

6. Réexaminer les Savings Plans et les autres engagements

Un engagement doit correspondre à la demande que vous prévoyez de conserver. Examinez les migrations prévues, les fins de projets et les redimensionnements avant d’utiliser l’historique pour choisir un nouvel engagement. AWS précise que ses recommandations Savings Plans reposent sur des données historiques et ne prévoient pas l’usage futur.

Pour les Savings Plans existants, distinguez deux mesures :

• Le taux d’utilisation indique la part de l’engagement acheté qui est consommée.
• Le taux de couverture indique la part de l’usage admissible couverte par les Savings Plans, mesurée à son équivalent au tarif à la demande.

Une couverture élevée peut inclure des usages inutiles. Un faible taux d’utilisation peut signaler un engagement qui ne correspond plus à la demande. Notez la durée, les services concernés, les obligations de paiement et le besoin de base attendu avant de décider d’un nouvel achat.

Pour les traitements par lots flexibles, testez séparément l’intérêt d’une capacité interruptible. Les instances EC2 Spot peuvent être interrompues. Intégrez donc les points de reprise, les nouvelles tentatives, le travail perdu et le risque de retard à la comparaison. Le tarif de la capacité ne constitue qu’une partie de la décision.

7. Transformer la revue en une courte liste d’actions

Choisissez quelques changements que l’équipe pourra réaliser et vérifier. Classez-les selon l’économie récurrente attendue, l’effort technique, le risque pour le service et la fiabilité de l’estimation. Une refonte complexe au bénéfice incertain ne doit pas automatiquement passer avant une petite modification bien comprise.

Pour chaque action, consignez :

• La ressource ou le traitement, son responsable et le changement proposé.
• La situation de référence et l’effet attendu sur les coûts, avec les hypothèses.
• Les exigences de performance et de reprise à préserver.
• La date de mise en œuvre, les conditions de retour en arrière et la date de validation.
• Le résultat observé, y compris les coûts imprévus et les régressions.

N’additionnez pas des estimations qui se recoupent. Un redimensionnement et une nouvelle remise peuvent concerner les mêmes heures de calcul. Recalculez leur effet combiné au lieu de présenter deux économies indépendantes.

Comparez les résultats après une quantité suffisante de travail représentatif et après réception des données de facturation. Précisez si le changement a réduit les dépenses réelles, évité une hausse prévue ou amélioré le coût unitaire. Ces résultats sont différents et peuvent chacun être utiles.

Maintenir les alertes entre les revues mensuelles

La revue mensuelle sert aux décisions qui demandent du contexte. Les dépenses inattendues nécessitent aussi une réponse entre les réunions. Adressez les notifications de budget et d’anomalie à une personne capable d’enquêter, avec un suppléant et une procédure d’escalade.

Une alerte budgétaire n’est pas automatiquement un plafond de dépense. La documentation des budgets Azure précise que les budgets n’arrêtent pas la consommation et n’agissent pas sur les ressources. La remontée des données et leur évaluation prennent aussi du temps : l’alerte ne constitue donc pas une limite en temps réel.

Si vous configurez une automatisation pour arrêter des ressources, testez-la séparément et définissez les exceptions pour les services critiques. Vérifiez si elle peut interrompre le travail des clients, affecter la reprise ou laisser fonctionner d’autres ressources facturées.

Checklist mensuelle d’optimisation des coûts cloud

1. Clôturer la période de suivi et confirmer la base de coût.
2. Expliquer les principales variations de volume, de tarif et de répartition entre services.
3. Identifier les responsables manquants et rendre visibles les coûts non attribués.
4. Comparer les dépenses au travail utile et à la qualité du service.
5. Examiner les ressources inactives, le dimensionnement, le stockage, les transferts et les engagements.
6. Attribuer quelques changements avec des responsables et des dates de validation.
7. Mesurer les actions précédentes et actualiser les prévisions.

Une revue utile permet, le mois suivant, de répondre à une question concrète : qu’est-ce qui a changé, combien cela a-t-il coûté et le service a-t-il continué à fournir ce dont les utilisateurs avaient besoin ?