Réduire votre facture AWS sans casser votre architecture : méthodes concrètes

Quand une PME découvre sa facture AWS au-dessus de 10 000 €/mois, la première réaction est presque toujours la même : “il faut couper quelque chose”. Et la deuxième, juste après : “mais on ne sait pas par où commencer sans tout casser”.

C’est le bon réflexe. Une optimisation FinOps mal pilotée crée plus de coûts qu’elle n’en supprime — un downtime à 3h du matin, une migration ratée, une perte de données. Cet article décrit la séquence que nous appliquons en mission Distribuée pour récupérer 30 à 50 % d’une facture AWS sans introduire de risque opérationnel.

Avant les leviers : la cartographie est non-négociable

Pas de FinOps sans tagging cohérent. Si vos coûts ne sont pas attribuables à une équipe, un produit, un environnement, vous optimisez à l’aveugle.

Notre standard de départ minimal :

Une fois les tags activés dans Billing > Cost allocation tags (compte sur 24h pour la prise en compte), Cost Explorer révèle où va vraiment l’argent. C’est seulement à ce moment qu’on commence à couper.

Levier 1 — Reserved Instances et Savings Plans

C’est le levier qui rapporte le plus, le plus vite, sans toucher au code. Vous échangez un engagement (1 ou 3 ans) contre une remise sur le tarif horaire.

En pratique, sur un baseline EC2/RDS stable, 70 % de couverture en Compute Savings Plans est le ratio que nous recommandons. Les 30 % restants en On-Demand absorbent les pics et les expérimentations.

Le calcul tient sur une commande AWS CLI :

# Voir la consommation moyenne mensuelle EC2 + Lambda + Fargate
aws ce get-cost-and-usage \
  --time-period Start=2026-01-01,End=2026-04-01 \
  --granularity MONTHLY \
  --metrics UnblendedCost \
  --filter '{"Dimensions":{"Key":"SERVICE","Values":["Amazon Elastic Compute Cloud - Compute","AWS Lambda","Amazon Elastic Container Service"]}}' \
  --query 'ResultsByTime[].Total.UnblendedCost.Amount'

Multipliez la moyenne par 0,7, et c’est votre cible de Compute SP. AWS vous propose même une recommandation pré-calculée dans Cost Explorer > Savings Plans > Recommendations — vérifiez-la, ne l’appliquez pas les yeux fermés.

Point d’attention : un Savings Plan est non remboursable. Si vous coupez la ressource sous-jacente, vous payez quand même. Ne couvrez pas une charge dont vous prévoyez la disparition dans les 12 mois.

Levier 2 — Right-sizing avec AWS Compute Optimizer

La majorité des EC2 que nous auditons sont sur-dimensionnées par un facteur 2 à 4. Compute Optimizer (gratuit) analyse les métriques CloudWatch sur 14 jours et propose des recommandations chiffrées.

# Activer Compute Optimizer
aws compute-optimizer update-enrollment-status --status Active

# Récupérer les recommandations EC2 avec économies estimées
aws compute-optimizer get-ec2-instance-recommendations \
  --query 'instanceRecommendations[?finding==`Overprovisioned`].[instanceArn,currentInstanceType,recommendationOptions[0].instanceType,recommendationOptions[0].savingsOpportunity.savingsOpportunityPercentage]' \
  --output table

Le pattern de remédiation : on commence par les instances les plus chères et les plus over-provisioned, on teste en staging, on pousse en prod sur une fenêtre de maintenance, on mesure 7 jours, on passe à la suivante.

Levier 3 — S3 lifecycle policies

S3 Standard à 0,023 $/GB est rentable pour les données chaudes. Pour le reste, les classes plus froides coûtent 5 à 25× moins. Une lifecycle policy bien posée déplace les données automatiquement.

