Cost Allocation & Tagging #
Tagihan cloud yang besar tapi tidak terpilah adalah masalah yang besar. Kamu tahu total biayanya, tapi tidak tahu tim mana yang menghabiskan berapa, produk mana yang paling mahal untuk dioperasikan, atau resource mana yang sudah tidak dipakai tapi masih berjalan. Cost allocation adalah praktik memecah biaya cloud menjadi unit yang bermakna — per tim, per produk, per environment, per customer. Tagging adalah mekanisme teknis yang memungkinkan ini terjadi.
Mengapa Cost Visibility Penting #
Tanpa cost allocation:
Total tagihan AWS bulan ini: $50.000
→ Tim engineering: "ini normal atau tinggi?"
→ CTO: "biaya apa saja yang paling besar?"
→ Finance: "tim mana yang over-budget?"
→ Tidak ada yang bisa menjawab dengan pasti.
Konsekuensi:
✗ Tidak ada accountability — tidak ada yang "memiliki" biaya tertentu
✗ Sulit identifikasi pemborosan — tidak tahu mana yang mahal tanpa alasan
✗ Tidak bisa alokasi biaya ke produk/customer untuk pricing
✗ Anggaran cloud tidak bisa dibuat secara realistis
Dengan cost allocation:
Total tagihan: $50.000
├── Team Frontend: $5.000
│ ├── Production: $4.000
│ └── Development: $1.000
├── Team Backend: $18.000
│ ├── Production: $15.000
│ └── Development: $3.000
├── Team Data: $22.000
│ ├── ML Training: $12.000
│ └── Data Pipeline: $10.000
└── Shared Infrastructure: $5.000
Sekarang bisa dilakukan:
✓ "Team Data menghabiskan 44% biaya — apakah wajar?"
✓ "ML Training $12.000 — bisa dioptimasi dengan spot instances?"
✓ Anggaran per tim yang realistis
✓ Chargeback atau showback ke masing-masing tim
Tagging — Mekanisme Cost Allocation #
Tag adalah pasangan key-value yang di-attach ke resource cloud. Ketika konsisten diterapkan, ia memungkinkan filtering dan agregasi biaya berdasarkan dimensi yang bermakna.
Contoh Resource dengan Tag:
EC2 Instance: i-1234567890abcdef0
Tags:
Name: "api-server-prod-01"
Team: "backend"
Product: "checkout-service"
Environment: "production"
CostCenter: "CC-1234"
Owner: "[email protected]"
Resource yang sama di staging:
Team: "backend"
Product: "checkout-service"
Environment: "staging"
CostCenter: "CC-1234"
Dari tag ini, billing system bisa menjawab:
→ "Total biaya untuk Team backend"
→ "Total biaya Environment production"
→ "Total biaya Product checkout-service di Production"
→ "Total biaya CostCenter CC-1234"
Strategi Tagging yang Efektif #
Tag Standar yang Direkomendasikan #
Minimal tag set yang bermakna untuk hampir semua organisasi:
Environment:
Nilai: production | staging | development | sandbox
Tujuan: pisahkan biaya prod vs non-prod
Team:
Nilai: backend | frontend | data | platform | security
Tujuan: alokasi biaya per tim engineering
Product / Service:
Nilai: checkout-service | user-service | ml-pipeline
Tujuan: alokasi biaya per produk atau layanan
Owner:
Nilai: email tim atau nama tim
Tujuan: tahu siapa yang harus dihubungi jika ada anomali
CostCenter:
Nilai: kode cost center dari sistem finance
Tujuan: integrasi langsung dengan sistem accounting
ManagedBy / CreatedBy:
Nilai: terraform | manual | cloudformation | eksctl
Tujuan: tahu resource mana yang di-manage secara otomatis
vs yang dibuat manual (dan mungkin terlupakan)
Konvensi Penamaan Tag #
Konsistensi konvensi penamaan sangat penting:
// ANTI-PATTERN: Inkonsistensi yang merusak agregasi
Resource A: env = "prod"
Resource B: env = "production"
Resource C: environment = "Production"
Resource D: Env = "PROD"
→ Empat cara menulis hal yang sama
→ Agregasi biaya menghasilkan empat baris terpisah
→ Tidak bisa hitung total biaya production dengan mudah
// BENAR: Konvensi yang terdokumentasi dan dipaksakan
Key format: lowercase, kata-kata dipisah tanda hubung
Value format: lowercase, kata-kata dipisah tanda hubung
environment: "production"
environment: "staging"
environment: "development"
→ Selalu konsisten → agregasi bekerja dengan benar
→ Dokumentasikan daftar nilai yang diizinkan per tag
→ Paksakan melalui policy (Service Control Policy / Organization Policy)
Menerapkan Tagging di Seluruh Organisasi #
Tantangan tagging di skala besar:
✗ Resource yang dibuat manual tanpa tag → biaya tidak ter-alokasi
✗ Tag yang salah ketik → tidak ter-agregasi dengan benar
✗ Tim baru tidak tahu konvensi tag yang ada
✗ Tag yang di-set tapi tidak di-update ketika resource pindah tim
Solusi yang terstruktur:
1. Dokumentasikan tag standard dalam wiki/docs
→ Daftar tag yang wajib
→ Nilai yang diizinkan per tag
→ Contoh penggunaan
2. Enforce melalui IaC (Infrastructure as Code)
Semua resource yang dibuat via Terraform/CloudFormation
wajib include tag → lebih mudah di-enforce via PR review
# Terraform example
locals {
common_tags = {
Team = var.team
Product = var.product
Environment = var.environment
ManagedBy = "terraform"
}
}
resource "aws_instance" "api_server" {
# ... config
tags = merge(local.common_tags, {
Name = "api-server-${var.environment}"
})
}
3. Policy enforcement (Tag Policy / Budget Alerts)
→ Larang pembuatan resource tanpa tag wajib
→ Alert jika ada resource baru yang untagged
4. Regular auditing
→ Laporan mingguan: resource baru tanpa tag
→ Resource yang sudah lama tanpa owner yang jelas → review
Showback vs Chargeback #
Showback:
→ Tampilkan biaya kepada tim/produk tanpa transfer uang aktual
→ "Tim backend, ini biaya cloud kamu bulan ini: $18.000"
→ Tidak ada implikasi finansial langsung pada anggaran tim
→ Lebih mudah diimplementasikan secara organisasional
→ Membangun kesadaran biaya tanpa kompleksitas internal billing
Cocok untuk: awal implementasi cost culture,
tim yang masih belajar cloud cost management
Chargeback:
→ Biaya cloud benar-benar di-charge ke anggaran tim/BU/produk
→ Tim backend anggaran IT berkurang $18.000
→ Membutuhkan proses finance internal
→ Memberikan accountability yang lebih kuat
→ Tim punya insentif finansial untuk optimasi
Cocok untuk: organisasi dengan unit bisnis yang otonom,
mature cloud adoption dengan akuntabilitas jelas
Tantangan chargeback:
→ Bagaimana mengalokasikan shared infrastructure?
→ Overhead admin yang signifikan
→ Bisa menciptakan gesekan antar tim
Pendekatan umum:
→ Mulai dengan showback → bangun kesadaran dan proses
→ Setelah stabil, pertimbangkan chargeback untuk organisasi besar
Cost Anomaly Detection #
Bahkan dengan tagging yang sempurna, perlu mekanisme untuk
mendeteksi lonjakan biaya yang tidak terduga:
Cost Anomaly Detection (managed service):
→ Provider cloud punya layanan yang bisa mendeteksi anomali biaya
→ Alert ketika spending di luar pola historis
→ Contoh: biaya compute naik 300% dalam sehari tanpa alasan yang jelas
Skenario yang perlu dideteksi:
→ Resource yang terlupa di-terminate setelah eksperimen
→ Data transfer yang tidak terduga (mungkin misconfiguration)
→ Instance yang di-spin up oleh credentials yang bocor
→ Bug yang menyebabkan loop tak terbatas di serverless function
Setup minimum:
✓ Budget alert: notifikasi saat 80% dan 100% budget bulanan
✓ Cost anomaly detector: alert untuk lonjakan yang tidak terduga
✓ Weekly cost review: 15 menit untuk lihat breakdown dan tren
Ringkasan #
- Tanpa tagging, tagihan cloud adalah kotak hitam — kamu tahu totalnya tapi tidak tahu apa yang menyebabkannya dan siapa yang bertanggung jawab.
- Minimal tag set: environment, team, product, owner — empat tag ini sudah memungkinkan sebagian besar analisis biaya yang berguna.
- Konsistensi konvensi tagging lebih penting dari kelengkapannya — satu nilai yang tidak konsisten memecah agregasi dan membuat analisis tidak akurat.
- Enforce tagging melalui IaC dan policy, bukan hanya dokumentasi — manusia lupa; automasi tidak.
- Mulai dengan showback, pertimbangkan chargeback di kemudian hari — showback membangun kesadaran tanpa kompleksitas organisasional yang langsung.
- Cost anomaly detection untuk mendeteksi kejutan sebelum tagihan datang — budget alert + anomaly detector adalah safety net minimum yang harus dipasang.
← Sebelumnya: Cloud Pricing Model Berikutnya: Reserved & Savings Plans →