Efisiensi Cost Secret Manager pada Cloud Run dan GKE

Ada kejutan yang sering kali baru disadari saat tagihan bulanan datang: Keamanan meningkat, tetapi biaya API Call membengkak.

Mengapa hal ini bisa terjadi? Jawabannya terletak pada ketidak pahaman kita terhadap behavior penarikan biaya (billing components). Oke, pembicaraan ini fokus ke Secret Manager, yak. karena kalian — kalian yang kerjanya ngurusin efisiensi cost pastinya mengurutkan dari atas sampai bawah tiap-tiap komponen cost, dan bilang :

“mana nih yang bisa di turunin?”

iya, nggak? . Artikel ini akan membedah bagaimana Secret Manager mengenakan biaya dan bagaimana strategi implementasi terbaik pada Cloud Run dan GKE demi efisiensi cost yang maksimal.

Mungkin kita pernah beranggapan bahwa menyimpan banyak secret sama dengan komponen mahal, atau biasa aja karna gak perlu lihat cloud-billing?. Faktanya, skema biaya GCP Secret Manager (maupun mayoritas cloud provider lainnya) dibagi menjadi dua:

1. Volume/Storage: Biaya per versi secret yang aktif
2. API Operations: Biaya setiap kali sistem melakukan akses atau penarikan data (Secret Access Requests).

Mungkin Angka biaya API Operations terlihat sangat kecil. Namun, bayangkan jika aplikasi microservices kamu melayani 10 ribu requests per detik (RPS), dan kode aplikasi kamu diprogram untuk memanggil SDK Secret Manager setiap kali membutuhkan koneksi database atau API key pihak ketiga. “ngeriiii”.

Misalnya nih ya :

10.000 RPS dikali 24 jam = 864.000.000 API calls dalam sehari . Tagihan? bisa Sekitar Rp40 Juta HANYA DALAM SEHARI untuk membaca password database. Sebuah malapetaka finansial.

Oleh karena itu, kunci efisiensi Secret Manager adalah mengurangi frekuensi API Call tanpa mengorbankan keamanan.

1. Arsitektur Terbaik pada Cloud Run: Native Secret Integration

Jika kamu menggunakan Serverless seperti Cloud Run, hindari menggunakan Google Cloud SDK di dalam kode aplikasi untuk menarik secret secara real-time (kecuali kamu mengimplementasikan mekanisme in-memory caching yang rumit). lagi males buat diagram arsitektur, generete pake e-ay gak papa kan yaa :

Strategi Efisiensi:

Manfaatkan fitur Native Secret Manager Integration bawaan Cloud Run. Melalui Terraform, kita bisa langsung menempelkan (mount) nilai dari Secret Manager ke dalam Environment Variable atau sebagai Volume di dalam container.

Bagaimana Behavior Biayanya?

Dengan metode ini, Cloud Run hanya akan memanggil API Secret Manager satu kali per instance container, yaitu saat instance baru dibuat (startup, scale-up, atau saat deployment baru).

Setelah container berjalan, nilai rahasia tersebut menetap di memori container sebagai local env. Berapa pun jutaan request yang masuk ke aplikasi kamu, API Secret Manager tidak akan dipanggil lagi. Biaya operasional harian Anda? Mendekati $0.

2. Arsitektur Terbaik pada GKE: Sinkronisasi ke Native Kubernetes Secret

Di dunia Kubernetes (GKE), siklus hidup Pod sangat dinamis (sering mati-nyala atau autoscaling). Ada dua jalan besar yang bisa kamu pilih untuk mengelola rahasia di sini:

lagi males buat diagram arsitektur, generete pake e-ay gak papa kan yaa :

Jalur A: Menggunakan External Secrets Operator (ESO) + Reloader

ESO bertugas sebagai jembatan yang mengambil nilai dari GCP Secret Manager, lalu menyalinnya menjadi kind: Secret lokal di dalam kluster. Pod aplikasimu kemudian hanya perlu membaca secret lokal tersebut.

