💰 FinOps : comparatif AWS, Azure, GCP pour réduire votre facture cloud

• 1. Absence totale de tagging → impossible de savoir qui consomme quoi. Solution : imposez des tags obligatoires (Environment, CostCenter, Owner) via des politiques cloud (AWS Tag Policies, Azure Policy, GCP Org Policies).
• 2. Pas d’owner désigné par ressource → les orphelins s’accumulent. Solution : chaque ressource doit avoir un tag Owner=email. Sinon, alerte puis arrêt automatique.
• 3. Multi-cloud inutile ou mal maîtrisé → duplicata de services, transferts data facturés cher. Solution : n’allez multi-cloud que si besoin métrique (régalia, résilience, lock-in). Pour le reste, choisissez un cloud primaire.
• 4. Sur-architecture (Kubernetes pour un blog, managed DB pour 10 utilisateurs) → dette technique + facture. Solution : start small, serverless d’abord, scaling plus tard.
• 5. Ressources oubliées (disques non attachés, IP publiques inutilisées, snapshots anciens) → fuite d’argent silencieuse. Solution : audit hebdomadaire (AWS Trusted Advisor, Azure Advisor, GCP Recommender).
• 6. Instance sizing démesuré (trop de RAM/CPU) → 80% des workloads tournent sur des instances 2x plus petites. Solution : utilisez des outils de rightsizing (Compute Optimizer, Azure Advisor, GCP Active Assist).
• 7. Aucune stratégie de réservation → vous payez le prix public toute l’année. Solution : identifiez la partie stable (base de données, prod) et achetez des Savings Plans / RI / CUD à 1 an.
• 8. Ne pas utiliser les instances spot pour les batchs → vous jetez de l’argent. Solution : tous les workloads tolérants (CI/CD, traitement données, dev) doivent passer en spot.
• 9. Ignorer les coûts de transfert de données (egress) → ces coûts explosent en multi-cloud ou avec CDN mal configuré. Solution : privilégiez le même cloud pour l’échange de données, utilisez des endpoints privés.
• 10. Pas de revue budgétaire mensuelle avec les équipes → personne n’est responsabilisé. Solution : mettez en place des budgets (AWS Budgets, Azure Cost Alerts, GCP Budgets) et des rapports Slack hebdomadaires.

Client : SaaS B2B scale-up, environ 150 VMs sur AWS (m5.large principalement), base PostgreSQL managée (RDS), quelques buckets S3 et un cluster Kubernetes managé (EKS).

Facture mensuelle initiale : 10 200 €

Actions concrètes menées (un mois de travail) :

• ✅ Rightsizing : 40 VMs overprovisionnées sont passées de m5.large à m5.xlarge ? Non, l'inverse : 70% des m5.large étaient à moins de 20% CPU → passage en t3.medium. Gain : -1 200 €/mois.
• ✅ Arrêt automatique des VMs de dev/preprod (20h → 8h + WE). Gain : -1 800 €/mois.
• ✅ Migration des batches CI/CD sur EC2 Spot (50% des workers). Gain : -800 €/mois.
• ✅ Achat de Savings Plans 1 an sur la partie prod stable (30% des VM + RDS). Gain : -700 €/mois.
• ✅ Nettoyage des snapshots RDS et EBS obsolètes (plus de 6 mois). Gain : -400 €/mois.
• ✅ Suppression de 3 IP publiques statiques non utilisées + réduction du transfert via endpoint VPC. Gain : -300 €/mois.
• ✅ Optimisation des logs CloudWatch : rétention à 30 jours (au lieu d’illimitée). Gain : -500 €/mois.

Nouvelle facture : 5 800 € (soit -43%). Coût de l’accompagnement : 2 jours d’audit + mise en œuvre. ROI atteint en moins d’un mois.

📌 Les gains les plus importants sont venus de l’arrêt des VM non critiques et du rightsizing, pas des réservations.

L’optimisation des coûts a un coût : le temps de vos équipes, la complexité, et parfois la vélocité. Voici les situations où il vaut mieux ne rien faire (ou très peu) :

• Startup en phase d’amorçage (early stage) : votre priorité absolue est le product-market fit et la vitesse d’exécution. Une refonte FinOps trop tôt crée de la dette produit. Limitez-vous à éteindre les ressources la nuit et tagger grossièrement.
• Équipe unique de 2-3 développeurs : passer 20h par semaine à optimiser une facture de 500€/mois est absurde. Privilégiez le serverless (Lambda, Cloud Functions) qui scale à zéro.
• Projet temporaire (PoC, hackathon, démo client) : mieux vaut déployer vite et détruire après. N’investissez pas dans des réservations 3 ans.
• Optimisation prématurée d’un service qui n’a pas encore de trafic : vous allez complexifier l’architecture (ex: ajouter des spot, des interruptions) pour un gain hypothétique. Attendez les premiers utilisateurs réels.
• Contrainte réglementaire forte (données de santé, financières) : parfois le peace of mind d’une architecture simple et déterministe vaut le surcoût d’un cloud public sans spot ni réservations exotiques.

Mon mantra : “Optimisez ce qui pèse, mais ne ralentissez pas le business pour gratter 3% sur une ressource qui coûte 50 €.” La dette FinOps est réelle : des scripts d’arrêt trop agressifs qui plantent les jobs de nuit, des spot mal configurés qui perdent des données…

👉 Règle d’or : si le temps passé à optimiser dépasse 20% du gain annuel estimé, n’y touchez pas.