07 Januari 2026 14 min read Architecture

EC2, ASG, EKS, dan Fargate: Panduan Lengkap Menentukan Arsitektur Compute di AWS

Memilih layanan compute di AWS bukan sekadar memilih “yang paling baru” atau “yang paling populer.” Setiap layanan lahir dari kebutuhan yang berbeda, dan memilih yang salah bisa berarti over-engineering sistem sederhana atau under-engineering sistem kritis. Empat layanan yang paling sering membingungkan — EC2, Auto Scaling Group, EKS, dan Fargate — masing-masing punya filosofi, trade-off, dan sweet spot yang sangat berbeda. Artikel ini membedah keempatnya secara mendalam agar kamu bisa mengambil keputusan arsitektur dengan percaya diri.

Gambaran Besar — Empat Level Abstraksi

Sebelum masuk ke detail masing-masing layanan, penting untuk memahami bahwa keempat layanan ini bukan pilihan yang setara. Mereka berada di level abstraksi yang berbeda, dan masing-masing menukar kontrol dengan kemudahan operasional.

%%{init: {'flowchart': {'padding': 20}} }%%
graph TB
    subgraph "Level Abstraksi AWS Compute"
        direction TB
        A["EC2<br/>Virtual Machine Langsung<br/>Kontrol penuh, kelola semuanya"]
        B["Auto Scaling Group<br/>EC2 + Autoscaling Controller<br/>Horizontal scaling otomatis"]
        C["EKS<br/>Managed Kubernetes<br/>Orkestrasi container standar industri"]
        D["Fargate<br/>Serverless Container<br/>Tanpa kelola server sama sekali"]
    end

    A -->|"+ autoscaling"| B
    B -->|"+ container orchestration"| C
    C -->|"- node management"| D

    style A fill:#fef3c7,stroke:#d97706,color:#000
    style B fill:#fde68a,stroke:#d97706,color:#000
    style C fill:#bfdbfe,stroke:#2563eb,color:#000
    style D fill:#bbf7d0,stroke:#16a34a,color:#000

Prinsip dasarnya sederhana: semakin tinggi level abstraksi, semakin kecil beban operasional — tetapi semakin besar biaya per unit dan semakin terbatas kontrol yang kamu miliki.

Amazon EC2 — Virtual Machine Klasik

EC2 adalah fondasi compute di AWS. Layanan ini memberikan kamu virtual machine dengan spesifikasi yang bisa dipilih sendiri — CPU, RAM, disk, OS — lalu kamu bebas menggunakannya seperti server fisik. SSH langsung, install apa saja, konfigurasi sesuka hati.

Mengapa EC2 Masih Relevan

Di era container dan serverless, EC2 terasa “kuno.” Tapi justru karena levelnya paling rendah, EC2 menjadi pilihan yang tepat ketika kamu membutuhkan kontrol penuh. Aplikasi legacy yang tidak bisa di-containerize, workload yang membutuhkan akses langsung ke hardware (GPU computing, high-performance networking), atau sistem yang bergantung pada konfigurasi OS spesifik — semua ini lebih cocok di EC2.

Karakteristik dan Trade-off

Kelebihan	Kekurangan
✅ Kontrol penuh atas OS dan konfigurasi	❌ Scaling manual tanpa ASG
✅ Cocok untuk aplikasi legacy dan monolit	❌ Tanggung jawab penuh: patching, security, availability
✅ Paling fleksibel — bisa install apa saja	❌ Single point of failure jika hanya satu instance
✅ Mudah dipahami untuk engineer level apapun	❌ Provisioning lambat dibanding container
✅ Billing per detik — efisien untuk workload stabil	❌ Tidak otomatis high-availability

Kapan EC2 Tepat Digunakan

EC2 cocok saat kamu menghadapi skenario berikut: aplikasi monolit yang belum di-refactor, workload stateful yang menyimpan data lokal, sistem yang butuh kernel module atau driver khusus, dan eksperimen atau learning environment di mana simplisitas lebih penting daripada skalabilitas.

