Tidak Semua Container Butuh Kubernetes. Beberapa Hanya Butuh Solusi yang Simple, Affordable, tapi Reliable seperti App Runner.

Terkadang, aplikasi yang seharusnya dideploy dengan infrastruktur yang simple, malah didapati dengan over-engineering. Tidak semua aplikasi, khususnya container, butuh cluster Kubernetes yang kompleks. Beberapa hanya butuh infrastruktur yang simple namun scalable. Bagaimana ya, implementasinya di AWS?

Artikel ini adalah rangkuman dari presentasi POROS Filkom Study Group 2025. Berikut slide presentasi yang digunakan:

Previous Next

Pendahuluan

#

Serverless Container, apa sih?

#

Singkat saja, Serverless container adalah pendekatan untuk menjalankan container di cloud tanpa perlu mengelola infrastruktur servernya. Dengan begitu, developer jadi bisa fokus ke aplikasi, bukan ke infranya.

Masalahnya begini,

#

Bayangkan, client menginfokan kalau aplikasi harus live besok pagi jam 6. Apabila tidak ada tim Ops, artinya, tim developer harus handle deploymentnya sendiri.

Untuk mendeploy production-ready application secara tradisional, setidaknya ada beberapa hal yang harus disiapkan:

1. Base infrastructure, yaitu server beserta ekosistemnya
2. Auto scaling
3. load balancing
4. Networking, subnet, firewall
5. Domain + SSL

Dan masih banyak lagi. Kalaulah memang harus diproses sendiri pasti memakan waktu dan membutuhkan skill infrastruktur yang tidak selalu dimiliki tim devloper. Maka dari itu, disinilah konsep Container as a Service dapat menjadi solusi yang menyederhanakan semuanya.

Sekilas tentang Cloud, just in case you’re not familiar, yet.

#

Cloud computing adalah terminlogi penggunaan infrastruktur remote yang dihost di internet untuk mengolah data, berbeda dengan menggunakan server lokal. Singkatnya, cloud menyediakan on-demand delivery untuk resource IT melalui internet dengan model pembayaran pay-as-you-go. Daripada membeli dan merawat data center sendiri, lebih baik menyewa layanan yang bisa diakses sesuai kebutuhan dari cloud provider.

Sedikit intermezzo tentang cloud

#

Istilah cloud sendiri sebenarnya hanyalah cara simple untuk menggambarkan sesuatu yang terlalu kompleks untuk digambar. Dulu, topologi internet hanya sesimple beberapa perangkat yang dapat digambarkan secara detail, seperti ini:

Namun, seiring berkembangnya internet, topologi internet semakin rumit untuk digambarkan.

Shingga, Kata cloud sebenarnya digunakan untuk mendeskripsikan kumpulan objek yang secara visual tampak seperti awan dari jauh.

Jadi, terminologi cloud adalah terjemahan untuk, “Bang, ini tuh lebih ribet dari yang lu ngerti, dan kita juga males ngegambarinnya, repot. Jadi anggap aja ini saking banyaknya tuh kayak kumpulan awan di sana, adalah pokoknya.”

Container di Cloud

#

Cloud container pada dasarnya adalah container biasa yang berjalan di infrastruktur cloud, bukan di mesin lokal atau data center sendiri.

Dulu, sebelum era infrastruktur cloud, trennya adalah menggunakan infrastuktur on-premise untuk mendeploy aplikasi yang masih bersifat monolith. Seiring berkembangnya zaman, tren aplikasi berubah dengan microservice yang terintegrasi dengan ekosistem cloud. Biasanya, aplikasi tersebut dideploy dalam bentuk container.

Serverless Container

#

Serverless adalah kategori layanan cloud di mana pengguna bisa memanfaatkan berbagai kapabilitas cloud tanpa harus melakukan provisioning, deploy, dan mengelola hardware maupun software resource. Istilah serverless container merepresentasikan ide bahwa pengguna sekarang bisa menjalankan container tanpa harus mengelola server atau infrastruktur komputasi yang menjalankan container tersebut.

