ECS vs EKS: Layanan Kontainer AWS Mana yang Tepat untuk Anda?

Apa itu ECS?

ECS adalah layanan orkestrasi kontainer terkelola milik Amazon. Layanan ini menyediakan cara yang sederhana dan aman untuk menjalankan aplikasi terkontainerisasi. Dirancang agar mudah, ECS mengurangi keputusan pelanggan terkait komputasi, jaringan, dan konfigurasi keamanan tanpa mengorbankan skala atau fitur.

Ada beberapa istilah dan komponen yang perlu Anda kenal di ECS.

1. Cluster
2. Capacity provider
3. Task definition
4. Task
5. Service

Cluster

Cluster ECS terdiri dari service, task, dan capacity provider. Ini juga memuat control plane ECS yang dikelola oleh AWS dan tidak terlihat oleh kita.

Capacity provider

Kontainer memerlukan sebuah server untuk dijalankan, baik mesin virtual di cloud maupun komputer lokal Anda. Dalam konteks ECS, Anda dapat memilih “Launch Type” untuk menjalankan kontainer di Elastic Compute Cloud (EC2) atau Fargate.

Tab Infrastructure pada konsol AWS ECS.

Task

Task adalah sekumpulan kontainer yang berjalan dan dikonfigurasi sesuai task definition. Intinya, task mewakili sebuah instance dari task definition, mirip seperti kontainer yang merupakan instance dari image.

Task definition

Kita memiliki Dockerfile untuk aplikasi kita dan telah membuat image darinya. Kita mendorong image tersebut ke container registry seperti DockerHub atau AWS ECR. Lalu apa? Kita lanjut membuat task definition, yaitu konfigurasi atau cetak biru untuk kontainer kita (yang akan dideploy pada cluster ECS) yang mencakup informasi berikut:

• Image. Satu task dapat memuat lebih dari satu image.
• Nomor port yang akan digunakan untuk berkomunikasi dengan aplikasi.
• Volume.
• Sumber daya (CPU dan memori) yang dicadangkan untuk aplikasi.

Task definition di konsol AWS ECS.

Service

Apa yang terjadi saat kita menjalankan kontainer mandiri dan kontainer tersebut crash? Tidak ada. Kontainer akan tetap dalam status crash. Perilaku ini sama jika kita membuat task mandiri di ECS. Kita menggunakan service ECS untuk memastikan aplikasi selalu aktif. Service memastikan jumlah task yang diinginkan selalu aktif dan berjalan setiap saat.

Jika sebuah task crash atau server yang menjadi host-nya (dan karenanya kontainernya) down, service akan membuat task baru di capacity provider yang tersedia.

Implementasi ECS

Setelah membahas dasar-dasar ECS, mari jalankan image Nginx sederhana dan mengaksesnya. Dengan menggunakan cluster ECS dan task definition di atas, saya akan membuat service yang mereferensikan task definition tersebut:

Services di konsol AWS ECS.

Service ini pada gilirannya akan membuat sebuah task.

Sebuah task di konsol AWS ECS.

Mengakses alamat IP publik dari task:

Berhasil mengakses aplikasi yang berjalan di ECS.

Apa itu EKS?

Sebelum masuk ke Elastic Kubernetes Service (EKS), penting untuk memahami apa itu Kubernetes. Kubernetes adalah engine orkestrasi kontainer open-source yang mengotomatisasi penerapan, penskalaan, dan pengelolaan aplikasi terkontainerisasi. 

Untuk mempelajari lebih lanjut, saya menyarankan untuk melihat kursus Introduction to Kubernetes. 

Namun, mem-bootstrapping dan mengelola cluster Kubernetes dari nol bisa kompleks dan memakan waktu. Banyak komponen dan konfigurasi yang diperlukan untuk menyiapkan Kubernetes bersifat serupa di berbagai organisasi dan tim. Untuk mengabstraksi pekerjaan berat yang tidak terdiferensiasi ini dan menyederhanakan adopsi Kubernetes, AWS mengembangkan EKS.

EKS adalah layanan Kubernetes terkelola yang disediakan AWS yang menangani banyak beban operasional. Layanan ini menyederhanakan penerapan, penskalaan, dan pengelolaan Kubernetes dengan menangani control plane atas nama pengguna. Dengan mengabstraksi kebutuhan mengelola komponen-komponen ini, Amazon EKS memungkinkan pengguna fokus menjalankan beban kerja terkontainerisasi dan mengelola worker node atau menggunakan AWS Fargate untuk komputasi tanpa server.

