FinOps Cloud : reprendre le contrôle des coûts AWS, GCP, Azure

La facture cloud explose rarement d'un coup. Elle dérive : une instance surdimensionnée ici, un cluster EKS oublié là, un bucket S3 en Standard alors que la donnée n'est plus lue depuis 18 mois. Chez nos clients, un audit FinOps mené sérieusement dégage en général 20 à 40 % d'économies sans dégrader la production. Voici comment structurer la démarche, en s'appuyant sur le référentiel de la FinOps Foundation (phases Inform, Optimize, Operate).

1. Inform : rendre les coûts lisibles avant tout

On n'optimise pas ce qu'on ne mesure pas. La première étape consiste à allouer chaque euro dépensé à une équipe, un produit ou un environnement. Sans cela, les discussions tournent en rond.

Stratégie de tagging

Définissez un schéma de tags obligatoire et appliqué via policy :

• cost-center (ex: CC-4521)
• environment (prod, staging, dev)
• product ou service
• owner (email d'équipe, pas d'individu)
• data-classification

Sur AWS, utilisez AWS Organizations + Service Control Policies pour refuser la création de ressources non taggées. Sur Azure, Azure Policy avec l'effet deny. Sur GCP, Organization Policies couplées aux labels.

{
  "Version": "2012-10-17",
  "Statement": [{
    "Effect": "Deny",
    "Action": "ec2:RunInstances",
    "Resource": "arn:aws:ec2:*:*:instance/*",
    "Condition": {
      "Null": {"aws:RequestTag/cost-center": "true"}
    }
  }]
}

Outillage

| Besoin | Natif | Alternatives | |---|---|---| | Visualisation multi-cloud | — | Vantage, CloudHealth, Finout | | Kubernetes cost allocation | — | OpenCost (CNCF), Kubecost | | Reporting brut | Cost Explorer, GCP Billing, Azure Cost Management | Export vers BigQuery/Athena | | Anomaly detection | AWS Cost Anomaly Detection | Datadog Cloud Cost Management |

OpenCost mérite une mention : c'est aujourd'hui le standard CNCF pour ventiler les coûts Kubernetes par namespace, deployment ou label — critique quand un même cluster héberge plusieurs équipes.

2. Optimize : les trois leviers qui payent vraiment

Rightsizing

La majorité des workloads tournent à 10-25 % de CPU moyen. AWS Compute Optimizer, Azure Advisor et GCP Recommender identifient les instances surdimensionnées à partir des métriques CloudWatch/Monitoring. Règle pratique : ciblez 60-70 % d'utilisation CPU en pic, pas en moyenne.

Pour les bases de données, méfiez-vous des recommandations automatiques : une RDS db.r6i.2xlarge peut sembler sous-utilisée côté CPU mais saturer en IOPS. Croisez toujours plusieurs métriques.

Commitments : Savings Plans et Reserved Instances

L'arbitrage est structurant :

• Savings Plans Compute (AWS) : jusqu'à 66 % de remise, flexibles entre EC2, Fargate, Lambda. À privilégier pour la charge stable.
• Reserved Instances : remise plus élevée mais rigides. Utiles uniquement pour des workloads figés (RDS, ElastiCache).
• GCP Committed Use Discounts (CUDs) : resource-based ou spend-based. Les spend-based CUDs sont plus souples.
• Azure Reservations + Savings Plans for Compute : combinaison possible depuis fin 2022.

Règle prudentielle : ne couvrez jamais plus de 70-80 % de la baseline identifiée sur 90 jours. Le reste en on-demand ou Spot.

Spot / Preemptible

Sur les workloads tolérants à l'interruption (batch, CI, entraînement ML, stateless web), les Spot Instances offrent jusqu'à 90 % d'économie. Karpenter (AWS) automatise le mix Spot/On-Demand dans EKS avec fallback propre.

Storage lifecycle

Checklist rapide :

• [ ] Politiques S3 Lifecycle vers Intelligent-Tiering, Glacier IR, Deep Archive
• [ ] Suppression des snapshots EBS orphelins (> 30 jours sans volume)
• [ ] Purge des images ECR/GCR non taggées
• [ ] Logs CloudWatch : retention explicite (défaut = never expire = piège classique)
• [ ] Bases de données : archivage des tables froides vers Parquet/S3

3. Operate : ancrer le FinOps dans la gouvernance

L'optimisation ponctuelle ne tient pas. Il faut un cycle continu :

1. Budgets et alertes par équipe (AWS Budgets, Azure Cost Alerts, GCP Budget API) avec seuils à 50 %, 80 %, 100 %.
2. Chargeback ou showback mensuel : envoyer aux équipes leur consommation les responsabilise plus que n'importe quelle politique.
3. KPIs FinOps : coût par transaction, coût par tenant, unit economics. C'est ce qui parle au COMEX, pas le montant absolu.
4. Reviews trimestrielles de couverture Savings Plans / RI et rachat si nécessaire.
5. Gate FinOps dans la CI/CD : Infracost estime le delta de coût d'une PR Terraform avant merge.

# .github/workflows/infracost.yml (extrait)
- name: Infracost breakdown
  run: |
    infracost breakdown --path=. \
      --format=json --out-file=/tmp/infracost.json
- name: Post PR comment
  run: infracost comment github --path=/tmp/infracost.json \
      --repo=$GITHUB_REPOSITORY --pull-request=${{github.event.number}} \
      --github-token=${{secrets.GITHUB_TOKEN}}

Le piège des LLM et du GPU

Depuis 2024, une nouvelle ligne pèse lourd : l'inférence LLM et les instances GPU (p5, A100, H100). Trois réflexes : privilégier les modèles managés facturés au token quand le volume est faible, batcher les requêtes, et surveiller le ratio coût/1000 tokens comme métrique produit à part entière.

À retenir

• Pas de FinOps sans allocation : imposez le tagging par policy avant toute optimisation.
• Rightsizing d'abord, commitments ensuite : acheter un Savings Plan sur une flotte surdimensionnée fige le gaspillage sur 1 à 3 ans.
• Couvrez 70-80 % de la baseline, gardez de la flexibilité en on-demand et Spot.
• Intégrez le coût au cycle de dev : Infracost en PR, OpenCost dans Kubernetes, alertes budgétaires par équipe.
• Mesurez en unit economics (coût par requête, par client) — c'est le seul langage qui rend le FinOps stratégique et non comptable.