Résumé exécutif

Nous avons commencé avec AWS Cost Optimization Hub et mis en œuvre ses recommandations. Cela a généré une valeur réelle, mais notre empreinte AWS d’environ 150 000 $/mois présentait encore un dérive de coûts significative. Ce billet de blogue porte sur les 11 000 $/mois d’économies que nous avons trouvés, en plus des quelque 15 000 $/mois obtenus grâce à la mise en œuvre des recommandations du Cost Optimization Hub.

Les écarts n’étaient pas simplement une question de dimensionnement approprié; ils découlaient plutôt des paramètres par défaut des services, de questions opérationnelles et d’angles morts en gouvernance que les moteurs de recommandations peuvent ne pas toujours relever.

• 11 000 $ US par mois en économies récurrentes, ce qui dépasse les recommandations du Centre d’optimisation des coûts (environ 133 000 $ US par année)
• Réduction d’environ 7,4 % par rapport à nos dépenses de référence de 150 000 $ par mois
• Mise en place d’un rythme opérationnel reproductible, y compris la répartition des responsabilités, les examens et les balises, afin de minimiser le retour en arrière
• Tous les changements ont été validés auprès des propriétaires d’applications pour prévenir des problèmes de performance majeurs et maintenir les contrôles d’audit et de sécurité nécessaires

Tout aussi important, une enquête sur les coûts a révélé un risque opérationnel qui était passé inaperçu pendant des mois : des échecs silencieux du cycle de vie des sauvegardes, ce qui a entraîné l’accumulation d’environ 50 To de données et une augmentation des dépenses en stockage et en sauvegarde. Cela a mis en lumière une leçon précieuse : une gestion efficace FinOps exige à la fois une hygiène opérationnelle et l’optimisation des coûts.

Pourquoi les FinOps menés par des outils atteignent un plateau

Le AWS Cost Optimization Hub (et des outils similaires) constitue un point de départ essentiel. Il est fort pour détecter les inefficacités au niveau des ressources : détection des ressources inactives, ajustement de la taille des ressources, opportunités de migration vers Graviton, et économies basées sur des engagements comme les plans d’épargne et les instances réservées.

Ces outils sont moins susceptibles de capturer pleinement la dérive de gouvernance spécifique à l’environnement, les contrôles en double, les paramètres de rétention incohérents, les solutions temporaires qui deviennent permanentes, ainsi que les processus qui ne fonctionnent plus comme prévu. Ces enjeux peuvent mener à une augmentation graduelle des coûts et, à l’occasion, à de véritables risques pour la fiabilité ou la conformité.

Après avoir réglé les améliorations évidentes, il est important de considérer une nouvelle série de questions :

• Les systèmes fonctionnent-ils comme prévu, de bout en bout ?
• Les paramètres par défaut actuels correspondent-ils aux habitudes d’utilisation réelles, ou sont-ils fondés sur des hypothèses dépassées ?
• Qui est responsable des coûts et qui veille à ce que les contrôles demeurent efficaces ?

Cette étude de cas décrit ce que nous avons découvert en adoptant cette perspective plus large.

Ce que nous avons fait différemment (et pourquoi c’est important)

Le coût caché d’une gouvernance infonuagique “suffisamment bonne”

Pendant cette initiative de six mois, nous avons constamment observé une tendance récurrente : laisser les valeurs par défaut non examinées et les hypothèses non remises en question mène à une augmentation des coûts et des risques avec le temps.

• La dette opérationnelle s'accumule de la même façon que la dette technique. Lors d'un examen des coûts de stockage, nous avons identifié une lacune dans le cycle de vie des sauvegardes : la suppression et la rétention ne fonctionnaient pas comme prévu. Il est important de se demander non seulement « est-ce configuré? » mais aussi « est-ce que ça fonctionne correctement de bout en bout? »
• L'étalement du nuage est fréquemment un problème organisationnel plutôt que simplement technique. Nous avons découvert plusieurs pistes CloudTrail mises en place par différentes équipes. Bien que chaque configuration fût logique individuellement, leur ensemble entraînait des dépenses inutiles.
• La « meilleure pratique » dépend du contexte. Bien que AWS Graviton offre généralement un bon rapport prix-performance, il n'est pas toujours un remplacement direct. Nous avons choisi AMD pour son risque de livraison moindre et son intégration plus rapide dans notre chaîne x86.
• Le FinOps est un signe d'excellence en ingénierie. Une gestion claire des responsabilités, des contrôles vérifiés et des processus reproductibles contribuent à l'efficacité des coûts et à l'excellence opérationnelle.