Bagian ini membahas EKS secara singkat. Untuk lebih lengkap, lihat artikel Fundamentals of Container Orchestration With AWS Elastic Kubernetes Service (EKS).

Ada beberapa istilah dan komponen yang perlu Anda kenal di EKS:

1. Cluster (master dan worker node)
2. Berkas manifest
3. Pod
4. ReplicaSet
5. Utilitas baris perintah kubectl

Cluster

Cluster Kubernetes adalah sekumpulan server atau mesin virtual tempat workload Kubernetes berjalan. Terdiri dari master node (umumnya disebut control plane) dan worker node. 

Di EKS, master node dikelola oleh AWS di VPC miliknya; ini diabstraksikan dari kita. Sementara itu, kita dapat mengelola worker node melalui instance EC2 atau menggunakan Fargate untuk opsi tanpa server.

Konektivitas jaringan control plane EKS. Sumber gambar: AWS

Pod

Pod adalah resource API Kubernetes. Ini adalah unit terkecil yang dapat dideploy di Kubernetes. Pod merupakan sekumpulan satu atau lebih kontainer dan memuat spesifikasi image yang digunakan, port, perintah, dan sebagainya.

Tab Resources di konsol AWS EKS.

ReplicaSet

Sama seperti pod, ReplicaSet juga merupakan resource API Kubernetes. Ini memastikan jumlah pod yang diinginkan selalu berjalan.

Berkas manifest

Berkas manifest Kubernetes adalah berkas konfigurasi yang digunakan untuk mendefinisikan status yang diinginkan dari resource Kubernetes secara deklaratif. Berkas ini menjelaskan resource apa yang harus ada di cluster Kubernetes, konfigurasinya, dan bagaimana saling berinteraksi.

Berkas manifest biasanya ditulis dalam YAML:

# pod.yml - Pod manifest
apiVersion: v1
kind: Pod
metadata:
  name: nginx-pod
  labels:
    app: nginx
spec:
  containers:
  - name: nginx-container
    image: nginx:1.27
    ports:
    - containerPort: 80

# service.yml - Kubernetes Service manifest
apiVersion: v1
kind: Service
metadata:
  name: nginx-node-port-service
spec:
  type: NodePort 
  selector:
    app: nginx
  ports:
    - protocol: TCP
      port: 8080
      targetPort: 80
      nodePort: 31000

kubectl

Utilitas baris perintah untuk berkomunikasi dengan cluster Kubernetes. Kita dapat menggunakan perintah kubectl untuk membuat, mengelola, dan menghapus resource Kubernetes secara imperatif atau menggunakannya bersama berkas manifest secara deklaratif.

# Create a pod that runs a container with the nginx:1.27 image
kubectl run nginx-pod --image nginx:1.27 
# Create a replicaset with 2 pods
kubectl create replicaset --replicas=2 --image nginx:1.27

Implementasi EKS

Sekarang mari kita demokan cara kerja EKS dengan menjalankan dan mengakses image Nginx yang sama. 

Untuk menyederhanakan, saya akan membuat instance EC2/worker node di subnet publik, menerapkan aplikasi di sana, mengeksposnya melalui resource service Kubernetes bertipe NodePort, dan mengaksesnya melalui IP publik instance tersebut. 

Saya akan menggunakan manifest pod dan service di atas dan perintah kubectl untuk membuat pod:

# Update local .kube/config file
aws eks update-kubeconfig --region ap-southeast-1 --name i-love-datacamp-eks-cluster
# Create the pod
kubectl create -f pod.yml
# Create the service
kubectl create -f service.yml

Cluster EKS memiliki satu instance EC2:

Instance EC2/worker node.

Temukan alamat IPv4 publik dari instance tersebut.

Alamat IP publik instance EC2/worker node.

Mengakses alamat IP publik instance dengan port 31000:

Berhasil mengakses aplikasi yang berjalan di EKS.

ECS vs. EKS: Persamaan

Setelah membahas dasar-dasar ECS dan EKS, kita dapat melihat beberapa persamaan di antara keduanya. Ini tidak mengejutkan, karena keduanya adalah alat orkestrasi kontainer.

Kapasitas komputasi

Kedua layanan memungkinkan aplikasi berjalan di EC2, di mana pengguna bertanggung jawab memelihara, menambal, dan meningkatkan instance EC2, atau di AWS Fargate, opsi komputasi tanpa server di mana AWS mengelola server di bawahnya sehingga tidak perlu mengelola infrastruktur.

Model pengelolaan workload

Kedua layanan memiliki struktur dan pendekatan yang serupa untuk mengelola dan memelihara resource aplikasi.