Anti-Pattern EC2

Kesalahan paling umum dengan EC2 adalah menjalankan single instance untuk production tanpa redundansi. Satu instance berarti satu titik kegagalan — jika instance mati karena hardware failure (yang di cloud bukan masalah “apakah” tapi “kapan”), seluruh sistem ikut mati.

graph LR
    subgraph "❌ Anti-Pattern: Single EC2"
        U1["User"] --> EC1["EC2<br/>(single instance)"] --> DB1["Database"]
    end

    style EC1 fill:#fecaca,stroke:#dc2626,color:#000
    style U1 fill:#f5f5f4,stroke:#78716c,color:#000
    style DB1 fill:#e0e7ff,stroke:#4f46e5,color:#000

graph LR
    subgraph "✅ Benar: Multi-AZ + Load Balancer"
        U2["User"] --> ALB["ALB"] --> EC2a["EC2-a<br/>AZ-1"]
        ALB --> EC2b["EC2-b<br/>AZ-2"]
        EC2a --> DB2["Database"]
        EC2b --> DB2
    end

    style ALB fill:#bbf7d0,stroke:#16a34a,color:#000
    style EC2a fill:#bfdbfe,stroke:#2563eb,color:#000
    style EC2b fill:#bfdbfe,stroke:#2563eb,color:#000
    style U2 fill:#f5f5f4,stroke:#78716c,color:#000
    style DB2 fill:#e0e7ff,stroke:#4f46e5,color:#000

Best Practice EC2

Gunakan IAM Role yang di-attach ke instance, bukan access key yang disimpan di disk.
Simpan konfigurasi di SSM Parameter Store atau Secrets Manager, bukan hardcode di AMI.
Buat AMI custom untuk konsistensi deployment — setiap instance baru harus identik.
Aktifkan CloudWatch agent untuk monitoring CPU, memory, dan disk sejak hari pertama.

Auto Scaling Group — EC2 yang Bisa Bernafas

ASG bukan layanan compute baru. ASG adalah controller yang mengelola sekumpulan EC2 secara otomatis — menambah instance saat traffic naik, mengurangi saat sepi, dan mengganti instance yang mati. Jika EC2 adalah mobil, ASG adalah sistem cruise control-nya.

Cara Kerja ASG

ASG bekerja berdasarkan tiga parameter: minimum (jumlah instance terendah yang selalu hidup), desired (jumlah instance yang diinginkan saat ini), dan maximum (batas atas scaling). Scaling policy menentukan kapan desired berubah — bisa berdasarkan CPU utilization, request count, custom metric, atau jadwal.

graph LR
    CW["CloudWatch Alarm<br/>'CPU > 70% selama 5 menit'"]
    ASG["Auto Scaling Group<br/>min: 2 | desired: 2 | max: 8"]
    LT["Launch Template<br/>t3.medium, AMI-xxx"]

    CW -->|"trigger scale-out"| ASG
    ASG -->|"launch instance baru dari"| LT

    ASG --> EC2a["EC2 Instance 1<br/>AZ-1"]
    ASG --> EC2b["EC2 Instance 2<br/>AZ-2"]
    ASG -.->|"instance baru"| EC2c["EC2 Instance 3<br/>AZ-1"]

    ALB["Application<br/>Load Balancer"] --> EC2a
    ALB --> EC2b
    ALB -.-> EC2c

    style CW fill:#fef3c7,stroke:#d97706,color:#000
    style ASG fill:#bfdbfe,stroke:#2563eb,color:#000
    style LT fill:#e0e7ff,stroke:#4f46e5,color:#000

Karakteristik dan Trade-off