Serverless itu artinya tidak perlu merawat infrastruktur. Serverless itu artinya service akan melakukan scale berdasarkan request secara realtime Serverless itu artinya bisa membayar hanya sesuai pemakaian dan durasi penggunaan

Dari FaaS ke CaaS

#

Secara tradisional, istilah serverless itu diartikan dengan model Functions as a Service (FaaS), yaitu model eksekusi cloud computing yang hany memberikan resource komputasi berdasarkan pemakaian. Sehingga, pengguna tidak perlu berurusan dengan maintenance infrastruktur.

Seiring waktu, pengguna ingin memperluas pendekatan tersebut. Daripada mengemas kode dalam file ZIP dan mengirimnya ke platform serverless, mereka ingin cara untuk mengirim container langsung. Belakangan ini, hal tersebut sudah tersedia dengan teknologi Containers as a Service (CaaS) yang sekarang dikenal sebagai serverless container.

Kenapa harus Amazon Web Services?

#

Amazon Web Services diluncurkan pada tahun 2006 dan awalnya dirancang untuk menyediakan infrastruktur untuk ritel Amazon sendiri. Saat ini, AWS adalah cloud provider terbesar di dunia dengan market share sekitar 33%. Beberapa perusahaan besar dunia seperti Netflix, Airbnb, dan Snapchat menjalankan bisnis mereka di AWS.

Hampir 80 persen dari seluruh cloud container berjalan di Amazon Web Services.¹

Serverless Container di AWS

#

ECS (Elastic Container Service)

#

Amazon Elastic Container Service (ECS) adalah fully managed container orchestration service. Fungsinya mirip dengan Kubernetes dan Docker Swarm, tapi ECS dimiliki oleh AWS dan tidak perlu disetup sendiri.

Bahkan kedua teknologi ini memiliki terminologi yang sebenarnya sama saja.

EKS (Elastic Kubernetes Service)

#

Amazon Elastic Kubernetes Service (EKS) menyediakan fully managed Kubernetes service yang menghilangkan kompleksitas dalam mengoperasikan cluster Kubernetes.

App Runner

#

AWS App Runner adalah layanan AWS yang menyediakan cara cepat, sederhana, dan hemat biaya untuk mendeploy aplikasi web yang scalable dan secure langsung dari source code atau container image ke AWS Cloud. Tidak perlu mempelajari teknologi baru, memilih compute service mana yang digunakan, atau mengetahui cara melakukan provisioning dan konfigurasi resource AWS.

App Runner terhubung langsung ke repositori kode atau image. App Runner menyediakan automatic integration and delivery pipeline dengan operasi yang fully managed, performa tinggi, scalability, dan keamanan.

Untuk developer, App Runner menyederhanakan proses deployment versi baru dari kode atau image repository. Untuk tim operasi, App Runner mengaktifkan automatic deployment setiap kali commit dipush ke repositori kode atau versi container image baru dipush ke image repository.

Hanya saja, sayangnya, App Runner tidak tersedia di seluruh region. Saat ini, hanya beberapa region saja yang support App Runner, seperti yang dapat dilihat pada tabel di atas.

AWS Lambda

#

AWS Lambda adalah compute service yang menjalankan kode tanpa perlu mengelola server. Kode berjalan dengan scaling otomatis naik dan turun, dengan harga pay-per-use. Lambda menjalankan kode di infrastruktur komputasi high-availability milik AWS.

Karena Lambda adalah serverless, event-driven compute service, Lambda menggunakan paradigma pemrograman yang berbeda dari aplikasi web tradisional.

Perlu diperhatikan bahwa AWS Lambda memiliki beberapa limitasi. Salah satu yang paling noticable adalah batas 6MB yang berlaku untuk request dan response payload. Hal ini bisa menjadi masalah jika memiliki HTTP API yang memperbolehkan pengguna meng-upload gambar dan file ke S3.

Jadi, pake apa?

#

