FinOps AWS : réduire vos coûts cloud de 40 % avec ces stratégies
← Retour au blogAWS & FinOps

FinOps AWS : réduire vos coûts cloud de 40 % avec ces stratégies

22 juillet 202510 min de lectureFinOpsAWSCost Optimization

Les factures AWS peuvent rapidement devenir incontrôlables. Voici les stratégies FinOps concrètes utilisées par Move2Cloud pour aider ses clients à réduire leurs dépenses cloud de 30 à 50 %.

Le problème du cloud sprawl

En moyenne, les entreprises gaspillent 32 % de leurs dépenses cloud selon Gartner (2024). Ce chiffre, stable depuis plusieurs années, s'explique par une accumulation silencieuse de gaspillages : instances EC2 sous-utilisées, volumes EBS non attachés, snapshots orphelins vieux de plusieurs mois, données en S3 Standard qu'on aurait dû basculer en Glacier après 30 jours, et réservations d'instances qui ne correspondent plus aux workloads actuels après une refactoring.

Le FinOps (Financial Operations) répond à ce problème en appliquant aux dépenses cloud les mêmes rigueurs que le DevOps applique au code : mesure continue, responsabilité par équipe, et cycle d'amélioration systématique.

Étape 0 : mettre en place la visibilité

Impossible d'optimiser ce qu'on ne mesure pas. Avant toute action, activez ces outils :

  • AWS Cost Explorer : visualisation des dépenses par service, tag, région, compte. Gratuit.
  • Cost and Usage Report (CUR) : export brut dans S3, requêtable via Athena. Granularité horaire par resource ID.
  • AWS Cost Anomaly Detection : alertes automatiques en cas d'écart anormal. Configurez un seuil à 10 % d'écart avec notification SNS → Slack.
  • Resource tagging : sans tags cohérents (Environment, Team, Project, CostCenter), vous ne saurez jamais quelle équipe génère quelle dépense. Enforcer le tagging via AWS Config rules.

Levier 1 : Rightsizing des instances EC2

AWS Compute Optimizer analyse 14 jours de métriques CloudWatch (CPU, mémoire via CloudWatch Agent, réseau, I/O disque) et recommande le type d'instance optimal. Dans tous nos audits FinOps, nous trouvons systématiquement 30 à 50 % des instances EC2 significativement oversizées — souvent des m5.xlarge qui tournent à 12 % CPU avec 2 GB de RAM utilisés sur 16 GB disponibles.

# Audit Compute Optimizer via CLI
aws compute-optimizer get-ec2-instance-recommendations   --region eu-west-1   --filters name=Finding,values=Overprovisioned   --query 'instanceRecommendations[].{Instance:instanceArn,CurrentType:currentInstanceType,RecommendedType:recommendationOptions[0].instanceType,Savings:recommendationOptions[0].estimatedMonthlySavings.value}'   --output table

Règle d'or : testez le rightsizing en non-production pendant une semaine, vérifiez les métriques, puis appliquez en production. Ne rightsizez jamais à l'aveugle sur une instance de base de données.

Levier 2 : Spot Instances et Savings Plans

Spot Instances

Les Spot Instances offrent jusqu'à 90 % de réduction vs On-Demand. Elles sont idéales pour les workloads tolérants aux interruptions : workers CI/CD, batch processing, nœuds Kubernetes non-stateful.

# Terraform — nodegroup EKS avec mix Spot/On-Demand
resource "aws_eks_node_group" "workers" {
  cluster_name    = aws_eks_cluster.main.name
  node_group_name = "mixed-workers"

  scaling_config {
    desired_size = 10
    min_size     = 3
    max_size     = 20
  }

  capacity_type  = "SPOT"  # 70% Spot
  instance_types = ["m6i.xlarge", "m6a.xlarge", "m5.xlarge", "m5a.xlarge"]
  # Multiple types = meilleure disponibilité Spot
}

Savings Plans

