Réduire les coûts cloud grâce aux données d’utilisation

L’optimisation des coûts du cloud peut produire d’importantes réductions mises en avant dans les titres, mais le pourcentage le plus élevé affiché est un mauvais point de départ. Pour un CTO, un ingénieur cloud ou un responsable d’infrastructure, la vraie question est de savoir quelles dépenses peuvent réellement être réduites, quelle intervention convient à chaque charge de travail, et si le changement coûte moins qu’il ne permet d’économiser. Répondre à cette question exige de la visibilité avant même de commencer l’optimisation.

L’ampleur des dépenses évitables rend cette visibilité essentielle : 91 % des organisations ont du mal à maîtriser des dépenses cloud évitables. Un framework pratique pour traiter ces dépenses identifie six leviers de réduction des coûts. Tous les six dépendent d’une bonne connaissance des ressources existantes et de la manière dont elles sont utilisées.

L’optimisation du cloud commence avant la première réduction de coûts

Les six interventions répondent à différentes causes de dépenses excessives : des instances surdimensionnées, des serveurs oubliés, des contrôles de provisioning insuffisants, des ressources pouvant suivre des calendriers d’arrêt, une capacité pouvant s’adapter automatiquement, et des charges de travail adaptées à d’autres modèles d’achat. Chacune s’applique dans des conditions différentes, car une instance surdimensionnée appelle une décision différente de celle d’un serveur de test que personne n’utilise. Une charge de travail stable ouvre aussi des options d’achat différentes de celles d’un traitement batch tolérant aux pannes.

Ces différences déterminent la manière dont le travail de réduction des coûts doit être organisé. Une équipe qui commence avec un objectif comme « utiliser davantage d’instances réservées » ou « tout redimensionner » a déjà choisi une intervention avant d’avoir établi ce qui génère sa facture. Une approche plus solide commence par des preuves sur les ressources et leur usage, s’en sert pour choisir une intervention, puis vérifie si la réduction atteignable justifie l’effort d’ingénierie.

Rendez les dépenses cloud attribuables avant de chercher à les optimiser

Ces preuves commencent par un tagging et un étiquetage appropriés des ressources cloud. Les dépenses agrégées montrent la facture totale, tandis que les tags associent ces dépenses à des équipes, des services ou des projets. Une fois que les coûts ont des responsables et un contexte organisationnel, les décideurs peuvent identifier où une intervention est nécessaire et qui doit l’évaluer.

L’attribution fournit aussi un inventaire utile de l’infrastructure. Des libellés adaptés aident une équipe à voir combien de ressources elle possède, dans quelle mesure elles sont utilisées, et à quels moments cet usage a lieu. Le nombre de ressources, le taux d’utilisation et le moment d’utilisation répondent à différentes questions d’optimisation : ce qui pourrait être supprimé, ce qui pourrait être surdimensionné, et ce qui pourrait potentiellement être arrêté pendant les périodes d’inactivité.

Les observations actuelles deviennent plus utiles lorsqu’elles sont combinées à des informations historiques. Une seule observation de faible utilisation ne capture qu’un instant donné, car la demande peut évoluer dans le temps. L’historique d’utilisation révèle ces schémas, ce qui permet aux équipes de fonder leurs changements sur la demande observée sur une période appropriée.

Les outils des fournisseurs cloud peuvent fournir une partie de ces preuves. AWS est le fournisseur spécifiquement cité pour ce travail, avec AWS Trusted Advisor, Compute Optimizer et Cost Explorer, qui offrent des moyens d’examiner les coûts et de découvrir des schémas. Les autres grands fournisseurs cloud proposent également des outils d’analyse des coûts cloud, de sorte que cette même étape de collecte de preuves s’applique à tous les fournisseurs.

Avec ces données disponibles, les équipes peuvent relier les conditions observées à des réductions concrètes. Une ressource inactive peut conduire à sa suppression, une inactivité récurrente à des arrêts planifiés, une faible utilisation à un right-sizing, et une demande variable à du scaling. La cause de chaque coût détermine l’intervention adaptée à la ressource, d’où l’importance de ces preuves.

Faire correspondre l’intervention à la manière dont le gaspillage se produit réellement

