AWS Summit Jakarta 2026 · Seri Sesi

Tagihan AWS Anda Memberitahu Setengah Cerita

Dari total tagihan cloud menuju unit economics: biaya per pesanan, per pengguna, per cangkir kopi.
Kode STP105Level 100 · DasarStartup Zone · FinOps
Edisi Pertama · 2026 · Bagian dari seri 61 sesi
Startup Zone · FinOps

Tentang Sesi Ini

01

Ringkasan & metadata

STP10513:30 WIBFloor 4, Expo Zone 2 (Startup Zone) Level 100 · DasarBahasa IndonesiaPembicara: Fore Coffee

Sesi ini dibawakan oleh tim Fore Coffee — jaringan kopi yang bertumbuh cepat dengan aplikasi pemesanan, promo, dan operasi digital di ratusan gerai. Pesan utamanya sederhana tetapi menohok: angka besar di tagihan AWS Anda hanya menceritakan setengah kisah. Tahu bahwa "bulan ini bayar Rp X" tidak memberitahu apakah pengeluaran itu sehat atau boros. Yang benar-benar penting adalah unit economics: berapa biaya cloud untuk setiap pesanan, pengguna aktif, atau transaksi.

Ini adalah inti dari FinOps (Cloud Financial Operations) — praktik dan budaya menghubungkan biaya cloud dengan nilai bisnis. Alih-alih melihat tagihan sebagai satu angka misterius di akhir bulan, FinOps mengajak tim engineering dan finance duduk bersama untuk menjawab: "biaya ini untuk apa, dan apakah sepadan?" Sesi Level 100 ini membumikan konsep tersebut lewat pengalaman nyata sebuah bisnis F&B/ritel yang setiap harinya melayani ribuan cangkir kopi.

Kenapa penting untuk Anda? Jika biaya cloud Anda terus naik seiring pertumbuhan tetapi Anda tak yakin apakah itu wajar, sesi ini memberi kerangka: ubah tagihan agregat menjadi metrik per unit yang bisa dibandingkan, dipantau, dan diperbaiki.
Konteks Nyata · Fore Coffee

Fore Coffee (PT Fore Kopi Indonesia Tbk) adalah jaringan kedai kopi Indonesia berbasis teknologi/aplikasi — memposisikan diri sebagai peritel kopi yang memadukan kopi dengan teknologi, dengan aplikasi untuk pemesanan (ambil sendiri maupun antar), promo, dan operasi digital. Perusahaan resmi IPO di Bursa Efek Indonesia pada 14 April 2025 dengan kode saham FORE, menghimpun dana sekitar Rp353,44 miliar. Dari sisi skala, gerai tumbuh cepat: sekitar 216 gerai di 43 kota plus 1 gerai di Singapura (per September 2024), menjadi sekitar 291 gerai pada September 2025, dengan target hingga 600 gerai dalam lima tahun. Pada tahun buku 2025 perusahaan membukukan pendapatan bersih sekitar Rp1,5 triliun dan laba bersih sekitar Rp90 miliar. Skala ratusan gerai dengan lalu lintas transaksi harian yang besar inilah yang membuat pembahasan unit economics (biaya cloud per pesanan / per cangkir) menjadi sangat relevan. Catatan: penggunaan AWS maupun praktik FinOps spesifik Fore Coffee tidak ditemukan dipublikasikan; justru yang terpublikasi adalah kolaborasi cloud Fore Coffee dengan Google Cloud (program Indonesia BerdAIa) — sehingga detail layanan/arsitektur AWS pada sesi ini bersifat ilustratif untuk menjelaskan konsep.

Sumber: Bursa Efek Indonesia / rilis IPO Fore Coffee; laporan media ekonomi Indonesia (Infobank, Bisnis.com, Bareksa) soal jumlah gerai, kinerja 2025, dan target ekspansi; blog resmi Google Cloud Indonesia; Wikipedia (profil Fore Coffee). Detail arsitektur spesifik sesi ilustratif kecuali disebutkan.

Konsep Inti

Kenapa Tagihan Total Tak Cukup

02

Setengah cerita di balik tagihan