Di AWS ECS, konfigurasi yang mendefinisikan cara kontainer harus dijalankan disebut task definition, sedangkan di AWS EKS, hal ini dicapai menggunakan berkas manifest pod. Setelah diterapkan, aplikasi terkontainerisasi di ECS berjalan dalam sebuah task, sedangkan di EKS, berjalan di dalam pod. Untuk memastikan sejumlah task atau pod yang ditentukan selalu berjalan, ECS menggunakan service, sementara EKS mengandalkan replica set untuk fungsi ini.

Integrasi mendalam dengan layanan AWS lainnya

Sebagai layanan kontainer di AWS, Amazon berupaya keras memastikan ECS dan EKS terintegrasi dengan baik dengan layanan AWS lainnya. 

Untuk jaringan, ada Amazon VPC, yang memungkinkan kontainer berjalan di lingkungan terisolasi dengan kontrol penuh atas konfigurasi jaringan, security group, dan subnet. Load balancer untuk merutekan trafik ke kontainer. 

Solusi seperti EBS, EFS, dan S3 tersedia untuk menangani kebutuhan penyimpanan persisten bagi aplikasi terkontainerisasi.

Kedua layanan menggunakan AWS IAM untuk mengontrol akses dan izin secara granular. Ini menentukan resource AWS mana yang dapat diakses aplikasi terkontainerisasi, seperti S3, DynamoDB, atau RDS.

Ringkasan persamaan utama

ECS vs. EKS: Perbedaan

Memahami perbedaan antara Amazon ECS dan Amazon EKS penting saat memilih di antara keduanya. 

Pada bagian ini, kita akan mengurai perbedaan inti dalam hal kemudahan penggunaan, skalabilitas, kustomisasi, dan biaya, membantu Anda menentukan layanan mana yang paling selaras dengan kebutuhan teknis dan tujuan bisnis Anda.

Kemudahan penggunaan dan kurva pembelajaran

EKS dibangun di atas Kubernetes, sehingga diperlukan pemahaman konsep dan alat Kubernetes. Karena itu, kurva pembelajaran EKS akan lebih curam dibandingkan ECS. Ini mencakup memahami cara kerja perintah kubectl dan beberapa resource API Kubernetes dasar yang penting, seperti service (jangan bingungkan dengan istilah “service” dalam konteks ECS), config map, ingress, dan lain-lain. Bagian “Apa itu EKS” di atas baru menyentuh permukaan dari apa yang ditawarkan EKS.

ECS dan EKS memerlukan pengetahuan tentang layanan AWS seperti CloudWatch, IAM, ASG, dan sebagainya. Untungnya, itu saja yang dibutuhkan untuk ECS, tetapi tidak untuk EKS. Dengan demikian, ECS unggul dalam kemudahan penggunaan.

Skalabilitas

Kedua layanan dapat melakukan skala dengan sama baiknya jika dikonfigurasi dengan benar. Namun, cara mereka melakukan skala berbeda. ECS mendukung penskalaan otomatis melalui ECS Service Auto Scaling untuk task dan ECS Cluster Auto Scaling untuk instance. Layanan ini hanya menggunakan layanan native AWS seperti metrik CloudWatch dan kebijakan penskalaan ASG.

Sementara EKS menggunakan fitur penskalaan native Kubernetes, seperti Horizontal Pod Autoscaler (HPA) untuk pod dan Cluster Autoscaler untuk instance. Cluster Autoscaler tidak diinstal secara default pada cluster EKS sehingga pengguna harus memasangnya sendiri. Ini menambah kompleksitas karena diperlukan konfigurasi yang tepat pada resource AWS (misalnya peran IAM) dan resource API Kubernetes (misalnya service account) agar Cluster Autoscaler berfungsi, yang memerlukan pemanggilan AWS API untuk scale in dan scale out.

Fitur baru yang baru-baru ini diluncurkan untuk EKS, EKS AutoMode, dapat mengatasi kompleksitas tambahan ini. Fitur ini melimpahkan pengelolaan dan penskalaan worker node EKS ke AWS tetapi disertai biaya tambahan.

Fleksibilitas dan kustomisasi

Seperti disebutkan, ECS adalah layanan orkestrasi kontainer terkelola milik Amazon yang dirancang untuk kesederhanaan. AWS menangani sebagian besar tugas pengelolaan cluster, menawarkan konfigurasi baku yang cocok untuk workload kontainer umum tetapi mungkin tidak memenuhi kebutuhan yang sangat spesifik. Walau mengurangi kompleksitas, ini membatasi opsi kustomisasi dibandingkan Kubernetes.

