Mes coûts d’infrastructure cachés mettaient mon budget à mal

Salut tout le monde, Jules Martin ici, de retour sur agntmax.com. J’espère que vous déchirez tout là-bas. Aujourd’hui, je veux parler de quelque chose qui me tracasse dernièrement, quelque chose que j’ai vu apparaître dans plus de conversations et d’analyses de projets que je ne veux l’admettre : le coût invisible d’une infrastructure non optimisée. Nous savons tous que nous devons construire vite, évoluer rapidement, et livrer des fonctionnalités hier. Mais souvent, dans cette course folle, nous laissons derrière nous une traînée de ressources oubliées, d’instances surdimensionnées, et de services fonctionnant en pilote automatique, accumulant des factures que nous ne regardons à peine jusqu’à ce que la révision budgétaire trimestrielle arrive comme un coup de tonnerre.

Donc, pour cet article, je me plonge tête baissée dans l’optimisation des coûts, mais avec un angle très spécifique et opportun : comment arrêter de saigner de l’argent sur des ressources « toujours actives » qui devraient être « à la demande » ou « déclenchées par des événements. » Nous sommes en 2026, les amis. Les jours où l’on provisionne des serveurs en mode « configurer et oublier » sont révolus. Si votre facture cloud ressemble toujours à un annuaire, il est temps d’intervenir.

Le Tueur Silencieux : Toujours Actif Alors Qu’il Devrait Être À la Demande

Soyons réalistes. Lorsque nous sommes sous pression pour sortir un nouvel outil destiné aux agents ou une amélioration du service client, le coût prend généralement un siège passager par rapport à la fonctionnalité et à la vitesse. Nous provisionnons une instance EC2 qui est « assez grande », peut-être même « un peu plus grande au cas où. » Nous lançons une base de données avec des IOPS provisionnées qui pourraient gérer l’ensemble d’Internet, seulement pour qu’elle soit principalement inoccupée pendant les heures creuses. Nous oublions de mettre en place des politiques de mise à l’échelle appropriées, ou nous laissons simplement des choses fonctionner 24/7 parce que, eh bien, c’est plus facile que d’y penser.

J’ai vu cela de mes propres yeux il y a quelques mois avec le nouveau tableau de bord analytique interne d’un client. L’équipe, que Dieu la bénisse, avait construit un système fantastique qui donnait aux agents des aperçus en temps réel des interactions avec les clients. C’était une énorme victoire pour la performance. Mais lorsque la première facture cloud est arrivée, le CFO a failli avoir une attaque cardiaque. Ils avaient provisionné un cluster EKS robuste, quelques instances RDS haut de gamme, et toute une série de fonctions Lambda avec des allocations de mémoire généreuses, toutes fonctionnant sans interruption. Le hic ? Le tableau de bord était principalement utilisé par des agents pendant les heures de bureau, de 9 h à 17 h, du lundi au vendredi. En dehors de cela, c’était une ville fantôme.

Ils payaient pour une capacité de niveau entreprise pour un système qui était effectivement inactif 70 % de la semaine. C’est comme acheter une voiture de Formule 1 pour aller au supermarché une fois par semaine.

Identifier les Coupables : Où Va Réellement Votre Argent

Avant de pouvoir réparer quoi que ce soit, vous devez savoir ce qui ne va pas. La plupart des fournisseurs cloud proposent des outils pour vous aider à visualiser vos dépenses, et vous devez absolument les utiliser. AWS Cost Explorer, Azure Cost Management, les rapports de facturation de Google Cloud – ce ne sont pas que pour les finances. Ils sont votre première ligne de défense.

Les Suspects Habituellement Impliqués