Bayangkan tagihan AWS bulanan sebagai satu angka besar: misalnya "Rp 200 juta". Angka itu naik 20% dibanding bulan lalu. Apakah itu buruk? Belum tentu. Kalau jumlah pesanan naik 40% di bulan yang sama, artinya biaya per pesanan justru turun — Anda makin efisien. Sebaliknya, jika pesanan hanya naik 5% tapi tagihan naik 20%, ada yang bocor. Tagihan total tidak bisa membedakan dua situasi itu; unit economics bisa.

Kuncinya adalah menautkan setiap rupiah cloud ke metrik bisnis. Untuk Fore Coffee, metrik itu bisa berupa "biaya AWS per cangkir kopi terjual" atau "biaya per pengguna aktif harian". Begitu biaya dinyatakan per unit, ia menjadi bahasa yang dimengerti semua orang — engineering, finance, sampai pemilik bisnis — dan bisa dilacak naik-turunnya dari waktu ke waktu.

Untuk sampai ke sana, dibutuhkan tiga hal mendasar: tagging & alokasi biaya (menempelkan label pada setiap sumber daya agar tahu biaya itu milik tim/fitur/produk mana), Cost & Usage Report (data rinci mentah tiap baris biaya), dan budaya FinOps (kolaborasi rutin engineering–finance, bukan sekadar tools).

Perangkat FinOps di AWS

Sesi menyoroti sejumlah layanan dan praktik yang membantu Anda melihat cerita lengkapnya:

Cost ExplorerVisualisasi & tren biaya
AWS BudgetsAmbang & peringatan biaya
Cost & Usage ReportData biaya paling rinci
TaggingLabel & alokasi biaya
Cost Anomaly DetectionDeteksi lonjakan tak wajar
ObservabilityKaitkan biaya ke performa
Alokasi BiayaBiaya per tim/fitur/produk

Perangkat ini saling melengkapi. Tagging menjadi fondasi — tanpa label, semua biaya menjadi satu tumpukan tak terpisahkan. Cost & Usage Report menyediakan data mentahnya, Cost Explorer menjadikannya grafik yang mudah dibaca, Budgets dan Cost Anomaly Detection memberi peringatan dini, dan Observability menautkan angka biaya dengan angka bisnis sehingga muncullah unit economics.

Perumpamaan

Analogi yang Mudah Dicerna

03

Ibarat bon belanja bulanan

Ibaratnya, tagihan AWS total itu seperti total belanja bulanan keluarga. Anda tahu bulan ini menghabiskan Rp 5 juta — tapi angka itu saja tak memberitahu apa pun tentang keputusan. Apakah boros? Apakah hemat? Anda tidak tahu sampai membuka rincian per item: mana yang sepadan (beras, sayur), dan mana yang boros (langganan yang tak terpakai, jajan berlebih).

BON TOTAL = Rp ?? Boros? Hemat? Tak tahu. RINCIAN PER ITEM Compute — biaya per pesanan Database — biaya per pengguna Jaringan — biaya per cangkir Unit economics jelas Tahu mana boros, mana sepadan.
Analogi: total bon vs rincian per item — hanya rincian yang mengungkap boros vs sepadan.
Arsitektur

High-Level Architecture & Alur

04

High-Level Architecture (HLA)

Secara garis besar, alur data FinOps terlihat seperti ini: sumber daya cloud yang sudah ditag menghasilkan data biaya rinci lewat Cost & Usage Report, yang lalu divisualisasikan di Cost Explorer, dijaga oleh Budgets dan Anomaly Detection, dan — yang paling penting — ditautkan ke metrik bisnis (jumlah pesanan, pengguna, cangkir kopi) untuk menghasilkan unit economics yang dibaca bersama oleh engineering dan finance.

Sumber daya(bertag) CUR(data biaya) Cost Explorer Budgets Anomaly Detect. Alokasi biaya Metrik bisnis → Unit economics (biaya per pesanan / per cangkir)
HLA: sumber daya bertag → CUR → Cost Explorer/Budgets/Anomaly, lalu ditautkan ke metrik bisnis jadi unit economics.

Alur dari tagihan ke unit economics

Bagaimana perjalanan dari "satu angka besar" menjadi "biaya per cangkir kopi"? Inilah langkah-langkahnya:

  1. Tag semua sumber daya. Beri label (mis. tim, fitur, lingkungan) pada tiap sumber daya agar biayanya bisa dipisah.
  2. Kumpulkan data. Cost & Usage Report mencatat tiap baris biaya secara rinci.
  3. Visualisasikan. Cost Explorer mengubahnya jadi grafik tren yang mudah dibaca.
  4. Tautkan ke bisnis. Bagi biaya dengan metrik bisnis (jumlah pesanan/pengguna) → dapat biaya per unit.
  5. Pantau & waspadai. Budgets dan Anomaly Detection memberi peringatan bila unit cost melonjak.
  6. Kolaborasi & perbaiki. Engineering + finance meninjau bersama dan mengambil tindakan efisiensi.