EKS menyediakan seluruh kapabilitas Kubernetes, memungkinkan pengguna mengkustomisasi deployment, penjadwalan pod, storage class, dan kebijakan jaringan sesuai kebutuhan. Fitur orkestrasi lanjutan, seperti custom resource definition (CRD) dan operator, memberikan fleksibilitas tak tertandingi dalam desain aplikasi. 

EKS juga dapat diintegrasikan dengan berbagai alat dan plugin open-source dari ekosistem Kubernetes, seperti Prometheus, Grafana, dan Istio, sehingga pengembang dapat membangun solusi yang sangat tersesuaikan. Dengan demikian, EKS unggul dalam fleksibilitas dan kustomisasi.

Biaya

Selain biaya standar untuk sumber daya jaringan (misalnya alamat IPv4 publik, NAT gateway) dan sumber daya komputasi serta penyimpanan (misalnya instance EC2, Fargate, dan volume EBS) yang berlaku untuk ECS dan EKS, ECS memiliki biaya yang lebih rendah dan struktur biaya yang jauh lebih sederhana.

Tidak ada biaya untuk control plane ECS. Dengan kata lain, jika Anda membuat cluster ECS tanpa ada task yang berjalan, Anda tidak akan menimbulkan biaya apa pun. Sementara untuk EKS, ada biaya untuk control plane yang dikelola AWS terlepas dari apakah Anda memiliki aplikasi yang berjalan di cluster Kubernetes atau tidak.

Biaya control plane EKS bervariasi tergantung pada versi Kubernetes yang digunakan. Versi Kubernetes dalam dukungan standar dikenai biaya $0,10 per cluster per jam, sedangkan yang dalam dukungan diperpanjang dikenai biaya $0,60 per cluster per jam.

Ringkasan perbedaan utama

Kapan Memilih ECS?

Pilihan bergantung pada kebutuhan aplikasi, tujuan bisnis, keahlian tim, anggaran operasional, dan prioritas keseluruhan Anda.

ECS, yang lebih sederhana dan hemat biaya, ideal untuk tim dengan anggaran ketat, kebutuhan time-to-market yang lebih singkat, dan preferensi operasi yang ringkas. Layanan ini sangat cocok untuk aplikasi yang tidak memerlukan portabilitas lintas lingkungan multi-cloud atau hibrida dan memang dirancang untuk berjalan secara eksklusif di AWS. Sebagai layanan spesifik AWS, ECS selaras dengan beban kerja yang berada dalam ekosistem AWS.

Meskipun ECS dan EKS sama-sama mendukung Fargate untuk deployment kontainer tanpa server, ECS menawarkan integrasi yang lebih langsung. Dengan ECS, Anda dapat langsung memilih task untuk berjalan di Fargate tanpa konfigurasi tambahan. Sebaliknya, Fargate dengan EKS memerlukan penentuan label pod untuk menetapkan workload mana yang harus berjalan di Fargate, sehingga menambah lapisan kompleksitas. Hal ini membuat ECS menarik bagi tim yang mencari pengalaman tanpa server yang lebih sederhana.

Kapan Memilih EKS?

Kubernetes, platform dasar untuk EKS, bersifat agnostik cloud, memungkinkan workload berjalan secara konsisten di AWS, penyedia cloud lain, dan lingkungan on-premises. Portabilitas ini sangat bermanfaat bagi organisasi yang beroperasi dalam pengaturan multi-cloud atau infrastruktur hibrida on-premises. Azure dan Google Cloud juga menawarkan layanan Kubernetes terkelola—Azure Kubernetes Service (AKS) dan Google Kubernetes Engine (GKE)—yang menegaskan keberadaan Kubernetes yang luas di lingkungan cloud modern.

EKS ideal jika aplikasi atau kasus penggunaan Anda memerlukan kustomisasi dan extensibility tingkat lanjut. Misalnya, Kubernetes mendukung pembuatan Custom Resource Definition (CRD), yang memungkinkan Anda mendefinisikan resource khusus untuk mengelola konfigurasi aplikasi tertentu atau berintegrasi dengan sistem eksternal. Fleksibilitas ini menjadi pembeda utama bagi EKS.

Meskipun EKS mengabstraksi control plane dan mengandalkan AWS untuk mengelolanya, beroperasi secara efektif di lingkungan EKS tetap menuntut pemahaman resource API dan konsep Kubernetes. Oleh karena itu, keahlian Kubernetes dalam tim sangat penting untuk memanfaatkan platform ini secara efektif.

EKS juga menawarkan beragam add-on yang dapat disesuaikan untuk dipasang guna memperluas fungsionalitas cluster. Add-on ini memudahkan penyediaan cluster dengan alat operasional yang diperlukan, menyederhanakan penyiapan, dan meningkatkan produktivitas.

