Entscheidung zwischen EC2, ECS und EKS für Node.js-Arbeitslasten
Vergleicht, wie EC2, ECS mit Fargate und EKS die Betriebstechnik von Node.js-Anwendungen handhaben, um Ihnen dabei zu helfen, den richtigen AWS-Rechenzugangsdienst für die Größe und Fähigkeiten Ihres Teams auszuwählen.
Quellen: EC2 vs ECS vs EKS for Node.js: Which AWS Service Should You Actually Choose?
Wenn es an der Zeit ist, einen Node.js-Backend auf Amazon Web Services zu verlegen, muss man fast sofort eine Entscheidung treffen. Die AWS-Konsole bietet mindestens drei verschiedene Rechenprodukte an: Amazon EC2, Amazon ECS und Amazon EKS.
Falls man nachfragt, erhält man widersprüchliche Ratschläge. Einige Entwickler sind der Ansicht, dass eine einfache virtuelle Maschine auf EC2 der einfachste und beste Weg ist. Andere beharren darauf, dass nichts Kubernetes über EKS übertreffen kann, wenn man eine wirklich moderne Architektur wünscht. In der Zwischenzeit haben viele Teams für ihre gesamte Flotte an Microservices stillschweigend ECS als Standard gewählt.
Die falsche Wahl des Tools neigt dazu, einen zu zwei frustrierenden Ergebnissen zu führen: Entweder muss man Betriebssysteme manuell reparieren und Server betreuen, oder man ist mit Kubernetes-Konfigurationsdateien überhäuft, nur um eine kleine Express-API – die vielleicht nur ein paar Dutzend Anfragen pro Sekunde verarbeiten kann – am Laufen zu halten.
Die vorliegende Vergleichsstudie lässt den Hype beiseite und betrachtet direkt, wie sich EC2, ECS und EKS insbesondere für Node.js-Anwendungen eignen: Was jede Plattform von dem Betriebsteam verlangt und wie man für die eigene Situation die richtige Option auswählen kann.
Eine einfache Erklärung der drei Dienste
Bevor man die Vor- und Nachteile vergleicht, ist es hilfreich, genau zu definieren, was jeder Dienst eigentlich ist.
+-------------------------------------------------------------------------+
| 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 stellt Ihnen eine virtuelle Maschine zur Verfügung, die als „Instance“ bezeichnet wird. Sie wählen ein Betriebssystem aus – Ubuntu und Amazon Linux sind gängige Optionen – melden sich über SSH an, installieren Node.js zusammen mit einem Prozessmanager wie PM2 und starten anschließend Ihre Anwendung selbst.
Alles vom Kernel an aufwärts steht unter Ihrer direkten Kontrolle.
2. Amazon ECS (Elastic Container Service)
ECS ist AWS eigenes System zur Orchestrierung von Docker-Containern. Anstatt direkt ein Betriebssystem zu verwalten, bauen Sie Ihre Node.js-Anwendung in ein Docker-Bild um und weisen ECS an, eine bestimmte Anzahl von Kopien dieses Containers am Laufen zu halten – zum Beispiel vier Replikate.
Falls Sie ECS mit AWS Fargate, seiner serverlosen Rechenlayer-Lösung, kombinieren, entfallen vollständig die Aufgaben zur Verwaltung der Server unter den Containern. AWS weist je nach Bedarf automatisch CPU und Speicher für jeden Container zu.
3. Amazon EKS (Elastic Kubernetes Service)
EKS bietet verwaltete Kubernetes-Cluster auf der AWS-Infrastruktur. Kubernetes selbst ist der Open-Source-Standard für die Container-Orchestrierung, der ursprünglich bei Google entstanden ist.
Mit EKS übernimmt AWS die Verantwortung für das Kubernetes-Kontrollflugzeug – also die Master-Node – während Sie weiterhin dafür verantwortlich sind, Pods, Deployments, Services, Eingangsregeln sowie Netzwerkrichtlinien zu definieren.
Warum die Eigenschaften von Node.js hier wichtig sind
Vor der Entscheidung für einen Dienst lohnt es sich, sich an ein paar Aspekten zu erinnern, wie Node.js tatsächlich läuft:
- Die Ausführung von JavaScript ist einthreadig: Ein Node.js-Prozess verwendet zur Ausführung Ihres JS-Codes stets nur einen einzigen CPU-Kern. Wenn Sie einen Prozess auf einer 8-Kern-EC2-Instanz platzieren, bleiben sieben dieser Kerne ungenutzt, es sei denn, Sie führen explizit einen Prozessclustern aus oder verteilen die Arbeit auf mehrere Instanzen.
- Der Start ist schnell und der Ressourcenverbrauch gering: Eine in Containern gehaltene Node.js-Anwendung kann in der Regel in weniger als zwei Sekunden bereitgestellt und in Betrieb genommen werden, was sie besonders für Umgebungen geeignet macht, die auf Containern und Automaskierung basieren.
- Die Arbeitslasten sind in der Regel I/O-gebunden: Die meisten Node.js-Dienste verbringen den größten Teil ihrer Zeit damit, auf Datenbanken, externe API-Aufrufe oder Festplattenvorgänge zu warten, anstatt intensive CPU-Berechnungen durchzuführen.
Diese Eigenschaften haben einen direkten Einfluss darauf, wie einfach – oder schwierig – die Skalierung in jedem der drei Dienste ist.
1. Amazon EC2: Maximale Kontrolle, umfangreiche Wartung
Die Arbeit mit EC2 erinnert stark an die Entwicklung auf dem eigenen Linux-Computer, da es im Grunde genommen derselbe ist.
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
Die Vorteile:
- Vorhersehbare Preise: Sie zahlen einen festen Stundensatz, der von der gewählten Instanzgröße abhängt.
- Vollständiger Systemzugriff: Sie können in Systemprotokolle schauen, Kernelparameter über
sysctlanpassen oder alle notwendigen native Bibliotheken installieren.
Die Kompromisse:
Der Betrieb einer Produktivumgebung auf EC2 erfordert viel manuelle Wartung. Sie sind für Folgendes verantwortlich:
- Das Anwenden von Sicherheitspatches für das Betriebssystem.
Praktischer Entwickler-Tipp: EC2 eignet sich gut für eine einzelne, monolithische Anwendung, die sich kaum ändert. Sobald Sie jedoch drei oder vier Microservices betreiben, führt die Verteilung auf separate EC2-Instanzen entweder zum Ressourcenverschwendung oder zwingt Sie zu einer unübersichtlichen Shared-Server-Einrichtung.
2. Amazon ECS: Der ideale Ansatz für die meisten Teams
Falls Ihre Node.js-Anwendung bereits in einem Docker-Container vorhanden ist, ist ECS in der Regel der effizienteste Weg auf AWS.
Die Erstellung eines für die Produktion geeigneten Node.js-Dockerfile erfordert nicht viel Aufwand:
# 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"]
Sobald Sie das Bild in Amazon ECR (Elastic Container Registry) hochgeladen haben, erstellen Sie eine ECS Task Definition, die Folgendes festlegt:
- Die CPU-Alokation (zum Beispiel
0,5 vCPU) und den Speicher (zum Beispiel1 GB) für den Container. - Umgebungsvariablen, die aus dem AWS Secrets Manager oder Parameter Store abgerufen werden.
- Health-Check-Endpunkte.
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)
Warum ECS mit Fargate für Node.js hervorragend geeignet ist:
Durch die Kombination von ECS mit Fargate entfällt die Serverebene vollständig – es müssen keine zugrunde liegenden EC2-Instanzen verwaltet werden.
Sollte die Trafficmenge plötzlich ansteigen, kann ECS innerhalb von Sekunden fünf neue Tasks starten. Da Node.js-Prozesse nur wenig Ressourcen verbrauchen, lässt sich die Rechenleistung in kleinen Schritten anpassen (0,25 vCPU und 512 MB RAM), wodurch die inaktive Kapazität – und damit auch die Kosten – nahe bei Null bleiben.
Die Kompromisse:
- AWS-Verankerung: Die ECS-Konfiguration ist spezifisch für AWS. Eine JSON-Datei mit Taskdefinitionen, die Sie für ECS erstellen, lässt sich ohne Nacharbeiten nicht auf Google Cloud oder Azure übertragen.
- Kleineres Tooling-Ökosystem: ECS integriert sich gut in CloudWatch und IAM, verfügt aber bei weitem nicht über das umfangreiche Ökosystem an Drittanbieter-Plugins, wie es sich um Kubernetes herum entwickelt hat.
3. Amazon EKS: Unternehmensgröße und Portabilität
EKS ist AWSs verwaltetes Kubernetes-Angebot. Kubernetes geht über das einfache Ausführen von Containern hinaus – es bietet eine gemeinsame Plattform für Netzwerke, Service-Entdeckung, schrittweise Bereitstellung sowie Verwaltung von Geheimnissen.
Auf EKS wird Ihre Node.js-Bereitstellung durch Kubernetes-Manifeste beschrieben:
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
Die Vorteile:
- Echte Portabilität: Die gleichen YAML-Manifeste laufen auf EKS, Google’s GKE, Azure’s AKS oder auf Servern in Ihrem eigenen Rechenzentrum.
- Weites Ökosystem: Werkzeuge wie Helm, ArgoCD, Prometheus und Istio lassen sich durch Standardkonfiguration integrieren.
- Präzise Steuerung der Automatischen Skalierung: Sie können Pods anhand von benutzerdefinierten Metriken – wie die Anzahl der Nachrichten in einer SQS-Warteschlange oder die Größe eines Redis-Puffers – mithilfe von KEDA (Kubernetes Event-driven Autoscaling) skalieren.
Die Kompromisse:
Kubernetes bringt außerdem erhebliche Betriebsbelastungen mit sich:
- Kosten für das Steuerungsplan: EKS berechnet etwa 73 US-Dollar pro Monat pro Cluster allein dafür, das Steuerungsplan am Laufen zu halten – unabhängig von den Kosten für Worker-Node und laufende Container.
Ein häufiger Fehler: Manche Teams wenden sich ausschließlich an EKS, weil Kubernetes der Branchenstandard ist. Bei einem kleinen Entwicklerteam – unter 15 Entwicklern – kann das Betreiben eines Kubernetes-Clusters 20 bis 30 Prozent der Arbeitszeit eines Senior-Entwicklers in Anspruch nehmen, Zeit, die sonst für das Produkt selbst genutzt werden könnte.
Eine direkte Vergleich
| Funktion | Amazon EC2 | Amazon ECS (Fargate) | Amazon EKS |
|---|---|---|---|
| Abstraktionsniveau | Virtuelle Maschinen | Kontainer | Kontainer plus Pods |
| Einrichtungskomplexität | Niedrig | Niedrig bis mittel |
Eine praktische Methode zur Entscheidungsfindung
Anstatt sich über jede Funktion den Kopf zu zerbrechen, wenden Sie diese einfache Faustregel an:
Wählen Sie EC2, wenn:
- Ihre Node.js-Anwendung veraltet ist und auf lokalen Hintergrunddiensten, plattformspezifischem Software oder Dateien angewiesen ist, die auf der lokalen Festplatte gespeichert bleiben müssen.
- Sie ein provisorisches Prototypenprojekt auf einer Einheit mit einem Monatspreis von 5 Dollar starten, bei dem nur der Preis eine Rolle spielt.
Wählen Sie ECS mit Fargate, wenn:
- Sie moderne, konteinerisierte Node.js-Dienste ausführen möchten, ohne sich um das zugrunde liegende Betriebssystem kümmern zu müssen.
- Ihr Team aus Backend-Entwicklern besteht und es keinen spezialisierten Infrastruktur- oder DevOps-Spezialisten gibt.
- Sie sich voll und ganz auf das AWS-Ecosystem (DynamoDB, SQS, RDS, IAM) konzentrieren und eine Sicherheitsintegration wünschen, die direkt funktionsfähig ist.
- Diese Konfiguration für etwa 80 Prozent der auf AWS arbeitenden Unternehmen geeignet ist, wodurch sie die sinnvolle Standardlösung darstellt.
Wählen Sie EKS, wenn:
- Sie Dutzende oder Hunderte von Microservices in mehreren Sprachen wie Node.js, Go, Python und Java betreiben.
- Ihre Organisation einen Multi-Cloud- oder Hybrid-Cloud-Ansatz vorschreibt, der überall konsistente Tools erfordert.
- Sie bereits eine Plattform oder ein SRE-Team haben, das in der Lage ist, Kubernetes-Cluster sicher zu überwachen, zu schützen und zu aktualisieren.
Zusammenfassung
Gute Cloud-Architektur bedeutet nicht, die auffälligste verfügbare Technologie zu wählen; es geht darum, das zu wählen, was das Problem mit dem geringsten Wartungsaufwand löst.
Insbesondere für Node.js:
- EC2 bietet Ihnen volle Kontrolle, verlangt aber regelmäßige Serverwartung.
- EKS gibt Ihnen enorme Macht und die Möglichkeit, zwischen verschiedenen Ökosystemen zu wechseln – auf Kosten von erheblicher Komplexität und zusätzlichem Aufwand bei der Clusterverwaltung.
Der sinnvolle Ansatz ist, klein anzufangen: Verpacken Sie Ihre Anwendung in einen kompakten Docker-Container, starten Sie sie zunächst auf ECS und wechseln Sie erst später zu Kubernetes, falls Ihre Organisation wirklich darüber hinauswächst. Da sich der Container selbst nicht ändert, ist er bereits für EKS bereit, sobald dieser Tag anbricht.