Choisir entre EC2, ECS et EKS pour les charges de travail Node.js
Compare la manière dont EC2, ECS avec Fargate et EKS gèrent opérationnellement les applications Node.js, vous aidant à choisir le service de calcul AWS adapté à l’échelle et aux compétences de votre équipe.
Sources: EC2 vs ECS vs EKS for Node.js: Which AWS Service Should You Actually Choose?
Lorsqu’il est temps de déplacer un backend Node.js sur Amazon Web Services, vous devez prendre une décision presque immédiatement. La console AWS vous propose au moins trois produits de calcul distincts : Amazon EC2, Amazon ECS et Amazon EKS.
Si vous demandez autour de vous, vous recevrez des conseils contradictoires. Certains développeurs affirment qu’une simple machine virtuelle sur EC2 constitue la solution la plus simple et la meilleure. D’autres insistent sur le fait qu’il n’y a rien de mieux que d’exécuter Kubernetes via EKS si l’on souhaite une architecture véritablement moderne. Entre-temps, de nombreuses équipes chargées des plateformes de production ont silencieusement standardisé leur ensemble de microservices sur ECS.
Choisir l’outil inadapté vous conduit généralement à l’un de deux résultats frustrants : soit vous finissez par corriger manuellement les systèmes d’exploitation et gérer les serveurs comme des bébés, soit vous vous retrouvez submergé par des fichiers de configuration Kubernetes rien que pour maintenir en fonction une petite API Express – celle qui ne traite peut-être que quelques dizaines de requêtes par seconde.
Cette comparaison met de côté le bruit médiatique et examine directement comment EC2, ECS et EKS se comparent pour les applications Node.js en particulier : quelles exigences chacun pose à votre équipe sur le plan opérationnel, et comment choisir la bonne option pour votre situation.
Les trois services expliqués simplement
+-------------------------------------------------------------------------+
| Amazon EKS |
| Fully managed Kubernetes. High control, high complexity, multi-cloud. |
+-------------------------------------------------------------------------+
▲
│ Built for complex orchestration
+-------------------------------------------------------------------------+
| Amazon ECS |
| AWS-native container orchestration. Fast, simple, deeply integrated. |
+-------------------------------------------------------------------------+
▲
│ Built for containers
+-------------------------------------------------------------------------+
| Amazon EC2 |
| Raw virtual machines in the cloud. Full OS access, manual maintenance.|
+-------------------------------------------------------------------------+
1. Amazon EC2 (Elastic Compute Cloud)
EC2 vous met à disposition une machine virtuelle, appelée « instance ». Vous choisissez un système d’exploitation — Ubuntu et Amazon Linux sont des options courantes — vous connectez-vous via SSH, vous installez Node.js ainsi qu’un gestionnaire de processus comme PM2, puis vous lancez votre application vous-même.
Tout, depuis le noyau jusqu’aux logiciels supérieurs, est sous votre contrôle direct.
2. Amazon ECS (Elastic Container Service)
ECS est le système développé par AWS pour orchestrer des conteneurs Docker. Au lieu d’administrer directement un système d’exploitation, vous créez votre application Node.js en image Docker et vous indiquez à ECS de maintenir un certain nombre de copies de ce conteneur en cours d’exécution et en bon état — disons, quatre réplicas.
Si vous combinez ECS avec AWS Fargate, sa couche de calcul sans serveur, vous êtes complètement libéré de la gestion des serveurs qui se trouvent en dessous des conteneurs. AWS alloue automatiquement la CPU et la mémoire à chaque conteneur en fonction de la demande.
3. Amazon EKS (Elastic Kubernetes Service)
EKS propose des clusters Kubernetes gérés sur l’infrastructure d’AWS. Kubernetes est lui-même la norme open source d’orchestration de conteneurs née chez Google.
Avec EKS, AWS prend en charge le plan de contrôle de Kubernetes — les nœuds maîtres — tandis que vous restez responsable de la définition des pods, des déploiements, des services, des règles d’ingress et des politiques réseau.
Pourquoi les caractéristiques de Node.js sont importantes ici
- L’exécution de JavaScript est en thread unique : un processus Node.js n’utilise qu’un seul cœur CPU pour exécuter votre code JavaScript. En plaçant un processus sur une instance EC2 à 8 cœurs, sept de ces cœurs restent inutilisés sauf si vous exécutez explicitement un cluster de processus ou répartissez le travail sur plusieurs instances.
- Démarrage rapide et empreinte faible : une application Node.js containerisée peut généralement être lancée en moins de deux secondes, ce qui la rend particulièrement adaptée aux environnements basés sur les conteneurs et l’auto-échellement.
- Les charges de travail sont souvent gourmandes en I/O : la plupart des services Node.js passent la majeure partie de leur temps à attendre des bases de données, des appels API externes ou des opérations disque plutôt qu’à effectuer des calculs intensifs sur le CPU.
Ces caractéristiques influencent directement le degré de simplicité — ou de difficulté — avec lequel l’escalade des ressources s’avère dans chacun des trois services.
1. Amazon EC2 : Contrôle maximal, maintenance intensive
Travailler avec EC2 ressemble beaucoup au développement sur sa propre machine Linux, car c’en est essentiellement une.
Bash
# Typical manual setup on an EC2 instance:
sudo apt update && sudo apt install -y nodejs npm
git clone https://github.com/your-org/api.git
cd api && npm ci --omit=dev
npm install -g pm2
pm2 start app.js -i max
Traffic ──> Application Load Balancer (ALB)
│
┌────────┴────────┐
▼ ▼
[EC2 Instance] [EC2 Instance]
├─ Node Process ├─ Node Process
├─ Node Process ├─ Node Process
└─ PM2 Manager └─ PM2 Manager
Les avantages :
- Prix prévisibles : vous payez un tarif horaire fixe lié à la taille de l’instance que vous choisissez.
- Accès complet au système : vous pouvez examiner les journaux du système, ajuster les paramètres du noyau via
sysctl, ou installer toutes les bibliothèques natives nécessaires à votre application.
Les inconvénients :
Exécuter des charges de travail en production sur EC2 implique une maintenance importante. Vous êtes responsable de :
- Appliquer les correctifs de sécurité du système d’exploitation.
Conseil pratique pour les développeurs : EC2 convient bien à une application monolithique qui ne change pas souvent. Mais lorsque vous exécutez trois ou quatre microservices, les répartir sur des instances EC2 distinctes gaspille des ressources ou vous oblige à utiliser une configuration de serveur partagé encombrée.
2. Amazon ECS : Le choix idéal pour la plupart des équipes
Si votre application Node.js est déjà contenue dans un conteneur Docker, ECS représente généralement la solution la plus efficace sur AWS.
Rédiger un Dockerfile de qualité pour production ne prend pas beaucoup de temps :
# Multi-stage Dockerfile for Node.js
FROM node:20-alpine AS builder
WORKDIR /app
COPY package*.json ./
RUN npm ci
FROM node:20-alpine
WORKDIR /app
ENV NODE_ENV=production
COPY package*.json ./
RUN npm ci --omit=dev
COPY . .
USER node
EXPOSE 3000
CMD ["node", "server.js"]
Lorsque vous téléversez cette image sur Amazon ECR (Elastic Container Registry), vous créez une Definition de tâche ECS qui spécifie :
- L’allocation de CPU (par exemple,
0,5 vCPU) et de mémoire (par exemple,1 GB) pour le conteneur. - Les variables d’environnement extraites de AWS Secrets Manager ou Parameter Store.
- Les points d’arrêt de vérification de santé.
Traffic ──> ALB
│
├── Path /api/users ──> [ECS Task: Users] (0.5 vCPU)
└── Path /api/orders ─> [ECS Task: Orders] (0.5 vCPU)
[ECS Task: Orders] (0.5 vCPU)
Pourquoi ECS avec Fargate est idéal pour Node.js :
La combinaison de ECS avec Fargate élimine complètement la couche serveur — il n’y a pas d’instances EC2 à gérer.
Lorsque le trafic augmente, ECS peut lancer cinq nouvelles tâches en quelques secondes. Comme les processus Node.js consomment peu de ressources, vous pouvez ajuster la puissance de calcul en petites unités (0,25 vCPU et 512 MB de RAM), ce qui maintient la capacité inutilisée — ainsi que les coûts — proches de zéro.
Les compromis :
- Verrouillage par AWS : La configuration d’ECS est spécifique à AWS. Une définition de tâche en JSON que vous écrivez pour ECS ne pourra pas être transférée vers Google Cloud ou Azure sans modification.
- Écosystème d’outils plus limité : ECS s’intègre bien à CloudWatch et IAM, mais il ne dispose pas de l’écosystème de plugins tiers qui a vu le jour autour de Kubernetes.
3. Amazon EKS : Échelle d’entreprise et portabilité
EKS est l’offre gérée de Kubernetes d’AWS. Kubernetes va au-delà du simple exécution de conteneurs — il vous fournit une plateforme commune pour le réseau, la découverte de services, les déploiements itératifs et la gestion des secrets.
Avec EKS, votre déploiement Node.js est décrit à l’aide de fichiers manifests Kubernetes :
apiVersion: apps/v1
kind: Deployment
metadata:
name: node-api
spec:
replicas: 3
selector:
matchLabels:
app: node-api
template:
metadata:
labels:
app: node-api
spec:
containers:
- name: node-api
image: 123456789012.dkr.ecr.us-east-1.amazonaws.com/node-api:v1.2.0
resources:
limits:
cpu: "500m"
memory: "512Mi"
requests:
cpu: "250m"
memory: "256Mi"
ports:
- containerPort: 3000
Les avantages :
- Portabilité réelle : les mêmes fichiers YAML fonctionnent sur EKS, GKE de Google, AKS d’Azure ou sur des serveurs dans votre propre centre de données.
- Écosystème étendu : des outils tels que Helm, ArgoCD, Prometheus et Istio s’intègrent grâce à une configuration standard.
- Contrôle précis de l’auto-échellement : vous pouvez ajuster l’échelle des pods en fonction de métriques personnalisées — comme le nombre de messages dans une file SQS ou la taille d’un buffer Redis — en utilisant KEDA (Kubernetes Event-driven Autoscaling).
Les compromis :
Kubernetes entraîne également des coûts opérationnels importants :
- Costs du plan de contrôle : EKS facture environ 73 dollars par mois par cluster rien que pour maintenir le plan de contrôle actif, en plus des dépenses liées aux nœuds travailleurs et à l’exécution des conteneurs.
Une erreur courante : Les équipes recourent parfois à EKS simplement parce que Kubernetes est la norme du secteur. Pour une petite équipe d’ingénieurs — composée de moins de 15 développeurs — faire fonctionner un cluster Kubernetes peut absorber de 20 à 30 pour cent de la semaine d’un ingénieur senior, un temps qui pourrait être consacré au produit lui-même.
Une comparaison directe
| Fonctionnalité | Amazon EC2 | Amazon ECS (Fargate) | Amazon EKS |
|---|---|---|---|
| Niveau d’abstraction | Machines virtuelles | Conteneurs | Conteneurs plus Pods |
| Complexité de mise en place | Basse | Basse à modérée |
Une méthode pratique pour décider
Au lieu de vous tourmenter à propos de chaque fonctionnalité, utilisez cette règle simple :
Sélectionnez EC2 lorsque :
- Votre application Node.js est ancienne et dépend de daemons en arrière-plan locaux, de logiciels spécifiques au système d’exploitation ou de fichiers qui doivent persister sur le disque local.
- Vous créez un prototype temporaire sur une machine coûtant 5 dollars par mois où le prix est la seule chose qui compte.
Sélectionnez ECS avec Fargate lorsque :
- Vous souhaitez exécuter des services Node.js modernes et conteneurisés sans avoir à gérer le système d’exploitation sous-jacent.
- Votre équipe est composée d’ingénieurs backend sans spécialiste dédié en infrastructure ou DevOps.
- Vous êtes entièrement engagé dans l’écosystème AWS (DynamoDB, SQS, RDS, IAM) et souhaitez une intégration de sécurité prête à l’emploi.
- Cette configuration convient à environ 80 pour cent des entreprises utilisant AWS, ce qui en fait le choix par défaut logique.
Choisissez EKS lorsque :
- Vous gérez des dizaines ou des centaines de microservices utilisant plusieurs langages, tels que Node.js, Go, Python et Java.
- Votre organisation exige une approche multi-cloud ou hybride qui nécessite des outils cohérents partout.
- Vous disposez déjà d’une plateforme ou d’une équipe SRE capable de surveiller, sécuriser et mettre à jour des clusters Kubernetes en toute sécurité.
En résumé
Une bonne architecture cloud ne consiste pas à choisir la technologie la plus sophistiquée disponible ; il s’agit plutôt de sélectionner ce qui résout le problème avec le moindre coût en termes de maintenance.
Spécifiquement pour Node.js :
- EC2 vous offre un contrôle total, mais vous impose des tâches de maintenance régulières du serveur.
- EKS vous donne un pouvoir considérable ainsi que la capacité de passer d’un écosystème à un autre, au prix d’une complexité réelle et d’une charge supplémentaire pour la gestion des clusters.
- ECS avec Fargate vous décharge des serveurs, permet d’échaler les conteneurs en quelques secondes et libère les développeurs pour qu’ils se concentrent sur la création de code Node.js fiable.
La démarche la plus judicieuse consiste à commencer petit : enveloppez votre application dans un conteneur Docker léger, lancez-la d’abord sur ECS, et n’optez pour Kubernetes que si votre organisation en a réellement besoin. Comme le conteneur lui-même ne change pas, il est déjà prêt pour EKS lorsque ce jour arrivera.