Elegir entre EC2, ECS y EKS para cargas de trabajo de Node.js
Compara cómo EC2, ECS con Fargate y EKS gestionan operativamente las aplicaciones Node.js, ayudándote a elegir el servicio de cómputo de AWS adecuado para la escala y las habilidades de tu equipo.
Fuentes: EC2 vs ECS vs EKS for Node.js: Which AWS Service Should You Actually Choose?
Cuando llega el momento de trasladar un backend de Node.js a Amazon Web Services, uno se enfrenta a una decisión que debe tomarse casi de inmediato. La consola de AWS le presenta al menos tres productos informáticos distintos: Amazon EC2, Amazon ECS y Amazon EKS.
Si pregunta a otros, recibirá consejos contradictorios. Algunos desarrolladores sostienen que una máquina virtual sencilla en EC2 es el camino más simple y adecuado. Otros insisten en que no hay nada mejor que ejecutar Kubernetes a través de EKS si se desea una arquitectura verdaderamente moderna. Mientras tanto, muchos equipos de plataformas de producción han estandarizado silenciosamente en ECS para toda su flota de microservicios.
Elegir la herramienta incorrecta tiende a llevarlo a uno de dos resultados frustrantes: o termina parcheando sistemas operativos y supervisando servidores manualmente, o se encuentra abrumado por archivos de configuración de Kubernetes solo para mantener activa una pequeña API Express, la cual podría atender solamente un par de docenas de solicitudes por segundo.
Esta comparación deja de lado el exceso de publicidad y analiza directamente cómo se comparan EC2, ECS y EKS para aplicaciones Node.js en particular: qué exigen cada uno de ellos a su equipo desde el punto de vista operativo, y cómo puede elegir la opción adecuada para su situación.
Explicación sencilla de los tres servicios
Antes de comparar las ventajas y desventajas, es útil definir con precisión qué es cada servicio.
+-------------------------------------------------------------------------+
| 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 le proporciona una máquina virtual, denominada “instancia”. Elige un sistema operativo; Ubuntu y Amazon Linux son opciones comunes. Inicia sesión mediante SSH, instala Node.js junto con un gestor de procesos como PM2 y lanza tu aplicación por ti mismo.
Todo, desde el kernel hacia arriba, está bajo tu control directo.
2. Amazon ECS (Elastic Container Service)
ECS es el sistema propio de AWS para orquestar contenedores Docker. En lugar de administrar directamente un sistema operativo, construyes tu aplicación Node.js en una imagen Docker e indicas a ECS que mantenga un cierto número de copias de ese contenedor en ejecución y funcionando correctamente; por ejemplo, cuatro réplicas.
Si combina ECS con AWS Fargate, su capa de cómputo sin servidores, quedará completamente exento de la tarea de gestionar los servidores subyacentes a los contenedores. AWS asigna automáticamente CPU y memoria para cada contenedor, según la demanda.
3. Amazon EKS (Elastic Kubernetes Service)
EKS ofrece clústeres Kubernetes gestionados sobre la infraestructura de AWS. Kubernetes en sí es el estándar de orquestación de contenedores de código abierto que surgió en Google.
Con EKS, AWS se hace responsable del plano de control de Kubernetes —los nodos maestros—, mientras que usted sigue siendo responsable de definir pods, despliegues, servicios, reglas de ingreso y políticas de red.
Por qué las características de Node.js son importantes aquí
Antes de decidirse por un servicio, vale la pena recordar algunos aspectos sobre cómo funciona realmente Node.js:
- La ejecución de JavaScript es single-threaded: un proceso de Node.js solo utiliza un núcleo de CPU para ejecutar su código JS. Si se coloca un proceso en una instancia EC2 de 8 núcleos, siete de esos núcleos permanecen sin usar a menos que se ejecute explícitamente un clúster de procesos o se distribuya el trabajo entre múltiples instancias.
- El inicio es rápido y el consumo de recursos es bajo: una aplicación Node.js contenerizada suele poder iniciarse y funcionar en menos de dos segundos, lo que la hace muy adecuada para entornos basados en contenedores y autoscaling.
- Las cargas de trabajo suelen estar limitadas por operaciones de E/S: la mayoría de los servicios Node.js pasan la mayor parte del tiempo esperando a bases de datos, llamadas a API externas u operaciones en disco en lugar de realizar cálculos intensivos en la CPU.
Estas características influyen directamente en cuán sencillo —o difícil— resulta escalar cada uno de los tres servicios.
1. Amazon EC2: Máximo control, mantenimiento intensivo
Trabajar con EC2 es muy similar a desarrollar en su propia máquina Linux, ya que en esencia lo es.
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
Las ventajas:
- Precio predecible: paga una tarifa horaria fija relacionada con el tamaño de instancia que elija.
- Acceso total al sistema: puede examinar los registros del sistema, ajustar parámetros del kernel mediante
sysctl, o instalar las bibliotecas nativas que necesite su aplicación.
Las desventajas:
Ejecutar una carga de trabajo en producción en EC2 implica mucho mantenimiento manual. Usted es responsable de:
- Aplicar parches de seguridad del sistema operativo.
Consejo práctico para desarrolladores: EC2 funciona bien para una aplicación monolítica que no cambia mucho. Pero cuando se ejecutan tres o cuatro microservicios, distribuirlos en instancias EC2 separadas desperdicia recursos o obliga a utilizar una configuración de servidor compartido caótica.
2. Amazon ECS: La opción ideal para la mayoría de los equipos
Si su aplicación Node.js ya se encuentra dentro de un contenedor Docker, ECS suele ser la opción más eficiente en AWS.
Escribir un Dockerfile de nivel producción para Node.js no requiere mucho tiempo:
# 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"]
Una vez que suba esa imagen a Amazon ECR (Elastic Container Registry), creará una Definición de Tarea de ECS que especifica:
- La asignación de CPU (por ejemplo,
0.5 vCPU) y memoria (por ejemplo,1 GB) para el contenedor. - Variables de entorno extraídas de AWS Secrets Manager o Parameter Store.
- Puntos finales para las verificaciones de estado.
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)
Por qué ECS con Fargate es ideal para Node.js:
Combinar ECS con Fargate elimina por completo la capa de servidor: no hay instancias EC2 subyacentes que gestionar.
Cuando el tráfico aumenta, ECS puede crear cinco tareas nuevas en cuestión de segundos. Dado que los procesos de Node.js ocupan poca memoria, es posible configurar la capacidad de cómputo en cantidades pequeñas (0.25 vCPU y 512 MB RAM), lo que mantiene la capacidad ociosa —y los costos— casi en cero.
Las compensaciones:
- Conexión obligatoria con AWS: La configuración de ECS es específica de AWS. Una definición de tarea en JSON que escribas para ECS no se transferirá a Google Cloud o Azure sin realizar modificaciones.
- Ecosistema de herramientas más limitado: ECS se integra perfectamente con CloudWatch e IAM, pero no cuenta ni de cerca con el mismo ecosistema de complementos de terceros que existe alrededor de Kubernetes.
3. Amazon EKS: Escala empresarial y portabilidad
EKS es la oferta gestionada de Kubernetes de AWS. Kubernetes va más allá de simplemente ejecutar contenedores: te proporciona una plataforma común para la red, el descubrimiento de servicios, las implementaciones progresivas y la gestión de secretos.
En EKS, tu implementación de Node.js se describe a través de manifiestos de 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
Las ventajas:
- Portabilidad real: los mismos manifiestos YAML funcionarán en EKS, GKE de Google, AKS de Azure o en servidores de su propio centro de datos.
- Ecosistema amplio: herramientas como Helm, ArgoCD, Prometheus e Istio se integran mediante una configuración estándar.
- Control preciso del autoscaling: puede escalar los pods según métricas personalizadas, como la cantidad de mensajes en una cola SQS o el tamaño del búfer de Redis, utilizando KEDA (Kubernetes Event-driven Autoscaling).
Las compensaciones:
Kubernetes también implica una carga operativa considerable:
- Costo del plano de control: EKS cobra aproximadamente $73 al mes por clúster solo para mantener activo el plano de control, independientemente de lo que gaste en nodos trabajadores y en la ejecución de contenedores.
Un error común: A veces los equipos optan por EKS simplemente porque Kubernetes es el estándar del sector. Para un equipo de ingeniería pequeño —con menos de 15 desarrolladores— mantener activo un clúster Kubernetes puede ocupar del 20 al 30 por ciento de la semana de un ingeniero senior, tiempo que de lo contrario podría destinarse al propio producto.
Una comparación directa
| Característica | Amazon EC2 | Amazon ECS (Fargate) | Amazon EKS |
|---|---|---|---|
| Nivel de abstracción | Máquinas virtuales | Contenedores | Contenedores más Pods |
| Complejidad de configuración | Baja | Baja a moderada |
Una forma práctica de decidir
En lugar de angustiarse por cada característica, utilice esta regla práctica:
Elija EC2 cuando:
- Su aplicación Node.js es antigua y depende de demonios en segundo plano locales, software específico del sistema operativo o archivos que deben permanecer en el disco local.
- Está creando un prototipo temporal en una instancia que cuesta 5 dólares al mes, donde el precio es lo único importante.
Elija ECS con Fargate cuando:
- Desea ejecutar servicios modernos de Node.js en contenedores sin tener que ocuparse personalmente del sistema operativo subyacente.
- Su equipo está formado por ingenieros de backend sin un especialista dedicado en infraestructura o DevOps.
- Tiene un compromiso total con el ecosistema de AWS (DynamoDB, SQS, RDS, IAM) y desea una integración de seguridad que funcione directamente sin configuraciones adicionales.
- Esta configuración se adapta aproximadamente al 80 por ciento de las empresas que desarrollan en AWS, lo que la convierte en la opción más razonable por defecto.
Elija EKS cuando:
- Opera docenas o cientos de microservicios en varios lenguajes, como Node.js, Go, Python y Java.
- Su organización exige un enfoque de nube múltiple o híbrida que requiere herramientas consistentes en todas partes.
- Ya cuenta con una plataforma o un equipo SRE capaz de monitorear, proteger y actualizar clústeres Kubernetes de manera segura.
Conclusión
Una buena arquitectura en la nube no se trata de elegir la tecnología más llamativa disponible; se trata de seleccionar aquello que resuelva el problema con el menor costo de mantenimiento.
En específico para Node.js:
- EC2 le brinda control total, pero le impone tareas rutinarias de mantenimiento del servidor.
- EKS le ofrece una gran potencia y la capacidad de moverse entre diferentes ecosistemas, a costa de una verdadera complejidad y sobrecarga en la gestión de clústeres.
- ECS con Fargate elimina la necesidad de gestionar servidores, escala los contenedores en cuestión de segundos y permite a los desarrolladores concentrarse en crear código sólido en Node.js.
El enfoque sensato es comenzar por lo sencillo: envuelva su aplicación en un contenedor Docker ligero, úncela primero a ECS y solo pase a Kubernetes más adelante si su organización realmente lo requiere. Dado que el contenedor en sí no cambia, ya está listo para EKS cuando llegue ese momento.