• Instances de Calcul (EC2, VMs) : Ce sont souvent les plus gros délinquants. Sont-elles surdimensionnées ? Fonctionnent-elles quand elles n’ont pas besoin de l’être ? Utilisez-vous la bonne famille d’instances pour votre charge de travail ?
• bases de données (RDS, Azure SQL, Cloud SQL) : Comme pour le calcul, les bases de données peuvent être sur-provisionnées en IOPS, CPU ou mémoire. De nombreuses options sans serveur sont désormais disponibles, qui descendent à zéro ou presque lorsque inactives.
• Stockage (volumes EBS, disques détachés) : Avez-vous déjà lancé une instance, l’avez-vous terminée, mais laissé le volume de stockage associé traîner ? Cela arrive plus souvent que vous ne le pensez.
• Réseautage (transfert de données, passerelles NAT) : Les coûts de transfert de données peuvent vous surprendre, surtout entre régions. Les passerelles NAT ont également un coût horaire, même si elles ne font rien.
• Services sous-utilisés : Payez-vous pour un cache Redis dédié qui n’a que quelques accès par jour ? Un cluster Kafka géré pour un file d’attente de messages ?

Mon client du récit du tableau de bord analytique a commencé par examiner son AWS Cost Explorer. Les plus gros postes étaient, sans surprise, EC2 et RDS. Ils ont également trouvé quelques volumes EBS attachés à des instances terminées et une passerelle NAT dans un VPC qui n’était plus utilisée activement pour le trafic de production. Des petites choses, mais ça s’additionne.

Stratégies pour Transformer Toujours-Actif en À la Demande (ou Hors-Pic)

D’accord, vous avez identifié les domaines où vous dépensez trop. Maintenant pour la partie amusante : le réparer. L’objectif n’est pas seulement d’économiser de l’argent, mais de créer un système plus résilient et efficace qui ne consomme des ressources que lorsqu’il en a réellement besoin.

1. Planifier Démarrage/Arrêt des Instances

C’est probablement le fruit le plus facile à atteindre pour de nombreuses applications. Si vos outils internes ou environnements de mise en scène ne sont utilisés que pendant les heures de bureau, il n’y a aucune raison qu’ils fonctionnent 24/7. La plupart des fournisseurs cloud offrent des moyens natifs de programmer des cycles de puissance des instances, ou vous pouvez créer votre propre solution avec des fonctions sans serveur.

Exemple Pratique : Planificateur AWS EC2 avec Lambda

Vous pouvez créer une simple fonction Lambda déclenchée par des événements CloudWatch (expressions CRON) pour arrêter et démarrer les instances EC2 sur la base des tags. Voici une version simplifiée du code de la fonction Lambda (Python) :

import boto3

def lambda_handler(event, context):
 ec2 = boto3.client('ec2')
 
 # Définir des tags pour identifier les instances à arrêter/démarrer
 # Par exemple, 'Schedule': 'business-hours'
 
 # Obtenir toutes les instances en cours d'exécution avec le tag 'Schedule' défini sur 'business-hours'
 running_instances = ec2.describe_instances(
 Filters=[
 {'Name': 'instance-state-name', 'Values': ['running']},
 {'Name': 'tag:Schedule', 'Values': ['business-hours']}
 ]
 )
 
 stop_instance_ids = []
 for reservation in running_instances['Reservations']:
 for instance in reservation['Instances']:
 stop_instance_ids.append(instance['InstanceId'])
 
 if stop_instance_ids:
 print(f"Arrêt des instances : {stop_instance_ids}")
 ec2.stop_instances(InstanceIds=stop_instance_ids)
 else:
 print("Aucune instance à arrêter.")
 
 # --- Logique similaire pour démarrer les instances à un autre moment ---
 # Vous auriez une autre fonction Lambda/événement CloudWatch pour le démarrage,
 # ou combiner la logique avec un tag 'start'.
 
 return {
 'statusCode': 200,
 'body': 'Planification des instances EC2 terminée.'
 }

Vous configureriez deux règles d’événements CloudWatch : une pour déclencher cette Lambda, disons, à 18h UTC pour arrêter les instances, et une autre à 7h UTC pour les démarrer. Cela peut réduire les coûts de calcul de plus de 70 % pour ces ressources spécifiques.

2. Adoptez le Sans-Serveur et l’Orchestration de Conteneurs

