Optimisation des coûts AWS

Une facture AWS qui dérive rarement par un seul gros poste : elle gonfle par mille petites fuites que personne ne regarde isolément. Surprovisionnement, instances oubliées, transfert de données invisible, engagements jamais arbitrés. L'optimisation des coûts AWS, discipline qu'on appelle aujourd'hui le FinOps, consiste à rendre cette dépense lisible, à la réduire sans dégrader le service, puis à empêcher qu'elle ne reparte. Cette page détaille chaque levier, son gain réaliste, l'effort qu'il demande, et la méthode que nous appliquons en mission.

Optimisation des coûts AWS : de quoi parle-t-on exactement

L'optimisation des coûts AWS est la démarche méthodique qui consiste à aligner la dépense Amazon Web Services sur la valeur métier réellement produite, en supprimant le gaspillage, en dimensionnant les ressources au plus juste et en engageant intelligemment sur les usages stables. Elle ne se résume pas à « payer moins » : elle vise à payer le bon prix pour le bon usage, ce qui suppose d'abord de voir où va l'argent.

C'est le sixième pilier du AWS Well-Architected Framework (« Cost Optimization »), et c'est aussi le terrain d'application le plus concret du FinOps. La distinction est importante : réduire ponctuellement une facture est un projet ; instaurer une maîtrise durable des coûts est une pratique. Les deux sont nécessaires, mais seule la seconde empêche la dérive de revenir six mois plus tard.

Dans nos missions, la dépense AWS pose presque toujours le même problème de fond : personne n'a une vue consolidée. Les coûts sont chez le DAF, les ressources chez la DSI, les décisions d'architecture chez les équipes produit. Le FinOps réunit ces trois regards sur une même réalité chiffrée. C'est pourquoi l'optimisation des coûts AWS est une déclinaison de la discipline plus large de l'optimisation des coûts cloud (FinOps), appliquée aux services, aux pièges et aux outils natifs propres au cloud d'Amazon.

Le bon objectif n'est pas la facture la plus basse, c'est le meilleur coût par unité de valeur. Une entreprise qui double son chiffre d'affaires peut voir sa facture AWS augmenter tout en s'optimisant, si son coût par client, par transaction ou par tenant baisse. C'est cette grille de lecture, et non le montant brut, qui distingue une démarche FinOps mature d'une simple chasse aux dépenses.

Le FinOps : cadre de référence de l'optimisation des coûts AWS

