Stable ajoute 6 recommandations pour aider les équipes à mieux maîtriser leurs coûts AWS

Stable a ajouté six nouvelles recommandations d’optimisation des coûts AWS afin d’aider les équipes à repérer des occasions d’économies précises dans Aurora, DynamoDB, OpenSearch et EBS.

Dans la plupart des environnements AWS, les coûts n’augmentent pas nécessairement du jour au lendemain. Ils s’accumulent souvent à partir de décisions tout à fait logiques au départ. Une base de données est lancée sur Aurora Serverless parce que le trafic est imprévisible. Un index DynamoDB est créé pour soutenir une fonctionnalité. Une charge de travail OpenSearch demeure en mode On-Demand en attendant que les tendances d’utilisation se précisent. Un volume EBS reste attaché parce que personne n’est tout à fait certain qu’il est encore nécessaire.

Avec le temps, ces décisions peuvent ne plus refléter la réalité.

Les nouvelles recommandations de Stable aident les équipes à repérer ces écarts. Elles signalent les ressources qui pourraient fonctionner avec un modèle de tarification mal adapté, être sous-utilisées ou être prêtes pour une configuration plus économique.

1. Migrer les charges Aurora Serverless prévisibles vers des instances provisionnées

Aurora Serverless est un excellent choix lorsque la demande est imprévisible ou de très forte montée en charge pendant de courte durée. Il offre aux équipes de la flexibilité, puisque la capacité peut augmenter ou diminuer selon les besoins de la charge de travail.

Mais lorsque l’utilisation devient stable, cette flexibilité peut coûter plus cher que nécessaire.

Si une base de données Aurora Serverless fonctionne depuis assez longtemps pour démontrer une tendance claire, et si sa plage d’utilisation en ACU est constante et prévisible, une instance Aurora provisionnée pourrait être plus rentable. Les économies peuvent être encore plus importantes si l’instance est couverte par une Reserved Instance d’un an.

Cette recommandation est pertinente lorsque :

• La charge de travail compte au moins 31 jours d’historique d’utilisation.
• La consommation en ACU demeure dans une plage prévisible.
• Les économies annuelles projetées sont significatives.
• L’application n’a pas besoin d’une mise à l’échelle rapide et imprévisible.

La migration d’Aurora Serverless vers Aurora provisionné exige de créer un nouveau cluster, de le restaurer à partir d’un instantané, de valider le nouvel environnement, de mettre à jour les endpoints et de décommissionner l’ancien cluster seulement une fois les tests terminés.

La question est simple : payez-vous encore pour de la flexibilité parce que vous en avez besoin, ou parce que personne n’a réévalué la configuration initiale?

2. Passer le stockage Aurora de Standard à IO-Optimized

Le stockage Aurora Standard peut être rentable pour les charges de travail avec une activité I/O modérée. Mais lorsque les frais d’I/O représentent une part importante de la facture, Aurora IO-Optimized peut devenir une meilleure option.

Avec Aurora Standard, vous payez pour le stockage et les requêtes I/O. Avec Aurora IO-Optimized, le stockage coûte plus cher par Go, mais les frais d’I/O sont éliminés. Pour les charges à forte intensité I/O, ce compromis peut réduire le coût total.

Stable signale cette occasion lorsque les frais d’I/O représentent une part importante des coûts combinés de stockage et d’I/O d’Aurora.

Cette recommandation est pertinente lorsque :

• Le cluster Aurora génère une forte activité I/O.
• Les frais d’I/O représentent environ 25 % ou plus des coûts combinés de stockage et d’I/O.
• La charge de travail devrait continuer à générer un volume élevé d’I/O.
• Les économies projetées justifient le changement.

Le changement peut être appliqué en ligne, sans interruption ni redémarrage d’instance. Il doit tout de même être évalué avec soin. Une fois qu’un cluster passe à IO-Optimized, il ne peut pas revenir à Standard pendant au moins 30 jours.

C’est un bon exemple de la raison pour laquelle l’optimisation des coûts AWS ne peut pas se limiter au prix unitaire. L’option qui semble moins chère ne l’est pas toujours lorsque l’utilisation réelle est prise en compte.

3. Supprimer les index DynamoDB inutilisés

Les Global Secondary Indexes sont utiles lorsque les applications doivent prendre en charge d’autres modèles de requêtes. Mais ils peuvent aussi devenir des vestiges coûteux lorsque ces requêtes ne sont plus utilisées.

Stable identifie les tables ou les index DynamoDB qui n’ont enregistré aucune activité de lecture au cours des 30 derniers jours. Pour un GSI inutilisé, les économies potentielles peuvent inclure les coûts de stockage de l’index et les coûts de capacité en écriture.

Cette recommandation est pertinente lorsque :

• Un GSI DynamoDB n’a aucune activité de lecture.
• L’index génère encore des coûts de stockage ou de capacité.
• Aucune application, tâche, rapport, interface d’administration ou autre processus n’en dépend.
• L’équipe de développement confirme qu’il peut être supprimé sans risque.

C’est le genre de recommandation qui semble simple, mais qui demande une vraie validation.

La suppression d’un GSI est permanente. Si l’application en dépend encore, certaines requêtes peuvent cesser de fonctionner. Recréer l’index par la suite exige une réindexation complète de la table, ce qui peut prendre du temps et consommer de la capacité en écriture.

Oui, les index inutilisés doivent être remis en question. Mais ils ne doivent pas être supprimés simplement parce qu’un tableau de bord les considère comme inactifs.

Le bon réflexe consiste à confirmer le propriétaire, vérifier les dépendances applicatives, revoir les modèles de requêtes et documenter l’approbation avant de supprimer quoi que ce soit.

4. Migrer les tables DynamoDB peu consultées vers Standard-Infrequent Access

