AWS Fargate 101: Wenn deine Container keinen Babysitter brauchen

Erinnerst du dich an den Moment, als du festgestellt hast, dass du mehr Zeit mit der Verwaltung von EC2-Instanzen verbringst als mit der Entwicklung von Features? Ja, ich auch. Es war 3 Uhr morgens, ich war per SSH in einen Production-Server eingeloggt und versuchte herauszufinden, warum der Speicherplatz bei 98% lag, und plötzlich wurde mir klar, dass ich ein sehr teurer Babysitter für Linux-Boxen geworden war.

Da begann AWS Fargate wirklich attraktiv auszusehen.

Was Fargate wirklich ist (ohne das Marketing-Geschwätz)#

Stell dir Fargate als den "Ich will nur meine Container laufen lassen"-Button vor. Du gibst AWS dein Docker-Image, sagst wie viel CPU und Memory du brauchst, und es kümmert sich um alles andere. Keine EC2-Instanzen zum Patchen, keine Cluster-Kapazität zum Verwalten, keine Mitternachts-Anrufe weil einem Host der Speicherplatz ausgegangen ist.

Hier ist das mentale Modell, das es für mich endlich klar gemacht hat: Wenn EC2 wie ein Auto besitzen ist (Ölwechsel, Reifenrotation, dieses komische Geräusch das es macht), ist Fargate wie ein Uber rufen. Du gibst an, wohin du willst (diesen Container ausführen), und jemand anders kümmert sich um die Fahrzeugwartung.

Die Architektur (Oder: Wie die Magie passiert)#

Die Schönheit liegt in dem, was du nicht siehst. Jede Fargate-Task läuft in ihrer eigenen isolierten Umgebung mit eigenem Kernel, CPU-Ressourcen, Memory und Network Interface. Es ist wie eine dedizierte Micro-VM für jeden Container zu haben, aber ohne den Overhead von VM-Verwaltung.

Dein erstes Fargate Deployment (Der echte Weg)#

Lass mich dir zeigen, wie du tatsächlich etwas auf Fargate deployst. Wir verwenden ECS, weil es ehrlich gesagt einfacher als EKS für den Einstieg ist, und du brauchst wahrscheinlich kein Kubernetes, es sei denn du weißt, dass du Kubernetes brauchst.

Zuerst erstellen wir eine Task Definition. Das sagt AWS im Grunde "das braucht mein Container zum Laufen":

{
  "family": "my-app",
  "networkMode": "awsvpc",
  "requiresCompatibilities": ["FARGATE"],
  "cpu": "256",
  "memory": "512",
  "containerDefinitions": [
    {
      "name": "my-app",
      "image": "nginx:latest",
      "portMappings": [
        {
          "containerPort": 80,
          "protocol": "tcp"
        }
      ],
      "logConfiguration": {
        "logDriver": "awslogs",
        "options": {
          "awslogs-group": "/ecs/my-app",
          "awslogs-region": "us-east-1",
          "awslogs-stream-prefix": "ecs"
        }
      }
    }
  ]
}

Jetzt, hier machen Leute normalerweise Fehler: die CPU und Memory Werte. Die sind nicht willkürlich. Fargate hat spezifische Kombinationen die es unterstützt:

Wähle falsch, und AWS wird dir höflich sagen, es nochmal zu versuchen. Ich hab das auf die harte Tour gelernt, nachdem ich eine Task Definition von EC2 kopiert hatte und mich wunderte, warum sie nicht starten wollte.

Der Networking-Tanz#

Fargate unterstützt nur den awsvpc Network Mode, was bedeutet, dass jede Task ihr eigenes Elastic Network Interface (ENI) mit einer privaten IP bekommt. Das ist eigentlich super für Security, aber es bedeutet, dass du über dein VPC-Design nachdenken musst.

Hier ist ein funktionierendes Beispiel mit Terraform (weil durch die Console klicken schnell langweilig wird):

resource "aws_ecs_service" "my_app" {
  name            = "my-app-service"
  cluster         = aws_ecs_cluster.main.id
  task_definition = aws_ecs_task_definition.my_app.arn
  desired_count   = 2
  launch_type     = "FARGATE"

  network_configuration {
    subnets          = aws_subnet.private[*].id
    security_groups  = [aws_security_group.ecs_tasks.id]
    assign_public_ip = false
  }

  load_balancer {
    target_group_arn = aws_lb_target_group.my_app.arn
    container_name   = "my-app"
    container_port   = 80
  }
}

# Wichtig: Fargate braucht 'ip' target type, nicht 'instance'
resource "aws_lb_target_group" "my_app" {
  name        = "my-app-tg"
  port        = 80
  protocol    = "HTTP"
  vpc_id      = aws_vpc.main.id
  target_type = "ip"  # <-- Das ist entscheidend für Fargate
  
  health_check {
    enabled             = true
    healthy_threshold   = 2
    unhealthy_threshold = 2
    timeout             = 5
    interval            = 30
    path                = "/health"
    matcher             = "200"
  }
}