Si votre charge de travail est vraiment sporadique ou déclenchée par des événements, le sans-serveur est votre meilleur ami. AWS Lambda, Azure Functions, Google Cloud Functions – ils descendent à zéro lorsque non utilisés, ce qui signifie que vous ne payez que pour le calcul lorsque votre code est réellement exécuté. C’est un changement énorme par rapport à la notion de « toujours actif ».

Pour des applications plus complexes qui ont encore besoin de services persistants mais ont une demande fluctueuse, les plateformes d’orchestration de conteneurs comme Kubernetes (EKS, AKS, GKE) combinées avec une mise à l’échelle intelligente sont puissantes. Les autoscalers de pods horizontaux (HPA) peuvent faire monter ou descendre vos pods d’application en fonction de l’utilisation du CPU ou de métriques personnalisées. Les autoscalers de clusters peuvent même ajouter ou retirer des nœuds de votre cluster en fonction de l’évolution de la demande.

Mon client a refactorisé certaines parties de son tableau de bord analytique pour utiliser Lambda afin de générer certains rapports qui n’étaient demandés que quelques fois par jour. Au lieu d’une instance EC2 dédiée exécutant un job cron, une fonction Lambda était déclenchée par un événement S3 (nouveaux données téléchargées) ou une requête API Gateway. Les économies réalisées étaient immédiates et significatives.

3. Dimensionnez Correctement Vos Bases de Données avec Sans-Serveur ou Auto-Mise à l’Échelle

Les bases de données sont souvent un sujet délicat car la persistance des données est essentielle. Cependant, de nombreuses bases de données modernes proposent des options sans serveur ou d’auto-mise à l’échelle qui n’étaient pas largement disponibles il y a quelques années.

• AWS Aurora Serverless v2 : C’est un changement significatif. Elle adapte sa capacité en fonction de l’utilisation réelle, de fractions d’une ACU (Unité de Capacité Aurora) jusqu’à des centaines, et vous ne payez que pour ce que vous utilisez. Plus besoin de provisionner pour une capacité de pointe alors que la plupart du temps vous opérez à charge de base.
• Azure SQL Database Serverless : Similaire à Aurora Serverless, elle ajuste automatiquement le calcul et se met en pause lorsqu’elle est inactive, économisant ainsi des coûts significatifs pour des charges de travail intermittentes.
• DynamoDB On-Demand : Pour les charges de travail NoSQL, le mode de capacité à la demande de DynamoDB signifie que vous payez par requête, sans avoir à provisionner des unités de capacité de lecture/écriture. Parfait pour des modèles de trafic imprévisibles.

Le tableau de bord analytique utilisait à l’origine une grande instance RDS PostgreSQL avec des IOPS provisionnées. Après migration vers Aurora Serverless v2, leurs coûts de base de données ont chuté de près de 60 %, simplement parce qu’elle ne fonctionnait plus à plein régime pendant les heures creuses.

4. Nettoyer le Stockage Détaché et les Instantanés

Cela peut sembler basique, mais c’est une source constante de dépenses inutiles. Lorsque vous terminez une instance EC2, son volume EBS associé n’est pas toujours supprimé par défaut, surtout s’il s’agissait d’un volume non racine. Il en va de même pour les instantanés – ils s’accumulent rapidement et peuvent devenir coûteux.

Exemple Pratique : Trouver et Supprimer les Volumes EBS Détachés (AWS CLI)

Vous pouvez utiliser l’AWS CLI pour trouver des volumes détachés et les supprimer. C’est une tâche de nettoyage courante.

# Liste de tous les volumes non attachés
aws ec2 describe-volumes --filters Name=status,Values=available --query 'Volumes[*].[VolumeId,Size,CreateTime]' --output table

# Pour supprimer un volume spécifique (SOYEZ PRUDENT, C’EST IRRÉVERSIBLE)
# Remplacez 'vol-xxxxxxxxxxxxxxxxx' par l'ID de volume réel
# aws ec2 delete-volume --volume-id vol-xxxxxxxxxxxxxxxxx

