FinOps et optimisation des coûts¶
Tagging, reserved instances, spot, rightsizing automatise et gouvernance budgetaire.
Principes FinOps¶
FinOps (Financial Opérations) est la pratique qui reconcilie la velocite cloud avec la responsabilité financiere. Le FinOps Foundation définit trois phases iteratives.
graph LR
A["Inform\n(visibilite)"] --> B["Optimize\n(reduction)"]
B --> C["Operate\n(gouvernance)"]
C --> A| Phase | Objectif | Actions typiques |
|---|---|---|
| Inform | Visibilité sur les coûts par équipe, produit, environnement | Tagging, dashboards, allocation |
| Optimize | Réduire le gaspillage et acheter plus efficacement | Rightsizing, reserved instances, spot |
| Operate | Ancrer la discipline FinOps dans les processus quotidiens | Budgets, alertes, chargeback, reviews |
FinOps pas qu'une affaire de finance
FinOps engage autant les équipes techniques que les équipes finance. Les ingénieurs prennent des décisions d'architecture qui ont un impact coût immédiat. La collaboration finance-ops-produit est le cœur du modèle FinOps.
Tagging¶
Le tagging est la fondation de toute pratique FinOps : sans tags, pas d'allocation de coûts fiable.
Stratégie de tagging¶
| Tag | Valeur exemple | Objectif |
|---|---|---|
env | prod, staging, dev | Séparer les coûts par environnement |
team | backend, data, platform | Chargeback par équipe |
product | api-core, analytics, billing | Allocation par produit |
cost-center | CC-42, CC-17 | Reconciliation comptable |
project | migration-v2, poc-ml | Suivi projets temporaires |
Enforcement¶
- Policy as code : AWS SCP, Azure Policy, GCP Organization Policy pour bloquer les ressources sans tags
- Validation CI/CD : Infracost ou Checkov verifient les tags dans les plans Terraform
- Audit régulier : rapport mensuel des ressources non taggees
Reserved instances, savings plans et spot¶
Trois stratégies d'achat pour réduire les coûts cloud au-delà du tarif à la demande.
| Stratégie | Économie typique | Engagement | Risque |
|---|---|---|---|
| On-demand | 0 % (référence) | Aucun | Aucun |
| Reserved Instance (1 an) | 30-40 % | 1 an, type fixe | Changement de type impossible |
| Reserved Instance (3 ans) | 50-60 % | 3 ans, type fixe | Fort engagement technologique |
| Savings Plans | 20-50 % | 1-3 ans, flexible | Engagement en $ par heure |
| Spot / Preemptible | 60-90 % | Aucun | Interruption possible sous 2 min |
Quand utiliser chaque stratégie¶
- Reserved Instances : charges de base stables et prévisibles (base de données, serveurs applicatifs)
- Savings Plans : charges flexibles mais avec volume garanti (Lambda, Fargate, EC2 mixed)
- Spot / Preemptible : charges tolerantes aux interruptions (batch, CI/CD, ML training, rendering)
Spot non adapté aux charges stateful
Les instances spot peuvent être interrompues avec 2 minutes de preavis. Ne jamais utiliser spot pour des bases de données primaires, des brokers de messages ou tout service qui ne peut pas redémarrer proprement après interruption.
Rightsizing automatise¶
Le rightsizing automatise identifie les ressources surdimensionnees et propose des ajustements.
Outils¶
| Outil | Type | Fonctionnement |
|---|---|---|
| AWS Compute Optimizer | Natif AWS | ML sur 14 jours, recommande type + taille |
| Azure Advisor | Natif Azure | Analyse 7-30 jours, score + recommandations |
| GCP Recommender | Natif GCP | Recommandations par ressource |
| Spot.io (Flexera) | Tiers multi-cloud | Rightsizing + spot automation |
| CloudHealth | Tiers multi-cloud | Reporting + recommandations |
| Kubecost | Kubernetes | Coûts et recommandations par namespace/workload |
Workflow de rightsizing¶
- Lancer l'outil de recommandation après 2-4 semaines de données production
- Filtrer les recommandations par impact coût (prioriser les économies > 20 %)
- Valider avec l'équipe technique (la recommandation ignore parfois les pics)
- Appliquer en heure creuse avec possibilite de rollback rapide
- Mesurer 2 semaines après pour confirmer que les performances sont maintenues
Budgets et alertes¶
La gouvernance budgetaire empêche les surprises en fin de mois.
Configuration des budgets¶
| Niveau | Granularité | Seuils d'alerte |
|---|---|---|
| Compte global | Total mensuel | 80 %, 90 %, 100 %, 110 % |
| Par équipe (tag) | Mensuel par team | 80 %, 100 % |
| Par environnement | Mensuel par env | dev > 30 % de prod = anomalie |
| Par service cloud | Mensuel par service | EC2, RDS, S3 séparés |
Chargeback vs showback¶
| Modèle | Principe | Maturité FinOps |
|---|---|---|
| Showback | Montrer les coûts à chaque équipe sans facturation interne | Débutant |
| Chargeback | Facturer reellement les coûts à chaque équipe (refacturation) | Avance |
Commencer par le showback
Le chargeback nécessité une comptabilité analytique mature. Commencer par le showback — voir les coûts créé déjà une responsabilisation. Passer au chargeback une fois le tagging fiabilise et les équipes sensibilisees.
Points clés¶
- FinOps est une discipline continue qui implique tech, finance et produit
- Le tagging est la fondation — sans tags corrects, impossible d'allouer les coûts
- Reserved instances pour la base stable, spot pour les charges batch/CI
- Le rightsizing automatise nécessité 2-4 semaines de données avant d'être fiable
- Commencer par le showback avant le chargeback pour sensibiliser progressivement