Kelebihan	Kekurangan
✅ High availability otomatis — instance mati langsung diganti	❌ Tetap harus mengelola OS dan patching
✅ Horizontal scaling berbasis metric	❌ Scaling relatif lambat (1-5 menit per instance baru)
✅ Terintegrasi native dengan ALB/NLB	❌ Tidak cocok untuk burst traffic yang sangat mendadak
✅ Multi-AZ untuk fault tolerance	❌ Aplikasi harus stateless agar scaling berfungsi benar
✅ Bisa mixed instance types (spot + on-demand)	❌ Warm-up time membuat scaling tidak instan

Kapan ASG Tepat Digunakan

ASG adalah pilihan natural untuk web backend tradisional, API server, dan worker queue berbasis EC2. Pola ini paling umum di industri karena menyeimbangkan simplisitas dengan reliability. Jika aplikasi kamu belum di-containerize tapi butuh high availability dan autoscaling, ASG adalah jawabannya.

Anti-Pattern ASG

Kesalahan terbesar dengan ASG adalah membuat aplikasi stateful lalu mengharapkan scaling horizontal bekerja. Jika setiap instance menyimpan session di memori lokal, menambah instance baru tidak membantu — user yang session-nya ada di instance A akan error jika request berikutnya masuk ke instance B.

graph LR
    subgraph "❌ Anti-Pattern: Session di Memory Lokal"
        R1["Request 1"] --> IA["Instance A<br/>session tersimpan"]
        R2["Request 2"] --> IB["Instance B<br/>session tidak ada ⚠️"]
    end

    style IA fill:#fef3c7,stroke:#d97706,color:#000
    style IB fill:#fecaca,stroke:#dc2626,color:#000
    style R1 fill:#f5f5f4,stroke:#78716c,color:#000
    style R2 fill:#f5f5f4,stroke:#78716c,color:#000

graph LR
    subgraph "✅ Benar: Session di External Store"
        R3["Request 1"] --> IC["Instance A"] --> RD["Redis<br/>session store"]
        R4["Request 2"] --> ID["Instance B"] --> RD
    end

    style IC fill:#bfdbfe,stroke:#2563eb,color:#000
    style ID fill:#bfdbfe,stroke:#2563eb,color:#000
    style RD fill:#bbf7d0,stroke:#16a34a,color:#000
    style R3 fill:#f5f5f4,stroke:#78716c,color:#000
    style R4 fill:#f5f5f4,stroke:#78716c,color:#000

Best Practice ASG

Selalu gunakan Launch Template (bukan Launch Configuration yang sudah deprecated) dengan versi yang di-track.
Pasang ALB atau NLB di depan ASG — jangan expose instance langsung.
Rancang aplikasi stateless sejak awal. Simpan session, cache, dan file di external service.
Kombinasikan target tracking scaling (misalnya target CPU 60%) dengan scheduled scaling untuk pola traffic yang sudah diketahui.
Gunakan mixed instances policy dengan spot instance untuk menghemat hingga 70% biaya.

Amazon EKS — Kubernetes Tanpa Kelola Control Plane

EKS adalah managed Kubernetes di AWS. AWS mengelola control plane (API server, etcd, scheduler), kamu mengelola workload dan — jika menggunakan mode EC2 — worker node. Kubernetes sendiri sudah menjadi standar de facto untuk container orchestration, dan EKS membuat adopsinya di AWS jauh lebih mudah dibanding membangun cluster sendiri.

Mengapa Kubernetes, dan Mengapa EKS

Kubernetes menyelesaikan masalah yang muncul saat kamu punya banyak container: bagaimana menjadwalkan mereka ke server yang tepat, bagaimana memastikan jumlah replika sesuai, bagaimana melakukan rolling update tanpa downtime, dan bagaimana mengelola networking antar service. EKS menghilangkan beban terberat — mengelola control plane — sehingga tim bisa fokus pada workload.