La première opportunité consiste à éviter un coût inutile avant même qu’une ressource ne soit provisionnée. Les ressources coûteuses méritent une attention particulière, notamment les services GPU et IA, car leur accès peut être limité aux utilisateurs appropriés. La décision de gouvernance qui en résulte définit qui peut créer une infrastructure à coût élevé et selon quelles règles financières cette infrastructure peut être créée.

Le policy-as-code offre un moyen d’appliquer ces règles au moyen de politiques définies par logiciel. Les exigences financières peuvent être codées sous forme de garde-fous de provisioning afin que les utilisateurs restent dans les tailles de ressources et les limites de dépenses approuvées. Ces garde-fous préservent une autonomie utile pour les personnes qui ont besoin d’infrastructure, tout en imposant des limites applicables aux choix qui créent des dépenses évitables.

Une fois l’infrastructure en fonctionnement, l’utilisation réelle peut révéler une capacité excédentaire que les contrôles de provisioning ne pouvaient pas prévoir. Une ressource a pu être surdimensionnée lors de sa création parce que ses besoins étaient incertains, ou bien ces besoins ont pu diminuer depuis le déploiement. Le right-sizing consiste alors à modifier le type ou la taille de l’instance afin que ses performances et sa capacité correspondent mieux à sa charge de travail actuelle.

Le right-sizing dépend directement des données d’usage recueillies plus tôt. La taille d’une instance, à elle seule, ne suffit pas à déterminer si elle doit être réduite, car les besoins observés de la charge de travail doivent justifier ce changement. Relier ces mesures à la capacité fait du redimensionnement une décision spécifique à chaque charge de travail.

Certaines ressources nécessitent une intervention plus radicale parce que leur capacité requise est tombée à zéro. Une infrastructure peut rester provisionnée après la disparition d’une demande fluctuante, et il arrive aussi que des personnes oublient simplement que des ressources temporaires existent encore. L’exemple concret est celui d’un serveur de test jamais supprimé : l’inventaire peut le révéler, puis sa suppression élimine les dépenses liées à une ressource qui n’a plus d’utilité.

Les ressources qui connaissent des périodes récurrentes d’inactivité nécessitent un traitement différent, car elles conservent une utilité continue. Les instances de développement, de staging et de QA peuvent avoir une valeur claire pendant les périodes de travail tout en restant inutilisées à d’autres moments. Lorsque les schémas d’usage le permettent, ces systèmes hors production peuvent être arrêtés pendant les heures creuses et les week-ends, supprimant ainsi le coût de leur fonctionnement lorsque personne ne les utilise.

Une demande variable appelle une autre réponse. L’autoscaling ajuste automatiquement la capacité cloud applicable à mesure que l’usage réel évolue, ce qui permet à la capacité de diminuer lorsque la demande baisse et d’augmenter lorsque la demande revient. Les charges de travail élastiques peuvent donc réduire les dépenses lorsque la capacité peut suivre en toute sécurité l’évolution de la demande.

Ensemble, ces interventions traitent le gaspillage à différentes étapes du cycle de vie d’une ressource. Les contrôles de provisioning empêchent la création de dépenses inutiles ; le right-sizing corrige la capacité excédentaire une fois les besoins visibles ; la suppression élimine les ressources qui n’ont plus d’utilité ; les calendriers d’arrêt suppriment les périodes de fonctionnement à vide ; et l’autoscaling ajuste la capacité applicable en fonction de la demande. Le bon choix découle de la compréhension de la raison d’être d’un coût donné.

Les remises ne fonctionnent que lorsque la charge de travail correspond au modèle tarifaire

Le sixième levier d’économies consiste à changer le modèle d’achat de la ressource. Les instances cloud peuvent être acquises selon différents modèles de coûts, et l’option appropriée dépend des caractéristiques de la charge de travail et du niveau d’engagement qu’une organisation peut accepter. Une remise mise en avant devient utile lorsque ces conditions correspondent au travail réellement exécuté.

Pour les charges de travail flexibles, les instances spot peuvent réduire les coûts de calcul de « jusqu’à 90 % ». La capacité spot convient aux traitements tolérants aux pannes, comme le traitement batch, car ces charges de travail peuvent s’accommoder de ses caractéristiques de fonctionnement. Elle peut aussi compléter une capacité obtenue via des instances à la demande ou des instances réservées.

