Facture AWS qui triple en 6 mois, la direction qui demande des comptes. En dizaines de missions FinOps, toujours le même constat : l’infra fonctionne, mais personne ne suit réellement l’évolution des coûts AWS.
Voici par où je commence. Les prix indiqués sont approximatifs en euros ; AWS facture en dollars, donc les montants réels varient selon le taux de change.
Le ménage d’abord
Premier réflexe : les ressources orphelines. Load balancers sans cibles, EBS volumes détachés, snapshots de 2019, Elastic IPs non associées. Sur une mission récente chez un client e-commerce, j’ai trouvé 47 EBS volumes détachés pour un total de 2.3 To. À ~0.10 €/Go/mois, ça fait ~230 €/mois pour du stockage inutilisé.
Un script qui parcourt toutes les régions aide à dresser l’inventaire complet. Cost Explorer montre bien les coûts par région, mais sans tags corrects, impossible de savoir qui a lancé quoi ni si c’est encore utile. Le vrai problème n’est pas de trouver les ressources, c’est de savoir à qui elles appartiennent et si elles sont toujours utilisées.
Les générations d’instances
Les instances EC2 vieillissent. Une m4.xlarge de 2016 offre moins de performances par euro qu’une m6i.xlarge de 2022, pour un prix comparable. AWS ne migre pas automatiquement, et les équipes n’y pensent pas.
Je trouve régulièrement des clusters entiers sur des instances de 2-3 générations de retard. Migration de m5 vers m6i ou m7i, c’est souvent 5-10% d’économie à performances équivalentes. Et les nouvelles générations sont plus performantes par vCPU, donc parfois on peut downsizer en même temps.
Exemple : des instances GPU p3.2xlarge (V100, ~3$/h) avec une vieille Debian 9 bourrée de CVE. Migrer vers des g5.2xlarge (A10G, ~1.20$/h) avec une AMI récente, c’est 60% moins cher, plus de VRAM (24 Go vs 16 Go), une architecture plus récente, et une surface d’attaque réduite. Seul compromis : moins de RAM système (32 Go vs 61 Go). Le gain n’est pas que financier.
Le rightsizing
CloudWatch stocke les métriques CPU par défaut. Pour la mémoire, il faut installer le CloudWatch Agent. Une fois en place, on peut analyser les ratios CPU/RAM réels et chercher une famille d’instance mieux adaptée au profil de consommation.
Cas classique : des instances t3.2xlarge choisies parce que les t3.medium avaient des problèmes de performance. Le CPU throttlait une fois les crédits épuisés, alors l’équipe a surdimensionné pour compenser. Sauf que le vrai problème venait du mode burstable, pas de la taille.
Passer sur des c5.large (performances constantes) a permis de diviser la taille par 4 et de réduire le nombre d’instances de 12 à 5 grâce à l’autoscaling. Résultat : 80% d’économie sur ce workload.
Point souvent ignoré : tous les vCPU ne se valent pas. Sur les instances burstables (T3, T4g), les vCPU sont partagés et peuvent throttler. Sur les familles dédiées (C5, M5, R5), chaque vCPU est garanti. Pour un workload client-facing, cette distinction est importante.
Graviton et ARM
Les instances Graviton (ARM) coûtent 20% moins cher que leurs équivalentes Intel/AMD, pour des performances souvent supérieures. Le frein habituel : “on ne sait pas si notre application tourne sur ARM”.
En pratique, si l’application est conteneurisée ou tourne sur une stack moderne (Node.js, Python, Go, Java récent), ça fonctionne. Il faut rebuilder les images Docker en multi-arch. Ça demande de configurer buildx et de vérifier que les dépendances ont des builds ARM. Comptez quelques jours pour adapter la CI/CD.
Commencer par les workloads stateless : workers, API sans état, batch processing. Le prérequis : des images container multi-arch (amd64 + arm64). Sans ça, les pods ne démarreront pas sur les nodes Graviton. Une fois les images prêtes, on ajoute des node groups ARM et on configure les node selectors ou taints appropriés.
À performance égale, ARM consomme moins d’énergie et coûte 20% moins cher. Pourquoi s’en priver ?
Les Spot Instances
Plus de 10 nodes EKS, 100% on-demand ? Vous aimez à ce point AWS ?!
60 à 80% de réduction sur les instances courantes, selon le type et la disponibilité. Oui, AWS peut reprendre l’instance avec 2 minutes de préavis. Mais sur Kubernetes, ça peut ne pas être un problème.
Kubernetes est conçu pour gérer le chaos. Un nœud qui se fait éjecter avec ses pods, le scheduler les replace ailleurs. Avec Karpenter ou le Cluster Autoscaler, le cluster provisionne automatiquement un nouveau node. En pratique, l’interruption est transparente si les bonnes pratiques Kubernetes sont respectées.
J’ai déjà fait tourner des clusters Kubernetes de 150 nœuds 100% Spot, sans problème majeur. Ça demande de la rigueur sur les bonnes pratiques Kubernetes.
Pour une base de données ou un service stateful critique, on reste sur on-demand. Pour le reste, Spot est un no-brainer si vous êtes sur Kubernetes.
Les engagements : Savings Plans et Reserved Instances
Une fois l’infra rightsizée, modernisée, et après avoir passé tout ce qu’on pouvait en Spot, on peut s’engager sur ce qui reste. Pas avant. Prendre des Savings Plans sans avoir fait les étapes précédentes, c’est dommage. On aurait pu diviser le coût du compute par 3 en passant sur chacune des étapes au-dessus. Au lieu de ça, on s’engage sur 1 an pour -30%.
Les Savings Plans sont plus flexibles que les Reserved Instances. Compute Savings Plans s’appliquent à n’importe quelle instance EC2, Fargate ou Lambda, dans n’importe quelle région. On s’engage sur un montant horaire, pas sur un type d’instance. Attention : les Compute Savings Plans ne couvrent pas RDS, ElastiCache ni Redshift. Pour ces services, il faut passer par des Reserved Instances dédiées.
Le calcul est simple. On regarde la baseline de consommation sur les 3 derniers mois. La partie stable, celle qui ne descend jamais en dessous d’un certain seuil, c’est ce qu’on peut couvrir en Savings Plans 1 an ou 3 ans.
→ Savings Plans 1 an : ~30% de réduction → Savings Plans 3 ans : ~50% de réduction
Je recommande de commencer par 1 an. Un engagement de 3 ans ? Si c’est pour perdre la flexibilité, autant ne pas être dans le cloud.
Les bases de données
RDS, c’est souvent le deuxième poste de dépense après EC2. Et c’est celui qu’on touche le moins parce que “la base de données, on n’y touche pas”.
Le premier levier : les Reserved Instances RDS. Contrairement à EC2 où les Savings Plans sont plus flexibles, pour RDS les Reserved Instances restent pertinentes. Une db.r6g.xlarge en on-demand coûte ~0.53 €/h. En Reserved 1 an, ~0.35 €/h. 34% d’économie. Sur une base de production qui tourne 24⁄7, c’est 1 300 €/an économisés par instance.
Le deuxième : le Multi-AZ. C’est 2x le prix. Pour une petite structure avec peu d’exigences de disponibilité, ce n’est pas toujours nécessaire, même en prod. En dev et staging, c’est rarement justifié.
Autre levier : la mutualisation. Plusieurs environnements de dev sur une seule instance RDS avec des schémas séparés, c’est souvent suffisant et bien moins cher que 5 instances dédiées.
Le troisième : le rightsizing. Même logique que EC2. Performance Insights montre l’utilisation CPU et mémoire. Une db.r6g.2xlarge à 30% de CPU, c’est une db.r6g.large qui suffit. Les bases de données sont sur-provisionnées par peur. Mais les métriques ne mentent pas.
Pour les workloads variables, Aurora Serverless v2 existe et scale automatiquement. Mais c’est encore plus de vendor lock-in. Revenir vers un MySQL ou PostgreSQL standard est faisable mais pénible : Aurora utilise un moteur de stockage propriétaire, et certaines fonctionnalités ne sont pas compatibles. À réserver aux cas où le scaling automatique est vraiment indispensable.
Attention au piège Aurora : au-delà du pricing complexe (stockage, I/O, compute facturés séparément), c’est du vendor lock-in. Aurora n’est pas PostgreSQL ou MySQL standard. Le jour où on veut quitter AWS, la migration sera douloureuse.
Les read replicas aussi. Chaque replica coûte autant que l’instance primaire. Trois replicas pour de la haute dispo, c’est 4x le prix. Parfois un ElastiCache devant la base coûte moins cher et améliore les perfs.
Le stockage
S3 d’abord. Les lifecycle policies sont gratuites et sous-utilisées. Des buckets avec des téraoctets de logs ou de backups qui n’ont pas été consultés depuis des années, facturés au tarif Standard. Ça arrive tout le temps.
| Classe | Prix/Go/mois | Cas d’usage |
|---|---|---|
| Standard | 0.024 € | Accès fréquent |
| Intelligent-Tiering | 0.024 € | Accès imprévisible (migration auto) |
| Glacier Instant | 0.005 € | Archives, accès rare mais immédiat |
| Glacier Deep Archive | 0.002 € | Compliance, jamais consulté |
Pour 10 To de backups consultés une fois par an, passer de Standard à Glacier Deep Archive économise 220 €/mois.
EBS ensuite. La migration de gp2 vers gp3, c’est 20% d’économie immédiate. gp3 offre plus d’IOPS et de throughput de base, pour moins cher. AWS ne migre pas automatiquement. J’en ai migré quelques-uns, c’est rapide et sans risque.
Le réseau
Pour les petites structures avec peu d’exigences de disponibilité : éviter le multi-AZ. Ça double les coûts réseau (trafic cross-AZ à 0.01 €/Go dans chaque sens).
Pour les autres : configurer des VPC Endpoints. Le NAT Gateway coûte 0.05 €/h plus 0.05 €/Go de données traitées. Les VPC endpoints pour S3, ECR et CloudWatch éliminent ce coût.
Un client m’a appelé après avoir reçu une alerte de facturation : pendant 3 jours, chaque jour il payait l’équivalent de sa facture mensuelle. Une boucle infinie dans son code tirait des images depuis S3 67 fois par minute. Sans VPC endpoint, tout passait par le NAT Gateway.
Leçon : les erreurs de code peuvent exploser la facture réseau. Mettez des VPC Endpoints.
L’observabilité
CloudWatch Logs, c’est souvent 5-10% de la facture sans que personne ne s’en rende compte. Par défaut, les logs sont conservés indéfiniment. Une application qui logge beaucoup peut générer des centaines de Go par mois.
Première action : définir une retention policy sur tous les log groups. 30 jours pour le dev, 90 jours pour la prod, 1 an pour l’audit si nécessaire. Pas “Never expire”.
Deuxième action : filtrer les logs avant ingestion. Les logs de debug en production, les health checks qui spamment, les requêtes HTTP 2xx/3xx qui n’apportent rien. Moins on ingère, moins on paie.
Les métriques CloudWatch aussi. La résolution à 1 minute coûte plus cher que 5 minutes. Vérifier si 5 minutes suffisent et ne pas laisser à 1 minute sans être sûr que c’est nécessaire.
Pour les clients avec un budget serré : activer CloudWatch Agent et le monitoring détaillé le temps de l’analyse (7-30 jours), collecter les données nécessaires pour le rightsizing, puis tout désactiver. On paie uniquement pour la période d’analyse.
Le tagging
Le cloud en self-service, c’est l’argent de quelqu’un d’autre. On prend l’instance la plus grosse parce que ça évite de réfléchir à combien on a vraiment besoin, et c’est la boîte qui paie.
Sans tags, impossible de savoir qui dépense quoi. On ne peut pas corriger un problème qu’on ne mesure pas. C’est un travail d’équipe de faire en sorte que la facture ne dérape pas.
Le minimum : un tag environment (prod, staging, dev) et un tag team ou project. Ça permet de ventiler les coûts dans Cost Explorer et d’identifier qui fait exploser la facture. Et surtout, ça responsabilise. Quand une équipe voit sa propre consommation, elle commence à faire attention.
AWS permet de rendre les tags obligatoires avec des SCPs (Service Control Policies). Si une ressource n’a pas le tag requis, elle ne peut pas être créée. Ça demande un peu de setup, mais ça évite les ressources orphelines non identifiables.
Activer les Cost Allocation Tags dans la console Billing. Sans ça, les tags existent mais ne remontent pas dans Cost Explorer.
Un outil gratuit souvent ignoré : Cost Anomaly Detection. AWS envoie des alertes automatiques quand les dépenses dévient de la normale. Ça ne coûte rien à configurer et ça évite les mauvaises surprises en fin de mois.
Le multi-compte
Les scale-ups qui grandissent finissent avec plusieurs comptes AWS. Un compte prod, un compte dev, un compte data, un compte sandbox. En tout cas faut espérer, sinon c’est le bordel.
AWS Organizations permet de centraliser la facturation. Tous les comptes remontent vers un compte de management, et on voit la facture consolidée. Sans ça, chaque compte a sa propre facture et personne n’a la vision globale.
Le vrai gain : le partage des Savings Plans et Reserved Instances. Un Savings Plan acheté sur le compte de management s’applique automatiquement à tous les comptes de l’organisation. Si le compte prod n’utilise pas tout le commitment, le compte dev en profite. Sans Organizations, chaque compte doit acheter ses propres engagements, et on perd en flexibilité.
Les SCPs (Service Control Policies) permettent de bloquer certaines actions au niveau de l’organisation. Interdire les instances > 4xlarge en dev, bloquer certaines régions coûteuses, forcer le tagging. C’est de la gouvernance, mais ça évite les dérapages.
Attention au compte de management : il ne doit rien héberger. Pas de workloads, pas d’infra. Juste la facturation et les policies. J’ai vu des organisations avec leur prod sur le compte de management. Mauvaise idée pour la sécurité et la lisibilité des coûts.
Besoin d’un regard externe sur votre facture AWS ? Contactez-moi.