Qu'est-ce que la tarification Amazon EKS ?
Amazon EKS facture un tarif fixe de 0,10 $ par heure pour le plan de contrôle de chaque cluster (environ 72 $/mois). À cela s'ajoute le coût des ressources AWS sous-jacentes (instances EC2, Fargate, volumes EBS, load balancers) utilisées pour exécuter vos nœuds worker et votre application. Le support étendu des versions plus anciennes de Kubernetes coûte 0,60 $ par heure.
Comprendre la tarification EKS est essentiel pour estimer précisément ses dépenses cloud et éviter les mauvaises surprises. AWS propose plusieurs modes opérationnels pour EKS, chacun avec sa propre structure de coûts. Il convient d'évaluer les implications tarifaires des clusters standards, des groupes de nœuds managés, des options d'auto scaling et des add-ons optionnels. Analyser ces composants en amont garantit une planification budgétaire efficace et permet d'optimiser les coûts.
Cet article fait partie d'une série consacrée à la tarification de Kubernetes.
Dans cet article :
- Comprendre les composants de la tarification AWS EKS
- Coûts cachés et additionnels d'Amazon EKS
- Exemples de tarification Amazon EKS
- 6 façons de réduire et d'optimiser les coûts Amazon EKS
Comprendre les composants de la tarification AWS EKS
Passons en revue les principaux composants de coût des clusters Amazon EKS.
Tarification des clusters Amazon EKS
Amazon EKS facture un tarif horaire par cluster pour chaque cluster EKS. Le prix dépend du niveau de support de la version Kubernetes utilisée par le cluster :
- Les clusters exécutant une version Kubernetes sous support standard coûtent 0,10 $ par cluster et par heure.
- Une version Kubernetes reste sous support standard pendant les 14 premiers mois suivant sa sortie sur Amazon EKS.
- À l'issue du support standard, la version passe en support étendu pour les 12 mois suivants.
- Le support étendu coûte 0,60 $ par cluster et par heure, soit le tarif horaire standard de 0,10 $ auquel s'ajoutent 0,50 $ supplémentaires par cluster et par heure.
Cette tarification concerne le cluster EKS lui-même. Les ressources AWS utilisées par les workloads, comme les instances EC2, les volumes EBS, les adresses IPv4 publiques ou le calcul Fargate, restent facturées séparément.
Tarification Amazon EKS Provisioned Control Plane
Amazon EKS Provisioned Control Plane permet de réserver une capacité de plan de contrôle définie pour un cluster. Cette option s'adresse aux workloads qui exigent des performances stables du plan de contrôle, une réaction plus rapide aux pics de trafic ou la prise en charge d'opérations Kubernetes à plus grande échelle.
La tarification repose sur le niveau de dimensionnement du plan de contrôle sélectionné. La facturation est horaire et s'ajoute au tarif standard du cluster EKS. Il n'y a ni frais initiaux ni engagement de long terme :
- Le niveau XL coûte 1,65 $ par cluster et par heure.
- Le niveau 2XL coûte 3,40 $ par cluster et par heure.
- Le niveau 4XL coûte 6,90 $ par cluster et par heure.
- Le niveau 8XL coûte 13,90 $ par cluster et par heure.
Il est possible de changer de niveau de dimensionnement ou de revenir au plan de contrôle standard. Pour les niveaux supérieurs à 8XL, AWS invite les utilisateurs à contacter l'équipe en charge de leur compte pour obtenir un tarif.
Amazon EKS Auto Mode
La tarification d'Amazon EKS Auto Mode s'applique aux clusters où EKS Auto Mode est activé. Le montant facturé dépend du type et de la durée d'utilisation des instances Amazon EC2 lancées et gérées par EKS Auto Mode. Ces frais sont distincts du prix des instances EC2 : vous payez le coût EC2 habituel pour les instances sous-jacentes, EKS Auto Mode ajoutant ses propres frais de gestion.
EKS Auto Mode est facturé à la seconde, avec un minimum d'une minute. La facturation est indépendante de l'option d'achat EC2 : elle s'applique que les instances utilisent la tarification On-Demand, des Reserved Instances, des Compute Savings Plans ou des instances Spot. Les organisations qui prévoient d'utiliser EKS Auto Mode pour plus de 150 nœuds doivent contacter l'équipe en charge de leur compte AWS pour obtenir les informations tarifaires.
Tarification Amazon EKS Capabilities
La tarification Amazon EKS Capabilities s'applique lorsque certaines capabilities sont activées sur un cluster EKS. Elle comprend deux volets horaires : un tarif de base pour chaque capability activée et un tarif d'usage basé sur le nombre de ressources gérées par cette capability :
- Pour Argo CD dans la région US East (Ohio), le tarif de base est de 0,02771 $ par heure de capability Argo CD. Le tarif d'usage est de 0,00136 $ par heure d'application Argo CD. Chaque application est comptabilisée par déploiement de cluster cible : une application déployée sur cinq clusters compte donc comme cinq applications.
- Pour AWS Controllers for Kubernetes (ACK), le tarif de base est de 0,004482 $ par heure de capability ACK. Le tarif d'usage est de 0,000045 $ par heure de ressource ACK.
- Pour Kubernetes Resource Orchestrator (KRO), le tarif de base est de 0,004482 $ par heure de capability KRO. Le tarif d'usage est de 0,000045 $ par heure d'instance RGD KRO.
- Tous les frais liés aux capabilities EKS sont facturés à l'heure, sans frais initiaux ni engagement minimum.
Tarification Amazon EKS Hybrid Nodes
Amazon EKS Hybrid Nodes permet de connecter une infrastructure on-premises ou edge à des clusters Amazon EKS. Les workloads Kubernetes peuvent ainsi s'exécuter sur une infrastructure hors AWS tout en conservant la gestion des clusters dans Amazon EKS.
La tarification est basée sur les vCPU-heures remontées à Kubernetes :
- La facturation démarre lorsqu'un nœud hybride rejoint le cluster et s'arrête lorsque le nœud est retiré.
- Dans les environnements bare metal avec hyperthreading activé, chaque cœur CPU physique remonte deux vCPU à Kubernetes, et la facturation s'appuie sur le nombre de vCPU remonté.
La tarification Hybrid Nodes est dégressive selon l'usage mensuel agrégé en vCPU-heures dans une même région AWS :
- Les premières 576 000 vCPU-heures mensuelles coûtent 0,020 $ par vCPU-heure.
- Les 576 000 suivantes coûtent 0,014 $ par vCPU-heure.
- Les 4 608 000 vCPU-heures mensuelles suivantes coûtent 0,010 $ par vCPU-heure.
- Les 5 760 000 suivantes coûtent 0,008 $ par vCPU-heure.
- Au-delà de 11 520 000 vCPU-heures mensuelles, le tarif est de 0,006 $ par vCPU-heure.
Si la facturation consolidée est utilisée via AWS Organizations, ces paliers s'appliquent à l'ensemble des comptes de l'organisation pour une même région. Les utilisateurs qui prévoient d'exécuter des nœuds hybrides sur des machines de plus de 32 vCPU par machine doivent contacter l'équipe en charge de leur compte AWS.
Tarification EKS Anywhere
Amazon EKS Anywhere est un logiciel open source qui exécute des clusters Kubernetes sur du matériel en data center ou en environnement edge. Le logiciel lui-même est disponible en open source, mais AWS commercialise des Enterprise Subscriptions pour le support et des fonctionnalités supplémentaires :
- Une Amazon EKS Anywhere Enterprise Subscription fournit du support pour les clusters EKS Anywhere sous licence. Elle donne aussi accès aux EKS Anywhere Curated Packages, qui ajoutent des fonctions comme le load balancing, l'observabilité et l'auto scaling.
- AWS Enterprise Support ou AWS Enterprise On-Ramp Support est requis avant l'achat d'une EKS Anywhere Enterprise Subscription.
- Les abonnements peuvent être achetés via la console Amazon EKS, l'API ou l'AWS CLI.
- Le tarif est forfaitaire par cluster et ne dépend pas de la taille du cluster. Un engagement d'un an coûte 24 000 $ par cluster, facturé 2 000 $ par mois. Un engagement de trois ans coûte 18 000 $ par cluster et par an, facturé 1 500 $ par mois.
- Un même achat d'abonnement peut inclure une ou plusieurs licences de cluster EKS Anywhere.
- Les abonnements peuvent être configurés pour se renouveler automatiquement et peuvent être annulés sans frais dans les sept premiers jours.
Coûts cachés et additionnels d'Amazon EKS
Au-delà des composants de base, voici des coûts supplémentaires, parfois méconnus, également liés à vos clusters EKS.
Coûts de stockage
L'exécution de workloads sur Amazon EKS nécessite souvent du stockage persistant, ce qui engendre des coûts supplémentaires. Ces coûts proviennent généralement de l'utilisation de volumes Amazon EBS, d'Amazon EFS (Elastic File System) ou de buckets S3 pour le stockage objet. La tarification de ces services de stockage dépend de la capacité provisionnée, du type de stockage (SSD ou HDD, par exemple) et des besoins en IOPS. Si les workloads exigent du stockage haute performance ou de grandes capacités, les coûts de stockage peuvent dépasser le tarif de base du cluster EKS.
Les coûts de stockage incluent aussi les frais de sauvegarde, de snapshots et de transfert de données. Par exemple, la création régulière de snapshots EBS pour la reprise après sinistre ou la conformité peut générer des frais mensuels supplémentaires. Les organisations devraient surveiller l'utilisation du stockage, supprimer les volumes inutilisés et ajuster les classes de stockage au plus juste pour éviter les dépenses inutiles. Comprendre l'étendue réelle des coûts de stockage aide à prévenir les dépassements budgétaires dans les environnements EKS.
Coûts de transfert de données
Les coûts de transfert de données dans Amazon EKS sont souvent négligés, alors qu'ils peuvent peser sur votre facture AWS globale. AWS facture les données transférées depuis les clusters EKS vers Internet, entre zones de disponibilité, et parfois entre services AWS de régions différentes. Pour les applications à fort trafic sortant ou à communication inter-zones intensive, ces frais peuvent s'accumuler et représenter une part significative des coûts totaux.
Concevez vos workloads EKS de façon à minimiser les transferts de données superflus. Par exemple, gardez le trafic dans la même zone de disponibilité lorsque c'est possible, ou utilisez AWS PrivateLink pour la communication entre services afin de réduire les coûts. Examinez régulièrement les schémas de transfert de données et ajustez la topologie réseau pour maîtriser ces dépenses dans vos déploiements EKS.
Coûts des NAT Gateways
Les clusters Amazon EKS qui ont besoin d'un accès Internet depuis des sous-réseaux privés utilisent généralement des NAT Gateways. AWS facture à la fois l'utilisation horaire de chaque NAT Gateway et le volume de données qui y transite. Dans les environnements à fort trafic ou les clusters comportant plusieurs sous-réseaux privés, les frais de NAT Gateway peuvent grimper rapidement.
Pour réduire ces coûts, envisagez de consolider le trafic sur un nombre réduit de gateways ou d'utiliser des instances NAT pour les besoins à plus faible débit. Surveillez l'utilisation des NAT Gateways et passez en revue l'architecture réseau pour identifier des pistes d'économies. Les frais de NAT Gateway n'étant inclus ni dans le prix du plan de contrôle EKS ni dans celui des nœuds, intégrez-les dans le calcul du coût total de possession d'EKS.
Logs et monitoring CloudWatch
Amazon CloudWatch est couramment utilisé pour les logs et le monitoring des clusters EKS, mais ses coûts sont distincts de la tarification EKS. Les frais CloudWatch dépendent du volume de logs ingérés, des métriques stockées et des dashboards créés. Une journalisation à haute fréquence, des logs applicatifs verbeux ou de nombreuses métriques personnalisées peuvent faire grimper les coûts, en particulier dans les environnements EKS de grande taille ou dynamiques.
Les organisations devraient mettre en place des politiques de rétention des logs, filtrer les logs superflus et agréger les métriques pour maîtriser les dépenses CloudWatch. L'échantillonnage des logs ou le recours à des solutions de logging tierces peut également réduire les coûts. Passez régulièrement en revue l'utilisation de CloudWatch et optimisez la collecte des logs et des métriques pour éviter les frais imprévus, tout en conservant une observabilité suffisante pour vos workloads EKS.
Exemples de tarification Amazon EKS
Exemple 1 : tarification d'un cluster EKS avec support standard et étendu
Un cluster EKS exécute la même version de Kubernetes pendant 26 mois sans mise à niveau du plan de contrôle. Pendant les 14 premiers mois, la version est sous support standard, à 0,10 $ par cluster et par heure. Elle passe ensuite en support étendu pendant 12 mois, à 0,60 $ par cluster et par heure.
Pour illustrer concrètement la différence : durant les 14 mois de support standard, le cluster coûte environ 1 022 $ en frais de cluster (14 × 730 heures × 0,10 $). Durant les 12 mois de support étendu, ce montant grimpe à 5 256 $ (12 × 730 heures × 0,60 $), soit plus de cinq fois le coût pour deux mois de moins. Rapporté à l'ensemble de la période de 26 mois, le tarif effectif est de 0,33 $ par cluster et par heure.
Exemple 2 : tarification EKS Hybrid Nodes pour plusieurs entités métier
Trois entités métier utilisent EKS Hybrid Nodes, chacune sur un cluster EKS dédié sous support standard de version Kubernetes, soit des frais de cluster mensuels de 73 $ chacune (730 heures × 0,10 $).
L'entité 1 exécute 8 nœuds de 8 vCPU chacun, générant 46 720 vCPU-heures et 934,40 $ de frais de nœuds. L'entité 2 exécute 4 nœuds de 16 vCPU chacun, générant 46 720 vCPU-heures et 934,40 $ de frais de nœuds. L'entité 3 exécute 6 nœuds de 4 vCPU chacun, générant 17 520 vCPU-heures et 350,40 $ de frais de nœuds.
Au total, les trois entités consomment 110 960 vCPU-heures sur le mois. Ce volume étant bien inférieur au plafond du premier palier de 576 000 vCPU-heures mensuelles, l'ensemble de l'usage est facturé 0,02 $ par vCPU-heure. La facture EKS mensuelle totale s'élève à 2 438,20 $, dont 219 $ de frais de cluster et 2 219,20 $ de frais de nœuds.
Exemple 3 : exemple de tarification Amazon EKS Auto Mode
Une application conteneurisée s'exécute sur Amazon EKS Auto Mode dans la région US West (Oregon). L'application comprend des pods frontend, des pods backend et des pods de traitement par lots. EKS Auto Mode sélectionne un mix d'instances EC2 pour répondre aux besoins de ces workloads.
Les instances sélectionnées sont c6a.2xlarge, c6a.4xlarge, m5a.2xlarge et m5a.xlarge. Leur coût EC2 combiné est de 1,434 $ par heure. EKS Auto Mode ajoute des frais de gestion distincts de 0,17208 $ par heure pour ces instances.
Sur un mois, cela représente 1 046,82 $ de coûts d'instances EC2 et 125,62 $ de frais EKS Auto Mode. Cet exemple montre que la tarification EKS Auto Mode s'ajoute au coût EC2 sous-jacent, sans le remplacer.
6 façons de réduire et d'optimiser les coûts Amazon EKS
1. Appliquer le right-sizing aux nœuds worker et aux requests des pods
Les nœuds worker surprovisionnés et les requests de ressources gonflées des pods sont des sources courantes de gaspillage sur EKS. Kubernetes planifie les pods en fonction du CPU et de la mémoire demandés, et non de l'utilisation réelle. Si les requests sont trop élevées, les clusters risquent de scaler inutilement, laissant une grande partie de la capacité des nœuds inutilisée tout en continuant de générer des coûts EC2.
Les équipes devraient analyser régulièrement la consommation réelle des ressources et ajuster les requests et limits en conséquence. Des outils comme Kubernetes metrics server, Prometheus, Vertical Pod Autoscaler (VPA), KEDA et Goldilocks aident à repérer les allocations inefficaces. L'utilisation de types d'instances plus petits, de groupes d'instances mixtes ou d'instances Graviton peut aussi améliorer l'efficience économique.
L'autoscaling de cluster devrait être configuré pour supprimer automatiquement les nœuds inutilisés. Combiner un dimensionnement précis des pods avec l'autoscaling réduit l'infrastructure inactive et améliore la densité des workloads sur le cluster.
2. Utiliser les instances Spot pour les workloads tolérants aux pannes
Les instances Amazon EC2 Spot peuvent réduire les coûts de calcul EKS, car elles exploitent la capacité AWS disponible à prix réduit. La tarification Spot est souvent inférieure de 70 à 90 % au tarif On-Demand standard, ce qui la rend adaptée aux workloads capables de tolérer des interruptions.
Les applications stateless, les jobs batch, les pipelines CI/CD, les workers d'arrière-plan et les tâches de traitement de données sont d'excellents candidats pour Spot. Les groupes de nœuds Kubernetes peuvent mélanger instances Spot et On-Demand, afin que les workloads critiques restent stables pendant que les workloads tolérants aux pannes profitent d'une capacité moins coûteuse.
Pour améliorer la fiabilité, utilisez plusieurs types d'instances et zones de disponibilité dans les groupes de nœuds Spot. Des fonctionnalités Kubernetes comme les Pod Disruption Budgets et le Cluster Autoscaler aident les workloads à se rétablir automatiquement en cas d'interruption Spot.
3. Optimiser les load balancers et l'ingress
Chaque service Kubernetes de type LoadBalancer dans EKS provisionne généralement un load balancer AWS dédié. Dans les grands environnements, des load balancers superflus ou dupliqués peuvent engendrer des coûts mensuels conséquents, surtout avec des Application Load Balancers ou des Network Load Balancers.
Un contrôleur d'ingress centralisé permet à plusieurs applications de partager un même load balancer au lieu d'en provisionner un par service. L'AWS Load Balancer Controller prend en charge le routage de plusieurs applications via des load balancers partagés, grâce à des règles de routage par hôte ou par chemin.
Supprimez les load balancers inutilisés et passez régulièrement en revue les ressources ingress inactives. Les services strictement internes devraient éviter les load balancers exposés à Internet, sauf si un accès externe est nécessaire. Optimiser l'architecture d'ingress réduit à la fois les frais de load balancer et les coûts de transfert de données associés.
4. Identifier les ressources inactives et sous-utilisées
Les ressources Kubernetes inutilisées continuent souvent de générer des frais AWS même lorsque les applications ne sont plus actives. Nœuds EC2 inactifs, volumes EBS non attachés, load balancers orphelins, Elastic IP inutilisées et namespaces inactifs sont des exemples courants de gaspillage dans les environnements EKS.
Des revues régulières des coûts et de l'utilisation aident à identifier les ressources à supprimer ou à consolider. AWS Cost Explorer, AWS Compute Optimizer, Kubecost et les outils de monitoring Kubernetes permettent de suivre l'usage inefficace des ressources sur l'ensemble des clusters.
Automatiser les processus de nettoyage améliore la maîtrise des coûts. Les organisations peuvent recourir à des politiques de cycle de vie, à des arrêts planifiés pour les environnements hors production et à des règles d'expiration de namespaces pour réduire les dépenses inutiles. Le monitoring continu est important, car les environnements Kubernetes évoluent fréquemment au gré du scaling des workloads et du déploiement de nouveaux services.
5. Mettre à niveau les versions de Kubernetes avant le support étendu
Amazon EKS augmente le prix du cluster dès qu'une version de Kubernetes passe du support standard au support étendu. Le tarif horaire passe de 0,10 $ à 0,60 $ par cluster-heure, ce qui peut alourdir les coûts sur plusieurs clusters.
Des mises à niveau régulières de Kubernetes permettent d'éviter ces frais supplémentaires tout en améliorant la sécurité, la stabilité et l'accès aux nouvelles fonctionnalités. Établir un calendrier de mise à niveau prévisible réduit le risque de laisser des clusters sur des versions non supportées pendant de longues périodes.
Testez les mises à niveau en environnement de staging avant le déploiement en production afin de réduire le risque opérationnel. Les équipes devraient également suivre le calendrier de versions d'Amazon EKS et planifier les mises à niveau suffisamment tôt pour éviter des migrations précipitées à l'approche des échéances de support.
6. Utiliser Karpenter pour un provisionnement de nœuds plus intelligent
Karpenter peut contribuer à réduire les coûts Amazon EKS en provisionnant la capacité de calcul en fonction des besoins réels des pods, plutôt qu'en s'appuyant uniquement sur des groupes de nœuds prédéfinis. Il évalue les pods en attente et lance des instances EC2 correctement dimensionnées, ce qui améliore le bin packing, réduit la capacité inactive et accélère le scaling.
Contrairement aux configurations classiques du Cluster Autoscaler qui dépendent fortement des Auto Scaling Groups, Karpenter peut choisir parmi un éventail plus large de types d'instances, de tailles, de zones de disponibilité, d'architectures et de types de capacité. Cette flexibilité permet aux équipes d'utiliser un mix plus varié d'instances On-Demand, Spot et Graviton tout en préservant la disponibilité des applications.
Karpenter est particulièrement utile pour les workloads dynamiques ou variables, car il peut rapidement ajouter de la capacité lorsque des pods ne peuvent pas être planifiés et consolider les nœuds sous-utilisés lorsque la demande baisse. Les équipes devraient configurer les NodePools avec des exigences d'instances adaptées, des contrôles de disruption, des politiques de consolidation et des contraintes de workloads pour concilier économies et fiabilité.
Optimiser les coûts EKS avec PerfectScale
EKS offre une plateforme puissante pour exécuter des workloads conteneurisés, mais avec son modèle de tarification, toute configuration de ressources inefficace se traduit directement par une facture plus élevée. Des requests CPU et mémoire surprovisionnées poussent les clusters à scaler plus que nécessaire, laissant tourner des nœuds EC2 à faible taux d'utilisation pendant que les coûts s'accumulent. PerfectScale by DoiT élimine ce gaspillage en analysant en continu la consommation réelle des workloads sur vos clusters EKS et en ajustant de manière autonome les requests et limits CPU et mémoire — sans réglage manuel ni temps d'ingénierie.
Contrairement aux outils qui se contentent d'émettre des recommandations que les équipes ont rarement le temps d'appliquer, PerfectScale applique les optimisations automatiquement, avec des garde-fous pour protéger les performances et la disponibilité. Il détecte et corrige en temps réel les risques de résilience comme les OOM kills, le throttling CPU et les évictions de pods, afin que les économies ne se fassent pas au détriment de la stabilité. Résultat : un cluster plus dense et mieux utilisé, qui dépense moins en capacité EC2 superflue tout en préservant la fiabilité qu'exigent vos workloads.
Découvrez comment PerfectScale réduit les coûts EKS de manière autonome