L’optimisation des coûts dans les environnements cloud n’est pas seulement une bonne pratique ; c’est une nécessité pour les entreprises qui souhaitent maximiser leur retour sur investissement dans les services cloud. AWS fournit une multitude d’outils et de services pour vous aider à gérer les coûts, mais sans une mise en œuvre et un suivi appropriés, les dépenses peuvent devenir incontrôlables. Dans ce blog, je présenterai un projet récent visant à améliorer la rentabilité dans un environnement AWS en identifiant et en corrigeant les principales inefficacités.
Énoncé du problème
L’une de nos entreprises financières clientes était confrontée à une augmentation des coûts du cloud, en particulier au niveau de son infrastructure AWS prenant en charge des services financiers critiques. Après avoir procédé à un examen complet de leur compte AWS, nous avons découvert plusieurs inefficacités à l’origine de cette augmentation des dépenses. En mettant en œuvre des stratégies ciblées d’optimisation des coûts, nous avons pu aider le client à réduire considérablement ses dépenses cloud tout en garantissant les performances, la sécurité et l’évolutivité requises pour ses opérations financières.
Découvrir les inefficacités
Au début du projet, nous avons identifié les inefficacités suivantes contribuant à l’augmentation des coûts du cloud :
- Manque de marquage approprié sur les services: Sans un marquage cohérent, le suivi de l’utilisation des ressources et l’allocation des coûts deviennent difficiles.
- Absence d’alertes budgétaires: Aucune alerte budgétaire ne peut conduire à des dépenses incontrôlées.
- Aucune allocation budgétaire par environnement: Sans budgets distincts pour différents environnements, il est difficile de gérer et de suivre les coûts avec précision.
- Absence de politique de conservation des journaux CloudWatch: Les journaux stockés indéfiniment augmentent les coûts de stockage.
- Absence de hiérarchisation intelligente S3 : Ne pas utiliser Intelligent-Tiering entraîne des coûts de stockage plus élevés pour les données rarement consultées.
- Sous-utilisation des instances basées sur Graviton : Ne pas utiliser d’instances basées sur Graviton signifie passer à côté d’économies de coûts et d’avantages en termes de performances.
- Ne pas utiliser d’instances Spot dans des environnements inférieurs : Ne pas avoir la possibilité d’utiliser des instances Spot dans des environnements hors production entraîne des coûts plus élevés.
- Environnements de développement et UAT exécutés en dehors des heures de bureau : L’exécution de ces environnements 24h/24 et 7j/7 augmente les coûts inutiles.
Discussion, résolution et étapes concrètes
1. Manque de marquage approprié des services :
L’un des premiers problèmes que nous avons rencontrés était le manque de balisage approprié dans nos services AWS. Les balises sont essentielles pour identifier les ressources, gérer les coûts et maintenir la sécurité. Sans un marquage cohérent, il est difficile d’attribuer les coûts à des projets, des équipes ou des départements spécifiques, ce qui entraîne un suivi financier et une responsabilité inexacts.
Résolution
Pour résoudre ce problème, nous avons mis en œuvre une stratégie de marquage complète. Chaque service était étiqueté avec des détails tels que l’environnement (Dev, UAT, Production), le propriétaire, le nom du projet et le centre de coûts. Les règles AWS Config ont également été définies pour garantir la conformité du balisage, garantissant que toutes les ressources non balisées sont signalées pour correction. Cela a non seulement amélioré la visibilité de nos dépenses, mais a également facilité la génération de rapports de répartition des coûts.
Étapes concrètes
- Définissez une politique de balisage claire qui s’aligne sur votre structure organisationnelle.
- Utilisez AWS Tag Editor pour baliser les ressources existantes.
- Automatisez le balisage lors de la création de ressources à l’aide d’AWS CloudFormation ou Terraform.
2. Absence d’alertes budgétaires :
Dans de nombreuses organisations, les coûts du cloud restent souvent incontrôlés jusqu’à l’arrivée de la facture, ce qui peut être trop tard pour prendre des mesures correctives. C’était le cas dans notre environnement, où il n’existait aucun mécanisme pour nous alerter en cas de dépassement de budget.
Résolution
AWS Budgets me permet de créer des budgets de coûts et d’utilisation personnalisés et de recevoir des alertes lorsque les seuils sont dépassés. Nous avons établi des budgets pour chaque environnement et les avons liés aux notifications SNS pour alerter les parties prenantes lorsque les dépenses atteignaient des niveaux critiques. Cette approche proactive nous a permis de prendre des mesures correctives, telles que la réduction de l’utilisation des ressources ou l’optimisation des services avant que les coûts ne deviennent incontrôlables.
Étapes concrètes
- Configurez des budgets AWS pour chaque compte et environnement.
- Intégrez-le à SNS pour envoyer des alertes par e-mail, SMS ou Slack.
- Examinez régulièrement les rapports budgétaires pour vous assurer que les dépenses correspondent aux attentes.
3. Aucune allocation budgétaire par environnement :
Dans notre configuration AWS, il n’y avait pas de séparation claire des budgets entre les différents environnements, tels que Dev, UAT et Production. Il était donc difficile de déterminer quel environnement contribuait le plus aux coûts et de faire respecter les limites de dépenses.
Résolution
Nous avons établi des budgets distincts pour chaque environnement, ce qui nous permet de surveiller les dépenses de manière plus précise. Cette séparation a également permis d’identifier les environnements qui consommaient inutilement des ressources, nous permettant ainsi de les optimiser en conséquence. Par exemple, nous avons découvert que l’environnement UAT consommait plus de ressources que prévu, ce qui nous a amené à étudier et à optimiser son utilisation.
Étapes concrètes
- Créez des budgets AWS spécifiques à l’environnement.
- Utilisez AWS Cost Explorer pour analyser les tendances de dépenses dans tous les environnements.
- Ajustez les politiques d’allocation et d’utilisation des ressources en fonction des performances budgétaires.
4. Absence de politique de conservation CloudWatch Logs :
Les journaux AWS CloudWatch peuvent s’accumuler rapidement, entraînant des coûts de stockage inutiles s’ils ne sont pas gérés correctement. Dans notre environnement, aucune politique de conservation n’était en place, ce qui signifie que les journaux étaient stockés indéfiniment, même lorsqu’ils n’étaient plus nécessaires.
Résolution
Nous avons mis en place des politiques de conservation des journaux pour supprimer automatiquement les journaux après une certaine période, en fonction de la criticité des données. Par exemple, les journaux des environnements hors production devaient expirer après 30 jours, tandis que les journaux de production étaient conservés pendant 90 jours. Ce simple changement a réduit considérablement nos coûts de stockage.
Étapes concrètes
- Examinez les groupes de journaux CloudWatch existants et définissez les périodes de conservation appropriées.
- Automatisez les politiques de conservation des journaux à l’aide de l’AWS CLI ou des SDK.
- Auditez régulièrement l’utilisation des journaux et ajustez les périodes de conservation si nécessaire.
5. Absence de S3 Intelligent-Tiering : Problème :
Dans notre configuration S3, tous les objets étaient stockés dans la classe de stockage Standard, quels que soient les modèles d’accès. Cela entraînait des coûts de stockage plus élevés, en particulier pour les données rarement consultées qui auraient pu être stockées de manière plus rentable.
Résolution
Nous avons activé S3 Intelligent-Tiering pour les compartiments où les modèles d’accès aux données étaient imprévisibles. S3 Intelligent-Tiering déplace automatiquement les objets entre deux niveaux d’accès (fréquent et peu fréquent) en fonction de l’évolution des modèles d’accès, optimisant ainsi les coûts de stockage. Pour les données consultées encore moins fréquemment, nous les avons déplacées vers Glacier ou Glacier Deep Archive pour un stockage à long terme à une fraction du coût.
Étapes concrètes
- Identifiez les compartiments S3 dans lesquels la hiérarchisation intelligente peut être appliquée.
- Activez Intelligent-Tiering via AWS Management Console ou CLI.
- Utilisez les politiques de cycle de vie S3 pour déplacer les données vers Glacier pour un stockage à long terme.
6. Sous-utilisation des instances basées sur Graviton :
Bien que les instances basées sur AWS Graviton offrent de meilleurs rapports prix-performances, aucune n’était utilisée dans nos environnements. Les instances Graviton sont basées sur ARM et peuvent générer des économies significatives pour les charges de travail compatibles avec l’architecture.
Résolution
Après avoir évalué nos charges de travail, nous en avons identifié plusieurs qui étaient adaptées à la migration vers les instances Graviton. En passant aux instances basées sur Graviton, nous avons réalisé des économies allant jusqu’à 20 % tout en maintenant les performances. Cela s’est avéré particulièrement efficace pour les tâches et les applications gourmandes en calcul qui pouvaient être facilement recompilées ou conteneurisées pour l’architecture ARM.
Étapes concrètes
- Identifiez les charges de travail qui peuvent être migrées vers des instances Graviton.
- Testez et comparez les performances sur les instances basées sur Graviton.
- Implémentez des instances Graviton dans les environnements de développement et de production.
7. Ne pas utiliser d’instances Spot dans des environnements inférieurs :
Les instances Spot offrent des économies significatives, mais n’étaient pas utilisées dans nos environnements hors production. Ces environnements, tels que Dev et UAT, sont généralement plus tolérants aux interruptions, ce qui en fait des candidats idéaux pour les instances Spot.
Résolution
Nous avons remplacé les instances à la demande dans nos environnements inférieurs par des instances Spot, ce qui a permis de réaliser des économies allant jusqu’à 70 %. Pour garantir une perturbation minimale, nous avons utilisé AWS Auto Scaling avec Spot Fleet, qui remplace automatiquement les instances Spot interrompues, garantissant ainsi une disponibilité continue.
Étapes concrètes
- Remplacez les instances à la demande dans les environnements hors production par des instances Spot.
- Utilisez les flottes Spot et Auto Scaling pour gérer les instances Spot.
- Surveillez la disponibilité et les performances de l’instance Spot pour ajuster les configurations si nécessaire.
8. Environnements de développement et UAT exécutés en dehors des heures de bureau : problème :
Dans de nombreuses organisations, y compris la nôtre, les environnements de développement et UAT fonctionnent souvent 24h/24 et 7j/7, même lorsqu’ils ne sont pas utilisés. Cela entraîne des coûts inutiles, surtout lorsque ces environnements ne sont nécessaires que pendant les heures de bureau.
Résolution
Nous avons mis en œuvre des planifications d’arrêt et de démarrage automatisées pour nos environnements de développement et UAT à l’aide d’AWS Lambda et EventBridge. Cela garantissait que ces environnements ne fonctionnaient que pendant les heures de bureau, réduisant ainsi considérablement les coûts sans impacter la productivité. Par exemple, l’arrêt des instances à 19 heures et leur démarrage à 7 heures du matin en semaine ont permis de réaliser près de 60 % d’économies dans nos environnements inférieurs.
Étapes concrètes
- Configurez des planifications automatisées pour les environnements de développement et UAT à l’aide d’AWS Lambda et EventBridge.
- Mettez en œuvre une politique start-stop qui s’aligne sur les heures de travail de votre organisation.
- Surveillez l’utilisation et ajustez les horaires en fonction des modèles d’utilisation réels.
Conclusion
L’optimisation des coûts du cloud est cruciale pour maintenir un environnement AWS efficace. Notre projet a permis une réduction notable des coûts allant jusqu’à 20 % en corrigeant les inefficacités telles qu’un marquage incorrect, le manque d’alertes budgétaires et une utilisation inefficace des ressources. La mise en œuvre d’un balisage complet, d’alertes budgétaires et de budgets spécifiques à l’environnement a amélioré le suivi et le contrôle des dépenses.
L’exploitation des fonctionnalités AWS telles que S3 Intelligent-Tiering, les instances basées sur Graviton et les instances Spot, ainsi que les planifications d’arrêt automatisées, ont permis des économies significatives et une utilisation optimisée des ressources. De plus, la sensibilisation aux coûts au sein des équipes et l’examen régulier de l’utilisation du cloud garantissent une efficacité continue.
En appliquant ces stratégies, nous avons réalisé des économies substantielles et maintenons une gestion efficace des coûts dans notre environnement AWS.
Source link