TypeRéductionFlexibilitéRecommandé pour
Compute Savings Plansjusqu'à 66 %Totale (instance, région, OS)Workloads changeants
EC2 Instance SPjusqu'à 72 %Famille + région fixéeWorkloads stables
Reserved Instances (1 an)jusqu'à 40 %Type exact fixéBDD, workloads très stables

Notre stratégie recommandée : couvrir 60-70 % de la consommation EC2 de base avec des Compute Savings Plans 1 an, garder 20 % en On-Demand pour la flexibilité, et utiliser Spot pour le reste.

Levier 3 : Optimisation S3

S3 est souvent l'un des premiers services en termes de coût (après EC2 et RDS). Les principales sources d'économie :

  • S3 Intelligent-Tiering : bascule automatiquement les objets entre Standard, IA, Glacier selon les patterns d'accès. Coût : 0,0025 $/1000 objets. ROI positif dès 30 jours pour les données à accès imprévisible.
  • Lifecycle policies : archiver vers Glacier Instant Retrieval après 30 jours, vers Glacier Deep Archive après 90 jours. Réduction du coût de stockage de 80 %.
  • Multipart upload cleanup : les uploads incomplets consomment de l'espace sans jamais être référencés. Configurez une règle pour supprimer les parties incomplètes après 7 jours.
resource "aws_s3_bucket_lifecycle_configuration" "example" {
  bucket = aws_s3_bucket.main.id

  rule {
    id     = "archive-old-logs"
    status = "Enabled"

    transition {
      days          = 30
      storage_class = "STANDARD_IA"
    }
    transition {
      days          = 90
      storage_class = "GLACIER_IR"
    }
    expiration {
      days = 365
    }
    abort_incomplete_multipart_upload {
      days_after_initiation = 7
    }
  }
}

Levier 4 : Nettoyage automatique des ressources orphelines

Les ressources orphelines (volumes EBS non attachés, Elastic IPs non associées, snapshots anciens, load balancers sans cibles) représentent souvent 5 à 10 % de la facture AWS. Automatisez leur détection et suppression :

# Lambda de nettoyage quotidien — ressources orphelines
import boto3
from datetime import datetime, timezone, timedelta

def cleanup_orphaned_resources():
    ec2 = boto3.client('ec2', region_name='eu-west-1')

    # Volumes EBS non attachés depuis plus de 7 jours
    volumes = ec2.describe_volumes(
        Filters=[{'Name': 'status', 'Values': ['available']}]
    )
    for vol in volumes['Volumes']:
        age = (datetime.now(timezone.utc) - vol['CreateTime']).days
        if age > 7 and 'DoNotDelete' not in [t['Key'] for t in vol.get('Tags', [])]:
            print(f"Deleting volume {vol['VolumeId']} (age: {age} days)")
            ec2.delete_volume(VolumeId=vol['VolumeId'])

    # Elastic IPs non associées
    eips = ec2.describe_addresses(
        Filters=[{'Name': 'domain', 'Values': ['vpc']}]
    )
    for eip in eips['Addresses']:
        if 'AssociationId' not in eip:
            print(f"Releasing EIP {eip['AllocationId']}")
            ec2.release_address(AllocationId=eip['AllocationId'])

Résultats obtenus chez nos clients

  • Client Fintech (500 k€/an AWS) : économie de 38 % en 6 mois — principalement rightsizing EC2 + Savings Plans
  • Client e-commerce (1,2 M€/an AWS) : économie de 44 % — Spot Instances pour les workers + S3 Intelligent-Tiering
  • Startup SaaS (80 k€/an AWS) : économie de 52 % — rightsizing radical + nettoyage ressources orphelines

Conclusion

Le FinOps n'est pas un projet ponctuel mais une pratique continue qui s'intègre dans vos rituels DevOps. Commencez par activer AWS Cost Explorer et Cost Anomaly Detection (gratuit), taggez toutes vos ressources, puis itérez chaque sprint. Un audit FinOps mensuel de 2 heures peut générer des dizaines à centaines de milliers d'euros d'économies annuelles. La clé : rendre visible la dépense cloud au niveau des équipes qui la génèrent, et leur donner les outils pour l'optimiser elles-mêmes.

← Retour au blog