Begini perbandingan keempat layanan serverless container di AWS yang sudah kita bahas tadi:

Lambda cocok untuk short-running tasks dan cron jobs, tapi dibatasi maksimal 15 menit runtime.

App Runner paling simple untuk aplikasi request response sederhana. Memang tidak menyediakan opsi konfigurasi yang terlalu detail, tapi cukup untuk kebanyakan aplikasi.

ECS Fargate itu agak kompleks, tapi menawarkan fleksibilitas dan kontrol konfigurasi yang lebih luas daripada App Runner.

EKS Fargate cocok untuk workload yang sangat besar dengan ekosistem Kubernetes yang luas, tapi tradeoffnya adalah, kompleksitasnya paling tinggi.

Jadi sebenarnya, AWS menyediakan beberapa opsi layanan container yang tersusun dalam beberapa layer.

Di layer provisioning ada AWS App Runner, AWS Elastic Beanstalk, dan Amazon Lightsail. Fokus mereka adalah menyederhanakan proses deployment tanpa perlu mengurus infrastruktur. Lanjut ke layer orchestration ada Amazon ECS, Amazon EKS, dan ROSA yang fokus ke orkestrasi container. Di paling bawah ada layer capacity, terdiri dari Amazon EC2 dan AWS Fargate. Pada dasarnya, keduanya adalah computing resource untuk menjalankan semua layanan container tersebut.

Semakin ke atas layernya, semakin sedikit yang perlu dikelola. Semakin ke bawah, semakin banyak kontrol yang didapat tapi juga semakin banyak yang harus dimanage sendiri.

Studi Kasus di Campushub Universitas Brawijaya

#

Kita ambil satu contoh yaitu Campushub, salah satu produk startup internal yang diciptakan mahasiswa Universitas Brawijaya. Dalam pengembangannya, aplikasi ini cukup simple, hanya terdiri dari frontend React dan backend Laravel. Kira-kira, apa solusi scalable deployment yang cocok untuk productionnya dari mulai skala kecil?

Murah gak, sih?

#

Karena masih dalam production skala kecil, Campushub hanya butuh spesifikasi kecil, sekitar 0.5 vCPU dan 1GB RAM per service. Perlu diingat juga, Campushub butuh autoscaling untuk antisipasi lonjakan traffic setelah grand launching.

Berikut perbandingan biaya bulanan untuk menjalankan 1 service di layanan container yang telah kita bahas, pada region singapore.

Rincian kalkulasinya sebagai berikut.

App Runner mengenakan $0.064/vCPU-hour untuk *active instance* dan $0.007/GB-hour untuk memori.² Yang menarik, ketika traffic sedang kosong, instance akan masuk ke mode idle dan hanya dikenakan biaya memori tanpa biaya vCPU. Dengan asumsi hanya active sekitar 300 jam per bulan, maka:

• vCPU (aktif 300 jam): 0.5 x $0.064 x 300 = $9.60
• RAM (730 jam penuh, termasuk idle): 1 x $0.007 x 730 = $5.11
• Total per service: $14.71/bulan

ECS Fargate mengenakan $0.05056/vCPU-hour dan $0.00553/GB-hour di ap-southeast-1 (Linux/x86).³ Fargate tidak punya mekanisme idle seperti App Runner. Selama task berjalan, biayanya tetap sama terlepas dari ada traffic atau tidak. Untuk 0.5 vCPU dan 1GB RAM yang berjalan 24/7 selama 730 jam:

• vCPU: 0.5 x $0.05056 x 730 = $18.45
• RAM: 1 x $0.00553 x 730 = $4.04
• Total per service: $22.49/bulan

EKS EC2 dan EC2 standalone menggunakan instance t4g.micro (2vCPU 1GB RAM) seharga $0.0106/jam di ap-southeast-1. Sehingga, biayanya dihitung per instance, bukan per container:

• Biaya instance: $0.0106 x 730 = $7.74/bulan