Automatisez cela avec une fonction Lambda programmée si vous créez et supprimez fréquemment des environnements. Le client a découvert plusieurs téraoctets de vieux volumes EBS non attachés et des centaines de snapshots obsolètes. Les supprimer a réduit sa facture mensuelle de quelques centaines de dollars – pas énorme, mais chaque petit geste compte.

5. Optimisez les Coûts Réseau

Les passerelles NAT sont fantastiques pour permettre aux instances dans des sous-réseaux privés d’accéder à Internet, mais elles entraînent des frais horaires et des frais de traitement des données. Si vous avez plusieurs passerelles NAT dans différentes zones de disponibilité, mais qu’une seule est utilisée activement, vous payez pour des redondantes.

• Consolidez les Passerelles NAT : Si votre architecture le permet, réduisez le nombre de passerelles NAT.
• Points d’accès VPC : Pour accéder aux services AWS comme S3 ou DynamoDB depuis votre VPC, utilisez les points d’accès VPC. Le trafic circule en privé au sein du réseau AWS, évitant ainsi les coûts de passerelle NAT et offrant une meilleure sécurité.

Nous avons constaté que le client avait une passerelle NAT dans chaque AZ, même si son application principale ne fonctionnait que dans deux. Ils ont pu consolider et économiser un peu à cet endroit, puis ont mis en œuvre des points d’accès VPC pour l’accès à S3, ce qui a réduit les coûts de traitement des données via la passerelle NAT.

Actions à Prendre pour Votre Prochain Sprint

Ce n’est pas seulement une question de réduction des coûts ; il s’agit de construire des systèmes plus intelligents et plus efficaces qui sont intrinsèquement conscients des coûts. Voici ce que vous pouvez commencer à faire dès aujourd’hui :

1. Auditez Régulièrement Votre Facture Cloud : Faites-en une habitude. Utilisez les outils de gestion des coûts de votre fournisseur cloud. Ne vous contentez pas de le transmettre au service financier. Comprenez où va chaque dollar.
2. Taguez Tout : C’est non-négociable. Taguez les ressources par projet, propriétaire, environnement (dev, staging, prod), et si elles peuvent être programmées pour l’arrêt. Cela rend l’identification et l’automatisation infiniment plus faciles.
3. Priorisez la Planification pour les Environnements Non-Prod : Les environnements de staging, dev et QA sont des candidats idéaux pour des arrêts programmés en dehors des heures de travail. C’est généralement la victoire la plus facile et la plus rapide.
4. Évaluez le Serverless pour de Nouvelles Charges de Travail : Si vous construisez quelque chose de nouveau, en particulier des microservices basés sur des événements ou des tâches en arrière-plan, envisagez toujours le serverless en premier.
5. Réévaluez les Choix de Bases de Données : Si vous avez des bases de données fonctionnant 24/7 avec des charges hautement variables, examinez les options serverless ou d’auto-scaling pour votre technologie de base de données spécifique.
6. Automatisez le Nettoyage : Mettez en œuvre des scripts automatisés ou des fonctions serverless pour identifier et supprimer les volumes de stockage non attachés, les anciens snapshots et d’autres ressources orphelines.
7. Éduquez Votre Équipe : Favorisez une culture de sensibilisation aux coûts. Assurez-vous que les développeurs comprennent les implications financières de leurs choix de provisionnement. Ce n’est plus seulement un problème d’exploitation.

Arrêter la fuite des ressources « toujours actives » n’est pas une solution ponctuelle ; c’est une discipline continue. Mais en opérant ces changements, vous économiserez non seulement une somme d’argent considérable pour votre entreprise, mais vous construirez également une infrastructure plus agile, résiliente et pérenne. Et, franchement, cela vous rend tout simplement meilleur dans le domaine technologique.

C’est tout pour moi cette fois. Continuez à construire intelligemment, et je vous retrouve à la prochaine !

🕒 Published: March 27, 2026