Wann Fargate Sinn macht (und wann nicht)#

Nach dem Betrieb von Workloads auf sowohl Fargate als auch EC2, hier meine ehrliche Einschätzung:

Verwende Fargate wenn:#

• Du unvorhersehbare oder spitze Workloads hast
• Dein Team klein ist und du dich lieber auf Code als auf Infrastruktur konzentrieren willst
• Du viele kleine, isolierte Services betreibst
• Compliance Workload-Isolation erfordert
• Du bereits "in Containern denkst"

Bleib bei EC2 wenn:#

• Du GPU-Instanzen brauchst (Fargate unterstützt sie nicht)
• Du Windows Container mit spezifischen Anforderungen betreibst
• Kosten deine Hauptsorge sind und du vorhersehbare, hohe Auslastung hast
• Du privilegierte Container ausführen oder Kernel-Module installieren musst
• Du Spot-Instanzen für erhebliche Einsparungen nutzen willst

Der Kosten-Reality-Check#

Lass uns ehrlich über die Preise sein. Fargate kostet mehr pro Compute-Einheit als EC2. Ich hab die Zahlen für einen unserer Services durchgerechnet:

# EC2 (t3.medium, 2 vCPU, 4GB RAM)
Monatlich: ~$30 (On-Demand)
Monatlich: ~$19 (Reserved Instance)

# Fargate (2 vCPU, 4GB RAM)
Monatlich: ~$72 (24/7 Nutzung)
Monatlich: ~$50 (mit Savings Plans)

Aber hier ist was diese Zahlen nicht zeigen:

• Keine Zeit für OS-Updates verschwendet
• Keine Cluster-Kapazitätsplanung
• Keine Auto-Scaling-Group-Konfiguration
• Kein Instance-Health-Monitoring
• Keine "Oh Mist, uns ist die Cluster-Kapazität ausgegangen"-Vorfälle

Für uns waren die extra $30-40 pro Monat es wert, unsere Wochenenden zurückzubekommen.

Die Fallstricke über die niemand spricht#

1. Cold Starts sind real: Der erste Task-Start in einer neuen Availability Zone kann 30-60 Sekunden dauern. Plan entsprechend.

2. ENI-Limits: Jede Fargate-Task braucht ein ENI. Triff dein VPC's ENI-Limit, und Tasks starten nicht. Frag mich nicht woher ich das weiß.

3. Kein SSH-Zugriff: Du kannst nicht per SSH in Fargate Container. Verwende ECS Exec für Debugging:

   Bash

   aws ecs execute-command \
     --cluster my-cluster \
     --task abc123 \
     --container my-app \
     --interactive \
     --command "/bin/sh"
   

4. Nur ephemerer Storage: Tasks bekommen 20GB ephemeren Storage. Brauchst du mehr? Verwende EFS, aber erwarte langsamere I/O.

5. Platform Versionen: Fargate hat Platform-Versionen (1.4.0, 1.3.0, etc.). AWS aktualisiert diese automatisch, was normalerweise ok ist, aber gelegentlich Dinge kaputt macht. Teste immer zuerst in Staging.

Ein echtes Production Setup#

Hier ist ein Pattern, das uns gut in Production gedient hat:

Die wichtigsten Erkenntnisse aus dem Production-Betrieb:

1. Verwende ALB für Load Balancing - Es integriert sich nahtlos mit Fargates IP-basierten Targets
2. Platziere Fargate Tasks in privaten Subnets - Verwende NAT Gateways für ausgehenden Internet-Verkehr
3. Verwende Parameter Store oder Secrets Manager - Backe keine Secrets in Images ein
4. Richte ordentliches Logging ein - CloudWatch Logs ist ok zum Starten, aber erwäge Datadog oder ähnliches für Production
5. Überwache ENI-Allokation - Es ist die Ressource, die dir zuerst ausgehen wird

Das Fazit#

Fargate ist keine Magie, und es ist nicht richtig für jede Workload. Aber für Teams, die Container laufen lassen wollen ohne Infrastruktur-Experten zu werden, ist es eine solide Wahl. Ja, du zahlst mehr als EC2, aber du schläfst auch besser.

Meine Faustregel: Fang mit Fargate an. Wenn deine AWS-Rechnung schmerzhaft genug wird, dass die Optimierung der Infrastrukturkosten geschäftlich Sinn macht, hast du genug Scale um die Engineering-Zeit für ordentliches EC2-Instance-Management zu rechtfertigen.

Mögen deine Container stateless und deine Bereitschaftsdienste ruhig sein.