apiVersion: external-secrets.io/v1beta1
kind: ExternalSecret
metadata:
  name: my-app-db-secret
spec:
  refreshInterval: "1h" # <--- contoh pakai refresh interval ESO
  target:
    name: credential-database
  # ...

• Behavior Biaya: Sangat hemat. Dengan parameter refreshInterval: "1h", ESO hanya memanggil API GCP 1 kali setiap jam. Jika aplikasi kamu melakukan autoscaling dari 1 Pod menjadi 100 Pod, biayanya tetap Rp 0 (Gratis) karena semua Pod hanya membaca data lokal kluster.

Reloader

Dipadukan dengan tool open-source bernama Reloader, setiap kali ESO mendeteksi password baru, GKE akan otomatis melakukan rolling restart pada Pod secara mulus tanpa downtime. Cari aja ya, sendiri Reloader.. hahaha

— — — — — — — — — — — — — — — — — — — — — — — — — — — — — — — — — — — —

Jalur B: Tanpa Operator Tambahan (Pendekatan Manual & Ramping)

Jika kamu ingin kluster tetap bersih tanpa third-party operator, atau kamu bekerja di perusahaan yang policy nya harus melakukan manual restart deployment (kubectl rollout restart) setiap kali ada perubahan rahasia:

1. Jembatan via Terraform (kubernetes_secret)

Terraform bertugas menarik nilai dari GCP Secret Manager saat kita melakukan terraform apply, lalu langsung menuliskannya ke kind: Secret lokal GKE.

• Behavior Biaya: Jujur, ini Paling murah secara mutlak. API call ke GCP hanya terjadi 1 kali saat proses apply infrastruktur. Mau Pod kamu restart ratusan kali atau crash-loop, biayanya tetap Rp 0. Namun, pastikan state file Terraform kamu diamankan karena nilai rahasia akan tersimpan di sana dalam bentuk teks biasa. Tricky sih

2. GKE Secrets Store CSI Driver (Fitur Resmi Google)

GKE akan me-mount GCP Secret Manager langsung ke dalam Pod sebagai bentuk file (volume mount). Nilai rahasia langsung melompat dari GCP ke memori Pod tanpa pernah transit di state file Terraform atau etcd kluster.

• Behavior Biaya: Biaya dihitung per startup Pod. Setiap kali Pod baru menyala (karena restart manual, deployment baru, atau scaling), CSI Driver akan melakukan 1x API Call ke GCP. Metode ini sangat aman, namun berpotensi memicu lonjakan biaya kecil jika klustermu memiliki ratusan Pod yang sering mengalami restart bersamaan. Tentunya kalian worry terkait pod yang tiba2 crash kaan ??

— — — — — — — — — — — — — — — — — — — — — — — — — — — — — — — — — — — -

Kesimpulan: Cerdas Memilih Lintasan Data

Tidak dipungkiri keamanan tinggi sejalan dengan biaya tinggi, namun aman di Cloud tidak harus berarti mahal (dalam konteks efisiensi cost). Dengan memahami konsep behavior biaya, kita bisa mengatur strategi efisiensi, misalnya pada case secret manager ini: kita bisa memisahkan lapisan fetching layer dari runtime consumption.

• Cloud Run: Gunakan native environment variable injection via Terraform.
• GKE (Skala Besar/Otomatis): Gunakan External Secrets Operator (ESO) + Reloader untuk mengunci biaya API via refreshInterval.
• GKE (Skala Kecil/Ramping): Gunakan pendekatan tanpa operator via injeksi Terraform langsung atau GKE CSI Driver, lalu lakukan rollout restart secara manual saat dibutuhkan.

Jadi, kita tidak hanya membangun infrastruktur yang kokoh dan aman, tetapi juga menjaga kesehatan finansial perusahaan.

Happy scaling, tanpa pusing tagihan! Enjoy your cost optimization

Bagaimana kamu mengelola Secret Manager di infrastruktur saat ini? Apakah kamu punya trik lain untuk menekan biaya API Call? Tulis di kolom komentar! mari berbagi pengalaman :D