L'optimisation des coûts AWS est l'application, au cloud d'Amazon, de la discipline FinOps : rapprocher les équipes techniques, financières et métier pour piloter la dépense cloud variable comme une décision d'investissement partagée. Son cycle se déroule en trois phases : Inform (rendre la dépense visible : tagging, allocation, tableaux de bord), Optimize (agir sur les leviers : rightsizing, engagements, Spot, stockage) et Operate (pérenniser par la gouvernance et l'automatisation). Le principe directeur tient en une phrase : on n'optimise bien que ce qu'on a d'abord rendu visible, et chaque ingénieur qui déploie une ressource prend une décision de dépense.

Le cadre canonique, les trois phases en détail, le modèle de maturité Crawl/Walk/Run, les six principes de la FinOps Foundation (dont nous sommes membre) et la distinction FinOps/DevOps/SRE, est développé sur notre page pilier : comprendre l'optimisation des coûts cloud (FinOps). Le reste de cette page se concentre sur sa déclinaison concrète aux services, pièges et outils natifs propres à AWS. Nous structurons nos missions selon ces trois phases, dans l'ordre : voir la dépense avant de la réduire, réduire avant de pérenniser.

Pourquoi la facture AWS dérape : les causes du gaspillage

Avant de réduire, il faut comprendre. Dans les comptes que nous auditons, la dérive vient presque toujours d'une combinaison des causes suivantes.

• Le surprovisionnement. Des instances EC2, des bases RDS ou des volumes EBS dimensionnés « avec de la marge » par prudence, qui tournent en permanence à 5 ou 10 % d'utilisation CPU. C'est, de loin, la première source de gaspillage observée.
• Les ressources orphelines ou « zombies ». Volumes EBS non attachés, adresses IP élastiques réservées et inutilisées, snapshots accumulés depuis des années, load balancers sans cible, environnements de test jamais détruits. Elles ne servent plus rien mais facturent chaque heure.
• L'absence de stratégie d'engagement. Tout en On-Demand, le tarif le plus cher, alors qu'une partie de la charge est parfaitement stable et prévisible. À l'inverse, des Reserved Instances achetées sur trois ans à l'aveugle, devenues inutiles après un changement d'architecture.
• Le manque de visibilité. Sans tagging ni allocation des coûts, impossible de savoir quelle équipe ou quel produit consomme quoi. La dépense devient un bloc opaque que personne ne peut challenger.
• Les coûts invisibles. Transfert de données entre zones de disponibilité, sortie de données (egress) vers Internet, NAT Gateway facturée au volume. Des postes que peu d'équipes surveillent et qui peuvent représenter une part significative de la facture (voir plus bas).
• L'absence d'automatisation. Des environnements de développement qui tournent 24h/24 alors qu'ils ne servent que de 9h à 19h en semaine.

Le gaspillage n'est presque jamais une faute, c'est une dette. Il s'accumule au fil des déploiements urgents, des « on nettoiera plus tard » et des départs d'équipe. Personne ne décide de gaspiller ; tout le monde, faute de visibilité, contribue à la dérive. C'est précisément ce qui rend une approche systématique plus efficace qu'une chasse ponctuelle.

Inform : visibilité et analyse des coûts AWS

On ne pilote que ce qu'on mesure. La première phase d'une optimisation sérieuse consiste à instrumenter la dépense avec les outils natifs AWS.

Les outils AWS de visibilité

• AWS Cost Explorer : l'outil de visualisation et d'analyse des coûts et de l'usage. Il permet de filtrer par service, compte, région ou tag, de remonter jusqu'à 12 mois d'historique, de projeter les coûts futurs et d'obtenir des recommandations de rightsizing et d'engagements. C'est le point d'entrée naturel de toute analyse.
• AWS Cost and Usage Report (CUR). Le rapport le plus détaillé et le plus granulaire : chaque ligne d'usage, à l'heure ou à la ressource, livrée dans un bucket S3 et exploitable via Athena, QuickSight ou un outil tiers. C'est la source de vérité pour les analyses fines, les unit economics et la facturation interne (showback/chargeback).
• AWS Budgets : définit des budgets de coût ou d'usage et déclenche des alertes par e-mail ou SNS dès qu'un seuil (réel ou prévisionnel) est franchi. Indispensable pour éviter les mauvaises surprises en fin de mois.
• AWS Cost Anomaly Detection : utilise l'apprentissage automatique pour repérer les variations de dépense inhabituelles et alerter avant que la dérive ne devienne une facture. Particulièrement utile contre les incidents (une boucle qui démultiplie les appels Lambda, un environnement laissé allumé).

Comment fonctionne AWS Cost Explorer

Cost Explorer agrège vos données de facturation et les expose sous forme de graphiques filtrables. Vous choisissez une dimension (service, compte lié, type d'usage, tag), une granularité (mensuelle, quotidienne, voire horaire) et une période, puis vous lisez la tendance. Il fournit aussi des recommandations : instances sous-utilisées à redimensionner, et engagements (Savings Plans, RI) à souscrire en fonction de votre historique. C'est gratuit pour l'interface ; seules les requêtes API sont facturées à l'unité.

L'analyse ne s'arrête pas à l'écran. Le travail consiste à transformer ces données en décisions : quels 20 % de ressources représentent 80 % de la facture ? Quels postes croissent plus vite que l'activité ? Où se cachent les coûts non alloués ? C'est l'objet de notre audit des coûts cloud, qui produit cette lecture priorisée plutôt qu'un simple export.

Tagging et allocation des coûts : la fondation de tout

Sans étiquetage, la facture AWS reste un bloc. Le tagging (ou étiquetage) consiste à apposer des paires clé/valeur sur les ressources (equipe=paiement, projet=appli-rh, environnement=prod, centre-de-cout=4012) pour pouvoir ensuite ventiler la dépense.

Activées dans la console de facturation, les cost allocation tags permettent de répartir chaque euro par équipe, par produit, par environnement ou par centre de coûts, directement dans Cost Explorer et dans le CUR. C'est ce qui rend possible le showback (montrer à chaque équipe ce qu'elle consomme) et le chargeback (la lui refacturer).

Une stratégie de tagging efficace repose sur quelques règles :

• Définir une taxonomie courte et obligatoire : 5 à 8 clés maximum, documentées, plutôt que cinquante tags incohérents.
• Rendre le tagging non négociable via l'infrastructure as code (Terraform applique les tags par défaut sur tous les modules) et via les AWS Tag Policies ou Service Control Policies au niveau de l'organisation.
• Mesurer la couverture : quel pourcentage de la dépense est correctement étiqueté ? Tant qu'une part significative reste « non taggée », l'allocation est faussée.

Tagger d'abord, optimiser ensuite. L'anti-pattern le plus coûteux que nous corrigeons consiste à lancer rightsizing et achats d'engagements avant d'avoir une allocation fiable. On optimise alors sans savoir qui consomme, on ne peut pas responsabiliser, et l'on ne mesure pas le gain par équipe. Le tagging n'est pas un préalable bureaucratique : c'est la condition de tout le reste.

Optimize : les leviers d'optimisation des coûts AWS

C'est le cœur du sujet. Voici les leviers, du plus simple au plus structurant, chacun avec son ordre de grandeur d'économie constaté dans nos missions ou documenté par AWS, jamais garanti, car le gain réel dépend toujours de votre profil de charge.

Rightsizing : dimensionner au plus juste

Le rightsizing consiste à ajuster la taille (type, famille, génération) d'une ressource à son usage réel, plutôt qu'à une marge de prudence. Une instance m5.2xlarge qui plafonne à 8 % de CPU peut souvent descendre d'une ou deux tailles, voire changer de famille.

Deux outils natifs guident l'exercice :

• AWS Compute Optimizer analyse les métriques CloudWatch de vos instances EC2, fonctions Lambda, volumes EBS et tâches ECS sur Fargate, puis recommande des configurations mieux dimensionnées avec une estimation d'économie et de risque de performance.
• AWS Trusted Advisor signale les ressources sous-utilisées, les instances inactives, les volumes EBS non attachés et d'autres opportunités d'économie, dans son pilier « Cost Optimization ».

Le rightsizing est le levier le plus universel : il s'applique à presque toutes les charges et ne demande aucun engagement financier. Les économies observées vont couramment de 10 à 30 % sur le poste compute concerné, parfois davantage sur des parcs jamais nettoyés.

Les modèles de tarification et les engagements

AWS propose quatre grands modes d'achat du compute. Bien les combiner est le levier au plus fort impact financier.

| Modèle | Principe | Engagement | Économie vs On-Demand | Pour quel usage | |---|---|---|---|---| | On-Demand | Paiement à l'usage, sans engagement | Aucun | Référence (0 %) | Charges imprévisibles, courtes, en test | | Savings Plans | Engagement sur un montant horaire ($/h) pendant 1 ou 3 ans | 1 ou 3 ans | Jusqu'à ~72 % | Charge stable, besoin de flexibilité | | Reserved Instances | Engagement sur un type d'instance précis | 1 ou 3 ans | Jusqu'à ~72 % | Charge très stable et prévisible | | Spot Instances | Capacité inutilisée d'AWS, interruptible | Aucun | Jusqu'à ~90 % | Charges tolérantes à l'interruption |

Reserved Instances et Savings Plans

Les Reserved Instances (RI) offrent une remise importante en échange d'un engagement de 1 ou 3 ans sur une configuration précise (famille, taille, région, OS). Elles existent en Standard (remise maximale, peu flexible) et Convertible (remise moindre, échangeable). Elles couvrent EC2, mais aussi RDS, ElastiCache, OpenSearch et Redshift.

Les Savings Plans sont le mécanisme plus récent et plus souple : vous vous engagez sur un montant de dépense horaire (en dollars par heure) plutôt que sur un type d'instance. Deux variantes :

• Compute Savings Plans : la plus flexible. La remise s'applique automatiquement à EC2, Fargate et Lambda, quelles que soient la famille, la taille, la région ou l'OS. Idéale quand l'architecture évolue.
• EC2 Instance Savings Plans : remise plus forte, mais limitée à une famille d'instances dans une région donnée.

Quelle est la différence entre Savings Plans et Reserved Instances ?

La différence tient en une phrase : les Reserved Instances engagent sur une configuration d'instance, les Savings Plans engagent sur un montant de dépense horaire. Les Savings Plans Compute apportent une flexibilité bien supérieure (familles, régions, services différents couverts automatiquement), au prix d'une remise parfois légèrement inférieure aux RI Standard. Pour la majorité des organisations dont l'architecture bouge, les Compute Savings Plans sont aujourd'hui le choix par défaut ; les RI conservent un intérêt sur des charges figées et sur les services non couverts par les Savings Plans (RDS, ElastiCache, Redshift).

Instances Spot

Les Spot Instances vendent la capacité EC2 inutilisée d'AWS avec une remise pouvant atteindre 90 % par rapport au On-Demand. Contrepartie : AWS peut les récupérer avec un préavis de deux minutes. Elles conviennent parfaitement aux charges tolérantes à l'interruption : traitements par lots, CI/CD, rendu, big data, et, point clé, aux nœuds de calcul Kubernetes orchestrés pour absorber les interruptions. Mélanger Spot et On-Demand dans un même groupe d'auto-scaling permet de capter la remise tout en gardant une base stable.

Taux de couverture et taux d'utilisation : les KPI que personne n'explique

Acheter des engagements ne suffit pas. Deux indicateurs déterminent s'ils sont rentables, et c'est ici que se joue la maturité d'une démarche FinOps, un sujet quasi absent des contenus francophones.

• Le taux de couverture (coverage) mesure quelle part de votre usage éligible est couverte par un engagement plutôt que payée en On-Demand. Une couverture trop basse signifie que vous payez le plein tarif sur une charge stable ; trop haute, que vous risquez de payer des engagements pour une capacité que vous n'utilisez plus.
• Le taux d'utilisation (utilization) mesure quelle part de vos engagements est effectivement consommée. Un Savings Plan utilisé à 70 % signifie que 30 % de ce que vous avez réservé est gaspillé.

L'arbitrage consiste à viser une couverture élevée sur la base stable et permanente (le « socle » qui tourne 24h/24 toute l'année) tout en maintenant une utilisation proche de 100 %. On ne réserve jamais le pic ; on réserve le plancher. C'est un travail de portefeuille, qui se révise à chaque renouvellement et à chaque évolution d'architecture. Cost Explorer fournit les rapports de couverture et d'utilisation ; encore faut-il savoir les lire et décider en conséquence.

