cloud-cost-optimizer

name	cloud-cost-optimizer
description	Optimise les coûts cloud (Azure, AWS, GCP) avec workflow FinOps structuré — audit, right-sizing, réservations, Spot, stockage, scheduling, monitoring. Se déclenche avec "coût cloud", "facture Azure", "AWS bill", "optimiser les coûts", "réduire la facture", "reserved instances", "FinOps", "cloud spending".

Cloud Cost Optimizer

Workflow en 8 étapes

1. Audit initial — inventaire & baseline

Collecte le coût mensuel réel par ressource avant toute action.

AWS

# Export Cost Explorer par service (derniers 30 jours)
aws ce get-cost-and-usage \
  --time-period Start=2026-05-24,End=2026-06-24 \
  --granularity MONTHLY \
  --metrics BlendedCost \
  --group-by Type=DIMENSION,Key=SERVICE \
  --output table

Azure

# Résumé de facturation par groupe de ressources
az consumption usage list \
  --start-date 2026-05-24 --end-date 2026-06-24 \
  --query "[].{Resource:instanceName, Cost:pretaxCost, Currency:currency}" \
  --output table

GCP

# Export vers BigQuery (recommandé) — requête sur le dataset billing
bq query --use_legacy_sql=false '
SELECT service.description, SUM(cost) AS total_cost
FROM `PROJECT.DATASET.gcp_billing_export_v1_*`
WHERE _PARTITIONTIME BETWEEN "2026-05-24" AND "2026-06-24"
GROUP BY 1 ORDER BY 2 DESC LIMIT 20'

Critère de déclenchement : si une ressource représente > 5 % de la facture totale, elle mérite une analyse dédiée.

---

2. Identifier les ressources sous-utilisées (idle / oversized)

Critères d'alerte :

Signal	Seuil	Action
CPU moyen sur 14 j	< 10 %	Downsize ou arrêt
Mémoire utilisée	< 20 %	Downsize
Volume EBS/Disk non attaché	> 7 j	Snapshot + suppression
IP publique non associée	toute durée	Libérer
DB connections actives	0 sur 7 j	Arrêt planifié

AWS — lister les EBS volumes détachés

aws ec2 describe-volumes \
  --filters Name=status,Values=available \
  --query "Volumes[*].{ID:VolumeId, Size:Size, Type:VolumeType}" \
  --output table

Azure — VMs avec CPU < 10 % (Advisor)

az advisor recommendation list \
  --category Cost \
  --query "[?shortDescription.problem=='Right-size or shutdown underutilized virtual machines']" \
  --output table

---

3. Right-sizing

Utiliser les recommandations natives avant de choisir manuellement.

• AWS : Compute Optimizer → export CSV des recommandations EC2/RDS/Lambda
• Azure : Advisor → blade "Cost" → recommandations VM/SQL
• GCP : Recommender API → gcloud recommender recommendations list --recommender=google.compute.instance.MachineTypeRecommender

Règle de décision :

• Downsize si l'utilisation peak sur 14 j < 40 % de la capacité provisionnée.
• Ne pas descendre en dessous de la P95 de la charge (éviter les throttlings).
• Tester sur staging avant de migrer la prod.

Terraform — changer le type d'instance sans recréer la ressource

resource "aws_instance" "api" {
  instance_type = "t3.small"  # Était t3.medium
  # ...
  lifecycle { create_before_destroy = true }
}

---

4. Reserved Instances & Savings Plans

Matrice de décision :

Cas	Recommandation
Workload stable 24/7, même région, même famille	RI 1 an (Standard) — jusqu'à 40 %
Workload stable mais famille/région variable	Savings Plan Compute — jusqu'à 66 %
Engagement fort, 3 ans, paiement anticipé	RI 3 ans — jusqu'à 72 %
Workload imprévisible	On-demand ou Spot

Calcul ROI rapide (AWS)

# Estimation des économies Savings Plans sur 1 an
aws ce get-savings-plans-purchase-recommendation \
  --savings-plans-type COMPUTE_SP \
  --term-in-years ONE_YEAR \
  --payment-option NO_UPFRONT \
  --lookback-period-in-days THIRTY_DAYS

Ne pas acheter de réservations avant d'avoir au moins 30 jours d'historique de charge stable.

---

5. Spot / Preemptible instances

Workloads compatibles Spot :

• CI/CD (GitHub Actions runners, GitLab runners)
• Batch processing, ETL, ML training
• Environnements de dev/test
• Rendering, transcoding

Non compatibles : bases de données stateful, services critiques sans failover.

AWS — Auto Scaling Group avec mix Spot/On-demand

{
  "MixedInstancesPolicy": {
    "InstancesDistribution": {
      "OnDemandPercentageAboveBaseCapacity": 20,
      "SpotAllocationStrategy": "capacity-optimized"
    }
  }
}

