Objectif de cette page : réduire votre facture AWS avec une méthode, pas des coups de rabot au hasard. Quand une facture AWS dérape, le coupable n'est pas le service : c'est une infrastructure dimensionnée pour le pire cas, jamais rationalisée, et privée de la moindre boucle de pilotage des coûts. La bonne nouvelle, c'est que l'écart entre ce que vous payez et ce que vous devriez payer est mesurable, et qu'on le réduit avec une méthode, pas avec des coups de rabot au hasard. Cette page détaille les leviers, leur gain réel, leurs pièges, et la façon de structurer une démarche FinOps qui tient dans le temps.
Réduire sa facture AWS : les 6 leviers essentiels
Pour répondre directement à la question, voici les six leviers qui pèsent le plus, par ordre d'impact habituel sur une infrastructure jamais optimisée :
- Rightsizing : redimensionner les instances EC2 et RDS surdimensionnées à l'aide d'AWS Compute Optimizer.
- Engagements : couvrir la charge stable avec des Savings Plans ou des Reserved Instances (jusqu'à 72 % de remise sur le tarif On-Demand).
- Spot : exécuter les charges tolérantes aux interruptions sur des instances Spot (jusqu'à 90 % de remise).
- Extinction hors usage : arrêter automatiquement les environnements non-production la nuit et le week-end.
- Stockage : déplacer les données S3 et EBS vers les classes adaptées à leur fréquence d'accès.
- Coûts cachés : traquer le transfert de données, les NAT Gateway et les ressources orphelines que personne ne surveille.
Sur une infrastructure qui n'a jamais été optimisée, l'application combinée de ces leviers permet d'observer 20 à 40 % d'économies en moyenne, et 30 à 50 % dans les cas les plus dégradés. Aucun de ces chiffres n'est garanti : ils dépendent de votre architecture, de votre profil de charge et de votre marge de manœuvre contractuelle.
| Levier | Gain moyen observé | Effort | Délai | Risque | |---|---|---|---|---| | Rightsizing EC2 / RDS | 10-25 % | Faible | J+7 à J+30 | Faible | | Savings Plans / Reserved Instances | 20-50 % sur le compute | Moyen | J+15 (engagement) | Moyen (sur-engagement) | | Spot Instances | 50-90 % sur les charges éligibles | Moyen à élevé | J+30 à J+90 | Élevé (interruption) | | Extinction hors usage (non-prod) | 30-65 % sur le non-prod | Faible | J+7 | Très faible | | Optimisation stockage S3 / EBS | 20-60 % sur le stockage | Faible à moyen | J+15 | Faible | | Suppression ressources orphelines | 2-10 % de la facture | Faible | J+7 | Très faible | | Coûts cachés (NAT, data transfer) | 5-20 % du réseau | Moyen | J+30 à J+90 | Faible à moyen |
Ce tableau est un point de départ, pas un diagnostic. La suite de cette page explique comment qualifier chaque levier sur votre propre compte, et notre audit des coûts cloud le fait sur vos données réelles plutôt que sur des moyennes de marché.
Le réflexe à éviter. La plupart des projets de réduction de facture commencent par le levier le plus visible (les engagements) avant d'avoir nettoyé et redimensionné. C'est l'inverse : on engage en dernier, sur une base déjà assainie, sinon on réserve durablement du gaspillage.
Pourquoi votre facture AWS dérape
Avant d'optimiser, il faut comprendre pourquoi une facture AWS gonfle. Les causes sont presque toujours structurelles, rarement accidentelles. Cette section répond à une question que beaucoup d'équipes se posent sans oser la formuler : pourquoi est-ce que je paie autant ?
La jungle tarifaire
AWS publie plus de 200 services, chacun avec sa propre logique de facturation. Une instance EC2 se facture à la seconde ; un bucket S3 au gigaoctet stocké, mais aussi aux requêtes et au transfert sortant ; une Lambda à la milliseconde-gigaoctet ; un NAT Gateway à l'heure et au gigaoctet traité. Personne ne tient cette complexité de tête. Résultat : on dimensionne large « pour être tranquille », et la marge de sécurité devient une rente versée à Amazon mois après mois.
Le sur-provisionnement systématique
C'est la première cause de gaspillage. Une instance dimensionnée pour le pic de Black Friday tourne 360 jours par an à 12 % d'utilisation CPU. Une base RDS provisionnée en db.r5.4xlarge parce que « ça plantera pas » consomme 8 fois ce dont elle a besoin. Le sur-provisionnement est rationnel à l'instant T (l'équipe veut éviter l'incident), mais personne ne revient jamais corriger le dimensionnement une fois la charge réelle connue.
L'absence de tagging et de visibilité
Sans étiquetage cohérent, vous ne savez pas quelle équipe, quel projet ou quel environnement consomme quoi. Une facture AWS sans tags, c'est un relevé bancaire sans libellés : un total, et aucune ligne. Impossible de responsabiliser, impossible de prioriser. La majorité des comptes que nous auditons ont moins de 30 % de leurs ressources correctement étiquetées.
Les environnements oubliés
Un POC monté il y a 18 mois et jamais arrêté. Un environnement de recette cloné pour un test ponctuel. Un compte de développeur parti depuis. Ces ressources « zombies » ne servent plus rien mais continuent de facturer. Sur les comptes anciens, elles représentent couramment 5 à 15 % de la dépense.
L'absence de boucle FinOps
Le vrai problème n'est ni technique ni ponctuel : c'est l'absence de processus. Sans personne qui regarde la facture chaque mois, sans alerte sur les anomalies, sans rituel d'arbitrage coût/valeur, toute optimisation se dégrade en quelques mois. La dérive revient parce que la cause, l'absence de gouvernance, n'a pas été traitée. C'est exactement ce que structure une démarche FinOps, et le cœur de notre approche d'optimisation des coûts cloud (FinOps).
Levier 1, le rightsizing : redimensionner au plus juste
Le rightsizing consiste à ajuster la taille (type, famille, génération) des ressources à la charge réellement observée, plutôt qu'à la charge théorique anticipée. C'est le levier au meilleur rapport gain/risque, parce qu'il ne change rien à votre architecture : il enlève seulement ce que vous payez sans l'utiliser.
Qu'est-ce que le rightsizing sur AWS
Concrètement, on compare l'utilisation observée (CPU, mémoire, réseau, IOPS) sur une fenêtre représentative, au moins 14 jours, idéalement un cycle métier complet, à la capacité provisionnée. Une instance m5.2xlarge qui ne dépasse jamais 20 % de CPU et 35 % de mémoire peut descendre en m5.large, soit 4 fois moins cher, sans dégradation perceptible.
AWS Compute Optimizer est l'outil natif de référence : il analyse les métriques CloudWatch de vos instances EC2, vos volumes EBS, vos fonctions Lambda et vos bases Aurora/RDS, puis propose des recommandations de redimensionnement chiffrées, avec le gain mensuel estimé. Il est gratuit. Son angle mort : il raisonne sur la métrique, pas sur le métier. Il ne sait pas qu'une instance « surdimensionnée » porte en réalité un pic trimestriel de clôture comptable. C'est là que l'analyse humaine reprend la main.
La piste souvent oubliée : changer d'architecture processeur
Le rightsizing ne se limite pas à la taille. Migrer une charge x86 (Intel/AMD) vers AWS Graviton (processeurs ARM conçus par AWS) offre couramment 20 % de réduction de coût à performance égale ou supérieure, et une meilleure efficacité énergétique. La migration est simple pour la plupart des charges interprétées (Java, Python, Node.js, Go) et des services managés (RDS, ElastiCache, OpenSearch proposent des variantes Graviton). Elle demande une recompilation/un test pour le code natif. C'est un levier que la majorité des pages concurrentes ignorent.
Erreur courante. Redimensionner instance par instance, à la main, une fois par an. Le rightsizing n'a de valeur que s'il est continu : la charge évolue, le code change, les pics se déplacent. On l'industrialise via Compute Optimizer + une revue mensuelle, pas via un grand nettoyage annuel.
Levier 2, les modèles de tarification : l'essentiel pour agir
C'est le levier financier le plus puissant et le plus risqué. Bien compris, il divise la facture compute par deux ou trois. Mal piloté, il vous enferme dans des engagements sur des ressources que vous n'utilisez plus. En version action, retenez quatre modèles et une règle.
Les quatre modèles : l'On-Demand (tarif plein, sans engagement, pour l'imprévisible) ; les Reserved Instances (engagement 1 ou 3 ans sur un type d'instance, jusqu'à 72 % de remise, encore incontournables pour RDS, Redshift, ElastiCache) ; les Savings Plans (engagement sur un montant horaire de dépense, jusqu'à 66 % pour les Compute SP qui couvrent EC2, Fargate et Lambda) ; et le Spot (capacité inutilisée, jusqu'à 90 % de remise, récupérable en 2 minutes, voir le levier 3 ci-dessous).
La règle qui évite la faute la plus chère : on engage en dernier, sur une base déjà assainie, et jamais 100 % de la charge. On couvre le socle stable (la « baseload ») à hauteur de 60 à 80 % de la consommation minimale garantie, on absorbe les variations en On-Demand, on bascule l'interruptible en Spot. Engager une charge surdimensionnée revient à réserver durablement du gaspillage.
Le comparatif chiffré complet (Savings Plans vs Reserved Instances vs Spot, arbitrage famille par famille, EC2 Instance SP vs Compute SP, cas RDS/Redshift), la mécanique détaillée des engagements et la gouvernance des achats sont traités en profondeur dans le guide complet d'optimisation des coûts AWS, à la section « Les modèles de tarification et les engagements ». Cette page-ci reste centrée sur l'action immédiate et l'angle distinctif des coûts cachés.
Le piège du sur-engagement (l'angle de pilotage AWS). Un Savings Plan ou un RI signé pour 3 ans sur une base de consommation trop optimiste devient un coût irrécupérable si votre architecture change (migration vers le serverless, baisse d'activité, refonte). Le bon réflexe, propre à cette page : surveiller en continu le taux de couverture (part de la conso couverte par un engagement) et le taux d'utilisation (part de l'engagement réellement consommée). Une utilisation sous 95 % signale du gaspillage ; une couverture sous 60 % signale un potentiel d'économie non capté. Ce sont les deux KPI que les prestataires de notre réseau pilotent en priorité sur AWS.
Levier 3, le Spot : l'économie maximale pour qui sait l'encaisser
Une instance Spot est de la capacité EC2 excédentaire qu'AWS loue à prix cassé tant qu'elle n'en a pas besoin pour ses clients On-Demand. Combien fait-elle économiser ? Couramment 70 à 90 % par rapport au tarif On-Demand. La contrepartie : AWS peut la récupérer à tout moment avec 2 minutes de préavis.
Le Spot n'est donc pas un levier universel, c'est un levier conditionnel. Il convient parfaitement aux charges qui peuvent être interrompues et reprises :
- Pipelines d'intégration et de déploiement continus (CI/CD).
- Traitements batch et ETL, jobs Spark/EMR, rendu, encodage vidéo, calcul scientifique.
- Workers asynchrones derrière une file (SQS).
- Environnements de test et de développement.
- Charges conteneurisées stateless sur EKS/ECS, via des node groups Spot.
L'industrialisation passe par les Auto Scaling Groups à capacité mixte (un pourcentage de base en On-Demand pour la stabilité, le surplus en Spot pour l'économie) et par une bonne gestion de l'interruption (sauvegarde d'état, drain propre des pods, reprise idempotente). Pour les conteneurs, Fargate Spot applique la même logique sans gérer de serveurs.
Levier 4, éteindre ce qui ne sert pas la nuit
C'est le levier le plus simple et le plus sous-exploité. Vos environnements de développement, de recette et de pré-production ne servent à personne entre 20 h et 8 h, ni le week-end. Pourtant, par défaut, ils tournent 168 heures par semaine. En les limitant aux heures ouvrées (environ 50 heures), vous coupez 65 à 70 % de leur coût compute sans aucune perte d'usage.
AWS Instance Scheduler est la solution native : elle démarre et arrête automatiquement les instances EC2 et RDS selon un calendrier défini par tag. On étiquette les ressources non-prod, on définit les plages horaires, et l'extinction devient automatique. Pour les charges conteneurisées, le même principe s'applique via le scale-to-zero : un Auto Scaling Group ou un node group qui descend à zéro nœud hors usage.
Comment arrêter automatiquement les instances EC2 non utilisées. On déploie AWS Instance Scheduler (ou un planificateur équivalent piloté par EventBridge + Lambda), on tague chaque ressource non-prod avec sa plage d'activité, et on vérifie qu'aucun batch nocturne légitime n'est cassé au passage. Ce levier seul rentabilise souvent à lui seul le coût d'un audit en quelques semaines.
Levier 5, optimiser le stockage S3, EBS et les snapshots
Le stockage paraît anodin (quelques centimes le gigaoctet), mais à l'échelle du téraoctet conservé pendant des années, il pèse. Et il est mal rangé dans 90 % des comptes.
Comment optimiser les coûts de stockage S3
Amazon S3 propose plusieurs classes de stockage, dont le prix décroît avec la fréquence d'accès attendue :
| Classe S3 | Cas d'usage | Coût relatif au stockage | |---|---|---| | S3 Standard | Données chaudes, accès fréquent | Référence (le plus cher) | | S3 Standard-IA (Infrequent Access) | Accès rare mais immédiat requis | ~40 % moins cher | | S3 Intelligent-Tiering | Accès imprévisible (déplace seul les objets) | Standard + frais de monitoring | | S3 Glacier Instant Retrieval | Archives consultées rarement, accès immédiat | Très bas | | S3 Glacier Flexible Retrieval | Archives, restauration en minutes/heures | Encore plus bas | | S3 Glacier Deep Archive | Conservation longue (légale, sauvegarde) | Le plus bas (~95 % sous Standard) |
La règle : on n'archive pas à la main, on définit des règles de cycle de vie (lifecycle policies) qui font transiter automatiquement les objets vers les classes plus froides selon leur âge. Pour les données dont le profil d'accès est imprévisible, S3 Intelligent-Tiering déplace les objets tout seul entre les paliers et évite de payer le tarif chaud sur du froid, sans risque de pénalité de récupération.
EBS et snapshots : la dette silencieuse
Les volumes EBS sont facturés qu'ils soient attachés ou non. Migrer un volume gp2 ancien vers gp3 réduit le coût de ~20 % à performance égale, avec IOPS et débit réglables indépendamment de la taille. Et surtout : les snapshots s'accumulent. Une politique de sauvegarde mal bornée crée des centaines de snapshots conservés indéfiniment, chacun facturé. On définit une rétention, on supprime les snapshots orphelins (dont le volume source n'existe plus), et on en fait une règle automatisée.
Levier 6, les ressources orphelines : le ménage qui rapporte
Ce sont les ressources qui facturent sans rendre aucun service. On les traque systématiquement :
- Volumes EBS détachés : restés après la suppression d'une instance, facturés au gigaoctet.
- Snapshots orphelins : dont le volume ou l'AMI d'origine n'existe plus.
- Adresses IP élastiques non associées : AWS facture une IP élastique réservée mais non rattachée à une instance active.
- Load Balancers inactifs : un ALB ou NLB sans cible saine continue de facturer son tarif horaire.
- NAT Gateway orphelins, endpoints inutilisés, clusters EKS vides, environnements de POC abandonnés.
Pris isolément, chaque élément paraît négligeable. Cumulés, ils représentent couramment 2 à 10 % de la facture. AWS Trusted Advisor signale une partie de ces gisements (IP non associées, load balancers inactifs, RI sous-utilisées), et un audit dédié remonte le reste. C'est l'un des premiers gestes de notre audit des coûts cloud.
Les coûts cachés que personne ne surveille
Voici le cœur de cette page, son angle distinctif et la section de référence du silo sur le sujet : les coûts qui n'apparaissent pas dans les listes de leviers classiques parce qu'ils sont diffus, techniques, et invisibles tant qu'on ne décompose pas la facture. C'est ici, et non ailleurs sur le site, que ces gisements sont traités en profondeur. Le guide complet d'optimisation des coûts AWS les résume et renvoie à cette page.
Le transfert de données : la facture fantôme
Le data transfer est probablement le poste le plus mal compris d'AWS. Trois pièges principaux :
- Sortie internet (data transfer out) : tout octet qui sort d'AWS vers internet est facturé, en moyenne autour de 0,09 €/Go (dégressif au volume) après une franchise mensuelle modeste. L'entrée est gratuite ; la sortie, jamais.
- Trafic inter-zones (cross-AZ) : deux services qui dialoguent entre deux zones de disponibilité différentes sont facturés dans les deux sens, de l'ordre de 0,01 €/Go par sens, soit ~0,02 €/Go au total. Anodin à l'unité, ruineux pour une architecture micro-services bavarde qui échange des téraoctets entre AZ.
- Trafic inter-région : répliquer ou échanger des données entre régions AWS (par exemple eu-west-3 ↔ eu-west-1) coûte sensiblement plus cher que le cross-AZ.
Comment éviter les frais de transfert de données AWS : garder le trafic chaud dans une même zone de disponibilité quand la résilience le permet, utiliser CloudFront pour servir le contenu sortant (le transfert CloudFront vers internet est moins cher que l'EgressEC2 direct et bénéficie du cache), rapatrier les échanges intensifs derrière des VPC Endpoints, et surveiller les services dont la sortie est facturée à part (sortie CloudFront, réplication S3, flux CloudWatch Logs).
Le NAT Gateway : pourquoi il coûte si cher
Le NAT Gateway est le champion des coûts cachés. Pourquoi coûte-t-il si cher ? Parce qu'il cumule deux facturations : un coût horaire (de l'ordre de 0,045 €/heure, soit ~32-40 €/mois par gateway, multiplié par le nombre d'AZ pour la haute disponibilité) plus un coût de traitement par gigaoctet (~0,045 €/Go) sur tout le trafic qui le traverse. Une infrastructure qui fait transiter ses appels vers S3, DynamoDB ou les API AWS par le NAT Gateway paie ce traitement par Go sur des volumes qui pourraient passer gratuitement.
La parade est architecturale et radicale :
- VPC Gateway Endpoints pour S3 et DynamoDB : ils sont entièrement gratuits. Le trafic vers S3/DynamoDB ne passe plus par le NAT Gateway, il emprunte un chemin privé sans frais de traitement. Sur une infra qui lit/écrit massivement dans S3, c'est une économie immédiate et structurelle.
- VPC Interface Endpoints (PrivateLink) pour les autres services AWS (ECR, CloudWatch, SSM, Secrets Manager, etc.) : ils ont un coût horaire et un coût par Go, mais ce dernier est de l'ordre de 78 % inférieur au traitement NAT pour le trafic concerné, tout en améliorant la posture de sécurité (pas de sortie internet).
Constaté en mission. Sur un environnement de production où l'application écrivait en continu dans S3 via un NAT Gateway, le simple ajout d'un Gateway Endpoint S3 a supprimé l'essentiel du trafic facturé du NAT. Le correctif tient en quelques lignes de Terraform. Ce gisement n'apparaît jamais dans Cost Explorer au niveau service : il faut décomposer le poste réseau pour le voir.
Les services dont le coût data est oublié
Au-delà du réseau, plusieurs services facturent des dimensions que les équipes oublient de surveiller :
- Amazon Aurora : facture les I/O en plus du compute et du stockage ; sur une charge très transactionnelle, le poste I/O peut dépasser le reste. Aurora I/O-Optimized peut alors devenir rentable.
- RDS et Redshift : stockage, IOPS provisionnés, sauvegardes au-delà de la franchise, réplicas de lecture souvent surdimensionnés.
- DynamoDB : capacité provisionnée payée même inutilisée (préférer le mode On-Demand sur charge irrégulière), plus le stockage et les flux.
- CloudWatch Logs : l'ingestion et la rétention infinie des logs coûtent cher ; définir une rétention par groupe de logs et filtrer ce qu'on ingère.
- ElastiCache : nœuds surdimensionnés, souvent jamais réservés alors qu'ils sont parfaitement stables.
Ces postes échappent aux optimisations « compute » classiques. Les repérer demande une lecture fine du Cost and Usage Report (CUR), pas du tableau de bord agrégé.
Le mode de facturation des bases : provisionné vs à la demande
Une décision récurrente, mal arbitrée, fait gonfler les factures de données : choisir entre capacité provisionnée (vous payez une réserve fixe, qu'elle serve ou non) et capacité à la demande (vous payez l'usage réel). La règle :
- Charge régulière et prévisible → provisionné, idéalement couvert par un engagement. C'est moins cher à l'unité.
- Charge irrégulière, en pics ou imprévisible → à la demande. On évite de payer une réserve dormante.
DynamoDB illustre parfaitement le piège : une table en capacité provisionnée fixe, dimensionnée pour un pic rare, paie 24/7 une capacité utilisée quelques heures par mois. Le mode On-Demand (ou l'auto-scaling de la capacité provisionnée) corrige cela. Le même raisonnement vaut pour Aurora Serverless v2 face à une instance Aurora provisionnée sur une charge en dents de scie.
Relier le coût au code : IaC, Terraform et FinOps « shift-left »
Le FinOps le plus rentable est celui qui agit avant que la ressource n'existe. Quand l'infrastructure est décrite en Terraform (Infrastructure as Code), le coût devient une propriété du code, pas une surprise de fin de mois. Trois pratiques concrètes :
- Estimer le coût dans la pull request : Infracost lit le plan Terraform et affiche, directement dans la revue de code, le delta de coût mensuel qu'un changement va provoquer. L'équipe arbitre en connaissance de cause, au moment où la décision est réversible et gratuite.
- Imposer les garde-fous par le code : les Service Control Policies d'AWS Organizations refusent au niveau organisation les ressources non taguées, les régions non autorisées ou les types d'instances bannis. Le gaspillage devient impossible à créer, pas seulement à corriger.
- Versionner et garder le contrôle : tout le code d'infrastructure et de correctif vit dans vos dépôts. Vous gardez l'historique, vous pouvez auditer chaque changement, et vous restez autonome. C'est notre principe de réversibilité appliqué au FinOps.
Cette approche relie la maîtrise des coûts à la gouvernance et au DevOps : elle ne traite plus le coût comme un rapport mensuel subi, mais comme une contrainte d'ingénierie intégrée au cycle de livraison. C'est l'aboutissement d'une démarche d'optimisation des coûts cloud (FinOps) mature.
L'auto-scaling et l'élasticité : payer pour la charge réelle
La logique fondatrice du cloud, c'est de payer ce qu'on consomme. Le sur-provisionnement la trahit ; l'élasticité la restaure. Les Auto Scaling Groups ajustent automatiquement le nombre d'instances à la charge : on monte aux heures de pointe, on redescend la nuit, on vise même le scale-to-zero pour les charges qui peuvent disparaître complètement hors usage.
Le levier le plus profond, c'est de réinterroger l'architecture elle-même. Une charge événementielle ou en pics qui tourne sur des instances EC2 allumées 24/7 paie du temps mort. La même charge en AWS Lambda (serverless, facturé à l'exécution) ou en Fargate (conteneurs sans serveur à gérer) ne paie que les invocations réelles. Pour des charges intermittentes, le passage au serverless divise la facture par un facteur souvent supérieur à celui de tous les autres leviers réunis. C'est un levier d'architecture, pas de réglage, et c'est pourquoi il relève d'un travail de conseil en architecture.
Conteneurs : le coût caché de la densité
Les charges conteneurisées sur Amazon EKS ou ECS ont leur propre gisement d'économies, distinct de l'EC2 brut. Le problème typique : des nœuds sous-utilisés parce que les requests CPU/mémoire des pods sont surdéclarées « par sécurité », ce qui empêche le bin-packing de remplir les nœuds. Trois leviers spécifiques aux conteneurs :
- Ajuster les requests/limits au plus juste : c'est le rightsizing à l'échelle du pod. Des requests réalistes augmentent la densité et réduisent le nombre de nœuds. Des outils comme le Vertical Pod Autoscaler ou Goldilocks aident à les calibrer.
- Optimiser le provisionnement de nœuds : un autoscaler de nœuds (Cluster Autoscaler ou Karpenter) qui choisit dynamiquement le type d'instance le moins cher répondant au besoin, et qui mélange On-Demand et Spot, évite de payer des nœuds à moitié vides.
- Basculer le plan de calcul vers Graviton et Spot : un node group ARM Spot pour les charges stateless concentre deux remises (jusqu'à 90 % Spot + ~20 % Graviton) sur la même charge.
Sur EKS, ne pas oublier le coût horaire du plan de contrôle de chaque cluster : multiplier les clusters de test inutilisés est un gaspillage discret que l'on traite comme une ressource orpheline. Pour un travail de fond sur l'architecture conteneurisée, voir notre offre d'infrastructure et DevOps.
Les outils natifs de visibilité AWS
On n'optimise pas ce qu'on ne mesure pas. AWS fournit une boîte à outils native, gratuite ou peu coûteuse, qu'il faut activer et configurer avant tout chantier d'optimisation.
- AWS Cost Explorer : l'outil d'analyse de référence. Il visualise et filtre la dépense par service, compte, tag, type d'usage, sur 13 mois d'historique, projette les coûts futurs et calcule les recommandations de Savings Plans/RI. Comment fonctionne Cost Explorer ? On l'active dans la console de facturation, on filtre par dimension (service, tag d'équipe, région), on identifie les postes dominants et leur tendance, puis on descend dans le détail pour isoler la cause d'une hausse.
- AWS Budgets : définit des seuils de dépense (ou d'utilisation des réservations) et déclenche des alertes par mail/SNS au franchissement. C'est le garde-fou anti-dérive.
- AWS Cost Anomaly Detection : détecte par apprentissage automatique les écarts anormaux de dépense et alerte avant que la facture mensuelle ne tombe. Indispensable pour attraper un environnement oublié allumé ou un job devenu fou.
- AWS Trusted Advisor : passe en revue les bonnes pratiques, dont un volet coûts (instances inactives, RI sous-utilisées, IP non associées, load balancers inactifs).
- AWS Compute Optimizer : déjà cité, le moteur de recommandation de rightsizing.
- Cost and Usage Report (CUR) : le relevé le plus détaillé d'AWS, à la ligne d'usage, exporté vers S3 et analysable dans Athena/QuickSight. C'est la matière première d'un audit FinOps sérieux : tout ce que les tableaux de bord agrègent, le CUR le décompose.
Outils tiers. Au-delà du natif, des plateformes comme CloudHealth, Spot.io, CloudZero ou Apptio Cloudability ajoutent de la granularité multicloud, de l'automatisation d'achat de Spot et de la répartition fine des coûts partagés. Et pour relier coût et code, Infracost estime le coût d'un changement Terraform avant le
terraform apply, dans la pull request : le FinOps déplacé en amont, au moment de la décision.
Le tagging et l'allocation des coûts : showback et chargeback
Sans étiquetage, pas de FinOps. Le tagging consiste à apposer sur chaque ressource des métadonnées normalisées : centre de coût, équipe, projet, environnement (prod/staging/dev), application. Ces tags, une fois activés comme tags de répartition des coûts dans la console de facturation, permettent de ventiler la facture par dimension métier.
De là découlent deux pratiques :
- Showback : on montre à chaque équipe ce qu'elle consomme, sans refacturation. La transparence suffit souvent à faire baisser la dépense : une équipe qui voit son coût rationalise d'elle-même.
- Chargeback : on refacture réellement la consommation aux centres de coût, ce qui responsabilise pleinement mais demande une comptabilité analytique mature.
La difficulté n'est pas technique, elle est organisationnelle : définir une taxonomie de tags stable, l'imposer dès la création des ressources (via Terraform et des Service Control Policies qui refusent les ressources non taguées), et la maintenir. C'est un prérequis, pas une option : une optimisation sans tagging se pilote à l'aveugle.
La démarche FinOps en bref : ce que ça change pour votre facture AWS
Réduire une facture une fois est facile ; la maintenir basse est un métier. C'est ce que structure le FinOps (Cloud Financial Operations), formalisé par la FinOps Foundation dont nous sommes membre : une discipline qui réunit finance, technique et métier autour d'une responsabilité partagée de la dépense, en trois phases, Inform (rendre la dépense visible), Optimize (appliquer les leviers ci-dessus, priorisés par ROI) et Operate (ancrer dans la durée pour empêcher la dérive de revenir). Sur AWS, cette démarche s'inscrit dans le pilier Cost Optimization du Well-Architected Framework.
Le cadre conceptuel complet (les six principes, le modèle de maturité Crawl/Walk/Run, FinOps vs DevOps/SRE) est détaillé sur le pilier : voir la méthode FinOps par paliers : Crawl, Walk, Run. Pour le métier qui porte cette démarche, voir le consultant FinOps ; pour l'écosystème AWS dans son ensemble, le guide complet d'optimisation des coûts AWS.
La gouvernance multi-comptes : industrialiser à l'échelle
Au-delà d'un seul compte, l'optimisation devient un sujet de gouvernance. Le principe à retenir pour agir : AWS Organizations consolide la facturation d'une arborescence de comptes, et surtout mutualise automatiquement réservations et Savings Plans sur l'ensemble des comptes liés. Un engagement non consommé par un compte bénéficie à un autre, ce qui maximise le taux d'utilisation. Les Service Control Policies y imposent les garde-fous anti-gaspillage (régions interdites, instances bannies, ressources non taguées refusées à la création).
La mise en œuvre détaillée de cette gouvernance multi-comptes (Organizations, SCP, IAM Identity Center, landing zone) est traitée dans le guide complet d'optimisation des coûts AWS, à la section « Operate : gouvernance, outils et culture FinOps ». Elle s'inscrit dans une logique plus large de gouvernance cloud, dont la maîtrise des coûts n'est qu'un volet.
Cadrer le plan : du diagnostic à l'exécution
Réduire une facture de façon fiable ne s'improvise pas : on établit d'abord la vérité de la facture (à partir du Cost and Usage Report, pas du résumé), on cartographie le gaspillage en euros par mois, on priorise par ROI (gain × effort), puis on exécute des quick wins vers le structurel. C'est exactement la séquence reprise dans la roadmap 30/90/365 plus bas : sa traduction pour AWS.
Le déroulé méthodologique complet de cet audit chiffré (les cinq étapes en lecture seule, le périmètre examiné, les prérequis de tagging, la feuille de route priorisée comme livrable et les garde-fous de production) est détaillé sur la méthode d'audit des coûts cloud, à la section « Méthodologie : les étapes d'un audit des coûts cloud ». Cette page-ci reste centrée sur les leviers AWS eux-mêmes et leur exécution.
Cas représentatif (anonymisé). Pour un éditeur SaaS (ETI) dont la facture AWS approchait 40 000 €/mois, le diagnostic a remonté : un non-prod jamais éteint, un sur-provisionnement RDS marqué, du trafic S3 routé par NAT Gateway, et zéro engagement. L'application des quick wins puis du structurel a permis d'observer une réduction de l'ordre de 30 % sur le trimestre, sans aucune dégradation de service. Ce résultat est représentatif d'une infra non optimisée, pas une garantie : votre cas dépend de votre point de départ.
Combien ça coûte, combien de temps, quels livrables
La transparence sur le prix fait partie de notre indépendance. Un audit de réduction de facture AWS se situe, selon le périmètre, entre 5 000 et 12 000 €, pour une durée de 2 à 5 jours d'analyse. Ce budget est indicatif : il dépend du nombre de comptes, du volume de la facture, de la complexité de l'architecture et du niveau de détail attendu. Le chiffrage ferme se fait sur devis, après un échange de cadrage. Un environnement mono-compte se traite dans le bas de la fourchette ; une organisation multi-comptes, data intensive et avec des engagements en cours, se situe plus haut.
La mission type s'organise en trois temps : un cadrage (accès en lecture seule, périmètre, objectifs sans dégrader perf ni sécurité), une collecte et analyse (CUR, Cost Explorer, Compute Optimizer, Trusted Advisor ; décomposition par service, tag, compte ; chasse aux coûts cachés et aux orphelins), puis une restitution : rapport de findings chiffrés, tableau de gains par levier, roadmap 30/90/365 jours, et (si vous le souhaitez) le code Terraform des correctifs versionné dans vos dépôts. Tout vous appartient.
Sur le retour sur investissement : sur une facture de 30 000 €/mois, une économie observée de 25 % représente environ 90 000 €/an, de sorte que l'audit se rentabilise généralement en 1 à 3 mois sur une infra non encore optimisée. Ces chiffres sont des ordres de grandeur observés, pas une promesse. Le détail du calcul de ROI, le business case pour la direction financière et le seuil de rentabilité d'une démarche sont développés sur la méthode d'audit des coûts cloud, à la section « Combien coûte un audit des coûts cloud, et combien de temps dure-t-il ? ». Voir aussi notre offre d'audit FinOps.
La roadmap 30 / 90 / 365 jours
Une réduction de facture durable suit une séquence. Vouloir tout faire d'un coup mène à l'engagement prématuré et à la dégradation.
J+30 : les quick wins (sans risque, gain immédiat)
- Supprimer les ressources orphelines (EBS détachés, snapshots, IP élastiques, load balancers inactifs).
- Activer l'extinction hors usage sur tout le non-prod.
- Appliquer les recommandations de rightsizing à risque nul de Compute Optimizer.
- Ajouter les Gateway Endpoints S3/DynamoDB et corriger les NAT Gateway les plus coûteux.
- Activer Cost Anomaly Detection et poser des budgets d'alerte.
Ces gestes ne demandent aucun engagement et capturent souvent 10 à 20 % dès le premier mois.
J+90 : le structurel
- Déployer une taxonomie de tags et l'imposer (Terraform + SCP).
- Mettre en place les règles de cycle de vie S3, migrer EBS vers gp3.
- Construire la stratégie d'engagement (couverture cible 60-80 % de la baseload) et signer les premiers Savings Plans une fois la base assainie.
- Basculer les charges interruptibles en Spot.
- Étudier les leviers d'architecture (Graviton, serverless, élasticité).
J+365 : le FinOps continu
- Rituel mensuel coût/valeur avec les équipes.
- Pilotage permanent du taux de couverture et d'utilisation des engagements.
- Intégration du coût dans les pull requests (Infracost) et les décisions d'architecture.
- Mesure de l'impact carbone (voir plus bas) et boucle d'amélioration.
Cette progression est exactement celle que nous coordonnons ; pour les organisations qui veulent l'externaliser dans la durée, elle se prolonge naturellement en infogérance cloud entreprise.
Les pièges et les limites : quand ne pas optimiser
Un expert senior se reconnaît à ce qu'il sait quand s'arrêter. L'optimisation n'est pas une fin en soi.
Le sur-engagement
Déjà évoqué : signer 3 ans de Savings Plans sur une consommation surestimée ou sur une architecture qu'on va refondre, c'est verrouiller du gaspillage. On engage conservateur, sur la baseload garantie, jamais sur la totalité.
La rigidité des Reserved Instances
Les RI Standard offrent la meilleure remise mais ne se revendent pas facilement en Europe et ne s'échangent pas. Une instance réservée sur une famille devenue obsolète ou une charge qui disparaît reste à votre charge. Les Convertibles ou les Savings Plans, plus flexibles, sont souvent un meilleur compromis.
Le trade-off performance vs coût
Descendre une instance de deux tailles pour économiser, c'est tentant, jusqu'à ce que la latence se dégrade aux heures de pointe et qu'un client parte. Le rightsizing agressif sans marge déstabilise. On optimise avec une réserve de sécurité, on mesure l'impact, on garde la perf comme contrainte non négociable sur les charges critiques. Sur une infrastructure déjà fragile, ce travail relève d'abord d'un diagnostic de stabilité (infrastructure cloud instable).
Quand l'optimisation ne paie pas
Sur une petite facture (quelques milliers d'euros par mois), un audit lourd peut coûter plus cher que le gain annuel : les quick wins en autonomie suffisent. Sur une charge déjà optimisée et bien gouvernée, le rendement marginal d'une nouvelle passe est faible. Et certains chantiers (re-architecturer une application monolithique pour grappiller 10 % de compute) coûtent en jours-homme bien plus que ce qu'ils rapportent. Savoir ne pas optimiser fait partie du métier : on priorise les leviers dont le ROI est franc, on documente ceux qu'on écarte, et on assume l'arbitrage.
Les erreurs courantes qui gonflent la facture
Pour résumer en creux, voici les fautes que nous retrouvons le plus souvent :
- Engager (Savings Plans/RI) avant d'avoir nettoyé et redimensionné.
- Laisser tourner le non-prod 24/7.
- Ignorer le poste réseau (NAT Gateway, data transfer cross-AZ).
- Conserver les logs CloudWatch en rétention infinie.
- Provisionner DynamoDB en capacité fixe sur une charge irrégulière.
- Ne jamais supprimer les snapshots et volumes orphelins.
- Absence totale de tagging, donc pilotage à l'aveugle.
- Sur-dimensionner « par sécurité » sans jamais revenir corriger.
- Croire qu'une optimisation est définitive et ne mettre aucune boucle FinOps en place.
Les deux KPI AWS qui pilotent les engagements
Une optimisation ne tient que si on la mesure dans la durée. Sur AWS, deux indicateurs commandent toute la stratégie d'engagement et méritent d'être suivis à chaque cycle. C'est l'angle de pilotage propre à cette page :
- Taux de couverture : part de la consommation éligible couverte par un engagement (Savings Plans/RI). Cible courante : 60 à 80 % de la baseload. En dessous, on laisse de l'économie sur la table ; au-dessus, on risque le sur-engagement.
- Taux d'utilisation des engagements : part de l'engagement réellement consommée. En dessous de 95 %, vous payez des réservations dans le vide ; c'est le signal d'un sur-engagement à corriger au prochain cycle.
Ces deux ratios se lisent directement dans Cost Explorer (rapports de couverture et d'utilisation des réservations/Savings Plans) et structurent l'arbitrage d'achat. La grille complète de KPI de pilotage (coût unitaire métier, part de gaspillage, couverture de tagging, showback/chargeback) et les rituels qui font tenir l'optimisation dans le temps sont développés sur les KPI et rituels qui font tenir l'optimisation dans le temps.
Optimisation et conformité : ne jamais sacrifier l'un pour l'autre
Réduire une facture sous contrainte réglementaire demande de la prudence. Quelques principes que nous tenons :
- La résidence des données prime sur l'économie. Déplacer une charge vers une région moins chère est interdit si les données doivent rester dans l'UE, ou hébergées chez un partenaire certifié HDS pour des données de santé. L'optimisation s'arrête là où commence l'obligation.
- La résilience reste une contrainte, pas une variable d'ajustement. Supprimer une réplication cross-AZ pour économiser du transfert peut faire chuter la disponibilité observée. Sur une charge critique, on ne touche pas aux mécanismes de continuité (PRA/PCA, RTO/RPO définis) au nom du coût.
- La traçabilité ne se coupe pas. Réduire la rétention des logs CloudWatch est sain pour le coût, mais certaines obligations (ISO 27001, DORA en finance et assurance) imposent une conservation minimale des journaux. On distingue les logs opérationnels (à rétention courte) des logs de sécurité et d'audit (à conserver selon la politique).
Le bon FinOps n'oppose jamais coût et conformité : il optimise dans le cadre, en traitant la conformité comme une donnée d'entrée. C'est aussi pour cela que l'indépendance compte : un acteur dont l'intérêt est de vous faire consommer davantage n'a pas la même rigueur sur ces arbitrages.
GreenOps : réduire la facture réduit l'empreinte carbone
Bonne nouvelle pour les directions qui cherchent un double bénéfice : les mêmes leviers AWS qui font baisser la facture, extinction hors usage, rightsizing, Graviton (plus efficient énergétiquement), serverless, choix de régions à mix bas carbone, réduisent aussi les émissions, mesurables via le Customer Carbon Footprint Tool d'AWS. Le cadre GreenOps complet (méthode, indicateurs, arbitrages carbone) est traité sur le pilier : voir GreenOps : optimiser le coût et l'empreinte carbone.
Notre approche : indépendante, transparente, réversible
Trois principes guident notre accompagnement sur la réduction de facture AWS, à rebours du modèle dominant. Indépendance : nous ne sommes pas revendeur AWS et ne touchons aucune commission sur votre consommation. Notre seul intérêt est de la faire baisser. Transparence : le coût de l'audit est annoncé en fourchette dès cette page (5 000 à 12 000 €, sur devis), chaque gain et chaque effort sont chiffrés. Réversibilité : tout ce qui est produit vous appartient. Le code Terraform des correctifs est versionné dans vos dépôts, vos comptes restent à votre nom, vous n'êtes jamais captif.
Nos références : une expérience éprouvée du FinOps et des prestataires qualifiés disposant des certifications requises (FinOps Certified Practitioner), rattachés à des partenaires AWS Partner (Advanced Tier Services), engagés auprès de la FinOps Foundation, dans une démarche ISO 27001. Les chiffres d'économie cités sont observés en mission, jamais garantis. L'argumentaire complet sur l'indépendance, l'autonomie et la réversibilité anti-lock-in (comptes à votre nom, IaC dans vos dépôts, clause de sortie) est développé sur Indépendance, autonomie et réversibilité : notre différence.
Passez à l'action. Pour cadrer votre situation en quelques minutes, lancez notre diagnostic en ligne. Pour un chiffrage et un échange, contactez-nous, réponse sous 48 h ouvrées.
Un mot sur les secteurs régulés. Réduire une facture ne doit jamais affaiblir la conformité. Pour les organisations soumises à des contraintes fortes (données de santé hébergées chez un partenaire certifié HDS, exigences DORA en finance et assurance, RGPD), l'optimisation se fait sous contrainte de conformité, pas à son détriment. Voir nos pages par secteur.
Par où commencer
Si votre facture AWS a dérapé ou si vous n'avez tout simplement aucune visibilité dessus, la première étape est un diagnostic. Notre diagnostic en ligne cadre votre situation en quelques minutes ; pour un chiffrage et un échange, contactez-nous (réponse sous 48 h ouvrées). Pour aller plus loin selon votre besoin : le guide complet d'optimisation des coûts AWS pour tout comprendre côté Amazon, l'audit chiffré pour cadrer le plan, la démarche FinOps de bout en bout, ou un consultant FinOps pour piloter dans la durée. Côté Microsoft, comparez avec réduire sa facture Azure et l'optimisation des coûts Azure ; et si vous voulez poser le problème dans son ensemble, voyez si votre facture cloud est trop élevée.
FAQ : réduire sa facture AWS
Comment réduire sa facture AWS ?
En combinant six leviers, dans le bon ordre : nettoyer les ressources orphelines, éteindre le non-prod hors usage, redimensionner les instances surdimensionnées (rightsizing), optimiser le stockage S3/EBS, traquer les coûts cachés (NAT Gateway, transfert de données), et seulement ensuite engager la charge stable en Savings Plans ou Reserved Instances. Engager avant d'avoir assaini revient à réserver du gaspillage. Sur une infra jamais optimisée, on observe couramment 20 à 40 % d'économies.
Pourquoi ma facture AWS est-elle si élevée ?
Presque toujours pour des raisons structurelles : sur-provisionnement (instances dimensionnées pour le pic, jamais corrigées), absence de tagging qui empêche de voir qui consomme quoi, environnements oubliés allumés 24/7, et coûts cachés invisibles dans les tableaux agrégés (NAT Gateway, transfert inter-zones, logs en rétention infinie). La cause profonde est l'absence d'une boucle de pilotage des coûts.
Combien peut-on économiser sur AWS avec le FinOps ?
En moyenne 20 à 40 %, et jusqu'à 30 à 50 % sur une infrastructure jamais optimisée. Ces chiffres sont des ordres de grandeur observés en mission, pas une promesse : le gain réel dépend de l'état de départ, du profil de charge et de la marge contractuelle. Une charge déjà bien gouvernée offre un rendement marginal plus faible.
Qu'est-ce que le rightsizing sur AWS ?
C'est l'ajustement de la taille des ressources (type, famille, génération) à la charge réellement observée plutôt qu'à la charge anticipée. Une instance utilisée à 20 % de CPU peut souvent descendre de plusieurs tailles sans dégradation. AWS Compute Optimizer analyse les métriques et propose des recommandations chiffrées. Migrer vers Graviton (ARM) est une variante souvent oubliée : ~20 % d'économie à performance égale.
Qu'est-ce qu'une instance Spot et combien fait-elle économiser ?
Une instance Spot est de la capacité EC2 inutilisée louée avec jusqu'à 90 % de remise (couramment 70-90 %), mais récupérable par AWS avec 2 minutes de préavis. Elle convient aux charges interruptibles : batch, CI/CD, traitement asynchrone, environnements de test, conteneurs stateless. On l'industrialise via des Auto Scaling Groups mixtes On-Demand/Spot ou Fargate Spot, avec une reprise propre en cas d'interruption.
Pourquoi le NAT Gateway coûte-t-il si cher sur AWS ?
Parce qu'il cumule deux facturations : un coût horaire (~32-40 €/mois par gateway, multiplié par AZ) et un coût de traitement par gigaoctet (~0,045 €/Go) sur tout le trafic qui le traverse. Une infra qui accède à S3 ou DynamoDB via le NAT paie ce traitement inutilement. La parade : des VPC Gateway Endpoints S3/DynamoDB (gratuits) et des Interface Endpoints (~78 % moins chers que le NAT) pour les autres services.
Comment éviter les frais de transfert de données AWS ?
Garder le trafic chaud dans une même zone de disponibilité quand la résilience le permet (le cross-AZ se facture dans les deux sens), servir le contenu sortant via CloudFront (moins cher que la sortie EC2 directe), rapatrier les échanges intensifs derrière des VPC Endpoints, et surveiller les postes facturés à part (sortie internet ~0,09 €/Go, réplication S3, flux CloudWatch). L'entrée est gratuite, la sortie ne l'est jamais.
Quels outils AWS utiliser pour suivre ses coûts ?
Cost Explorer (analyse et tendances), AWS Budgets (seuils et alertes), Cost Anomaly Detection (détection automatique des dérives), Trusted Advisor (bonnes pratiques de coût), Compute Optimizer (recommandations de rightsizing) et le Cost and Usage Report (détail à la ligne d'usage). Des outils tiers comme CloudHealth, Spot.io ou CloudZero ajoutent du multicloud et de l'automatisation ; Infracost estime le coût d'un changement Terraform avant déploiement.
Comment arrêter automatiquement les instances EC2 non utilisées ?
Avec AWS Instance Scheduler (ou un planificateur EventBridge + Lambda) : on étiquette les ressources non-prod avec leur plage d'activité, on définit les horaires, et le démarrage/arrêt devient automatique. Limiter le non-prod aux heures ouvrées coupe 65 à 70 % de son coût compute sans perte d'usage. Pour les conteneurs, on applique le scale-to-zero hors usage.