Mes coûts d’infrastructure cachés ont tué mon budget

Salut tout le monde, Jules Martin ici, de retour sur agntmax.com. J’espère que vous vous en sortez tous bien. Aujourd’hui, je veux parler de quelque chose qui me tracasse dernièrement, quelque chose que j’ai vu surgir dans plus de conversations et de post-mortems de projet que je ne veux l’admettre : le tirage invisible des coûts d’infrastructure non optimisés. Nous savons tous qu’il faut construire rapidement, évoluer vite et livrer des fonctionnalités hier. Mais souvent, dans cette précipitation, 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 à peine jetons un coup d’œil avant que la révision budgétaire trimestrielle ne tombe comme une tonne de briques.

Donc, pour cet article, je plonge tête première dans l’optimisation des coûts, mais avec un angle très spécifique et opportun : comment arrêter de perdre de l’argent sur des ressources « toujours allumées » qui devraient être « à la demande » ou « déclenchées par événement. » Nous sommes en 2026, les gens. Les jours de la provision de serveurs à la carte sont révolus. Si votre facture cloud ressemble encore à un annuaire téléphonique, il est temps d’intervenir.

Le Tueur Silencieux : Toujours Allumé Quand Cela Devrait Être À la Demande

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

J’ai vu cela de mes propres yeux il y a quelques mois avec le nouveau tableau de bord d’analytique interne d’un client. L’équipe, que Dieu les bénisse, avait construit un système fantastique qui fournissait 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 complète est arrivée, le directeur financier a failli avoir une attaque cardiaque. Ils avaient provisionné un cluster EKS robuste, quelques instances RDS haut de gamme, et une multitude de fonctions Lambda avec des allocations de mémoire généreuses, toutes fonctionnant sans interruption. Le clou du spectacle ? Le tableau de bord était principalement utilisé par les agents pendant les heures de bureau, de 9h à 17h, 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.

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

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

Les Suspects Habituels