graph TB
    subgraph "EKS Cluster"
        subgraph "AWS Managed"
            CP["Control Plane<br/>API Server, etcd,<br/>Scheduler, Controller Manager"]
        end
        subgraph "Kamu Kelola (EC2 Mode)"
            NG["Node Group"]
            NG --> N1["Worker Node 1<br/>(EC2)"]
            NG --> N2["Worker Node 2<br/>(EC2)"]
            NG --> N3["Worker Node 3<br/>(EC2)"]
        end
        subgraph "Workload"
            N1 --> P1["Pod A"]
            N1 --> P2["Pod B"]
            N2 --> P3["Pod C"]
            N2 --> P4["Pod D"]
            N3 --> P5["Pod E"]
        end
    end
    CP ---|"orchestrate"| NG

    style CP fill:#bbf7d0,stroke:#16a34a,color:#000
    style NG fill:#bfdbfe,stroke:#2563eb,color:#000

Karakteristik dan Trade-off

Kelebihan	Kekurangan
✅ Kubernetes compliant — portable antar cloud	❌ Learning curve sangat tinggi
✅ Ekosistem CNCF yang sangat luas (Helm, Istio, ArgoCD, dll)	❌ Biaya control plane ($0.10/jam ≈ $73/bulan) di atas biaya worker
✅ Cocok untuk arsitektur microservices skala besar	❌ Over-engineering untuk sistem sederhana
✅ Rolling update, canary deployment, blue-green native	❌ Debugging lebih kompleks dibanding EC2 langsung
✅ Vendor lock-in rendah dibanding ECS	❌ Butuh tim yang paham Kubernetes

Kapan EKS Tepat Digunakan

EKS tepat saat kamu menjalankan microservices skala besar (puluhan hingga ratusan service), punya tim yang sudah berpengalaman dengan Kubernetes, membutuhkan portabilitas antar cloud (multi-cloud strategy), atau sedang membangun internal platform engineering. Jika kamu hanya menjalankan 2-3 service, EKS kemungkinan besar over-engineering.

Anti-Pattern EKS

Kesalahan fatal yang sering terjadi adalah mengadopsi EKS tanpa memahami Kubernetes. Tim yang tidak paham konsep Pod, Service, Ingress, ConfigMap, dan RBAC akan menghabiskan lebih banyak waktu debugging infrastruktur daripada membangun fitur.

graph LR
    subgraph "❌ Anti-Pattern: EKS Tanpa Kesiapan"
        T1["Tim 3 orang"] --> EKS1["EKS"] --> S1["2 service"]
        S1 --> H1["80% waktu<br/>habis untuk infra"]
    end

    style T1 fill:#f5f5f4,stroke:#78716c,color:#000
    style EKS1 fill:#fecaca,stroke:#dc2626,color:#000
    style S1 fill:#fef3c7,stroke:#d97706,color:#000
    style H1 fill:#fecaca,stroke:#dc2626,color:#000

graph LR
    subgraph "✅ Benar: EKS Saat Skala & Tim Siap"
        T2["Tim 10+ orang"] --> EKS2["EKS"] --> S2["20+ service"]
        S2 --> H2["Infra di-handle<br/>platform team"]
    end

    style T2 fill:#f5f5f4,stroke:#78716c,color:#000
    style EKS2 fill:#bfdbfe,stroke:#2563eb,color:#000
    style S2 fill:#bbf7d0,stroke:#16a34a,color:#000
    style H2 fill:#bbf7d0,stroke:#16a34a,color:#000

Kesalahan lain yang umum adalah menjalankan database di dalam Kubernetes. Workload stateful seperti database memerlukan pengelolaan storage, backup, dan failover yang jauh lebih cocok ditangani oleh managed service (RDS, Aurora, ElastiCache).

Best Practice EKS

Gunakan namespace untuk isolasi antar tim atau environment, dan terapkan ResourceQuota untuk mencegah satu tim menghabiskan resource cluster.
Terapkan HPA (Horizontal Pod Autoscaler) untuk scaling berdasarkan CPU/memory, dan VPA (Vertical Pod Autoscaler) untuk right-sizing resource request.
Gunakan IRSA (IAM Role for Service Account) agar setiap Pod hanya punya akses AWS yang dibutuhkan — jangan gunakan node-level IAM role.
Wajibkan resource requests dan limits di setiap Pod. Tanpa ini, scheduler tidak bisa membuat keputusan penempatan yang baik.
Implementasikan observability stack sejak awal: Prometheus untuk metrics, Grafana untuk dashboard, Fluent Bit untuk log forwarding.

