7 signaux discrets dans votre facture cloud qui peuvent trahir un anti-pattern ou un surcoût, et les bons réflexes à adopter à la place.
Pour optimiser ses coûts cloud, il faut parfois savoir lire entre les lignes de sa facture.
On se concentre souvent sur les pics de coûts visibles, mais qu'en est-il des signaux plus subtils, moins évidents, tapis derrière les chiffres ?
Dans un récent épisode du podcast Cloud Masters, nous avons réuni trois Technical Account Managers (TAMs) de DoiT pour mettre en lumière sept signaux d'alerte peu évidents qu'ils ont repérés chez leurs clients, et discuter des bons réflexes à adopter.
Il ne s'agit pas des pics de coûts spectaculaires qui sautent aux yeux ; ce sont plutôt des indices subtils qui laissent penser que quelque chose cloche, signalant potentiellement un surcoût ou des pratiques peu efficaces.
Écoutez l'épisode complet ci-dessous, ou poursuivez votre lecture : nous décortiquons ces signaux et proposons des conseils concrets pour chacun.
Signal d'alerte #1 : vous payez pour AWS CloudTrail
Si vous payez quoi que ce soit pour CloudTrail, vous avez une marge d'économies sur votre facture cloud. Le premier trail CloudTrail dans une région est gratuit, et votre seul trail devrait se situer au niveau de l'AWS Organization, car les Organization trails sont automatiquement créés dans tous les comptes membres de l'Organization.
Gardez à l'esprit que le nouveau trail s'ajoute en plus des trails existants dans les comptes membres. Par conséquent, si vous avez créé par le passé des trails distincts dans les comptes membres, vous pouvez réaliser des économies en les supprimant.
Créer votre trail CloudTrail au niveau de l'Organization vous aide à appliquer uniformément votre stratégie de journalisation des événements sur l'ensemble des comptes de votre organisation, puisque la configuration du trail de l'organisation se propage à tous les comptes. Vérifiez donc que la configuration de votre Organization trail correspond à celle que vous souhaitez voir appliquée à tous les comptes qui en font partie.
Signal d'alerte #2 : les coûts de stockage augmentent régulièrement faute de politiques de cycle de vie des données
Si vous constatez une hausse régulière de vos coûts de stockage cloud au fil du temps, c'est peut-être le signe que vous n'avez pas appliqué les politiques de cycle de vie des objets appropriées.
Ces politiques automatisent le passage des données vers différentes classes de stockage, ou leur suppression selon des règles prédéfinies, en alignant le coût de stockage sur la valeur et l'accessibilité des données. Vous évitez ainsi de payer trop cher le stockage de données qui n'exigent pas un accès immédiat ou qui sont devenues obsolètes.
Sans politiques de cycle de vie, vous accumulerez des données, votre stockage de logs ne cessera de croître et/ou vous aurez un excès de snapshots. Vos coûts de stockage suivront alors une trajectoire ascendante, surtout si des données anciennes ou peu consultées restent dans des classes de stockage coûteuses.
La plupart du temps, il suffit de transférer ou de faire expirer les objets après 30 à 90 jours. Mais le signe révélateur qu'il faut examiner le stockage de plus près, c'est une tendance haussière des coûts.
Signal d'alerte #3 : les coûts de l'API GetMetricData de CloudWatch sont élevés
Les services tiers comme New Relic et Datadog scannent régulièrement vos comptes cloud — généralement les métriques CloudWatch — pour disposer d'informations à jour sur votre utilisation.
Pourtant, beaucoup ignorent que vous payez aussi pour les requêtes API que ces services effectuent. Ces requêtes apparaissent dans CloudWatch sous le SKU API GetMetricData. Sans vigilance, vous risquez de payer une somme considérable pour CloudWatch à cause de ces appels GetMetricData provenant de logiciels tiers.
Soyez donc attentif à :
- la fréquence de ces appels d'API,
- les métriques et données scannées.
Par exemple, vous pouvez avoir un compte de développement riche en ressources qui vous coûte cher en CloudWatch parce que des appels d'API sont effectués chaque minute. Dans ce cas, demandez-vous si la fréquence — et peut-être la granularité des données — est vraiment nécessaire.
Pour réduire les coûts CloudWatch issus de ces appels d'API, il suffit souvent de demander aux services tiers d'ajuster la fréquence et les métriques récupérées pour des comptes ou projets spécifiques.
Signal d'alerte #4 : les coûts de logging dépassent 20 % de votre facture cloud
La journalisation est essentielle pour le monitoring et le dépannage, mais un logging excessif peut faire gonfler votre facture cloud.
Comme pour les conseils donnés sur les appels d'API au signal précédent, demandez-vous si la fréquence et les métriques que vous collectez via votre logging correspondent vraiment au cas d'usage. Par exemple, si vous alimentez un dashboard à partir de logs, inutile d'obtenir des mises à jour à la seconde — une mise à jour toutes les cinq minutes peut suffire.
En règle générale, vous ne devriez pas consacrer plus de 20 % de votre facture cloud au logging. Si vous dépassez ce seuil, c'est le signe qu'il faut regarder de plus près la composition de ces coûts. Demandez aux différentes équipes qui exploitent vos logs à quoi elles s'en servent : vous pourrez ainsi identifier où ajuster la fréquence ou les métriques collectées.
Pensez également à examiner attentivement le logging dans les environnements non-production, qui ne génèrent pas forcément de revenus. Vous n'aurez sans doute pas besoin de la même fréquence ni des mêmes métriques que dans les comptes de production. En cas de panne dans un environnement non-production, il suffit d'activer ou de désactiver les logs, contrairement à la production où vous aurez besoin de plus d'informations pour comprendre l'origine du problème.
Signal d'alerte #5 : ne pas recouper les décisions
Ce signal n'est pas un élément précis que vous pouvez repérer dans votre facture ou un rapport de coûts et d'utilisation, mais ne pas recouper vos décisions technologiques et de conception peut se traduire à terme par des casse-têtes sur la facture cloud et des problèmes de performance.
Exemple très courant : une équipe achète une remise sur engagement (par ex. un Savings Plan) de manière isolée, sans tenir compte de la stratégie globale ni des besoins des autres équipes. Le département technique peut envisager un passage au serverless dans les deux ans à venir, mais quelqu'un achète soudain un Savings Plan sur 3 ans, le verrouillant sur l'utilisation de VMs.
Il n'existe pas de décision objectivement bonne lorsqu'on construit dans le cloud. Prendre des décisions liées au cloud en silo conduit à des inefficacités et à des coûts accrus. Demandez-vous comment vous validez en interne, auprès de vos pairs ou d'autres équipes, la pertinence de vos décisions. Concrètement, cela peut consister à confronter vos décisions d'infrastructure cloud à la stratégie et à la vision d'engineering, ou aux documents RFC/ADR pertinents.
Signal d'alerte #6 : vous ne limitez pas les régions et les types d'instances avec des politiques organisationnelles
Les politiques organisationnelles (voir la documentation Google Cloud et AWS) vous aident à définir comment vos utilisateurs cloud peuvent accéder aux ressources cloud de votre entreprise, les utiliser et les gérer.
Du point de vue de l'optimisation des coûts (et de la sécurité), elles s'avèrent particulièrement utiles pour empêcher le lancement de services là où ils n'ont pas lieu d'être.
Concrètement, sans politiques organisationnelles pour restreindre les types d'instances et les régions, vous exposez votre infrastructure cloud à des vulnérabilités de sécurité et à des risques de surcoût. Des acteurs malveillants peuvent exploiter ce manque de contrôle pour déployer des instances dans des régions inutilisées, échappant à la détection et menant à bien leurs activités.
Limitez les types d'instances et les régions à ceux que vous utilisez réellement, afin que personne — par malveillance ou par erreur — ne puisse lancer, par exemple, une instance x1 plutôt qu'une t4 en Amérique du Sud alors que toutes vos ressources sont en Europe.
En déployant des politiques organisationnelles, vous protégez efficacement votre environnement cloud et optimisez l'utilisation de vos ressources.
Signal d'alerte #7 : trop d'appels d'API vers les buckets de stockage
Des appels d'API fréquents et inutiles vers les buckets de stockage peuvent faire gonfler les coûts et nuire aux performances. Ce signal d'alerte se manifeste dans de nombreuses situations.
Vos applications peuvent effectuer des appels d'API fréquents vers les buckets de stockage cloud. C'est particulièrement problématique pour les applications qui génèrent un grand volume de données ou qui réalisent fréquemment des transferts. Il peut aussi s'agir d'un processus planifié qui interagit avec vos buckets de stockage et accumule peu à peu un nombre important d'appels d'API.
Au-delà du coût, gardez à l'esprit que des appels d'API fréquents pèsent aussi sur les performances de votre application : ralentissements, timeouts, voire pannes système.
Sans monitoring approprié, vous pouvez facilement dépenser trop sans déclencher d'alerte jusqu'à l'arrivée de la facture ou jusqu'à ce qu'un quota de service soit atteint.
Revoyez et optimisez donc le code de votre application pour réduire le nombre d'appels d'API nécessaires à chaque opération. Mettez également en place des mécanismes de cache afin de stocker en mémoire les données fréquemment consultées et de limiter les appels répétés vers les buckets de stockage.
Poser les bonnes questions à votre facture cloud
Nous pouvons vous donner une liste de signaux d'alerte à surveiller, mais les pistes à explorer sont infinies. D'où l'importance, sur le long terme, de rester curieux face à vos dépenses cloud. Ne vous contentez pas du montant affiché sur votre facture. Demandez pourquoi, puis demandez encore pourquoi.
Par exemple, si les coûts S3 augmentent, identifiez le ou les buckets à l'origine de la hausse. Cherchez ensuite quels SKUs sont responsables de cette augmentation. Puis, lorsque vous découvrirez qu'il s'agissait des coûts de transfert de données, demandez-vous, avec votre équipe, si cette hausse pour ces buckets était anticipée ou non. Les coûts ont peut-être augmenté pour une bonne raison, mais vous ne le saurez qu'en posant la question.
Avec le temps, cette démarche contribue à instaurer une culture d'optimisation des coûts dans toute l'entreprise, où chacun a conscience de sa contribution à la facture cloud et se sent légitime pour agir.
Chacun de ces signaux souligne l'importance d'une responsabilité partagée et d'une curiosité face à votre facture cloud. N'oubliez pas : identifier ces opportunités d'optimisation ne doit pas reposer uniquement sur les épaules du Head of Infrastructure ou du FinOps Lead. C'est une démarche qui se nourrit du travail d'équipe.