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 êtes tous en pleine forme. Aujourd’hui, je veux parler de quelque chose qui me préoccupe récemment, quelque chose que j’ai vu surgir dans plus de conversations et de post-mortems de projet que je ne veux l’admettre : le coût invisible des infrastructures non optimisées. Nous savons tous que nous devons construire rapidement, évoluer rapidement et livrer des fonctionnalités hier. Mais souvent, dans cette course folle, nous laissons derrière nous un sillage de ressources oubliées, d’instances surdimensionnées et de services fonctionnant en pilote automatique, accumulant des factures que nous à peine regardons jusqu’à ce que la révision trimestrielle du budget nous tombe dessus comme un coup de massue.

Donc, pour cet article, je 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 perdre de l’argent sur des ressources « toujours actives » qui devraient être « à la demande » ou « déclenchées par un événement. » Nous sommes en 2026, les gens. Les jours de la provision de serveurs que l’on règle et oublie sont depuis longtemps révolus. Si votre facture de cloud ressemble toujours à un annuaire téléphonique, il est temps d’intervenir.

Le Tueur Silencieux : Toujours Actif Quand Cela Devrait Être À La Demande

Soyons lucides. Lorsque nous sommes sous pression pour obtenir un nouvel outil à destination des agents ou une amélioration du service client, le coût est souvent relégué 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 au cas où. » Nous lançons une base de données avec des IOPS provisionnés capables de gérer l’ensemble d’Internet, seulement pour qu’elle reste principalement inactive 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 d’y penser.

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 la bénisse, avait construit un système fantastique qui fournissait aux agents des informations en temps réel sur les interactions avec les clients. C’était une grande victoire pour les performances. Mais lorsque la première facture complète du cloud est arrivée, le directeur financier a failli faire une crise cardiaque. Ils avaient provisionné un cluster EKS puissant, 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 les agents pendant les heures de bureau, de 9h à 17h, du lundi au vendredi. En dehors de ça, c’était une ville fantôme.

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

Identifiez les Coupables : Où Va Vraiment Votre Argent

Avant de pouvoir réparer quoi que ce soit, vous devez savoir ce qui ne va pas. 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 seulement pour la finance. 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 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 surprovisionnées pour les IOPS, le CPU ou la mémoire. Beaucoup offrent désormais des options sans serveur qui diminuent à zéro ou presque zéro coût lorsqu’elles sont inactives.
• Stockage (volumes EBS, disques non attachés) : Avez-vous déjà lancé une instance, l’avez-vous supprimée, mais laissé le volume de stockage associé traîner ? Cela arrive plus souvent qu’on ne le pense.
• Réseautage (transfert de données, NAT Gateways) : Les coûts de transfert de données peuvent vous surprendre, surtout lors de transferts inter-régions. Les NAT Gateways ont également un coût horaire, même s’ils 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 de l’histoire 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 un NAT Gateway dans une VPC qui n’était plus activement utilisé pour le trafic de production. Des petites choses, mais cela s’accumule.

Stratégies Pour Transformer Toujours Actif en À La Demande (ou Hors-Pic)

OK, alors vous avez identifié les domaines où vous dépensez trop. Maintenant pour la partie amusante : y remédier. L’objectif n’est pas seulement d’économiser de l’argent, mais de construire un système plus résilient et efficace qui consomme des ressources uniquement quand il en a vraiment besoin.

1. Planifiez le 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 test ne sont utilisés que pendant les heures de bureau, il n’y a aucune raison pour qu’ils fonctionnent 24/7. La plupart des fournisseurs de cloud proposent des moyens natifs de planifier les cycles d’alimentation des instances, ou vous pouvez créer votre propre 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 des instances EC2 en fonction des balises. 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 balises pour identifier les instances à arrêter/démarrer
 # Par exemple, 'Schedule': 'business-hours'
 
 # Obtenir toutes les instances en cours d'exécution avec la balise 'Schedule' définie 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/événement CloudWatch pour démarrer,
 # ou combiner la logique avec une balise 'start'.
 
 return {
 'statusCode': 200,
 'body': 'Planification des instances EC2 terminée.'
 }

Vous configureriez 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 redémarrer. Cela en soi peut réduire les coûts de calcul de plus de 70 % pour ces ressources spécifiques.

2. Adoptez les Solutions Sans Serveur et l’Orchestration de Conteneurs

Si votre charge de travail est véritablement sporadique ou déclenchée par un événement, les solutions sans serveur sont votre meilleur allié. AWS Lambda, Azure Functions, Google Cloud Functions – elles diminuent à zéro quand elles ne sont pas utilisées, ce qui signifie que vous ne payez que pour le calcul quand votre code s’exécute réellement. C’est un changement massif par rapport au paradigme « toujours actif ».