AWS Fargate — Container Tanpa Server

Fargate mengubah paradigma: kamu mendefinisikan container (image, CPU, memory), dan AWS menjalankannya. Tidak ada instance untuk di-SSH, tidak ada OS untuk di-patch, tidak ada capacity planning untuk node. Fargate bisa digunakan melalui dua orchestrator: ECS (lebih sederhana) atau EKS (jika kamu sudah investasi di Kubernetes).

Cara Kerja Fargate

Setiap task atau pod yang berjalan di Fargate mendapat micro-VM sendiri yang terisolasi. Kamu tidak berbagi kernel dengan tenant lain. Ini membuat Fargate lebih aman secara default dibanding container yang berjalan di shared EC2 node.

graph LR
    subgraph "Tanpa Fargate (EC2 Mode)"
        EC2["EC2 Instance<br/>(kamu kelola)"]
        EC2 --> C1["Container A"]
        EC2 --> C2["Container B"]
        EC2 --> C3["Container C"]
    end

    subgraph "Dengan Fargate"
        F1["Fargate Task<br/>Container A<br/>(micro-VM terisolasi)"]
        F2["Fargate Task<br/>Container B<br/>(micro-VM terisolasi)"]
        F3["Fargate Task<br/>Container C<br/>(micro-VM terisolasi)"]
    end

    style EC2 fill:#fef3c7,stroke:#d97706,color:#000
    style F1 fill:#bbf7d0,stroke:#16a34a,color:#000
    style F2 fill:#bbf7d0,stroke:#16a34a,color:#000
    style F3 fill:#bbf7d0,stroke:#16a34a,color:#000

Karakteristik dan Trade-off

Kelebihan	Kekurangan
✅ Zero server management — tidak ada OS, patching, atau capacity planning	❌ Lebih mahal per vCPU/GB dibanding EC2 langsung
✅ Isolasi keamanan per task/pod (micro-VM)	❌ Cold start bisa mencapai 30-60 detik untuk image besar
✅ Billing per detik berdasarkan resource yang dipakai	❌ Tidak bisa SSH ke runtime environment
✅ Scale-to-zero memungkinkan (dengan ECS)	❌ Kontrol terbatas — tidak bisa tuning kernel atau mount host volume
✅ Cocok untuk workload sporadis dan event-driven	❌ Tidak cocok untuk workload GPU atau high-performance computing

Kapan Fargate Tepat Digunakan

Fargate bersinar di tiga skenario utama. Pertama, background job dan event-driven worker — task yang dipicu oleh event (SQS message, S3 upload, scheduled cron) lalu mati setelah selesai. Kedua, microservice dengan traffic rendah-sedang yang tidak justify biaya mengelola EC2 node. Ketiga, tim kecil tanpa dedicated infra engineer yang ingin fokus menulis kode, bukan mengelola server.

Anti-Pattern Fargate

Kesalahan umum adalah menjalankan semua workload di Fargate tanpa mempertimbangkan biaya. Untuk workload yang berjalan 24/7 dengan utilisasi tinggi, EC2 (terutama dengan Reserved Instance atau Savings Plan) bisa 3-5x lebih murah.

graph LR
    subgraph "❌ Anti-Pattern: Semua di Fargate"
        SA1["Service A<br/>24/7, high CPU"] --> FG1["Fargate"] --> C1["Biaya sangat tinggi"]
        SB1["Service B<br/>24/7, high CPU"] --> FG2["Fargate"] --> C2["Biaya sangat tinggi"]
    end

    style SA1 fill:#fef3c7,stroke:#d97706,color:#000
    style SB1 fill:#fef3c7,stroke:#d97706,color:#000
    style FG1 fill:#fecaca,stroke:#dc2626,color:#000
    style FG2 fill:#fecaca,stroke:#dc2626,color:#000
    style C1 fill:#fecaca,stroke:#dc2626,color:#000
    style C2 fill:#fecaca,stroke:#dc2626,color:#000