Pourquoi c’est important maintenant : Les dépenses infonuagiques augmentent rapidement en raison de la modernisation, des plateformes de données et des initiatives d’IA/AA. Sans un modèle opérationnel qui valide régulièrement l’architecture, les contrôles et les processus, les organisations peuvent accumuler des coûts évitables et un risque opérationnel inattendu, même lorsqu’elles utilisent des moteurs de recommandations.

Action suggérée : Utilisez le Cost Optimization Hub comme point de départ et complétez-le par des examens continus de l’architecture et des opérations (tels que le cycle de vie du stockage, les pratiques de journalisation, la gestion des réseaux et les vérifications de sauvegarde) qui ont une propriété définie et des mesures de protection quantifiables.

Le modèle opérationnel FinOps que nous avons utilisé

Nous avons adopté un modèle opérationnel cible simple, axé sur des améliorations durables plutôt que sur une simple réduction ponctuelle des coûts. Le cadre a été volontairement simplifié :

Nous avons également mis en place une gouvernance régulière. Des rapports de coûts hebdomadaires, mensuels et trimestriels ont été examinés dans un forum FinOps avec l’équipe FinOps, les responsables de service, les architectes et l’ingénierie de plateforme. 

Des alertes d’anomalies de coûts et de budget ont aussi été configurées, et l’équipe FinOps a collaboré avec les responsables applicatifs pour identifier les causes premières, convenir des actions correctives et assurer leur suivi jusqu’à la résolution. 

D’où proviennent les économies de 11 000 $/mois?

• Stockage : S3, EFS et cycle de vie de la sauvegarde

S3 tiering, classement intelligent et expiration

Constatation : Environ 50 To de données sont restées dans S3 Standard plus longtemps que nécessaire. En utilisant S3 Storage Lens et les examens du propriétaire du compartiment, nous avons cartographié les modèles d'accès et les exigences de conservation pour chaque charge de travail.

Correction :

• Ajout de règles de cycle de vie S3 pour transférer les objets vers Standard-IA puis vers les niveaux d’archivage lorsque c’est approprié
• Application de politiques de cycle de vie pour l’expiration (suppression) des données dans les compartiments n’ayant pas besoin d’une rétention à long terme
• Activation du S3 Intelligent-Tiering pour les compartiments aux schémas d’accès imprévisibles
• Économies : ~1 200 $/mois

Gestion du cycle de vie EFS (IA/Archive)

