EKS vs ECS vs Fargate pour une PME : le vrai comparatif coût/complexité

« On part sur Kubernetes, c’est le standard. » C’est la réponse la plus fréquente qu’on entend en mission quand une PME choisit son orchestrateur de conteneurs — et c’est souvent la mauvaise réponse. Pas parce qu’EKS serait un mauvais produit, mais parce que la question posée n’est pas la bonne. Pour une équipe de 5 à 30 ingénieurs sur AWS, le choix entre ECS, EKS et Fargate n’est pas une question de standard du marché : c’est un arbitrage entre un forfait fixe de complexité opérationnelle et une facture mensuelle de control plane, à mettre en face de ce que l’équipe sait déjà faire.

Cet article détaille les coûts réels — control plane, compute Fargate, extended support — et propose un arbre de décision qui évite l’erreur la plus commune : partir sur EKS parce que « ça se voit bien sur un CV », et découvrir six mois plus tard qu’une personne à temps plein est mobilisée pour maintenir le cluster.

Trois produits, deux questions distinctes

Le vocabulaire prête à confusion parce qu’ECS et EKS répondent à la question « qui orchestre mes conteneurs », tandis que Fargate répond à une question orthogonale : « qui gère l’infrastructure sous-jacente ».

• ECS (Elastic Container Service) : orchestrateur propriétaire AWS, plus simple, intégration native avec IAM, ALB, CloudWatch, Service Discovery — sans le vocabulaire Kubernetes (pods, deployments, CRDs).
• EKS (Elastic Kubernetes Service) : control plane Kubernetes managé par AWS. Vous héritez de l’écosystème CNCF complet (Helm, ArgoCD, Istio, operators tiers) et de la portabilité multi-cloud, au prix d’une complexité intrinsèquement plus élevée.
• Fargate : mode de calcul serverless, utilisable avec ECS ou avec EKS. Vous ne provisionnez plus d’instances EC2 — AWS facture le vCPU et la mémoire consommés par chaque tâche/pod, à la seconde.

Le vrai carrefour de décision est donc en deux temps : ECS ou EKS pour l’orchestration, puis Fargate ou EC2 pour le compute. Ce sont quatre combinaisons possibles, pas deux.

Le coût réel : le control plane EKS n’est pas négociable

C’est le point le plus sous-estimé en mission. ECS n’a aucun frais de control plane — vous ne payez que le compute (EC2 ou Fargate). EKS, lui, facture le control plane $0,10 par cluster par heure, soit environ 73 $/mois par cluster, quel que soit le nombre de services qui tournent dessus. Un cluster EKS pour trois microservices coûte le même forfait de control plane qu’un cluster EKS pour cinquante.

Le piège caché : si le cluster n’est pas mis à niveau vers une version Kubernetes supportée dans les délais, AWS bascule automatiquement en extended support — le tarif passe à 0,60 $/heure, soit environ 438 $/mois, un facteur ×6 sur la seule ligne control plane. C’est un des cas classiques de facture AWS qui explose sans qu’aucune charge n’ait augmenté : une simple version Kubernetes qu’on a laissée traîner.

Sur la couche compute Fargate elle-même, les tarifs eu-west-3 (Paris) tournent autour de 0,046 €/vCPU-heure et 0,005 €/Go-heure — soit environ 41 €/mois pour une tâche 1 vCPU / 2 Go tournant 24/7. Ce tarif est strictement identique que la tâche tourne sous ECS ou sous EKS : Fargate ne fait pas de distinction. La différence de facture vient uniquement du control plane et, pour EKS avec EC2, du mode Auto Mode.

EKS Auto Mode, lancé pour automatiser le provisioning et le patching des nœuds, ajoute une surcharge de 10 à 12 % sur le coût EC2 sous-jacent, facturée à la seconde avec un minimum d’une minute — en plus du forfait control plane. C’est un compromis raisonnable si l’équipe n’a personne dédié à l’ops Kubernetes, mais ce n’est pas gratuit.

Sur un cas concret — trois services conteneurisés, 1 vCPU / 2 Go chacun, tournant en continu — l’écart entre ECS + Fargate (≈123 €/mois) et EKS + Fargate (≈196 €/mois) tient uniquement au control plane. Ce n’est pas rédhibitoire à cette échelle, mais ça devient significatif quand une PME multiplie les clusters par environnement (dev, staging, prod) sans mutualiser.