Azure — VMSS avec Spot

az vmss create --name myVMSS --resource-group myRG \
  --priority Spot --eviction-policy Deallocate \
  --max-price -1  # prix marché

Toujours configurer un interruption handler (SIGTERM sur AWS, Azure Scheduled Events).

---

6. Optimiser le stockage

Lifecycle policies — S3

{
  "Rules": [{
    "Status": "Enabled",
    "Transitions": [
      { "Days": 30, "StorageClass": "STANDARD_IA" },
      { "Days": 90, "StorageClass": "GLACIER_IR" },
      { "Days": 365, "StorageClass": "DEEP_ARCHIVE" }
    ],
    "NoncurrentVersionExpiration": { "NoncurrentDays": 30 }
  }]
}

Azure Blob — lifecycle (Bicep)

resource lifecyclePolicy 'Microsoft.Storage/storageAccounts/managementPolicies@2023-01-01' = {
  name: 'default'
  properties: {
    policy: {
      rules: [{
        name: 'tiering'
        type: 'Lifecycle'
        definition: {
          actions: { baseBlob: { tierToCool: { daysAfterModificationGreaterThan: 30 }
                               , tierToArchive: { daysAfterModificationGreaterThan: 90 } } }
          filters: { blobTypes: ['blockBlob'] }
        }
      }]
    }
  }
}

Supprimer les snapshots orphelins : vérifier que le volume source existe encore avant tout nettoyage.

---

7. Auto-scaling & scheduling

Scale-to-zero pour tous les workloads non-continus :

• AWS Lambda, ECS Fargate (scale to 0 tasks)
• Azure Container Apps (min replicas: 0)
• GCP Cloud Run (concurrency 0)

Arrêt automatique des envs dev/staging (économies 65-75 %)

# AWS — Lambda schedulée via EventBridge (arrêt le soir, démarrage le matin)
aws events put-rule --schedule-expression "cron(0 19 ? * MON-FRI *)" \
  --name "StopDevInstances"

# Azure — Start/Stop VMs v2 (solution native gratuite)
az deployment group create --resource-group myRG \
  --template-uri https://aka.ms/startstopv2deploy

Kubernetes — scale down la nuit

# kube-downscaler ou KEDA
apiVersion: keda.sh/v1alpha1
kind: ScaledObject
spec:
  minReplicaCount: 0
  scaleTargetRef:
    name: api-deployment

---

8. Monitoring continu & FinOps

Tagging strategy — obligatoire pour l'attribution des coûts

Environment: prod | staging | dev
Team: backend | frontend | data
Project: rivora | access | wfc
CostCenter: 1234

Budgets avec alertes (AWS)

aws budgets create-budget --account-id 123456789 --budget '{
  "BudgetName": "monthly-prod",
  "BudgetLimit": {"Amount": "5000", "Unit": "USD"},
  "TimeUnit": "MONTHLY",
  "BudgetType": "COST"
}' --notifications-with-subscribers '[{
  "Notification": {"NotificationType":"ACTUAL","ComparisonOperator":"GREATER_THAN","Threshold":80},
  "Subscribers": [{"SubscriptionType":"EMAIL","Address":"[e-mail]"}]
}]'

Azure Cost Anomaly Detection

az costmanagement alert create --scope /subscriptions/{sub-id} \
  --name anomaly-alert --type Anomaly

Revue mensuelle obligatoire : comparer la facture N vs N-1, valider les recommandations Advisor/Compute Optimizer non traitées.

---

Garde-fous & anti-patterns

Anti-pattern	Risque	Correction
Supprimer directement les ressources idle	Perte de données, rollback impossible	Snapshot → désactivation → suppression après 7 j
Acheter des RI sans historique stable	Surengagement inutile	Attendre 30 j, commencer par Savings Plans flexibles
Spot pour les BDD ou services stateful	Perte de données sur eviction	On-demand obligatoire pour stateful
Ignorer le coût réseau (egress)	Facture cachée massive	Auditer le trafic inter-régions et vers internet
Tags inconsistants ou absents	Impossible d'imputer les coûts	Enforcer via Azure Policy / AWS SCP / GCP Org Policy
Over-provisioning "au cas où"	40-60 % de gaspillage courant	Right-sizing + auto-scaling, jamais de marge fixe > 30 %
Optimiser dev/staging avant prod	Gains marginaux, risques réels en prod	Prioriser : prod > staging > dev

Ordre de priorité recommandé

1. Quick wins (< 1 semaine) : idle resources, IPs inutilisées, snapshots orphelins, arrêt env dev la nuit
2. Medium term (1-4 semaines) : right-sizing, lifecycle storage, auto-scaling
3. Long term (> 1 mois) : réservations 1 an, refactoring vers serverless, architecture multi-region optimisée