Certaines tables DynamoDB sont rarement consultées.

Elles peuvent contenir des historiques, des données d’audit, des dossiers clients, des journaux opérationnels ou d’autres données qui doivent rester disponibles sans être interrogées en continu. Dans ces cas, la classe de table Standard n’est pas toujours l’option la plus rentable.

DynamoDB Standard-Infrequent Access offre des coûts de stockage plus bas, avec des coûts de lecture et d’écriture légèrement plus élevés. Cette option peut être très intéressante lorsque le stockage représente la majorité du coût de la table et que l’accès aux données est faible.

Cette recommandation est pertinente lorsque :

• Une table DynamoDB génère des coûts de stockage élevés.
• L’activité de lecture et d’écriture est faible.
• La table ne fait pas partie d’une configuration Global Table.
• Les coûts de stockage dominent les coûts de débit.
• Les économies projetées sont significatives.

L’élément clé, c’est le modèle d’accès. Standard-IA n’est pas automatiquement plus avantageux simplement parce que son stockage coûte moins cher. Si une table est interrogée fréquemment, les coûts de requêtes plus élevés peuvent réduire ou annuler les économies.

Il faut aussi tenir compte de la stratégie d’engagement. Les tables Standard-IA ne peuvent pas bénéficier de DynamoDB Reserved Capacity. Pour les tables en capacité provisionnée qui pourraient être admissibles à Reserved Capacity, les deux options doivent être comparées avant de prendre une décision.

5. Acheter des Reserved Instances pour les charges OpenSearch stables

OpenSearch peut devenir coûteux lorsque des charges de travail stables restent en tarification On-Demand.

Pour les domaines dont l’utilisation est prévisible, les Reserved Instances peuvent réduire les coûts par rapport aux tarifs On-Demand. Stable identifie les nœuds OpenSearch qui ne sont pas actuellement couverts par des Reserved Instances et dont l’utilisation est suffisamment stable pour justifier une décision d’engagement.

Cette recommandation est pertinente lorsque :

• Les nœuds OpenSearch fonctionnent de manière constante.
• Le type d’instance et la région ne devraient pas changer prochainement.
• La charge de travail devrait se poursuivre pendant toute la durée de l’engagement.
• Les économies projetées justifient un engagement d’un an ou de trois ans.

Les Reserved Instances peuvent offrir de bons rabais, mais elles représentent aussi un engagement.

Les Reserved Instances OpenSearch sont liées à un type d’instance et à une région spécifiques. Si la charge de travail change, la RI pourrait ne plus convenir. Les équipes pourraient devoir vendre la RI inutilisée sur AWS Marketplace ou continuer à la payer jusqu’à la fin du terme.

Avant d’acheter, il faut revoir la feuille de route. Le domaine sera-t-il redimensionné? La famille d’instances changera-t-elle? Une migration est-elle prévue? La charge de travail est-elle assez stable pour justifier un engagement?

6. Supprimer les volumes EBS inactifs

Les volumes EBS sont faciles à créer, et tout aussi faciles à oublier.

Un volume peut avoir servi à un test, une migration, une charge temporaire, un processus de sauvegarde ou un ancien chemin applicatif. S’il reste attaché à une instance EC2 en cours d’exécution, mais qu’il montre peu ou pas d’activité I/O, il peut générer des coûts sans fournir de réelle valeur.

Stable identifie les volumes EBS attachés à des instances EC2 actives qui présentent très peu d’activité de lecture et d’écriture au cours des 30 derniers jours.

Cette recommandation est pertinente lorsque :

• Le volume affiche une très faible activité I/O.
• Le volume n’est pas un volume racine.
• Les données ne sont plus nécessaires.
• Un instantané a été créé avant la suppression.
• Le propriétaire confirme qu’il peut être supprimé sans risque.

C’est l’une des occasions d’économies les plus directes, mais elle exige tout de même une stratégie claire.

La suppression d’un volume EBS est permanente, à moins qu’un instantané ait été créé. Les volumes racines demandent une attention particulière, puisque leur suppression ou leur détachement peut affecter l’instance elle-même. Avant de supprimer quoi que ce soit, les équipes doivent vérifier les points de montage, les dépendances applicatives, l’état des sauvegardes et le propriétaire de la ressource.

Ce que ces recommandations ont en commun

Ces six recommandations sont différentes, mais elles reposent sur la même logique.

Stable repère les écarts entre les ressources AWS et le comportement réel des charges de travail.

Cela peut vouloir dire :

• Une base de données flexible qui est devenue prévisible.
• Un modèle de stockage qui ne correspond plus au profil I/O.
• Un index qui ne soutient plus de requêtes actives.
• Une classe de table qui ne reflète plus le modèle d’accès.
• Une charge de travail assez stable pour justifier un engagement.
• Un volume qui ne semble plus remplir de fonction utile.

C’est là que l’optimisation des coûts AWS devient opérationnelle.

Les meilleures occasions d’économies ne sont pas toujours les plus évidentes. Elles se trouvent souvent dans des choix de configuration qui étaient raisonnables au moment où ils ont été faits, mais qui n’ont pas été réévalués depuis.

Le mot de la fin

Avec ces nouvelles recommandations, Stable donne aux équipes plus de visibilité sur les ressources AWS qui peuvent avoir un impact direct sur les coûts mensuels. Elles permettent d’identifier de nouvelles occasions d’économies et de les analyser, les prioriser et les valider avec le bon contexte technique.

Pour les équipes qui gèrent des environnements AWS en croissance, c’est important. L’optimisation des coûts devient moins réactive, moins manuelle et plus connectée à la façon dont les charges de travail fonctionnent réellement.

Commencez votre essai gratuit dès aujourd’hui!