• Instances de Calcul (EC2, VMs) : Ce sont souvent les plus gros coupables. Sont-elles surdimensionnées ? Fonctionnent-elles quand elles ne devraient pas 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 pour les IOPS, le CPU ou la mémoire. Beaucoup offrent désormais des options sans serveur qui se réduisent à zéro ou à un coût proche de zéro lorsqu’elles sont inactives.
• Stockage (volumes EBS, disques non attaché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 le pensez.
• Réseautage (Transfert de données, NAT Gateways) : Les coûts de transfert de données peuvent vous surprendre, surtout entre régions. Les NAT Gateways 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 filet de messages ?

Mon client du récit du tableau de bord d’analytique a commencé par regarder son AWS Cost Explorer. Les plus gros postes de dépenses étaient, prévisiblement, EC2 et RDS. Ils ont également trouvé quelques volumes EBS attachés à des instances terminées et une NAT Gateway dans une VPC qui n’était plus utilisée pour le trafic de production. Des petites choses, mais cela s’accumule.

Stratégies pour Transformer Toujours Allumé en À la Demande (ou Hors-Peak)

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

1. Planifiez le Démarrage/Arrêt des Instances

C’est probablement le fruit le plus facile pour de nombreuses applications. Si vos outils internes ou vos environnements de staging 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 de cloud proposent des moyens natifs de planifier des cycles d’alimentation des instances, ou vous pouvez créer votre propre solution avec des fonctions sans serveur.

Exemple Pratique : Planificateur EC2 AWS 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 des instances EC2 en fonction 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'
 
 # Récupérer 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 des instances à un autre moment ---
 # Vous auriez une autre Lambda/CloudWatch Event pour démarrer,
 # ou combiner la logique avec un tag 'start'.
 
 return {
 'statusCode': 200,
 'body': 'Planification des instances EC2 terminée.'
 }

Vous devriez configurer deux règles d’événements CloudWatch : l’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 à lui seul 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 allié. AWS Lambda, Azure Functions, Google Cloud Functions – elles se réduisent à zéro lorsque non utilisées, ce qui signifie que vous ne payez que pour le calcul lorsque votre code s’exécute réellement. C’est un énorme changement par rapport au paradigme « toujours allumé ».

Pour des applications plus complexes qui nécessitent toujours des services persistants mais ont une demande fluctuante, les plateformes d’orchestration de conteneurs comme Kubernetes (EKS, AKS, GKE) combinées avec une mise à l’échelle intelligente sont puissantes. Les Horizontal Pod Autoscalers (HPA) peuvent faire varier la taille de vos pods d’application en fonction de l’utilisation du CPU ou de métriques personnalisées. Les Cluster Autoscalers peuvent même ajouter ou retirer des nœuds de votre cluster au fur et à mesure que la demande change.

Mon client a refactorisé des parties de son tableau de bord d’analytique pour utiliser Lambda pour 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 cron job, une fonction Lambda était déclenchée par un événement S3 (nouveaux fichiers téléchargés) ou une requête API Gateway. Les économies étaient immédiates et significatives.

3. Dimensionnez Correctement Vos Bases de Données avec le Sans Serveur ou l’Auto-Scalabilité

Les bases de données sont souvent problématiques car la persistance des données est critique. Cependant, de nombreuses bases de données modernes offrent des options sans serveur ou d’auto-scaling qui n’étaient pas largement disponibles il y a quelques années.

• AWS Aurora Serverless v2 : C’est un changement significatif. Il ajuste la capacité en fonction de l’utilisation réelle, allant de fractions d’un 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 fonctionnez à base charge.
• Azure SQL Database Serverless : Semblable à Aurora Serverless, il s’adapte automatiquement à la capacité de calcul et se met en pause lorsqu’il est inactif, réalisant des économies significatives pour les 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 d’analytique utilisait à l’origine une instance RDS PostgreSQL grande 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. Nettoyez les Stockages Non Attachés et les Snapshots

Cela peut sembler basique, mais c’est une source constante de gaspillage d’argent. 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 snapshots – ils s’accumulent rapidement et peuvent devenir coûteux.

Exemple Pratique : Trouver et Supprimer des Volumes EBS Non Attachés (AWS CLI)

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

# Lister 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 (FAITES ATTENTION, C'EST IRRÉVERSIBLE)
# Remplacez 'vol-xxxxxxxxxxxxxxxxx' par l'ID du 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 souvent 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 permis d’économiser quelques centaines de dollars sur leur facture mensuelle – ce n’est pas énorme, mais chaque petit geste compte.

5. Optimiser les Coûts Réseau

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

• Consolidez les NAT Gateways : Si votre architecture le permet, consolidez vers moins de NAT Gateways.
• Endpoints VPC : Pour accéder aux services AWS comme S3 ou DynamoDB depuis votre VPC, utilisez des Endpoints VPC. Le trafic circule de manière privée au sein du réseau AWS, évitant les coûts des NAT Gateways et offrant une meilleure sécurité.

Nous avons constaté que le client avait un NAT Gateway dans chaque AZ, même si son application principale ne fonctionnait que dans deux. Ils ont pu consolider et réaliser des économies par là, puis ont ensuite mis en œuvre des Endpoints VPC pour l’accès à S3, ce qui a réduit les coûts de traitement des données via le NAT Gateway.

Actions à Entreprendre 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, 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 : En faites-en une habitude. Utilisez les outils de gestion des coûts de votre fournisseur cloud. Ne le remettez pas uniquement aux finances. Comprenez où va chaque dollar.
2. Taguez Tout : Ceci 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 facilite énormément l’identification et l’automatisation.
3. Priorisez la Programmation pour les Environnements Non Produits : Les environnements de staging, dev, QA sont des candidats idéaux pour les arrêts programmés en dehors des heures de bureau. C’est généralement le gain le plus facile et le plus rapide.
4. Évaluez le Serveurless pour les 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, considérez toujours le serverless en premier.
5. Réévaluez Vos Choix de Base de Données : Si vous avez des bases de données fonctionnant 24/7 avec des charges très 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 autres ressources orphelines.
7. Éduquez Votre Équipe : Favorisez une culture de la 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’opérations.

Arrêter les pertes liées aux ressources « toujours actives » n’est pas une solution ponctuelle ; c’est une discipline continue. Mais en apportant ces changements, vous économiserez non seulement une somme d’argent significative pour votre entreprise, mais vous construirez également une infrastructure plus agile, résiliente et prête pour l’avenir. Et franchement, cela fait de vous un meilleur acteur dans le domaine technologique.

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

🕒 Published: March 27, 2026