resource "aws_s3_bucket_lifecycle_configuration" "logs" {
  bucket = aws_s3_bucket.logs.id

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

    transition {
      days          = 30
      storage_class = "STANDARD_IA"
    }

    transition {
      days          = 90
      storage_class = "GLACIER_IR"
    }

    transition {
      days          = 365
      storage_class = "DEEP_ARCHIVE"
    }

    expiration {
      days = 2555  # 7 ans pour SOC2 / RGPD
    }
  }
}

Sur des buckets de logs ou de backups qui dépassent les 1 To, on observe systématiquement 60 à 80 % d’économie sur le poste storage.

Levier 4 — Couper les flux data transfer évitables

Le data transfer est le poste le plus sous-estimé d’AWS. Notre article dédié sur les coûts cachés détaille les chemins qui facturent. Les deux fixes les plus rentables :

1. VPC Gateway Endpoints pour S3 et DynamoDB : gratuits, suppriment 100 % du trafic NAT/Internet vers ces services. À ajouter sur tous les VPC, partout.
2. Coloacalisation des charges : si votre app EC2 parle à RDS, garde-les dans la même AZ. Cross-AZ = 0,01 $/GB en aller, 0,01 $/GB en retour.

resource "aws_vpc_endpoint" "s3" {
  vpc_id            = aws_vpc.main.id
  service_name      = "com.amazonaws.${var.region}.s3"
  vpc_endpoint_type = "Gateway"
  route_table_ids   = aws_route_table.private[*].id
}

Levier 5 — Scheduling des workloads non-prod

Les environnements de dev et staging tournent rarement la nuit et le week-end. À 168 heures par semaine, en éteindre 110 (week-end + nuits) divise leur coût par 3.

Pattern simple avec EventBridge + Lambda :

resource "aws_cloudwatch_event_rule" "stop_dev" {
  name                = "stop-dev-instances"
  description         = "Arrêt des instances dev tous les soirs à 20h"
  schedule_expression = "cron(0 20 ? * MON-FRI *)"
}

resource "aws_cloudwatch_event_target" "stop_dev" {
  rule      = aws_cloudwatch_event_rule.stop_dev.name
  target_id = "StopDevInstances"
  arn       = aws_lambda_function.stop_instances.arn
  input     = jsonencode({ environment = "dev" })
}

La Lambda elle-même est triviale : 20 lignes de Python qui filtrent les instances par tag Environment=dev et appellent stop_instances().

Comment éviter de casser quoi que ce soit

C’est la partie la plus importante. Les leviers ci-dessus marchent à condition d’avoir une discipline d’exécution :

1. Test en staging d’abord, sans exception. Y compris pour un changement de type d’instance.
2. Une optimisation à la fois. Si vous bougez un Savings Plan + un right-sizing + une lifecycle policy le même jour et qu’un coût bouge, vous ne saurez pas qui a fait quoi.
3. Fenêtre de maintenance documentée, même si vous pensez que c’est transparent. Une bascule d’AZ pendant un déploiement, c’est un downtime.
4. Mesure 7 jours avant de passer à la suivante. Les workloads ont des cycles hebdomadaires.
5. Rollback documenté, scripté quand c’est possible.

Le résultat empilé

Sur une facture initiale de 10 000 €/mois, voici le profil typique des économies cumulables sans toucher au comportement applicatif :

Cinquante pour cent. Sur une PME qui scale, c’est le salaire d’un ingénieur senior chaque mois. Et l’architecture n’a pas bougé d’un iota.

Conclusion

Le FinOps n’est pas une question de magie noire ni d’outils sophistiqués. C’est une séquence disciplinée : cartographier, prioriser, tester, mesurer. Les leviers sont publics et documentés. Ce qui se monnaie, c’est la rigueur d’exécution et la connaissance des pièges.

Si votre facture AWS dépasse 10 000 €/mois et que vous n’avez pas fait d’audit FinOps depuis plus d’un an, il y a très probablement entre 2 000 € et 5 000 € de gaspillage par mois dans votre compte. Démarrons un audit.