Sehingga untuk 2 service, totalnya sekitar $29.42/bulan dengan App Runner. Nominal tersebut jauh lebih rendah dibandingkan ECS Fargate dan EKS EC2.

Memang, EC2 standalone lebih murah. Apalagi kedua service bisa dijalankan di instance yang sama, sehingga totalnya tetap $7.74/bulan. Tapi tidak ada *autoscaling*, tetap di*charge* penuh walaupun *traffic* kosong, dan harus memaintenance segalanya sendiri. Untuk EKS EC2, ditambah biaya *cluster* EKS $0.10/jam menjadi $80.74/bulan.⁴

Maka dari itu, untuk Campushub yang masih dalam tahap production berskala kecil dengan traffic ringan, App Runner menjadi solusi managed service yang paling cocok. Harganya affordable, simple, scalable, dan reliable.

Mari Implementasi!

#

Campushub terdiri dari dua komponen, yaitu frontend React dan backend Laravel. Keduanya dicontainerize menggunakan Docker dan dideploy ke App Runner melalui ECR.

Push Image ke ECR

#

Pertama, mari kita buat registry ECR terlebih dahulu untuk container image Campushub. Cari layanan ECR melalui pencarian di console.

Klik tombol create pada bagian create repository.

Berikan nama untuk repository yang akan dibuat untuk kedua image, yaitu frontend dan backend. Biarkan value yang lainnya default saua. Lalu, klik create pada bagian bawah.

Jika berhasil, nantinya akan muncul kedua repository sebagai berikut.

Kemudian, push image Campushub ke ECR tadi. Bisa menggunakan AWS CLI yang sudah terpasang pada server yang memiliki imagenya. Jika belum terpasang, baca panduannya di sini.

aws login --remote
aws ecr get-login-password --region ap-southeast-1 | docker login --username AWS --password-stdin 768052528660.dkr.ecr.ap-southeast-1.amazonaws.com

docker tag campushub-backend:latest 768052528660.dkr.ecr.ap-southeast-1.amazonaws.com/campushub/backend:latest
docker push 768052528660.dkr.ecr.ap-southeast-1.amazonaws.com/campushub/backend:latest

docker tag campushub-frontend:latest 768052528660.dkr.ecr.ap-southeast-1.amazonaws.com/campushub/frontend:latest
docker push 768052528660.dkr.ecr.ap-southeast-1.amazonaws.com/campushub/frontend:latest

Membuat IAM Role untuk App Runner

#

Sebelum membuat App Runner service, diperlukan sebuah IAM role yang mengizinkan App Runner untuk menarik image dari ECR. Tanpa role ini, App Runner tidak punya akses ke private repository ECR.

aws iam create-role \
  --role-name CampushubAppRunnerECRAccessRole \
  --assume-role-policy-document '{
    "Version": "2012-10-17",
    "Statement": [
      {
        "Effect": "Allow",
        "Principal": {
          "Service": "build.apprunner.amazonaws.com"
        },
        "Action": "sts:AssumeRole"
      }
    ]
  }'

aws iam attach-role-policy \
  --role-name CampushubAppRunnerECRAccessRole \
  --policy-arn arn:aws:iam::aws:policy/service-role/AWSAppRunnerServicePolicyForECRAccess

Command pertama membuat IAM role dengan trust policy yang mengizinkan App Runner untuk meng-assume role tersebut. Command kedua meng-attach policy bawaan AWS yang memberikan akses read-only ke ECR.

ARN dari role yang baru dibuat akan digunakan sebagai AccessRoleArn pada konfigurasi App Runner service di langkah selanjutnya.

Membuat App Runner Service

#

App Runner service bisa dibuat melalui AWS Console atau CLI. Supaya lebih mudahnya, berikut contoh jika menggunakan CLI.

Pertama, kita buat dahulu service untuk bacFWkend.