Pilihan add-on EKS.

Singkatnya, EKS sangat cocok untuk arsitektur mikrolayanan atau aplikasi dengan banyak komponen yang saling terhubung yang memerlukan kontrol dan granularitas tinggi. Layanan ini sangat menguntungkan bagi tim yang membutuhkan opsi kustomisasi tingkat lanjut atau beroperasi di lingkungan yang menuntut portabilitas workload.

Bagan alur keputusan ECS vs. EKS. Gambar oleh Penulis.

Alat dan Integrasi

Baik aplikasi terkontainerisasi maupun aplikasi yang berjalan langsung di VM, monitoring dan observabilitas adalah hal yang sangat penting. Berada dalam ekosistem AWS, ECS dan EKS dapat memanfaatkan alat AWS dan layanan pihak ketiga untuk meningkatkan seluruh Siklus Hidup Pengembangan Perangkat Lunak (SDLC) bagi aplikasi terkontainerisasi.

Monitoring dan logging

Monitoring dan logging penting untuk visibilitas terhadap aplikasi dan infrastruktur Anda. AWS menyediakan alat native dan mendukung integrasi pihak ketiga untuk ECS dan EKS, seperti Amazon CloudWatch untuk metrik, log, dan alarm. 

AWS X-Ray untuk penelusuran permintaan lintas mikrolayanan memudahkan analisis dan debug masalah kinerja pada task ECS atau pod EKS. Alat pihak ketiga seperti Datadog, Prometheus, Grafana, dan New Relic menyediakan kemampuan visualisasi dan peringatan yang disesuaikan untuk kontainer.

Pipeline CI/CD

Pipeline CI/CD membantu mengotomatisasi pengujian, pemindaian, dan deployment, memastikan iterasi yang lebih cepat dan mengurangi upaya manual. Alat CI/CD populer seperti pipeline GitLab dan GitHub Actions terintegrasi dengan ECS dan EKS untuk memungkinkan build, pengujian, dan deployment kontainer. Alat-alat ini bekerja dengan kontainer Docker untuk ECS atau chart Helm untuk EKS.

Infrastructure as Code (IaC)

IaC penting untuk membuat infrastruktur yang konsisten dan dapat diulang, meminimalkan waktu provisioning, dan mengurangi risiko kesalahan manusia yang terkait dengan konfigurasi manual melalui AWS Management Console. 

Alat IaC yang populer meliputi Terraform dan AWS CloudFormation. Meskipun keduanya banyak digunakan, Terraform sering dipilih karena kemampuannya yang agnostik cloud, memungkinkan tim mengelola infrastruktur di beberapa penyedia cloud dengan satu alat.

Jaringan dan keamanan

AWS menyediakan fitur jaringan dan keamanan yang kuat untuk ECS dan EKS guna memastikan komunikasi dan kontrol akses yang aman, seperti jaringan AWS VPC untuk mengisolasi resource dalam subnet privat. AWS WAF dan Shield: Melindungi aplikasi yang dihosting pada ECS dan EKS dari kerentanan web umum dan serangan DDoS. AWS KMS untuk mengenkripsi volume EBS dan secret Kubernetes yang disimpan di etcd.

Kesimpulan

ECS dan EKS adalah layanan orkestrasi kontainer tangguh dari AWS, masing-masing disesuaikan untuk memenuhi kebutuhan aplikasi dan prioritas tim yang berbeda. 

ECS lebih mudah untuk mulai digunakan, lebih sederhana dalam penyediaan, deployment, dan pemeliharaan, serta memiliki biaya operasional lebih rendah. Sebaliknya, EKS memiliki kurva pembelajaran lebih curam dan kompleksitas awal lebih tinggi tetapi menawarkan fleksibilitas tak tertandingi dan opsi kustomisasi lanjutan, menjadikannya ideal untuk tim dengan kebutuhan khusus atau kompleks. 

Pilihan antara ECS dan EKS bergantung pada kebutuhan aplikasi Anda, keahlian tim, serta keseimbangan yang diinginkan antara kesederhanaan dan kontrol.

Jika Anda ingin memperkuat pengetahuan AWS, kursus AWS Concepts adalah tempat yang tepat untuk memulai. Untuk mendalami alat dan teknologi AWS, lihat kursus AWS Cloud Technology and Services. Selain itu, bagi yang ingin menguasai kontainerisasi, Containerization and Virtualization Track menawarkan wawasan berharga untuk membantu Anda unggul dalam mengelola dan menerapkan kontainer.