graph LR
    subgraph "✅ Benar: Hybrid — Sesuaikan dengan Workload"
        SA2["Service A<br/>24/7, high CPU"] --> EC2["EC2 + ASG"] --> C3["Biaya rendah"]
        SB2["Service B<br/>event-driven"] --> FG3["Fargate"] --> C4["Biaya minimal"]
    end

    style SA2 fill:#fef3c7,stroke:#d97706,color:#000
    style SB2 fill:#e0e7ff,stroke:#4f46e5,color:#000
    style EC2 fill:#bfdbfe,stroke:#2563eb,color:#000
    style FG3 fill:#bbf7d0,stroke:#16a34a,color:#000
    style C3 fill:#bbf7d0,stroke:#16a34a,color:#000
    style C4 fill:#bbf7d0,stroke:#16a34a,color:#000

Best Practice Fargate

Set resource request dengan tepat. Fargate billing berdasarkan vCPU dan memory yang kamu minta, bukan yang dipakai. Over-provisioning langsung membuang uang.
Gunakan Fargate Spot untuk workload yang toleran terhadap interupsi (batch processing, data pipeline). Hemat hingga 70%.
Optimalkan container image size. Image yang lebih kecil berarti cold start lebih cepat. Gunakan multi-stage build dan alpine base image.
Implementasikan health check yang proper agar orchestrator tahu kapan task perlu di-restart.

Perbandingan Langsung

Tabel berikut merangkum perbedaan fundamental keempat layanan dari berbagai aspek.

Aspek	EC2	ASG	EKS	Fargate
Level abstraksi	Rendah	Rendah–Menengah	Tinggi	Sangat Tinggi
Autoscaling	Manual	Horizontal otomatis	HPA + Cluster Autoscaler	Per task/pod otomatis
Kelola server	Ya, sepenuhnya	Ya, tapi ASG bantu replace	Ya untuk worker node	Tidak sama sekali
Waktu provisioning	1-3 menit	1-5 menit	Detik (pod scheduling)	30-60 detik (cold start)
Isolasi keamanan	Shared tenancy (default)	Shared tenancy	Shared node	Micro-VM per task
Biaya per unit	Paling murah	Murah	Menengah + control plane	Paling mahal per vCPU
Cocok untuk	Legacy, stateful, GPU	Web/API tradisional	Microservices besar	Event-driven, tim kecil
Learning curve	Rendah	Rendah	Tinggi	Rendah–Menengah
Vendor lock-in	Menengah	Menengah	Rendah (K8s portable)	Tinggi

Decision Guide — Pilih yang Tepat

Tidak perlu menghafal semua detail. Gunakan decision tree berikut untuk memandu keputusan arsitektur.

