Le parcours de l’équipe de développement d’AB180 pour gérer ses coûts AWS : de la vérification de la facture à une culture FinOps
(engineering.ab180.co)Résumé par Gemini.
--
En exploitant « Airbridge », une solution de mesure des performances marketing qui traite d’immenses volumes de données, nous avons mis en place une culture structurée de gestion des coûts AWS (FinOps). Voici les expériences et le savoir-faire que nous en avons tirés.
La manière dont AB180 pilote la gestion des coûts :
Pour réellement « gérer » les coûts, nous faisons tourner les processus suivants.
- Tableau de bord basé sur Google Sheets : nous avons construit un tableau de bord dans Google Sheets, facile à manipuler et à partager. Il affiche non seulement l’état des coûts par tag, mais aussi les volumes de données collectées qui influencent directement les coûts, ce qui permet d’identifier intuitivement les causes des variations. Nous visualisons également la couverture des Savings Plans et simulons à l’avance les effets d’un changement de contrat pour aider à prendre des décisions rationnelles.
- Contrôles de coûts périodiques et automatisés : toutes les deux semaines, nous passons en revue les variations de coûts lors d’une courte réunion d’environ 30 minutes. Les tâches répétitives, comme la génération des supports de réunion, les notifications Slack ou la rédaction du compte rendu, sont automatisées autant que possible pour gagner en efficacité. Lorsque la variation de coût est importante, le responsable analyse la cause et la partage via les commentaires Google Sheets afin d’assurer la transparence.
- Estimation des coûts avant le développement : lors du développement de nouvelles fonctionnalités ou de changements d’architecture, nous avons rendu obligatoire l’estimation des coûts dans le document « Tech Spec ». Cela permet de prendre, dès la phase de développement, de meilleures décisions techniques en intégrant la question des coûts.
Le processus de montée en maturité du système de gestion des coûts :
Le système actuel ne s’est pas construit du jour au lendemain. Il a évolué en passant par les étapes suivantes.
- Phase 0 (vérification de la facture) : au début, nous nous contentions de vérifier la facture chaque mois.
- Phase 1 (classification minimale) : nous avons commencé à classer les ressources a minima à l’aide du tag Name.
- Phase 2 (stratégie de tags avancée) : nous avons établi une stratégie de tags fondée sur des règles claires, comme Team ou Service. Comme la simple diffusion d’un guide ne suffisait pas, nous avons relié cela à des politiques IAM pour imposer la configuration des tags, et mis en place un mécanisme envoyant automatiquement des alertes via un bot Slack pour les ressources sans tag. Résultat : nous maintenons le coût des ressources non taguées à moins de 1 % du total.
Cinq enseignements tirés de ce parcours :
- Une ingénierie adaptée au contexte est essentielle. Plutôt que de viser un système parfait de contrôle des coûts, il est plus judicieux de construire progressivement un cadre de gestion « approprié » à la taille et à la situation de l’entreprise.
- Le « contrôle » des coûts et leur « optimisation » sont deux choses différentes. Le « contrôle », qui vise à rendre les coûts plus prévisibles, et l’« optimisation », qui consiste à réduire le montant lui-même, sont clairement distincts. Il faut décider sur quoi se concentrer selon les priorités du moment.
- Il faut automatiser sans hésiter. Au-delà de l’automatisation des tâches répétitives, mettre en place un environnement en self-serve où les collègues peuvent consulter directement les données et identifier les problèmes permet de maximiser la productivité.
- Il faut créer des « mécanismes ». Au lieu de dire « mettons bien les tags », il est plus efficace de concevoir des dispositifs qui imposent le respect des règles, par exemple en empêchant l’attribution de permissions à une ressource sans tag.
- FinOps est avant tout une « culture ». Le plus important est de faire vivre durablement l’idée que la gestion des coûts n’est pas l’affaire d’un seul responsable, mais la responsabilité de toutes les personnes qui construisent le produit.
5 commentaires
Oh… donc, si on applique au moins les tags les plus basiques, on peut déjà s’en sortir dans une certaine mesure… :)
Mais du coup, est-ce que réduire les coûts en utilisant des choses comme les RI ou les SP fait partie des bases… ?
Déterminer à peu près quelle taille nous allons utiliser dans notre infrastructure, c’est aussi un point qui demande pas mal de réflexion…
Comme c’est aussi mentionné dans l’article, j’avais de mon côté créé un simulateur de SP : à partir de la charge de travail des n derniers jours, il calculait combien de SP supplémentaires il fallait acheter pour minimiser au mieux « le coût existant + les coûts réduits grâce à la couverture + les coûts gaspillés à cause de la récurrence », et c’est sur cette base que je prenais mes décisions.
Je travaille actuellement chez AWS Corée.
L’une des formations les plus importantes que l’on suit après l’embauche consiste à réfléchir à la manière d’aider les clients à réduire leurs coûts cloud, et l’une des méthodes les plus efficaces recommandées pour cela est d’utiliser les RI et les SP.
Veuillez réduire les frais, s’il vous plaît..
Même si vous ne connaissez pas les RI, dans le cas des SP, ils peuvent s’appliquer à plusieurs workloads, donc s’il y a des coûts fixes récurrents, cela vaut vraiment la peine de les envisager. Nous en avons même acheté en tenant compte de la date d’optimisation prévue... haha. Par exemple, si nous pensions que l’optimisation serait terminée dans 9 mois et que les coûts serveurs seraient réduits de moitié, il restait quand même plus avantageux d’acheter un engagement d’un an, donc nous le faisions ainsi.