TagCURVisual÷ BisnisUnit cost
Alur FinOps: tag → CUR → visual → dibagi metrik bisnis → biaya per unit (dipantau & diperbaiki).
Contoh Penerapan

Dari Konsep ke Bisnis Nyata

05

Contoh nyata (konteks Indonesia)

Agar tidak berhenti di teori, berikut tiga skenario penerapan unit economics lintas jenis bisnis di Indonesia.

Contoh Penerapan · F&B / Ritel

Fore Coffee — biaya AWS per pesanan

Jaringan kopi dengan aplikasi pemesanan mentag sumber daya per fitur (katalog, checkout, promo). Dengan Cost & Usage Report dan Cost Explorer, tim menghitung biaya cloud per pesanan dan per cangkir terjual. Ketika kampanye promo besar membuat lalu lintas melonjak, mereka bisa memastikan biaya per pesanan tetap sehat — bukan sekadar melihat total tagihan naik dan panik. Anomaly Detection menangkap lonjakan tak wajar sejak dini.

Contoh Penerapan · Startup

Mengejar efisiensi menuju profitabilitas

Startup tahap awal punya runway terbatas. Dengan menautkan biaya ke pengguna aktif, mereka tahu berapa biaya melayani tiap pengguna dan apakah itu menurun seiring skala (tanda model yang sehat). Budgets menjaga pengeluaran agar tak melampaui rencana, dan budaya FinOps membuat setiap keputusan arsitektur mempertimbangkan dampak biaya per unit sejak awal.

Contoh Penerapan · SaaS

Unit economics per pelanggan & per tenant

Penyedia SaaS B2B mentag sumber daya per tenant sehingga tahu biaya melayani tiap pelanggan. Ini memungkinkan penetapan harga yang sehat (pastikan margin positif per pelanggan) dan mengidentifikasi pelanggan "berat" yang boros. Alokasi biaya berbasis tag menjadi tulang punggung analisis profitabilitas per lini produk.

Mode Slide

Ringkasan Visual (Geser)

06

Ringkasan visual

Enam kartu berikut merangkum inti sesi. Gunakan tombol atau tombol panah keyboard (← →) untuk berpindah.

STP105 · Slide 1

Tagihan total = setengah cerita

Satu angka besar tak memberitahu apakah pengeluaran cloud Anda sehat atau boros.

1 / 6
STP105 · Slide 2

Yang penting: unit economics

Biaya per pesanan, per pengguna, per cangkir kopi — bahasa yang dimengerti semua tim.

2 / 6
STP105 · Slide 3

Fondasinya: tagging

  • Tag → alokasi biaya per tim/fitur/produk
  • Cost & Usage Report → data mentah rinci
  • Cost Explorer → visual tren
3 / 6
STP105 · Slide 4

Analogi bon belanja

Total bon tak cukup; rincian per item mengungkap mana yang boros dan mana yang sepadan.

4 / 6
STP105 · Slide 5

Jaga & waspadai

Budgets + Cost Anomaly Detection memberi peringatan dini saat unit cost melonjak.

5 / 6
STP105 · Slide 6

Bawa pulang

FinOps = budaya kolaborasi engineering & finance. Mulai dari tag, tautkan biaya ke metrik bisnis.

6 / 6
Penutup

Poin yang Bisa Dibawa Pulang

07

Poin yang bisa dibawa pulang

Tentang Buku Ini
Sainskerta · Seri AWS Summit Jakarta 2026

Buku ini adalah rangkuman edukatif independen atas satu sesi AWS Summit Jakarta 2026, dibuat agar materi tetap bisa dipelajari oleh mereka yang tak sempat hadir. Bukan materi resmi AWS maupun Fore Coffee; seluruh nama produk & merek adalah milik pemiliknya masing-masing. Contoh penerapan bersifat ilustratif.

Bagian dari seri 61 sesi AWS Summit Jakarta 2026 — satu buku untuk tiap sesi.