L'essentiel
Sur la grille tarifaire, les prix d'AWS EC2 semblent simples. En pratique, les coûts annexes — transfert de données, stockage EBS, adresses IPv4 publiques — peuvent ajouter 40 à 50 % au-dessus des heures de calcul. Ce guide détaille les tarifs on-demand, reserved, spot et Savings Plans avec des chiffres concrets, quantifie les lignes de facture que les équipes FinOps oublient régulièrement au moment de budgéter, et présente les stratégies d'optimisation qui transforment des dépenses EC2 imprévisibles en un montant maîtrisable et défendable.
La plupart des équipes FinOps connaissent leur tarif EC2 on-demand. Beaucoup moins savent dire à quoi ressemble réellement leur coût EC2 total une fois le transfert de données, le stockage, les load balancers et la facturation des IPv4 publiques de 2024 pris en compte. C'est cet écart entre la grille tarifaire et la facture réelle qui provoque les mauvaises surprises budgétaires et place les programmes FinOps sous surveillance.
Si les tarifs EC2 sont complexes, ce n'est pas par manque de transparence : AWS publie chaque chiffre. La complexité tient au fait que ces tarifs couvrent des dizaines de dimensions, et que la plupart des modèles de coûts sous-estiment les frais annexes qui s'accumulent autour de chaque instance. Ce guide donne aux praticiens FinOps le contexte tarifaire, le calcul des coûts cachés et les cadres d'optimisation nécessaires pour bâtir des budgets EC2 précis et les défendre.
Qu'est-ce qu'AWS EC2 ?
Amazon Elastic Compute Cloud (AWS EC2) fournit des serveurs virtuels redimensionnables, appelés instances, dans le cloud AWS. Les équipes provisionnent de la capacité de calcul à la demande, sans avoir à acheter ni à maintenir de matériel physique.
Pour les praticiens FinOps, le cadrage le plus pertinent est ailleurs : EC2 représente généralement le premier poste de la facture AWS. Gartner prévoit 723 milliards de dollars de dépenses mondiales en cloud public en 2025 (Gartner), et le calcul tire ces dépenses. AWS facture EC2 à la seconde (avec un minimum d'une minute) pour les instances Linux, et à l'heure pour Windows. Les tarifs varient selon la famille d'instances, la taille, la région, le système d'exploitation et le mode de tenancy.
Une instance polyvalente m7i.large dans la région US East (N. Virginia) coûte 0,1008 $/heure en on-demand. Une c7i.large optimisée pour le calcul dans la même région coûte 0,08925 $/heure. De petits écarts horaires deviennent significatifs à grande échelle : 100 instances m7i.large fonctionnant en continu reviennent à environ 73 584 $/an en on-demand, avant tout frais annexe.
Tarifs en vigueur en mai 2026. Consultez la page AWS EC2 On-Demand Pricing pour les tarifs en temps réel.
Comment les types d'instances EC2 influencent-ils les décisions tarifaires ?
Chaque famille d'instances EC2 est optimisée pour un ratio de ressources particulier, et ce ratio pèse directement sur l'arbitrage coût-performance que les équipes FinOps doivent évaluer.
Les instances polyvalentes (famille m) équilibrent CPU, mémoire et réseau. Elles couvrent l'éventail le plus large de workloads et constituent le point de départ par défaut pour la plupart des applications. Les instances optimisées pour le calcul (famille c) offrent davantage de vCPU par dollar de mémoire, ce qui les rend 10 à 15 % moins chères par heure de vCPU pour les workloads CPU-bound comme le traitement par lots ou l'encodage média. Les instances optimisées pour la mémoire (familles r et x) inversent ce ratio, allouant plus de RAM par vCPU pour les bases de données en mémoire et l'analytique.
L'impact tarifaire se résume à l'adéquation. Faire tourner un workload CPU-bound sur une instance optimisée mémoire revient à payer de la RAM inutilisée. Faire tourner une base de données gourmande en mémoire sur une instance optimisée calcul oblige à surprovisionner les vCPU pour obtenir assez de RAM, ce qui gonfle le nombre d'instances et le coût. Le groupe de travail EC2 autoscaling de la FinOps Foundation recommande de viser 40 à 70 % d'utilisation CPU moyenne et de signaler toute instance restant sous 20 à 30 % en vue d'un downsizing (FinOps Foundation).
Les nouvelles générations pèsent également sur la tarification. AWS a lancé en 2025 les familles m8i et c8i de 8ᵉ génération, avec un rapport prix-performance jusqu'à 15 % supérieur à la 7ᵉ génération. Les équipes FinOps ont tout intérêt à comparer les instances de nouvelle génération à leurs réservations actuelles avant de renouveler leurs commitments.
Comment AWS calcule-t-il et facture-t-il EC2 ?
La facturation EC2 part du tarif horaire de l'instance, mais ne s'arrête pas là. Cette section couvre les trois modèles tarifaires, les coûts annexes qui gonflent le chiffre réel et les indicateurs de right-sizing qui permettent de le ramener à la baisse.
Quel modèle tarifaire EC2 convient à votre workload ?
AWS propose trois modèles tarifaires principaux pour EC2. Chacun implique un arbitrage différent entre flexibilité et profondeur de remise.
On-demand facture au tarif horaire publié, sans engagement. Ce modèle offre une flexibilité totale, mais c'est le plus coûteux. Il convient aux workloads imprévisibles, aux projets courts et à toute capacité dont l'usage n'est pas encore assez stable pour être prévu.
Les Reserved Instances (RI) et les Savings Plans échangent de l'engagement contre des remises. Une Standard RI sur 1 an offre en moyenne environ 40 % de remise sur le on-demand. Une Standard RI sur 3 ans, environ 60 %. Les Compute Savings Plans offrent des remises similaires (jusqu'à 66 %) avec plus de flexibilité, puisqu'ils s'appliquent automatiquement à différentes familles d'instances, régions, et même à Fargate et Lambda. La FinOps Foundation situe le point d'équilibre d'une RI 1 an autour de 7 à 8 mois en utilisation pleine avec une remise de 40 % (FinOps Foundation).
Le revers : les commitments ne peuvent pas être annulés en cours de période. Les schémas de workload évoluent, et les réservations inutilisées deviennent un coût irrécupérable. C'est ce qui fait des erreurs courantes liées aux commitments AWS l'un des problèmes les plus coûteux du FinOps.
Les Spot Instances exploitent la capacité EC2 inutilisée avec des remises de 60 à 90 % par rapport au on-demand. AWS fixe les prix spot en fonction de l'offre et de la demande à long terme (et non par enchères) et envoie un préavis d'interruption de 2 minutes lorsqu'il récupère la capacité. Pour les workloads tolérants aux pannes — traitement par lots, pipelines CI/CD, microservices sans état — le spot offre la remise la plus profonde disponible.
Tarifs en vigueur en mai 2026. Consultez les pages AWS Reserved Instance Pricing et Spot Pricing pour les tarifs en temps réel.
| Modèle | Remise par rapport au On-Demand | Engagement | Flexibilité | Garantie de capacité |
|---|---|---|---|---|
| On-Demand | Aucune | Aucun | Totale | Oui |
| Standard RI 1 an | ~40 % | 1 an | Faible (verrouillée famille/région) | Limitée à l'AZ |
| Standard RI 3 ans | ~60 % | 3 ans | Faible | Limitée à l'AZ |
| Compute Savings Plan | Jusqu'à 66 % | 1 ou 3 ans | Élevée (multi-familles, multi-régions) | Non |
| Spot | 60 à 90 % | Aucun | Totale (capacité possiblement perdue) | Non |
Le tableau reflète les fourchettes de remise publiées par AWS en mai 2026. Les remises réelles varient selon le type d'instance, la région et l'option de paiement.
Quels coûts cachés s'ajoutent au prix de l'instance ?
Le tarif de l'instance ne dit jamais tout. Le stockage EBS, le transfert de données, les load balancers et les frais d'IPv4 publiques peuvent ajouter 40 à 50 % au-dessus des heures de calcul pour un workload typique exposé sur Internet.
Le stockage EBS (stockage en bloc par défaut pour EC2) démarre à 0,08 $/Go-mois pour les volumes gp3. Un modeste volume racine de 100 Go par instance ajoute 8 $/mois par instance, soit 960 $/an pour une flotte de 10 instances. Les snapshots coûtent 0,05 $/Go-mois en plus.
Le transfert de données prend les équipes FinOps au dépourvu plus que n'importe quelle autre ligne de facture. La sortie Internet depuis US East coûte 0,09 $/Go au-delà du palier gratuit des 100 premiers Go/mois. Un workload générant 5 To/mois de sortie paie environ 450 $/mois en seuls frais de transfert. Le trafic inter-AZ coûte 0,01 $/Go dans chaque sens (0,02 $/Go aller-retour), une surprise fréquente dans les déploiements Kubernetes multi-AZ où le trafic du service mesh traverse les zones de disponibilité en continu.
Les adresses IPv4 publiques coûtent désormais 0,005 $/heure (~3,60 $/mois chacune) depuis le changement tarifaire de février 2024. Ces frais s'appliquent à chaque IPv4 publique en cours d'utilisation sur les instances EC2, les load balancers, les NAT gateways et les endpoints RDS.
Les NAT Gateways aggravent le problème du transfert de données : 0,045 $/heure par AZ (~32,40 $/mois) plus 0,045 $/Go traité, en plus des tarifs de sortie standard pour le trafic à destination d'Internet.
Prenons un scénario réaliste : 10 instances m7i.large avec 100 Go de stockage gp3 chacune, un ALB, 12 adresses IPv4 publiques, 5 To de sortie mensuelle et 500 Go de trafic inter-AZ. Cet environnement coûte environ 1 380 $/mois. Les heures d'instance représentent 736 $ de ce total. Les coûts annexes pèsent 47 % de la facture.
Tarifs en vigueur en mai 2026. Consultez les pages AWS EBS Pricing et EC2 Data Transfer Pricing pour les tarifs en temps réel.
Comment dimensionner les instances en fonction de leur utilisation ?
Le right-sizing consiste à ajuster la capacité de l'instance à la demande réelle du workload. C'est la voie la plus rapide pour réduire les dépenses EC2 sans engagement ni changement d'architecture.
Le livre blanc d'AWS sur le right-sizing fixe un seuil clair : toute instance dont l'utilisation maximale du CPU et de la mémoire reste sous 40 % sur une période de quatre semaines peut être réduite (AWS). Diviser par deux la taille d'une instance surdimensionnée fait économiser environ 50 % sur cette instance, sans impact sur les performances tant que l'utilisation reste dans la nouvelle capacité.
AWS Compute Optimizer automatise cette analyse via du machine learning, en visant un P99.5 CPU à 80 % d'utilisation soutenue. Le moteur de right-sizing de Cost Explorer signale les instances dont l'utilisation CPU maximale est inférieure ou égale à 1 % comme inactives et recommande leur arrêt.
Les configurations de sécurité peuvent également peser sur les coûts. Chiffrer les volumes EBS avec AWS KMS ajoute un léger coût par requête, et faire tourner des instances en tenancy dédiée (parfois exigée pour la conformité) coûte nettement plus cher que la tenancy partagée. Les équipes FinOps ont intérêt à intégrer ces impacts tarifaires liés à la conformité dans leurs calculs de right-sizing, plutôt qu'à traiter la sécurité comme un coût fixe.
Pour des stratégies d'optimisation continue, le right-sizing doit s'exercer en continu, pas trimestriellement. Les schémas de workload évoluent au fil des applications, et une instance bien dimensionnée aujourd'hui peut basculer en surprovisionnement en quelques semaines.
Quelles stratégies d'optimisation EC2 les équipes FinOps doivent-elles privilégier ?
McKinsey a constaté que des pratiques FinOps efficaces réduisent les coûts cloud de 20 à 30 %, sur la base de leur analyse de 3 milliards de dollars de factures cloud réelles (McKinsey). Ces économies ne tiennent pas à un seul levier. Elles supposent une approche de portefeuille combinant remises basées sur l'engagement, adoption du spot et right-sizing continu.
Comment évaluer une stratégie d'achat de Reserved Instances ?
La FinOps Foundation recommande d'évaluer les achats de commitments à l'aune de l'Effective Savings Rate (ESR), et non du pourcentage de remise affiché. L'ESR mesure les économies réalisées moins le coût des commitments inutilisés, le tout divisé par les dépenses équivalentes en on-demand. L'ESR moyen sur AWS Compute s'établit autour de 26 %, bien en deçà des maxima théoriques de 66 à 72 %, parce que la plupart des organisations conservent un stock de commitments inutilisés (FinOps Foundation).
Un portefeuille défendable commence par couvrir la base prévisible — le point bas d'utilisation sur un mois — avec des EC2 Instance Savings Plans ou des Standard RIs pour les remises les plus profondes. On superpose ensuite des Compute Savings Plans pour les workloads à régime variable mais stable, puisqu'ils s'appliquent aux familles, aux régions et au serverless. On laisse les workloads en pics ou incertains en on-demand jusqu'à ce que l'utilisation se stabilise suffisamment pour être prévue.
Les bons outils d'optimisation des coûts cloud automatisent l'analyse de couverture et signalent les baisses d'utilisation des commitments sous les seuils cibles.
Quand utiliser les Spot Instances pour les workloads sensibles aux coûts ?
Le spot convient à tout workload qui tolère l'interruption. Travaux par lots, pipelines CI/CD, traitement de données, serveurs API sans état derrière des auto-scaling groups, microservices conteneurisés avec gestion d'arrêt propre : tous sont éligibles.
La clé d'un usage fiable du spot : diversifier sur les types d'instances et les zones de disponibilité. Utilisez la sélection d'instances par attributs pour permettre à EC2 de puiser dans le pool de capacité le plus large possible. Le Spot Instance Advisor d'AWS affiche la fréquence d'interruption par type d'instance ; la plupart des familles polyvalentes et optimisées calcul en US East restent sous 5 % d'interruption.
Combiner du spot avec un fallback on-demand ou Savings Plan dans un auto-scaling group crée un taux mixte. Une flotte composée à 70 % de spot et à 30 % d'on-demand peut atteindre 45 à 60 % d'économies effectives par rapport à un tarif 100 % on-demand.
Comment rendre les tarifs AWS EC2 prévisibles et défendables ?
Le rapport State of FinOps 2025 de la FinOps Foundation, couvrant 69 milliards de dollars de dépenses cloud auprès de 861 répondants, indique que la réduction du gaspillage et l'optimisation des workloads restent la priorité numéro un pour 50 % des praticiens (FinOps Foundation). À cette échelle, même des progrès marginaux dans la gestion des coûts EC2 se traduisent par des montants conséquents.
L'optimisation manuelle ne passe pas à l'échelle. Revues trimestrielles de right-sizing, suivi des RI dans des tableurs, adoption réactive du spot : autant d'occasions manquées entre deux cycles de revue. L'analyse McKinsey de 3 milliards de dollars de factures cloud a identifié 10 à 20 % d'économies supplémentaires inexploitées dans la plupart des organisations, même celles dotées de programmes FinOps existants (McKinsey).
FlexSave for Compute de DoiT automatise les remises basées sur l'engagement en analysant en continu les schémas d'utilisation EC2 et en appliquant le mix optimal de Savings Plans et de capacité réservée, sans intervention manuelle. La plateforme Procurement de DoiT consolide la facturation sur l'ensemble des comptes AWS et apporte la visibilité sur les coûts dont les outils AWS FinOps ont besoin pour rendre les dépenses EC2 prévisibles plutôt que réactives.
Questions fréquentes sur les tarifs AWS EC2
Combien coûte une instance EC2 par mois ?
Le coût mensuel dépend du type d'instance, de la région et du modèle tarifaire. Une instance polyvalente m7i.large en US East coûte environ 73,58 $/mois en on-demand (730 heures × 0,1008 $/heure). Les Reserved Instances et les Savings Plans réduisent ce montant de 40 à 72 % selon la durée d'engagement et l'option de paiement. Ajoutez le stockage EBS, le transfert de données et les autres frais annexes pour une vue complète.
Quels modèles tarifaires AWS propose-t-il pour EC2 ?
AWS propose quatre options tarifaires principales pour EC2 : On-Demand (sans engagement, flexibilité totale), Reserved Instances (engagement de 1 ou 3 ans, jusqu'à 72 % de remise), Savings Plans (engagement de 1 ou 3 ans, jusqu'à 66 % avec plus de flexibilité entre familles et régions) et Spot Instances (sans engagement, 60 à 90 % de remise, interruptibles).
Pourquoi ma facture EC2 dépasse-t-elle le prix de l'instance ?
Les factures EC2 ne se limitent pas aux heures d'instance. Stockage EBS, transfert de données (notamment la sortie Internet à 0,09 $/Go), Elastic Load Balancers, adresses IPv4 publiques (0,005 $/heure depuis février 2024), NAT Gateways et snapshots ajoutent autant de lignes. Pour les workloads exposés sur Internet, ces coûts annexes peuvent représenter 40 à 50 % des dépenses totales liées à EC2.
Quel Effective Savings Rate les équipes FinOps doivent-elles viser ?
L'ESR moyen sur AWS Compute s'établit autour de 26 %. Les pratiques FinOps matures visent 30 à 40 % ou plus, en maintenant un taux d'utilisation élevé des commitments, en couvrant la charge de base avec les instruments offrant les plus fortes remises et en mesurant les économies par rapport aux dépenses équivalentes en on-demand plutôt qu'au pourcentage de remise affiché.
Découvrez comment FlexSave for Compute peut optimiser vos coûts AWS EC2 grâce à des outils concrets et fiables, conçus pour les équipes cloud modernes. Contactez-nous pour voir comment DoiT peut rendre vos dépenses EC2 prévisibles.