aws apprunner create-service \
  --service-name campushub-backend \
  --source-configuration '{
    "AuthenticationConfiguration": {
      "AccessRoleArn": "arn:aws:iam::768052528660:role/CampushubAppRunnerECRAccessRole"
    },
    "AutoDeploymentsEnabled": true,
    "ImageRepository": {
      "ImageIdentifier": "768052528660.dkr.ecr.ap-southeast-1.amazonaws.com/campushub/backend:latest",
      "ImageConfiguration": {
        "Port": "8000",
        "RuntimeEnvironmentVariables": {
          "APP_NAME": "Campushub-API",
          "APP_ENV": "production",
          "APP_KEY": "[redacted]",
          "APP_DEBUG": "false",
          "APP_TIMEZONE": "Asia/Jakarta",
          "APP_URL": "[redacted]",
          "DB_CONNECTION": "mysql",
          "DB_HOST": "[redacted]",
          "DB_PORT": "[redacted]",
          "DB_DATABASE": "[redacted]",
          "DB_USERNAME": "[redacted]",
          "DB_PASSWORD": "[redacted]",
          "JWT_SECRET": "[redacted]",
          "JWT_TTL": "1440"
        }
      },
      "ImageRepositoryType": "ECR"
    }
  }' \
  --instance-configuration '{"Cpu": "512", "Memory": "1024"}' \
  --region ap-southeast-1

Setelah service berhasil dibuat, App Runner akan memberikan URL default berformat https://<random-id>.<region>.awsapprunner.com. URL ini bisa diakses langsung atau dikonfigurasi dengan custom domain. URL dari backend dapat dimasukkan ke image frontend pada proses build. Sehingga, pada proses ini sebenarnya harus membuild ulang image frontend dan menguploadnya ke ECR kembali.

Jika sudah, maka bisa konfigurasi untuk service frontend.

aws apprunner create-service \
  --service-name campushub-frontend \
  --source-configuration '{
    "AuthenticationConfiguration": {
      "AccessRoleArn": "arn:aws:iam::768052528660:role/CampushubAppRunnerECRAccessRole"
    },
    "AutoDeploymentsEnabled": true,
    "ImageRepository": {
      "ImageIdentifier": "768052528660.dkr.ecr.ap-southeast-1.amazonaws.com/campushub/frontend:latest",
      "ImageConfiguration": {
        "Port": "3000"
      },
      "ImageRepositoryType": "ECR"
    }
  }' \
  --instance-configuration '{"Cpu": "512", "Memory": "1024"}' \
  --region ap-southeast-1

Perlu dicatat bahwa, konfigurasi di atas artinya adalah:

1. AutoDeploymentsEnabled diset true supaya App Runner otomatis melakukan deployment setiap kali image baru dipush ke ECR.

2. Cpu dan Memory dikonfigurasi dalam satuan milliCPU dan MB. 512 CPU berarti 0.5 vCPU, dan 1024 Memory berarti 1GB RAM.

3. AccessRoleArn di AuthenticationConfiguration wajib ada untuk private ECR repository, karena App Runner membutuhkan role ini untuk menarik image dari ECR.

Setelah deployment menggunakan App Runner telah berhasil, setiap kali image baru dipush ke ECR, App Runner akan mendeteksi perubahan dan melakukan rolling deployment tanpa adanya downtime. Sehingga, tidak perlu mengelola cluster, task definition, atau service update seperti di ECS.

Lalu, bagaimana dengan autoscalingnya? App Runner secara default sudah menggunakan konfigurasi autoscaling bernama DefaultConfiguration dengan parameter berikut:⁵

Artinya, dengan konfigurasi Campushub 0.5 vCPU dan 1GB RAM saat ini, App Runner akan selalu menjalankan minimal 1 instance. Ketika satu instance sudah menangani 100 concurrent request, App Runner otomatis menambah instance baru dengan spek yang sama. Proses ini berlanjut hingga mencapai batas maksimum 25 instance. Ketika traffic menurun, instance tambahan akan discale down kembali. Sebenarnya konfigurasi autoscaling ini bisa dicustom melalui create-auto-scaling-configuration jika diperlukan.