Les charges de travail prévisibles justifient un autre choix d’achat. Les instances réservées impliquent un engagement sur une instance pendant une période donnée en échange d’une remise décrite comme « généralement jusqu’à 72 % ». Une demande stable rend cet engagement dans le temps plus compatible avec l’usage attendu, reliant directement la décision d’achat au profil de la charge de travail.

Les savings plans offrent une autre manière de réduire les coûts dans le cadre des modèles d’achat cloud. Avec les instances spot et les instances réservées, ils font du choix tarifaire un élément de l’architecture d’infrastructure, où il peut être examiné en lien avec le comportement de la charge de travail qui détermine les besoins en capacité. L’économie possible dépend du choix d’une option de paiement adaptée à la manière dont la capacité sera réellement nécessaire.

Parce que les modèles de paiement influencent les décisions d’architecture, leur compréhension est considérée comme une connaissance fondamentale du cloud pour les rôles d’ingénierie et d’architecture. Les options de paiement des instances sont largement couvertes dans les certifications cloud de niveau fondamental à intermédiaire, ce qui reflète l’importance que les fournisseurs cloud accordent à la compréhension, par les praticiens, des choix d’achat à leur disposition. Pour les responsables techniques, les modèles tarifaires doivent donc faire partie des décisions d’infrastructure au même titre que la capacité, les exigences de fiabilité et les schémas d’usage.

Une économie n’a de valeur que si elle dépasse le coût nécessaire pour l’obtenir

Choisir une intervention techniquement valide laisse encore place à un calcul business. Une fois qu’une équipe a identifié les ressources pouvant être modifiées, elle doit estimer l’argent que l’intervention est susceptible d’économiser et le comparer aux personnes et au temps nécessaires pour la mettre en œuvre. Le retour sur ce travail d’optimisation détermine jusqu’où l’exercice doit aller.

Ce retour crée une asymétrie économique entre les organisations ayant des factures d’infrastructure différentes. Lorsque les dépenses cloud sont plus faibles, le volume d’économies potentielles l’est aussi, de sorte qu’il peut devenir difficile de justifier l’affectation de davantage d’ingénieurs ou de temps d’ingénierie à la réduction des coûts. Le niveau d’effort d’optimisation pertinent dépend donc en partie du montant des dépenses disponibles à optimiser.

Avec ce calcul en place, chaque ressource conduit à une décision économique précise : l’arrêter, ajuster sa capacité, encadrer plus strictement son provisioning, ou appliquer un savings plan lorsque cela est approprié. Découvrir, mettre en œuvre et maintenir chaque optimisation consomme des ressources, de sorte que la réduction atteignable doit être mise en balance avec ce travail. L’optimisation des coûts a elle-même un coût.

Points clés à retenir pour les décideurs

• Construire la visibilité avant d’optimiser : Les responsables d’infrastructure ont besoin de tags de ressources, de données d’utilisation, d’une attribution claire et d’un historique d’usage pour identifier où les dépenses cloud peuvent être réduites. Ces éléments relient chaque source de gaspillage à l’intervention appropriée.
• Faire correspondre les actions à la source du gaspillage : Les équipes plateforme et infrastructure peuvent utiliser des contrôles de provisioning, le right-sizing, la suppression, des calendriers d’arrêt et l’autoscaling selon la manière dont chaque ressource est réellement utilisée. Le comportement de la charge de travail détermine l’intervention adaptée.
• Adapter les modèles tarifaires aux charges de travail : Les architectes cloud peuvent utiliser des instances spot pour les charges de travail flexibles et tolérantes aux pannes, ainsi que des engagements comme les instances réservées ou les savings plans lorsque la demande le justifie. La remise atteignable dépend des caractéristiques de la charge de travail et des engagements d’achat.
• Comparer les économies à l’effort d’ingénierie : Les responsables technologiques doivent mettre en balance les économies cloud attendues avec le temps et les personnes nécessaires pour découvrir, mettre en œuvre et maintenir chaque optimisation. Le montant de la facture cloud aide à déterminer quel niveau de travail d’optimisation est économiquement justifié.