Nous avons activé la gestion du cycle de vie EFS pour transférer les fichiers rarement consultés vers EFS-IA et (là où c'est admissible) EFS Archive, conformément aux modèles d’accès à la charge de travail.

Économies réalisées : ~600 $/mois

Optimisation des coûts par la découverte des risques (RMAN → cycle de vie de la sauvegarde EFS)

Certains des constats FinOps les plus précieux ne commencent pas comme des « idées d’optimisation ». Ils débutent comme des anomalies qui indiquent qu’un processus dévie—ou échoue silencieusement. Dans notre cas, l’examen d’une empreinte EFS inhabituellement grande a révélé un problème de cycle de vie de sauvegarde qui persistait depuis près de deux ans.

Constat : Un système de fichiers EFS utilisé pour les sauvegardes RMAN d’Oracle RAC (Flashgrid sur EC2) avait atteint ~60 To. L’équipe de la charge de travail croyait que la rétention RMAN était appliquée (suppression après 35 jours), mais la vérification a montré que les sauvegardes s’accumulaient.

Cause fondamentale et correctif : La suppression RMAN dépendait de la commande CROSSCHECK, qui échouait parce qu’une configuration de canal de sauvegarde faisait référence à des clés AWS IAM manquantes ou invalides. Les sauvegardes étaient toujours créées sur EFS, mais le nettoyage du cycle de vie ne se terminait jamais. Après avoir corrigé la configuration du canal et validé le comportement CROSSCHECK/suppression de bout en bout, nous avons supprimé ~50 To de sauvegardes obsolètes.

Avantage additionnel : Comme le système de fichiers EFS était aussi protégé par AWS Backup, la réduction de l’empreinte source a également réduit la capacité de stockage de sauvegarde en aval.

Économies réalisées : ~2 000 $/mois (EFS + stockage de sauvegarde réduit)

Leçon clé retenue : N’auditez pas seulement la création des sauvegardes—auditez l’ensemble du cycle de vie (rétention, suppression, restaurations) et rapprochez le volume de sauvegardes stockées avec la politique selon une cadence fixe.

Ce qui est transférable vs. spécifique au contexte : Les outils ici (RMAN, EFS) sont spécifiques, mais le mode de défaillance est commun : les hypothèses de rétention ne sont pas validées. Considérez la vérification du cycle de vie des sauvegardes comme un contrôle avec une responsabilité explicite, des tests et des preuves périodiques.

Hiérarchisation du cycle de vie AWS Backup (stockage tiède → stockage froid)

AWS Backup prend en charge les transitions du cycle de vie vers le stockage froid pour les types de ressources admissibles. Cela peut réduire considérablement les coûts de sauvegarde longue conservation, mais exige habituellement une rétention minimale et peut entraîner des frais de suppression anticipée. Validez l’admissibilité et les exigences de conformité pour vos charges de travail.

Constats :

• Toutes les sauvegardes étaient envoyées dans la voûte standard
• Ces sauvegardes étaient rarement consultées, mais étaient conservées pour la conformité

Correction :

• Politiques configurées pour déplacer les sauvegardes vers le stockage à froid pour EFS
• Le niveau froid AWS Backup coûte environ 80 % de moins que le stockage chaud (0,01 $/Go/mois contre 0,05 $/Go/mois)
• Économies : environ 500 $/mois
• Journalisation : conservation des journaux CloudWatch (et choix de la bonne classe de journaux)

Les journaux CloudWatch Logs peuvent discrètement devenir un poste de dépenses important. Notre principal problème n’était pas l’ingestion, mais les paramètres par défaut de conservation.

Constat : Bon nombre de groupes de journaux étaient réglés sur Jamais expirer, même si les mêmes journaux étaient déjà centralisés dans S3 et Splunk pour une conservation et une recherche prolongées.

Correction : Conservation des journaux CloudWatch Logs normalisée à 2 semaines pour la plupart des journaux d’application, avec une rétention plus longue uniquement lorsque requis expressément.

Économies réalisées : ~800 $/mois

Remarque sur les classes de journaux AWS CloudWatch : CloudWatch Logs offre plusieurs classes de journaux, comme Standard et Accès peu fréquent, chacune présentant des compromis de prix et de fonctionnalités différents. Nous avons examiné ces options et déterminé que le maintien de bonnes pratiques de conservation offrait le meilleur retour sur investissement dans notre environnement. Si votre flux de travail dépend de requêtes ponctuelles, assurez-vous d’évaluer l’impact sur les coûts et les fonctionnalités avant de changer de classe de journaux.

• Audit des auditeurs : consolidation de CloudTrail

Conclusion :

• 6 pistes en double enregistrant les mêmes événements de gestion. Ceux-ci dupliquaient les données à la fois dans CloudWatch et S3.
• Journalisation d'événements de données non nécessaire sur des compartiments S3 non critiques.

Remédiation :

• Fusionné en une seule piste à l’échelle de l’organisation, livrée dans un compartiment S3 centralisé (avec les contrôles d’immutabilité/rétention appropriés).
• Réduction de la journalisation des événements de données, en la maintenant activée seulement pour les compartiments/charges de travail où elle était requise pour des raisons de sécurité ou d’enquête.
• Économies réalisées : ~300 $/mois

Remarque sur AWS CloudTrail : Les coûts d’AWS CloudTrail sont influencés par des facteurs comme le nombre de trails, les régions, les types d’événements (gestion ou données) et toutes les fonctionnalités supplémentaires. Pour la FinOps, il est important de noter que la duplication des trails et la journalisation d’un large éventail d’événements de données peuvent entraîner des dépenses inutiles. 

La consolidation doit préserver les exigences en matière de sécurité telles que la propriété centralisée, le chiffrement, la validation des fichiers journaux, l’accès restreint, le contrôle de la rétention et l’immutabilité lorsque nécessaire.

• Coûts de réseau inactif : Hygiène de la passerelle de transit

Nos comptes de test réseau avaient des douzaines de connexions Transit Gateway (TGW) inactives laissées en marche « juste au cas où ».

Justification : « C’est trop de travail de reconfigurer celles-ci pour des tests occasionnels. »

Constatation :

• Les pièces jointes TGW entraînent des frais horaires (varient selon la région) en plus des frais de traitement des données par Go
• Traitement des données : 0,02 $/Go traité
• Pour plus de 20 pièces jointes inactives dans des comptes de test, cela s'est traduit par environ 700 $/mois de dépenses évitables

Correction :

• Passé à l’infrastructure comme code en utilisant des modèles CloudFormation
• Création de modèles réutilisables pour les environnements de test, incluant les rattachements TGW, les tables de routage et les groupes de sécurité
• L’équipe met maintenant en place des environnements sur demande et les détruit une fois terminés
• Économies réalisées : ~700 $/mois
• Calcul : ajustement de la capacité Intel vers AMD (x86)

Le Cost Optimization Hub recommande souvent Graviton pour son excellent rapport qualité-prix, mais Graviton n’est pas toujours un remplacement direct dans les environnements x86. Pour réduire les risques de déploiement et accélérer le temps menant aux économies, nous avons donné la priorité aux familles d’instances x86 de type AMD (par exemple, les variantes « *a ») lorsque la performance et la compatibilité répondaient aux besoins de la charge de travail.

Économies réalisées : ~5 000 $/mois

Les décisions FinOps doivent tenir compte des défis pratiques de la mise en œuvre, et pas seulement des économies potentielles. Dans notre cas, AMD a permis des économies rapides avec peu de modifications d’ingénierie, et nous continuons de planifier l’adoption de Graviton dans de futurs projets lorsque cela correspond à nos objectifs de développement.

Résumé des économies (au-delà du Cost Optimization Hub)

En résumé

FinOps, ce n’est pas qu’une série d’outils : c’est la création d’une culture et de pratiques opérationnelles cohérentes. Le Cost Optimization Hub offre une base solide, mais les résultats à long terme reposent sur la vérification du comportement des systèmes et l’intégration des meilleures pratiques comme norme.

• Passer en revue l’architecture et rechercher les doublons (comme plusieurs équipes qui traitent séparément les mêmes enjeux)
• Définir des valeurs par défaut standards (pour la conservation, le cycle de vie, la hiérarchisation) et s’assurer que les exceptions sont explicites
• Tester les opérations de façon approfondie (y compris la suppression et la restauration de sauvegardes, des tests allant au-delà de la simple vérification des configurations)
• Automatiser la maintenance à l’aide d’une infrastructure comme code et de révisions régulières pour éviter la dérive

Se fier uniquement aux recommandations d’outils peut faire passer sous silence des problèmes tels que des contrôles de journalisation redondants, une conservation excessive des journaux, des ressources réseau inutilisées et des processus de cycle de vie défectueux. La collaboration entre des ingénieurs expérimentés et les équipes FinOps est essentielle pour relever ces défis.

Liste de vérification rapide

Voici quelques autres domaines courants à examiner qui ne sont pas abordés dans le blogue, mais qui méritent d’être investigués :

• Adresses IP élastiques/pubic IPv4 inactives, équilibreurs de charge non utilisés, passerelles NAT, points de terminaison VPC
• Coûts de transfert de données (entre zones de disponibilité, entre régions, sortie Internet)
• Gestion des bases de données et du stockage : expiration DynamoDB (TTL), gestion de paliers, auto-ajustement du stockage RDS et conservation des instantanés
• Pratiques exemplaires pour les conteneurs : politiques du cycle de vie ECR, gestion des nœuds EKS surdimensionnés et contrôles d’ingestion des journaux
• Stratégies d’achat : revoir les cibles de couverture des Savings Plans/RI et la gestion des exceptions
• Replateformage ou réarchitecture : migration vers des OS et bases de données open source, passage au sans serveur, adoption de Graviton et utilisation d’instances Spot
• Revue de l’architecture : Aligner la haute disponibilité, les stratégies de sauvegarde et de relève (DR) selon le niveau de criticité actuel de l’application. Par exemple, avons-nous toujours besoin d’un site de relève tiède ou d’une configuration active-active lorsque la criticité de l’application est révisée à un niveau inférieur ?
• Spécifique à GenAI : dimensionnement optimal des modèles, optimisation des invites, contrôle des réponses du modèle, mise en cache des invites, mise en cache sémantique, routage intelligent des invites et regroupement