N'achetez jamais un engagement de 3 ans à l'aveugle. C'est l'anti-pattern le plus coûteux du FinOps. La bonne pratique est de réserver progressivement le socle stable, en commençant par des Savings Plans Compute 1 an si l'architecture est incertaine, puis d'augmenter la couverture et la durée à mesure que la prévisibilité se confirme. Un engagement mal calibré bloque votre capital pendant des années sur une capacité dont vous n'avez peut-être plus besoin.

Optimisation du stockage AWS

Le stockage est un poste souvent négligé parce qu'il paraît modeste à l'unité. À l'échelle, il pèse, et il s'optimise sans toucher au code.

Les classes de stockage Amazon S3

Amazon S3 propose plusieurs classes au tarif décroissant selon la fréquence d'accès :

• S3 Standard : accès fréquent, latence minimale. Tarif de référence.
• S3 Standard-IA (Infrequent Access) : données peu consultées mais à accès immédiat. Stockage moins cher, coût de récupération.
• S3 Intelligent-Tiering : déplace automatiquement les objets entre paliers d'accès selon leur usage réel, sans frais de récupération. Le choix par défaut quand les schémas d'accès sont inconnus ou variables.
• S3 Glacier Instant Retrieval / Flexible Retrieval : archivage à coût très bas, récupération de quelques minutes à quelques heures.
• S3 Glacier Deep Archive : la classe la moins chère, pour la conservation longue durée (réglementaire, sauvegardes froides), récupération en heures.

Le levier consiste à définir des lifecycle policies : des règles qui font transiter automatiquement les objets vers des classes moins chères en fonction de leur âge (par exemple Standard → Standard-IA après 30 jours → Glacier après 90 jours → suppression après la durée de rétention légale). Sur des données froides accumulées, les économies sont parmi les plus simples à obtenir.

EBS, snapshots et nettoyage

Côté blocs, deux gestes rentables :

• Migrer les volumes vers gp3. Le type EBS gp3 offre des performances de base supérieures à gp2 pour un coût au gigaoctet plus faible, et il découple le débit/IOPS de la capacité. La bascule gp2 → gp3 est souvent une économie quasi automatique de l'ordre de 20 % sur le poste EBS concerné.
• Faire le ménage dans les snapshots et volumes orphelins. Les snapshots EBS s'accumulent silencieusement ; les volumes détachés continuent de facturer. Une politique de rétention et un nettoyage régulier suppriment une dépense pure.

Extinction des ressources hors usage

C'est l'un des leviers au meilleur rapport effort/gain, et l'un des plus négligés. La plupart des environnements de développement, de test et de pré-production ne servent qu'en heures ouvrées, mais tournent 24h/24, 7j/7.