La complexité qu’on ne voit pas sur le papier

Le coût en euros n’est souvent pas le vrai facteur bloquant — c’est le coût en temps d’équipe. Trois angles morts qu’on retrouve systématiquement en audit :

La courbe d’apprentissage n’est pas linéaire. ECS se prend en main en quelques jours pour une équipe qui connaît déjà IAM et les Security Groups. EKS demande de maîtriser les objets Kubernetes, les RBAC, les CNI (VPC CNI, Calico), l’observabilité spécifique (metrics-server, kube-state-metrics) — un socle de connaissances qui prend plusieurs semaines à une équipe qui n’a jamais opéré de cluster, et qui nécessite un maintien à niveau continu (versions Kubernetes tous les 4 mois).

Les upgrades Kubernetes sont un point de friction récurrent. AWS déprécie les anciennes versions EKS sur un rythme régulier — contrairement à ECS, où il n’y a rien à mettre à jour côté orchestrateur. Une PME sans processus d’upgrade documenté se retrouve régulièrement en extended support par simple négligence, avec la facture ×6 qui va avec.

L’écosystème CNCF a un coût d’intégration. Helm, cert-manager, external-dns, ingress-nginx ou l’AWS Load Balancer Controller ne sont pas fournis clé en main — chaque brique est un choix, une version à suivre, une source de vulnérabilités à patcher. Sur ECS, l’équivalent (ALB, Service Discovery, Secrets Manager) est intégré nativement et maintenu par AWS.

À l’inverse, EKS devient le bon choix dès que l’un de ces critères est vrai : équipe qui opère déjà du Kubernetes ailleurs (on-premise, autre cloud), besoin réel de portabilité multi-cloud, ou dépendance à un outil spécifiquement Kubernetes (operators, service mesh, GitOps avancé) qui n’a pas d’équivalent ECS.

Arbre de décision pour une PME

En synthèse, la méthode qu’on applique en mission pour trancher rapidement :

1. L’équipe a-t-elle déjà une expertise Kubernetes en interne ? Non → ECS, sauf contrainte externe forte. Oui → EKS reste pertinent.
2. Y a-t-il une contrainte de portabilité multi-cloud ou hybride documentée ? Non → ECS. Oui → EKS.
3. Le volume justifie-t-il de payer le control plane fixe (73 $/mois minimum) ? Trois services critiques en prod → oui, le ratio devient vite négligeable. Un seul service interne → non, ECS suffit largement.
4. Fargate ou EC2 ? Charge stable et prévisible, prête à optimiser finement → EC2 (moins cher au vCPU, plus d’ops). Charge variable, équipe petite, priorité à ne pas gérer l’infra → Fargate, quitte à payer la prime.
5. Process d’upgrade Kubernetes en place ? Si la réponse est non pour EKS, c’est un signal d’alerte — pas un motif de renoncer à EKS, mais un chantier à budgétiser dès le démarrage, avant la facture extended support.

Dans la grande majorité des audits qu’on mène chez des PME de 10 à 100 personnes sans équipe Kubernetes dédiée, ECS + Fargate reste le point de départ le plus rentable : coût de démarrage minimal, control plane gratuit, intégration AWS native, et une charge opérationnelle compatible avec une équipe qui doit aussi livrer des fonctionnalités. EKS se justifie quand la compétence existe déjà ou que la portabilité est une exigence business réelle — pas une aspiration technique.

Conclusion

Le choix ECS vs EKS n’est pas un choix de maturité technique, contrairement à ce que laisse penser une bonne partie du contenu sur le sujet. C’est un choix économique et organisationnel : combien coûte le control plane rapporté à votre échelle, et combien coûte le temps d’équipe à maintenir un cluster Kubernetes plutôt qu’à livrer du produit. Fargate, de son côté, se décide indépendamment — c’est un arbitrage compute vs ops, pas un argument pour ou contre Kubernetes.

Si votre stack actuelle mélange déjà EC2 auto-scalé et conteneurs mal orchestrés, notre article sur ce que révèle vraiment une Well-Architected Review détaille comment ce type d’angle mort remonte en audit.

Si vous hésitez entre ECS et EKS pour un projet en cours de cadrage, c’est exactement le type d’arbitrage qu’on tranche en Audit DevSecOps — avec le calcul de coût réel sur votre charge, pas sur une charge théorique.