graph TD
    Start["Butuh menjalankan<br/>aplikasi di AWS"] --> Q1{"Aplikasi sudah<br/>di-containerize?"}

    Q1 -->|"Belum"| Q2{"Butuh autoscaling?"}
    Q2 -->|"Tidak"| EC2["✅ EC2<br/>Single atau multi-instance"]
    Q2 -->|"Ya"| ASG["✅ EC2 + ASG<br/>Autoscaling tradisional"]

    Q1 -->|"Sudah"| Q3{"Tim paham<br/>Kubernetes?"}
    Q3 -->|"Tidak"| Q4{"Butuh kelola<br/>server sendiri?"}
    Q4 -->|"Tidak"| FGECS["✅ Fargate + ECS<br/>Serverless container, simple"]
    Q4 -->|"Ya"| ECSEC2["✅ ECS + EC2<br/>Container orchestration sederhana"]

    Q3 -->|"Ya"| Q5{"Berapa banyak<br/>service?"}
    Q5 -->|"< 10"| FGECS2["✅ Fargate + ECS/EKS<br/>Kubernetes tanpa node mgmt"]
    Q5 -->|"> 10"| Q6{"Butuh kontrol<br/>penuh atas node?"}
    Q6 -->|"Ya"| EKSEC2["✅ EKS + EC2 Node Group<br/>Full Kubernetes power"]
    Q6 -->|"Tidak"| EKSFG["✅ EKS + Fargate<br/>Serverless Kubernetes"]

    style EC2 fill:#fef3c7,stroke:#d97706,color:#000
    style ASG fill:#fde68a,stroke:#d97706,color:#000
    style FGECS fill:#bbf7d0,stroke:#16a34a,color:#000
    style ECSEC2 fill:#bfdbfe,stroke:#2563eb,color:#000
    style FGECS2 fill:#bbf7d0,stroke:#16a34a,color:#000
    style EKSEC2 fill:#bfdbfe,stroke:#2563eb,color:#000
    style EKSFG fill:#d9f99d,stroke:#65a30d,color:#000

Arsitektur Produksi per Jenis

Teori tanpa contoh nyata sulit dicerna. Berikut arsitektur produksi yang realistis untuk masing-masing pendekatan.

EC2 Tunggal — Minimum Viable Production

graph LR
    User["User"] --> EC2["EC2 Instance<br/>t3.medium<br/>App + Nginx"]
    EC2 --> RDS["RDS<br/>PostgreSQL"]
    EC2 --> S3["S3<br/>Static Assets"]

    style EC2 fill:#fef3c7,stroke:#d97706,color:#000

Single point of failure. Cocok untuk MVP awal atau internal tools. Jangan gunakan untuk traffic publik yang signifikan.

EC2 + ASG — Pola Paling Umum

graph LR
    User["User"] --> ALB["ALB"]
    ALB --> EC2a["EC2<br/>AZ-1"]
    ALB --> EC2b["EC2<br/>AZ-2"]
    ALB --> EC2c["EC2<br/>AZ-1"]

    EC2a --> RDS["RDS Multi-AZ"]
    EC2b --> RDS
    EC2c --> RDS

    EC2a --> Redis["ElastiCache<br/>Redis"]
    EC2b --> Redis
    EC2c --> Redis

    ASG["ASG<br/>min:2 max:6"] -.->|"manage"| EC2a
    ASG -.-> EC2b
    ASG -.-> EC2c

    style ALB fill:#e0e7ff,stroke:#4f46e5,color:#000
    style ASG fill:#bfdbfe,stroke:#2563eb,color:#000

High availability, horizontal scaling, multi-AZ. Pola paling umum untuk web backend dan API tradisional.

EKS + EC2 Node Group — Full Power Kubernetes

graph TB
    User["User"] --> ALB["ALB + Ingress Controller"]
    ALB --> SvcA["Service A<br/>(3 replicas)"]
    ALB --> SvcB["Service B<br/>(2 replicas)"]
    ALB --> SvcC["Service C<br/>(4 replicas)"]

    subgraph "EKS Cluster"
        SvcA
        SvcB
        SvcC
    end

    SvcA --> RDS["Aurora"]
    SvcB --> DDB["DynamoDB"]
    SvcC --> SQS["SQS"] --> Worker["Worker Pods"]

    style ALB fill:#e0e7ff,stroke:#4f46e5,color:#000

Kontrol penuh atas node, efisien untuk workload stabil dan berat. Cocok untuk platform skala menengah-besar dengan tim yang paham Kubernetes.

EKS + Fargate — Serverless Kubernetes