AWS Instance Scheduler (ou un équivalent en Lambda/EventBridge ou en IaC) permet d'arrêter ces ressources la nuit et le week-end, puis de les redémarrer automatiquement le matin. Un environnement utilisé de 8h à 20h en semaine n'a besoin de tourner que ~60 heures sur les 168 d'une semaine. L'extinction du reste représente une économie pouvant atteindre 70 % sur ces ressources non productives. Le même principe s'applique aux bases RDS non productives et aux clusters de test.

C'est typiquement le genre de quick win qu'on déploie dès les premières semaines d'une mission, parce qu'il ne touche pas à la production et se met en place via quelques règles automatisées.

Élasticité, auto-scaling et architectures économes

Réduire le gaspillage, c'est aussi cesser de payer pour de la capacité qu'on n'utilise qu'aux pics.

Auto-scaling

EC2 Auto Scaling ajuste automatiquement le nombre d'instances en fonction de la charge : on monte en capacité au pic, on redescend au creux. C'est le scaling horizontal (ajouter/retirer des instances), à distinguer du scaling vertical (changer la taille d'une instance). Bien réglé, l'auto-scaling élimine la sur-capacité permanente : vous payez la charge réelle, pas la charge maximale anticipée.

Serverless et conteneurs

Pousser plus loin, c'est repenser l'architecture pour ne payer qu'à l'exécution :

• AWS Lambda facture à la milliseconde d'exécution et à la mémoire allouée. Pour des charges intermittentes ou événementielles, le coût peut s'effondrer par rapport à des serveurs allumés en permanence.
• AWS Fargate exécute des conteneurs (ECS/EKS) sans gérer ni payer de serveurs sous-jacents à l'arrêt. On dimensionne la tâche, on paie ce qui tourne.
• Amazon Aurora Serverless adapte automatiquement la capacité de la base de données à la charge, jusqu'à la mettre en pause, ce qui supprime le coût des bases peu sollicitées (environnements de test, applications à trafic irrégulier).

Le serverless n'est pas toujours moins cher : au-delà d'un certain volume constant, une instance réservée redevient plus économique. L'arbitrage se fait au cas par cas, sur les chiffres.

Processeurs AWS Graviton

Les processeurs AWS Graviton (architecture Arm, conçue par AWS) offrent un meilleur rapport prix/performance que les équivalents x86 : AWS annonce jusqu'à 40 % de gain prix/performance selon les charges. Ils sont disponibles sur EC2, RDS, Aurora, Lambda, Fargate, ElastiCache et OpenSearch. Pour des applications compatibles Arm (de plus en plus nombreuses, notamment en environnements conteneurisés et langages interprétés), la bascule est un gain quasi gratuit, sans changer l'architecture. C'est aussi un levier GreenOps, Graviton consommant moins d'énergie à performance égale.

Les coûts invisibles : transfert de données et egress

C'est le poste que presque aucun contenu francophone ne traite, et qui surprend le plus en audit. Le transfert de données obéit à une logique propre : l'ingress vers AWS est généralement gratuit, mais l'egress vers Internet se facture au gigaoctet, le transfert inter-AZ se facture dans les deux sens, l'inter-région coûte plus cher encore, et les NAT Gateway facturent un coût horaire et un coût par gigaoctet traité, souvent du trafic qui aurait dû passer par un VPC endpoint gratuit ou moins cher. Les leviers de fond : rapatrier les flux dans une même AZ, utiliser des VPC endpoints (Gateway S3/DynamoDB gratuits), placer un CDN (CloudFront) devant le contenu servi, auditer les flux des bases répliquées et des clusters.

Ces coûts cachés justifient à eux seuls un traitement dédié. L'analyse en profondeur (chiffrage du NAT Gateway, du transfert inter-AZ, de l'egress, des VPC Endpoints et de la densité des conteneurs, avec les arbitrages d'architecture associés) est l'angle distinctif de notre page action : les coûts cachés AWS que personne ne surveille. Sur certaines factures, ce poste invisible se chiffre en milliers d'euros mensuels une fois rendu visible.

FinOps Kubernetes : optimiser un cluster EKS

Kubernetes ajoute une couche d'abstraction qui rend les coûts particulièrement opaques : on paie des nœuds EC2, mais on déploie des pods, et la correspondance entre les deux n'a rien d'évident. C'est un angle souvent traité superficiellement ailleurs.

Les leviers spécifiques à Amazon EKS :

• Régler les requests et limits. La plupart des clusters surprovisionnent par défaut : les pods réservent plus de CPU et de mémoire qu'ils n'en consomment. Ajuster les requests au plus juste libère de la capacité et réduit le nombre de nœuds.
• Améliorer le bin packing. Mieux empiler les pods sur les nœuds réduit le nombre de nœuds nécessaires.
• Karpenter, l'autoscaler de nœuds open source porté par AWS, provisionne en temps réel le type d'instance exactement adapté aux pods en attente, exploite nativement le Spot et consolide les nœuds sous-utilisés. Il surpasse souvent le Cluster Autoscaler classique sur l'efficience des coûts.
• Kubecost apporte la visibilité qui manque nativement : il ventile le coût par namespace, déploiement, équipe ou label, ce qui permet enfin d'allouer la dépense d'un cluster partagé.
• Mélanger Spot et On-Demand sur les groupes de nœuds, avec des charges tolérantes à l'interruption sur le Spot.

L'optimisation EKS est un chantier à part entière, souvent couplé à un audit d'infrastructure cloud quand le cluster porte des charges critiques.

Bases de données et licences

Les bases de données concentrent une part importante de la facture et offrent des leviers propres :

• Rightsizing RDS et Aurora : les instances de base sont fréquemment surdimensionnées ; Compute Optimizer couvre désormais RDS.
• Réservations : RDS et ElastiCache acceptent des Reserved Instances, avec des remises comparables à EC2.
• Aurora Serverless pour les charges irrégulières.
• Graviton sur RDS et Aurora pour le gain prix/performance.
• Licences (BYOL). Pour SQL Server ou Oracle, l'arbitrage entre licence incluse (License Included) et Bring Your Own License peut changer significativement le coût. C'est un poste technique et juridique qui mérite une analyse dédiée, d'autant que les règles de mobilité de licence varient selon l'éditeur.

Unit economics : du coût total au coût par valeur

Le montant brut de la facture ne dit rien de votre efficience. Une démarche FinOps mature raisonne en unit economics : le coût cloud ramené à une unité de valeur métier : le coût par tenant ou par utilisateur actif pour un éditeur SaaS, le coût par transaction pour une plateforme, le coût par paiement traité pour une fintech. C'est le seul ratio qui dise si vous vous optimisez vraiment : une facture qui monte n'est un problème que si le coût unitaire monte aussi.

Côté AWS, construire ces métriques s'appuie sur un CUR propre rapproché des données métier via Athena ou QuickSight, la mécanique concrète détaillée plus bas. Le concept général, ses formules et son rôle dans la maturité FinOps sont développés sur le pilier : Cloud Unit Economics : du coût total au coût par client. C'est le niveau de maturité que nous visons avec nos clients SaaS et scale-ups.

Le standard FOCUS côté AWS : exporter ses coûts au format normalisé

Le FOCUS (FinOps Open Cost and Usage Specification) est le standard ouvert qui normalise les données de coût et d'usage entre fournisseurs, pour consolider AWS, Azure et GCP avec un vocabulaire commun. Le point concret à retenir côté AWS : AWS publie désormais ses données au format FOCUS via les Data Exports, ce qui permet d'alimenter un pilotage multi-cloud unifié sans retraiter le CUR à la main. C'est un marqueur de maturité, encore quasi absent des contenus francophones.

La spécification FOCUS elle-même et la stratégie de pilotage multi-cloud (AWS/Azure/GCP) sont traitées sur le pilier : le standard FOCUS et le FinOps multi-cloud.

Operate : gouvernance, outils et culture FinOps

Optimiser une fois ne suffit pas : sans gouvernance, la dérive revient. La phase Operate installe la maîtrise dans la durée.

Les outils natifs d'optimisation continue

• AWS Cost Optimization Hub : service récent qui consolide en un seul endroit toutes les recommandations d'économie d'AWS (rightsizing, instances inactives, engagements Savings Plans/RI, volumes EBS), chiffrées et dédoublonnées, avec l'estimation d'économie. Il met fin à la dispersion entre Compute Optimizer, Trusted Advisor et Cost Explorer. Encore peu connu en France, c'est aujourd'hui le point de départ recommandé.
• AWS Compute Optimizer : recommandations de rightsizing fondées sur les métriques réelles.
• AWS Trusted Advisor : contrôles d'économie, de sécurité et de fiabilité.
• AWS CloudWatch : métriques d'utilisation qui alimentent toutes les décisions de dimensionnement.
• AWS Config et CloudTrail. Pour gouverner : détecter les ressources non conformes (non taggées, types interdits) et tracer qui a créé quoi.

Gouvernance des engagements et multi-comptes AWS

Côté AWS, la phase Operate a deux angles bien spécifiques. D'abord la gouvernance du portefeuille d'engagements : qui décide d'acheter un Savings Plan, quand le renouveler, comment piloter dans le temps la couverture et l'utilisation (les deux KPI détaillés plus haut). Sans propriétaire ni revue régulière, on bascule soit en sous-couverture (trop d'On-Demand), soit en sur-engagement (des réservations inutilisées). Ensuite la gouvernance multi-comptes via AWS Organizations : des Service Control Policies (SCP) pour interdire les types d'instances onéreux ou les régions non autorisées, des Tag Policies pour rendre l'étiquetage non négociable, et la facturation consolidée pour mutualiser les engagements sur l'ensemble des comptes liés. C'est l'implémentation propre à AWS d'une gouvernance des coûts.

La gouvernance FinOps générique (collaboration IT/Finance/Métier, grille de KPI de pilotage, rituels, showback/chargeback et culture de la responsabilisation) est développée sur le pilier : les KPI et rituels qui font tenir l'optimisation dans le temps. Le rôle d'un intermédiaire n'est pas de couper les coûts à la place des équipes, mais de leur donner les outils et la lecture pour décider : c'est ce que nous appelons transférer l'autonomie.

L'optimisation des coûts est une boucle, pas un projet. Un environnement cloud vit : on déploie, on supprime, on change d'architecture. Une dépense optimisée aujourd'hui dérive de nouveau en quelques mois sans monitoring continu, sans alertes et sans gouvernance des engagements. C'est pourquoi nous installons la pratique, pas seulement le résultat.

GreenOps : l'optimisation réduit aussi l'empreinte carbone

Optimiser les coûts et réduire l'empreinte carbone vont dans le même sens : le rightsizing, l'extinction hors usage, le passage à Graviton (plus économe en énergie) et la suppression des ressources orphelines sont à la fois des leviers d'économie et des leviers GreenOps. Côté outillage AWS, le Customer Carbon Footprint Tool suit les émissions associées à votre usage. Le cadre GreenOps complet est développé sur le pilier : GreenOps : optimiser le coût et l'empreinte carbone.

Les mécaniques d'économie propres à AWS

L'essentiel des leviers FinOps se retrouve sur les deux grands clouds, sous des noms différents ; le tableau comparatif neutre AWS vs Azure (Savings Plans, réservations, Spot, rightsizing natif, gouvernance, Arm/Graviton) est tenu à jour sur le pilier : les leviers d'optimisation des coûts cloud et le comparatif Azure vs AWS. Inutile de le redupliquer ici.

Ce qui distingue vraiment AWS, ce sont quelques mécaniques natives qu'on ne retrouve pas à l'identique ailleurs, et que cette page détaille :

• AWS Graviton (processeurs Arm conçus par AWS) : gain prix/performance annoncé jusqu'à 40 %, disponible jusque sur RDS, Aurora, Lambda et Fargate (section dédiée plus haut).
• AWS Cost Optimization Hub : la console qui consolide et dédoublonne toutes les recommandations d'économie d'AWS, sans équivalent direct côté Azure (section Operate).
• Les Data Exports au format FOCUS : l'export normalisé natif d'AWS pour le pilotage multi-cloud.
• La maturité de l'offre Spot et des Spot Instances dans les groupes d'auto-scaling, un atout historique d'AWS.

Symétriquement, le levier le plus structurant d'Azure, l'Azure Hybrid Benefit (réutilisation de licences Windows/SQL), sans équivalent natif AWS, relève de l'autre guide : optimisation des coûts Azure et réduire sa facture Azure. C'est précisément l'arbitrage que nous instruisons sans préférence commerciale.

Tableau de synthèse : effort, gain et délai par levier

Pour prioriser, voici une vue d'ensemble des leviers, avec l'effort de mise en œuvre, le gain potentiel constaté et le délai typique. Les pourcentages s'entendent sur le poste concerné, pas sur la facture totale, et restent indicatifs.

| Levier | Effort | Gain potentiel | Délai | Risque | |---|---|---|---|---| | Nettoyage ressources orphelines | Faible | Variable, immédiat | Jours | Très faible | | Extinction hors usage (scheduling) | Faible | Jusqu'à ~70 % (non-prod) | Jours | Faible | | Migration EBS gp2 → gp3 | Faible | ~20 % (EBS) | Jours | Faible | | Rightsizing EC2/RDS | Moyen | 10–30 % (compute) | Semaines | Moyen | | Classes S3 + lifecycle | Faible | Variable (stockage froid) | Jours | Faible | | Savings Plans / Reserved Instances | Moyen | Jusqu'à ~72 % (socle) | Semaines | Moyen (engagement) | | Spot Instances | Moyen-élevé | Jusqu'à ~90 % | Semaines | Élevé (interruption) | | Graviton | Moyen | Jusqu'à ~40 % prix/perf | Semaines | Faible-moyen | | Auto-scaling / serverless | Élevé | Variable, structurel | Semaines-mois | Moyen | | Optimisation transfert/egress | Moyen | Variable (souvent élevé) | Semaines | Faible |

La logique de priorisation est constante : on commence par les quick wins sans risque et sans engagement (nettoyage, scheduling, gp3), on enchaîne sur le rightsizing, et on n'engage du capital sur les Savings Plans qu'une fois la base stabilisée et taggée.

Étude de cas représentative : avant / après

Le cas qui suit est représentatif de nos missions et anonymisé ; les chiffres illustrent une trajectoire typique, ils ne constituent pas une promesse de résultat.

Contexte. Un éditeur SaaS B2B (ETI), facture AWS d'environ 42 000 € par mois, en croissance, tout en On-Demand, sans tagging structuré, avec un cluster EKS et plusieurs environnements de non-production allumés en permanence.

Démarche. Quatre semaines de mission, en commençant par la visibilité (CUR, tagging, allocation), puis les leviers, par ordre de risque croissant.

| Levier appliqué | Économie mensuelle constatée | |---|---| | Suppression ressources orphelines + snapshots | ~1 800 € | | Scheduling des environnements non-prod | ~3 500 € | | Migration EBS gp3 | ~900 € | | Rightsizing EC2 / RDS (Compute Optimizer) | ~4 200 € | | Lifecycle S3 + Intelligent-Tiering | ~1 100 € | | Compute Savings Plans (socle stable, 1 an) | ~6 500 € | | Karpenter + Spot sur EKS | ~3 000 € | | Total | ~21 000 € / mois |

Résultat constaté : la facture passe d'environ 42 000 € à ~21 000 € par mois, soit de l'ordre de 50 % d'économie sur ce périmètre, avec un retour sur l'investissement de la mission en quelques semaines. La part « engagements » et « Spot » demande une gouvernance continue ; le reste est structurel. Surtout, le coût par tenant a baissé de plus de 40 %, ce qui était le véritable objectif. Chaque environnement varie : ce profil ne préjuge pas du vôtre.

Roadmap d'optimisation 30 / 60 / 90 jours

Une optimisation efficace sépare les quick wins des chantiers structurels. Voici la trame que nous adaptons à chaque mission.

Jours 0–30 : visibilité et quick wins

• Activer Cost Explorer, configurer AWS Budgets et Cost Anomaly Detection.
• Déployer le tagging et l'allocation des coûts ; mesurer la couverture.
• Lancer le nettoyage des ressources orphelines (volumes, IP, snapshots, load balancers).
• Mettre en place le scheduling des environnements non-prod.
• Migrer les volumes vers gp3.
• Première lecture du Cost Optimization Hub.

Jours 30–60 : rightsizing et stockage

• Rightsizing EC2/RDS guidé par Compute Optimizer, par vagues maîtrisées.
• Politiques de lifecycle S3 et Intelligent-Tiering.
• Analyse des coûts de transfert (inter-AZ, egress, NAT) et premières corrections (VPC endpoints, CloudFront).
• Tests de Graviton sur les charges compatibles.

Jours 60–90 : engagements et structurel

• Calibrage et achat progressif des Savings Plans sur le socle stabilisé, suivi de la couverture/utilisation.
• Optimisation EKS (requests/limits, Karpenter, Spot) si applicable.
• Mise en place de l'auto-scaling et étude des bascules serverless pertinentes.
• Installation de la gouvernance : alertes, revue mensuelle, propriétaire des engagements, showback par équipe.

Internaliser ou externaliser le FinOps AWS ?

C'est une vraie décision, pas une évidence. En résumé : internaliser a du sens quand le volume de dépense justifie un poste FinOps dédié et que les équipes plateforme sont matures, c'est l'objectif final souhaitable. Externaliser ou se faire accompagner a du sens pour démarrer vite avec une méthode éprouvée, obtenir un regard indépendant (sans intérêt à pousser la consommation, contrairement à un revendeur cloud) et franchir un cap avant transfert.

Le détail du métier de consultant FinOps (rôle, consultant vs ingénieur interne vs FinOps Officer, TJM, formats de mission et critères chiffrés d'arbitrage internaliser/externaliser) est traité sur la page dédiée : pourquoi faire appel à un consultant FinOps externe plutôt que d'internaliser.

Notre conviction, sur AWS comme ailleurs : le bon accompagnement rend le client autonome. Tout ce qui est construit pour vous vous appartient : code Terraform versionné dans vos dépôts, comptes AWS à votre nom, dashboards et documentation remis. La réversibilité est totale ; vous n'êtes jamais prisonnier. Si votre problème immédiat est une facture cloud trop élevée, la priorité est l'audit et les quick wins ; l'autonomie se construit ensuite.

Comment se déroule une mission, livrables et budget

Durée et déroulé

Une mission d'optimisation des coûts AWS s'étale typiquement de 2 à 7 jours de travail effectif pour la phase d'analyse et de premières actions, selon la taille du compte, le nombre de comptes liés (AWS Organizations) et la complexité de l'architecture. Le déploiement des chantiers structurels et l'installation de la gouvernance s'inscrivent ensuite dans la trame 30/60/90 jours décrite plus haut.

Livrables

• Cartographie de la dépense : où va l'argent, par service, équipe et produit, avec allocation.
• Rapport d'optimisation chiffré : leviers identifiés, gain estimé par levier, effort et risque, priorisés.
• Roadmap 30/60/90 jours datée, distinguant quick wins et chantiers structurels.
• Mise en place du socle de visibilité : tagging, budgets, alertes, anomaly detection.
• Code IaC des automatisations (scheduling, lifecycle, tagging) versionné dans vos dépôts.
• Transfert de compétences à vos équipes et restitution en langage clair pour la DSI et la direction.

Combien coûte une mission d'optimisation des coûts AWS ?

Le budget indicatif se situe entre 5 000 € et 15 000 € selon le périmètre, sur devis après cadrage. Cette fourchette couvre l'audit, le plan d'action chiffré, les premiers quick wins et la mise en place du socle de visibilité ; les chantiers structurels et l'accompagnement dans la durée font l'objet d'un cadrage dédié. Dans la grande majorité des cas que nous traitons, les économies constatées couvrent largement le coût de la mission dès les premiers mois, mais aucune économie ne peut être garantie à l'avance, car elle dépend entièrement de votre situation de départ.

Notre transparence sur les coûts est un principe, pas un argument. Pas d'engagement caché, pas de commission sur votre consommation cloud, pas de revente de licences. Nous facturons notre expertise, pas votre facture AWS. C'est ce qui fonde l'indépendance de nos recommandations.

Pourquoi Architecte Cloud pour optimiser vos coûts AWS

Architecte Cloud est un intermédiaire indépendant qui cadre votre besoin et vous met en relation avec des prestataires d'expertise et d'infogérance cloud sur Microsoft Azure et AWS, du conseil à l'exploitation. Sur le FinOps :

• Indépendance : aucun parti pris fournisseur, aucune commission sur votre consommation. Nos recommandations servent votre intérêt, pas celui d'un cloud.
• Compétences qualifiées : AWS Partner (Advanced Tier Services), prestataires disposant de la certification FinOps Certified Practitioner, membre de la FinOps Foundation, dans une démarche ISO 27001.
• Expérience : 12 ans d'expertise, plus de 120 projets accompagnés, plus de 40 clients, une satisfaction client reconnue.
• Autonomie et réversibilité : tout ce qui est construit pour vous vous appartient et reste documenté ; vous n'êtes jamais enfermé.
• Langage clair : des recommandations traduites en coûts, risques et délais, lisibles par la DSI comme par la direction financière.

Pour aller plus loin selon votre besoin : juste les quick wins et les coûts cachés AWS si vous voulez agir vite ; le cadre FinOps générique et le comparatif Azure vs AWS pour la vue d'ensemble ; faire auditer vos coûts AWS pour un diagnostic chiffré ; internaliser ou externaliser : l'avis d'un consultant FinOps pour le pilotage dans la durée ; ou l'équivalent côté Azure. Nos missions FinOps s'articulent aussi avec nos autres expertises : audit FinOps, migration cloud (l'occasion idéale d'optimiser dès la conception), conseil en architecture et infrastructure DevOps. Pour situer le FinOps dans une stratégie cloud globale, consultez notre guide du cloud et notre page services.

Prêt à voir où part votre facture AWS ? Lancez un diagnostic en ligne ou contactez-nous : réponse sous 48 h ouvrées.

FAQ : Optimisation des coûts AWS

Comment réduire sa facture AWS ?

On réduit une facture AWS en trois temps. D'abord rendre la dépense visible (Cost Explorer, tagging, allocation) pour savoir où va l'argent. Ensuite agir sur les leviers, du moins risqué au plus structurant : nettoyer les ressources orphelines, éteindre les environnements hors usage, redimensionner (rightsizing), souscrire des Savings Plans sur le socle stable, exploiter le Spot. Enfin pérenniser par la gouvernance et les alertes. Les premiers gains arrivent en quelques jours ; les plus importants demandent quelques semaines.

Qu'est-ce que le FinOps sur AWS ?

Le FinOps est une discipline qui rapproche équipes techniques, financières et métier pour gérer la dépense cloud comme une décision partagée. Sur AWS, il s'appuie sur les outils natifs (Cost Explorer, CUR, Budgets, Compute Optimizer, Cost Optimization Hub) et se déroule en trois phases (Inform, Optimize, Operate) portées par la FinOps Foundation. L'objectif n'est pas seulement de payer moins, mais d'optimiser le coût par unité de valeur métier.

Quelle est la différence entre Savings Plans et Reserved Instances ?

Les Reserved Instances engagent sur une configuration d'instance précise (famille, taille, région), tandis que les Savings Plans engagent sur un montant de dépense horaire. Les Compute Savings Plans sont les plus flexibles : leur remise s'applique automatiquement à EC2, Fargate et Lambda, quelles que soient la famille ou la région. Les RI restent pertinentes sur des charges très stables et sur des services non couverts par les Savings Plans (RDS, ElastiCache, Redshift). Les deux offrent jusqu'à environ 72 % de remise sur 3 ans.

Combien peut-on économiser avec les instances réservées AWS ?

Les Reserved Instances et les Savings Plans permettent jusqu'à environ 72 % d'économie par rapport au On-Demand, sur un engagement de 3 ans avec paiement initial. La remise réelle dépend de la durée (1 ou 3 ans), du mode de paiement et du type d'engagement. L'économie ne se concrétise que si la couverture et l'utilisation sont bien pilotées : un engagement mal calibré peut au contraire générer du gaspillage.

Quels outils AWS pour suivre et optimiser ses coûts ?

Pour la visibilité : AWS Cost Explorer, Cost and Usage Report (CUR), AWS Budgets et Cost Anomaly Detection. Pour l'optimisation : AWS Compute Optimizer (rightsizing), Trusted Advisor, et le Cost Optimization Hub qui consolide toutes les recommandations en un seul endroit. CloudWatch fournit les métriques d'usage, AWS Config et CloudTrail la gouvernance. Pour Kubernetes, Kubecost complète l'allocation par namespace.

Comment fonctionne AWS Cost Explorer ?

Cost Explorer agrège vos données de facturation et les présente sous forme de graphiques filtrables par service, compte, région ou tag, jusqu'à 12 mois d'historique. Il projette les coûts futurs et fournit des recommandations de rightsizing et d'engagements. L'interface est gratuite ; seules les requêtes API sont facturées. C'est le point d'entrée de toute analyse, mais l'enjeu est d'en tirer des décisions priorisées, pas seulement des graphiques.

Qu'est-ce que le rightsizing sur AWS ?

Le rightsizing consiste à ajuster la taille et le type d'une ressource à son usage réel, plutôt qu'à une marge de prudence. AWS Compute Optimizer analyse les métriques CloudWatch des instances EC2, fonctions Lambda, volumes EBS et tâches Fargate, puis recommande des configurations mieux dimensionnées avec une estimation d'économie et de risque. C'est le levier le plus universel, car il s'applique à presque toutes les charges sans engagement financier.

Comment optimiser les coûts de stockage Amazon S3 ?

En choisissant la bonne classe selon la fréquence d'accès et en automatisant les transitions. S3 Intelligent-Tiering déplace seul les objets entre paliers sans frais de récupération. Les classes Standard-IA, Glacier et Deep Archive offrent des tarifs décroissants pour des données de moins en moins consultées. Des lifecycle policies font transiter automatiquement les objets vers des classes moins chères selon leur âge, puis les suppriment à l'issue de la rétention légale.

Que sont les instances Spot et combien font-elles économiser ?

Les Spot Instances vendent la capacité EC2 inutilisée d'AWS avec une remise pouvant atteindre 90 % par rapport au On-Demand. En contrepartie, AWS peut les récupérer avec un préavis de deux minutes. Elles conviennent aux charges tolérantes à l'interruption : traitements par lots, CI/CD, big data, nœuds de calcul Kubernetes. Les mélanger avec du On-Demand dans un groupe d'auto-scaling permet de capter la remise tout en gardant une base stable.

Comment éviter les frais imprévus sur AWS ?

En instrumentant la facture en amont : AWS Budgets pour des alertes sur seuils de coût ou d'usage, et Cost Anomaly Detection qui repère par apprentissage automatique les variations inhabituelles avant qu'elles ne deviennent une facture. S'y ajoutent un tagging fiable pour identifier vite la source d'une dérive, et une gouvernance (qui peut créer quelles ressources). Les frais imprévus viennent souvent du transfert de données, des environnements oubliés et des incidents, tous détectables par ces dispositifs.

Pourquoi ma facture AWS augmente-t-elle autant ?

Les causes les plus fréquentes sont le surprovisionnement (ressources trop grandes pour leur usage), les ressources orphelines qui facturent sans servir, l'absence d'engagements sur une charge stable (tout payé en On-Demand), les coûts de transfert de données invisibles (inter-AZ, egress, NAT Gateway) et les environnements non-prod allumés en permanence. Sans tagging ni visibilité, ces causes restent masquées. Un audit des coûts permet de chiffrer chacune et de les corriger par priorité.

Qu'est-ce qu'AWS Compute Optimizer ?

AWS Compute Optimizer est un service qui analyse les métriques d'utilisation (CloudWatch) de vos ressources (instances EC2, fonctions Lambda, volumes EBS, tâches ECS sur Fargate, instances RDS) et recommande des configurations mieux dimensionnées, avec une estimation d'économie et de risque de performance. C'est l'outil de référence pour piloter le rightsizing sur des données réelles plutôt que sur des intuitions.

Comment optimiser les coûts d'un cluster EKS / Kubernetes sur AWS ?

En agissant sur plusieurs leviers spécifiques : ajuster les requests et limits des pods (souvent surprovisionnés), améliorer le bin packing pour réduire le nombre de nœuds, adopter Karpenter pour provisionner en temps réel le bon type d'instance et exploiter le Spot, et utiliser Kubecost pour allouer le coût par namespace et équipe. Mélanger Spot et On-Demand sur les groupes de nœuds réduit fortement le coût des charges tolérantes à l'interruption.

Combien coûte une mission d'optimisation des coûts AWS ?

Le budget indicatif se situe entre 5 000 € et 15 000 € selon le périmètre, sur devis après cadrage. Cette fourchette couvre l'audit, le plan d'action chiffré, les premiers quick wins et la mise en place du socle de visibilité. Dans la plupart des cas, les économies constatées couvrent largement le coût de la mission dès les premiers mois, mais aucune économie ne peut être garantie à l'avance : elle dépend de votre situation de départ.