Kenapa Gue Pilih ECS Fargate, Bukan Kubernetes

Setiap kali mulai project baru yang butuh container orchestration, pertanyaan ini pasti muncul: “Pakai Kubernetes atau ECS?” Dan jawaban gue hampir selalu ECS Fargate — paling enggak buat kondisi tertentu.

Bukan berarti K8s jelek. Gue pakai K8s juga di beberapa project. Tapi buat mayoritas project yang gue handle (tim kecil, fully AWS, 3-8 services), Fargate hampir selalu lebih masuk akal.

Konteks: Project yang gimana?

Supaya fair, ini konteks project yang biasa gue handle:

• Tim: 1-5 backend engineers
• Cloud provider: AWS (100%)
• Services: 3-8 microservices
• Traffic: moderate (ratusan hingga ribuan RPS)
• Budget: terbatas — startup atau SMB

Kalau konteks lo beda (multi-cloud, 50+ services, dedicated platform team), kesimpulan di artikel ini mungkin gak relevan.

Masalah Kubernetes buat Tim Kecil

Kubernetes itu brilliant dari sisi design. Tapi operational burden-nya real:

Cluster maintenance. EKS managed memang ngurangin beban, tapi lo tetep perlu handle node groups, AMI updates, dan capacity planning. Fargate? Zero. Literally gak ada infra yang lo maintain.

Networking complexity. Service mesh, ingress controllers, network policies - semua ini powerful tapi butuh waktu buat setup dan debug. Di ECS, ALB + service discovery sudah cukup buat kebanyakan use case.

Learning curve. Onboarding engineer baru ke K8s environment butuh waktu. Kubectl, helm charts, kustomize, RBAC - stack knowledge yang harus dikuasai sebelum bisa produktif.

Upgrade cycles. K8s release baru setiap 4 bulan. Skip 2 versi dan lo bakal punya technical debt yang menyakitkan.

Kenapa Fargate Works

# Task definition — sesimpel ini
resource "aws_ecs_task_definition" "api" {
  family                   = "my-api"
  requires_compatibilities = ["FARGATE"]
  network_mode             = "awsvpc"
  cpu                      = 256
  memory                   = 512

  container_definitions = jsonencode([{
    name  = "api"
    image = "${aws_ecr_repository.api.repository_url}:latest"
    portMappings = [{
      containerPort = 8080
      protocol      = "tcp"
    }]
  }])
}

Yang gue suka dari Fargate:

1. Gak ada nodes. Push image, define resources, run. Selesai.
2. Auto-scaling straightforward. Target tracking policy based on CPU/memory/custom metric.
3. Security posture lebih simpel. Setiap task punya ENI sendiri, IAM role per-task, no shared kernel antar tenant.
4. Billing granular. Pay per-second untuk resources yang actual dipakai. Gak ada idle nodes yang burning money.

Tapi Fargate Bukan Tanpa Kekurangan

Gue gak akan pretend Fargate sempurna:

• Cold start. Task baru butuh 30-60 detik buat ready. Kalau butuh ultra-fast scaling, ini bisa jadi issue.
• Cost per-vCPU lebih tinggi. Dibanding EC2 atau self-managed nodes, Fargate memang premium. Untuk workload yang consistently high-utilization, bisa 20-40% lebih mahal.
• Less flexibility. Gak bisa pasang DaemonSets, custom CNI plugins, atau GPU scheduling yang complex.
• Vendor lock-in. Ya, ini AWS-only. Kalau suatu saat mau pindah cloud, migration effort lebih besar.

Decision Framework

Ini rule of thumb yang gue pakai:

Kondisi	Pilihan
Tim < 5, fully AWS	ECS Fargate
Butuh multi-cloud atau hybrid	Kubernetes (EKS/GKE)
10+ services, dedicated platform team	Kubernetes
Startup early-stage, speed matters	ECS Fargate
Butuh custom operators/CRDs	Kubernetes
Cost-sensitive, consistent high load	ECS on EC2 atau K8s on Spot

Setup Minimal yang Production-Ready

Kalo lo mau start pake Fargate, ini minimum yang gue selalu setup:

# Service dengan auto-scaling
resource "aws_ecs_service" "api" {
  name            = "api-service"
  cluster         = aws_ecs_cluster.main.id
  task_definition = aws_ecs_task_definition.api.arn
  desired_count   = 2
  launch_type     = "FARGATE"

  network_configuration {
    subnets          = var.private_subnets
    security_groups  = [aws_security_group.ecs_tasks.id]
    assign_public_ip = false
  }

  load_balancer {
    target_group_arn = aws_lb_target_group.api.arn
    container_name   = "api"
    container_port   = 8080
  }
}

# Auto-scaling
resource "aws_appautoscaling_target" "api" {
  max_capacity       = 10
  min_capacity       = 2
  resource_id        = "service/${aws_ecs_cluster.main.name}/${aws_ecs_service.api.name}"
  scalable_dimension = "ecs:service:DesiredCount"
  service_namespace  = "ecs"
}

resource "aws_appautoscaling_policy" "api_cpu" {
  name               = "cpu-auto-scaling"
  policy_type        = "TargetTrackingScaling"
  resource_id        = aws_appautoscaling_target.api.resource_id
  scalable_dimension = aws_appautoscaling_target.api.scalable_dimension
  service_namespace  = aws_appautoscaling_target.api.service_namespace

  target_tracking_scaling_policy_configuration {
    predefined_metric_specification {
      predefined_metric_type = "ECSServiceAverageCPUUtilization"
    }
    target_value = 70.0
  }
}

Dengan config ini lo udah punya: load-balanced service, private networking, dan auto-scaling based on CPU. Gak perlu helm install apapun.

Kesimpulan

Pilihan antara ECS Fargate dan Kubernetes bukan soal mana yang “lebih bagus” — tapi mana yang cocok buat konteks lo sekarang. Untuk kebanyakan project yang gue handle, Fargate menang di simplicity dan speed to production.

Tapi gue juga realistis: kalau suatu saat project grow ke titik di mana Fargate jadi bottleneck (cost, flexibility, multi-cloud needs), migrasi ke K8s bukan hal yang impossible. Yang penting jangan over-engineer dari awal.