graph TB
    User["User"] --> ALB["ALB"]

    subgraph "EKS + Fargate"
        ALB --> PodA["Pod A<br/>(Fargate)"]
        ALB --> PodB["Pod B<br/>(Fargate)"]
        SQS["SQS"] --> PodC["Worker Pod<br/>(Fargate)"]
        Cron["EventBridge<br/>Schedule"] --> PodD["Cron Pod<br/>(Fargate)"]
    end

    PodA --> RDS["Aurora Serverless"]
    PodB --> RDS

    style PodA fill:#bbf7d0,stroke:#16a34a,color:#000
    style PodB fill:#bbf7d0,stroke:#16a34a,color:#000
    style PodC fill:#bbf7d0,stroke:#16a34a,color:#000
    style PodD fill:#bbf7d0,stroke:#16a34a,color:#000

Tanpa worker node, operasional minimal. Ideal untuk tim kecil atau workload yang tidak konstan.

Fargate + ECS — Event-Driven Worker

graph LR
    S3["S3 Upload"] --> EB["EventBridge"]
    SQS["SQS Queue"] --> ECS["ECS Service"]
    Schedule["Cron Schedule"] --> EB

    EB --> FG1["Fargate Task<br/>Image Processor"]
    ECS --> FG2["Fargate Task<br/>Queue Worker"]

    FG1 --> S3Out["S3 Output"]
    FG2 --> DB["DynamoDB"]

    style FG1 fill:#bbf7d0,stroke:#16a34a,color:#000
    style FG2 fill:#bbf7d0,stroke:#16a34a,color:#000

Event-driven, scale-to-zero, biaya efisien untuk workload sporadis. Tidak ada server yang berjalan saat tidak ada pekerjaan.

Kesalahan Arsitektur yang Paling Sering Terjadi

Berdasarkan pengalaman di berbagai skala sistem, berikut kesalahan yang berulang kali muncul.

Menggunakan EKS untuk 2-3 service. Overhead mengelola Kubernetes — RBAC, networking, monitoring, upgrade — tidak sebanding dengan manfaat untuk sistem kecil. Gunakan ECS + Fargate sebagai gantinya.

Menggunakan EC2 tunggal untuk production. Satu instance = satu titik kegagalan. Minimal gunakan ASG dengan min: 2 di dua AZ berbeda.

Menjalankan database di Kubernetes. StatefulSet dan PersistentVolume memang ada, tapi mengelola backup, failover, dan performance tuning untuk database di K8s jauh lebih rumit dibanding menggunakan RDS atau Aurora.

Menggunakan Fargate untuk semua workload tanpa analisis biaya. Workload yang berjalan 24/7 dengan utilisasi tinggi hampir selalu lebih murah di EC2 dengan Reserved Instance.

Memilih teknologi berdasarkan resume, bukan kebutuhan. “Kami pakai EKS karena keren” bukan alasan arsitektur. Setiap pilihan harus bisa dijustifikasi dengan kebutuhan teknis dan bisnis yang konkret.

Ringkasan

EC2 — virtual machine klasik dengan kontrol penuh. Cocok untuk legacy, stateful workload, dan eksperimen. Jangan gunakan single instance untuk production.
ASG — bukan compute baru, melainkan controller untuk EC2. Memberikan autoscaling horizontal dan high availability. Aplikasi harus stateless.
EKS — managed Kubernetes untuk microservices skala besar. Powerful tapi kompleks. Hanya adopt jika tim dan skala sudah siap.
Fargate — serverless container tanpa kelola server. Ideal untuk event-driven, background job, dan tim kecil. Waspadai biaya untuk workload 24/7.
Semakin tinggi abstraksi, semakin kecil beban operasional — tetapi semakin besar biaya per unit dan semakin terbatas kontrol.
Tidak ada pilihan yang “paling benar” — yang ada adalah paling tepat untuk konteks kamu. Gunakan decision tree untuk memandu keputusan.
Hybrid adalah jawaban realistis — banyak production system mengombinasikan EC2 (untuk steady-state heavy workload) dengan Fargate (untuk event-driven dan sporadis).
Pilih berdasarkan kebutuhan, bukan hype — EKS untuk 2 service adalah over-engineering. EC2 tunggal untuk production adalah under-engineering. Temukan sweet spot di tengah.