Pour les applications plus complexes qui ont toujours besoin de services persistants mais ont une demande fluctuante, les plateformes d’orchestration de conteneurs comme Kubernetes (EKS, AKS, GKE) combinées à une mise à l’échelle intelligente sont puissantes. Les Autoscalers de Pods Horizontaux (HPA) peuvent faire évoluer vos pods d’application vers le haut ou vers le bas en fonction de l’utilisation du CPU ou de métriques personnalisées. Les Autoscalers de Cluster peuvent même ajouter ou retirer des nœuds de votre cluster en fonction de la demande.

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 job cron, une fonction Lambda était déclenchée par un événement S3 (nouveaux données mises en ligne) ou une demande d’API Gateway. Les économies de coûts étaient immédiates et significatives.

3. Ajustez Vos Bases de Données avec des Options Sans Serveur ou D’Auto-Scalabilité

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

• AWS Aurora Serverless v2 : C’est un changement significatif. Elle ajuste la capacité en fonction de l’utilisation réelle, allant de fractions d’une ACU (Aurora Capacity Unit) jusqu’à des centaines, et vous ne payez que pour ce que vous utilisez. Fini de provisionner pour la capacité de pointe alors que la plupart du temps, vous opérez à une charge de base.
• Azure SQL Database Serverless : Semblable à Aurora Serverless, elle ajuste automatiquement le calcul et se met en pause lorsqu’elle est inactive, générant d’importantes économies pour les charges de travail intermittentes.
• DynamoDB À La Demande : Pour les charges de travail NoSQL, le mode de capacité à la demande de DynamoDB signifie que vous payez par demande, sans avoir à provisionner des unités de capacité de lecture/écriture. Parfait pour des schémas de trafic imprévisibles.

Le tableau de bord analytique utilisait à l’origine une grande instance RDS PostgreSQL avec des IOPS provisionnés. 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 le Stockage Non Attaché et les Instantanés

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’agit 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 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 réel du volume
# aws ec2 delete-volume --volume-id vol-xxxxxxxxxxxxxxxxx

Automatisez cela avec une fonction Lambda planifiée si vous créez et détruisez fréquemment des environnements. Le client a trouvé plusieurs téraoctets d’anciens volumes EBS non attachés et des centaines de snapshots obsolètes. Les supprimer a réduit de quelques centaines de dollars leur facture mensuelle – ce n’est pas massif, mais chaque petit geste compte.

5. Optimiser les Coûts Réseau

Les NAT Gateways sont fantastiques pour permettre aux instances dans des sous-réseaux privés d’accéder à Internet, mais ils entraînent 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’un seul est activement utilisé, vous payez pour des redondants.

• Consolidez les NAT Gateways : Si votre architecture le permet, consolidez en moins de NAT Gateways.
• Points de terminaison VPC : Pour accéder aux services AWS comme S3 ou DynamoDB depuis votre VPC, utilisez des points de terminaison VPC. Le trafic circule de manière privée au sein du réseau AWS, évitant ainsi 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 leur application principale ne fonctionnait que dans deux d’entre elles. Ils ont pu consolider et économiser un peu là, puis ont mis en œuvre des points de terminaison VPC pour un accès à S3, ce qui a réduit les coûts de traitement des données via le NAT Gateway.

Mesures à 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. Audit de Votre Facture Cloud Régulièrement : Faites-en une habitude. Utilisez les outils de gestion des coûts de votre fournisseur de cloud. Ne le laissez pas uniquement aux finances. 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 une extinction. Cela rend l’identification et l’automatisation infiniment plus faciles.
3. Priorisez la Planification pour les Environnements Non Prod : Les environnements de staging, dev, QA sont des candidats idéaux pour des arrêts programmés en dehors des heures de bureau. C’est généralement le gain le plus facile et rapide.
4. Évaluez le Serveur Sans Serveur pour de Nouvelles Charges de Travail : Si vous construisez quelque chose de nouveau, en particulier des microservices déclenchés par des événements ou des tâches en arrière-plan, pensez toujours au sans serveur en premier.
5. Revoyez Vos Choix de Base de Données : Si vous avez des bases de données fonctionnant 24/7 avec des charges très variables, explorez les options sans serveur ou de mise à l’échelle automatique pour votre technologie de base de données spécifique.
6. Automatisez le Nettoyage : Mettez en œuvre des scripts automatisés ou des fonctions sans serveur 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 conscience des 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.

Stopper la fuite des ressources « toujours actives » n’est pas une solution ponctuelle ; c’est une discipline continue. Mais en effectuant ces changements, vous économiserez non seulement une somme considérable d’argent pour votre entreprise, mais vous construirez également une infrastructure plus agile, résiliente et à l’épreuve du temps. Et franchement, cela fait de vous un meilleur acteur dans le domaine technologique.

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

🕒 Published: March 27, 2026