AI Agent Workflow Automation untuk Audit Biaya Cloud dengan n8n: Deteksi Pemborosan, Auto-Tagging, dan Slack Alert Harian
· 7 menit baca
AI Agent Workflow Automation untuk Audit Biaya Cloud dengan n8n: Deteksi Pemborosan, Auto-Tagging, dan Slack Alert Harian
Tim kecil pakai AWS/GCP/Azure biasanya ngalamin pola yang sama: awalnya biaya cloud “masih wajar”, lalu tiba-tiba membengkak dan semua orang panik. Masalahnya bukan karena cloud itu mahal—tapi karena biaya cloud itu mudah bocor: instance lupa dimatikan, storage numpuk, NAT gateway diam-diam jadi “pajak harian”, log retention kebablasan, sampai resource tanpa tag yang akhirnya nggak jelas punya siapa. Di artikel ini kita akan bikin AI Agent workflow automation pakai n8n automation untuk audit biaya cloud secara rutin: deteksi anomali, rekomendasi tindakan, auto-tagging, dan kirim alert harian ke Slack.
Catatan: ini bukan artikel “apa itu FinOps”. Ini tutorial gaya build dulu, rapikan sambil jalan alias vibe coding, tapi tetap production-minded.
Kenapa “AI Agent workflow automation” itu cocok buat audit biaya cloud?
Audit biaya cloud itu bukan sekali setup terus beres. Dia ritual harian/mingguan yang repetitif tapi butuh penilaian kontekstual:
- “Lonjakan biaya ini wajar nggak?” (butuh konteks release, traffic, campaign)
- “Resource ini aman dimatikan nggak?” (butuh baca tag, owner, log pemakaian)
- “Ini kesalahan konfigurasi atau perubahan harga?” (butuh interpretasi billing)
Di sinilah AI Agent berguna. Bukan buat “menebak biaya”, tapi buat mengubah data billing + usage jadi actionable checklist yang bisa langsung dieksekusi tim.
Konsepnya singkat: AI Agent = analis FinOps + sekretaris yang cerewet
Bayangin kamu punya analis yang tiap pagi:
- narik data cost & usage,
- nge-flag yang aneh,
- nyari resource penyebabnya,
- nulis rekomendasi yang spesifik,
- dan nge-ping Slack ke channel yang tepat.
Itu yang kita bangun: AI Agent workflow automation berbasis n8n. Kuncinya: AI Agent hanya boleh “mengusulkan” untuk tindakan berisiko (terminate), tapi boleh “mengeksekusi” untuk tindakan aman (tagging, notifikasi, membuat ticket).
AI Agent workflow automation: arsitektur workflow (versi produksi tapi tetap ringan)
Target output harian: 1 pesan Slack berisi “Top 5 pemborosan” + 1 ringkasan “trend biaya” + tombol/command untuk follow-up (ticket/Jira/Linear).
1) Data Ingest: tarik cost harian (AWS contoh) — AI Agent workflow automation
- Trigger: Cron (setiap jam 08:00)
- HTTP Request / custom node: panggil AWS Cost Explorer API (GetCostAndUsage)
- Normalize: ubah response jadi tabel: date, service, region, cost, usageType (kalau ada)
Tip: kalau kamu multi-cloud, mulai dari satu dulu. “Satu cloud yang beres” lebih bernilai daripada “tiga cloud setengah matang”.
2) Deteksi anomali sederhana (tanpa ML ribet) — AI Agent workflow automation
Jangan langsung lompat ke model anomaly detection canggih. Dalam banyak kasus, aturan sederhana menang:
- MoM / WoW spike: biaya hari ini vs rata-rata 7 hari terakhir
- Service spike: top services by delta
- Budget threshold: per service/per environment
Di n8n, ini bisa dilakukan dengan:
- Code node (JavaScript) untuk hitung baseline & delta
- IF node untuk filter yang melewati threshold
3) Enrichment: mapping cost → resource candidates
Billing sering agregat; kamu butuh “petunjuk” ke resource yang bikin bengkak. Strategi praktis:
- Kalau spike di EC2: tarik daftar instance + metrik (CPU, Network, status) dari CloudWatch / AWS API
- Kalau spike di EBS/S3: tarik bucket/volume growth, lifecycle policy, last accessed (kalau tersedia)
- Kalau spike di NAT Gateway/Data Transfer: cari VPC + top talkers (butuh flow logs/observability)
Di n8n, kamu bisa pakai kombinasi HTTP Request ke API cloud + query ke tool observability (Datadog/CloudWatch Logs/ELK) kalau kamu punya.
4) AI Agent: ubah data mentah jadi rekomendasi yang bisa dieksekusi
Masukkan ke LLM bukan “data billing raw 1 minggu full”. Itu boros token dan bikin jawaban ngaco. Beri ringkasan terstruktur:
- Top 10 services by cost hari ini
- Top 10 services by delta vs baseline
- Daftar resource kandidat (mis. 15 instance) lengkap dengan tag, umur, CPU avg, owner (kalau ada)
- Kebijakan internal: jam kerja, environment (prod/staging), resource yang never terminate
Prompt template (inti):
Role: Kamu adalah FinOps assistant.
Tujuan: Identifikasi pemborosan biaya cloud yang paling mungkin, berikan rekomendasi tindakan yang aman.
Aturan:
- Jangan menyarankan terminate resource produksi kecuali ada bukti sangat kuat.
- Prioritaskan tindakan non-destruktif: tagging, rightsizing proposal, jadwal stop/start, lifecycle policy.
- Output harus JSON: {summary, findings[], actions[]}
Data:
- cost_summary: ...
- deltas: ...
- resources: ...
- policies: ...
Output JSON ini penting supaya workflow bisa lanjut otomatis (mis. bikin ticket). Ini cara paling gampang bikin AI Agent yang “nggak cuma ngomong”.
5) Action layer: auto-tagging + ticket + Slack alert — n8n automation
Setelah AI kasih rekomendasi, kita split jadi 2 jalur:
- Low-risk auto actions: auto-tagging resource yang missing tag, bikin laporan, bikin ticket.
- High-risk actions: butuh approval (mis. stop instance prod, reduce DB tier).
Implementasi di n8n:
- Parse JSON dari output LLM (Set/Code node)
- Loop Over Items untuk actions[]
- IF: action.type == "AUTO_TAG" → call API tagging
- IF: action.type == "CREATE_TICKET" → Jira/Linear node
- IF: action.risk == "HIGH" → kirim Slack message dengan tombol approve
Kalau mau approval beneran, kamu bisa:
- pakai Slack interactive message → webhook n8n → lanjut eksekusi, atau
- pakai form internal (Retool/Next.js mini app) yang memanggil webhook n8n.
Breakdown teknis workflow n8n (node-by-node) biar kamu bisa langsung build
A. Cron → Cost Explorer → Baseline Calculator
- Cron (08:00)
- HTTP Request: AWS Cost Explorer (GetCostAndUsage, GroupBy: SERVICE)
- Code: hitung baseline 7 hari, delta%, rank by delta
B. Router berdasarkan service yang spike
- IF: service in ["AmazonEC2"] → branch EC2
- IF: service in ["AmazonS3"] → branch S3
- IF: service in ["AWSLambda"] → branch Lambda
C. Enrichment per service
- EC2 branch:
- HTTP Request: DescribeInstances
- HTTP Request: CloudWatch GetMetricData (CPUUtilization 24h)
- Code: gabungkan instance + metrik + tags
- S3 branch:
- HTTP Request: ListBuckets + (opsional) Storage Lens / Inventory
- Code: estimasi growth dari metrik yang ada
D. LLM (AI Agent) → Structured JSON output
- LLM node (OpenAI/Anthropic/LLM lokal via HTTP)
- Set: simpan summary + actions
E. Execution + Notifikasi
- Split actions
- HTTP Request: Tagging API (CreateTags/TagResource)
- Jira/Linear: Create Issue
- Slack: Post message (ringkasan + link ticket + rekomendasi)
Contoh use case real: “Biaya EC2 naik 2x” padahal traffic normal
Skenario yang sering kejadian di startup/indie SaaS:
- Kemarin deploy fitur baru.
- Hari ini biaya EC2 naik 2x.
- Traffic normal, tapi CPU beberapa instance “flat” rendah.
Workflow kita akan menghasilkan output seperti:
- Finding: ada 6 instance non-prod berjalan 24/7 tanpa schedule, CPU avg 2–5% selama 24h.
- Action (low risk): tambahkan tag Environment=staging + Schedule=office-hours ke instance yang missing tag.
- Action (medium risk): buat ticket rightsizing: turunkan tipe instance dari m5.large → t3.medium (butuh cek memory/latency).
- Slack alert: “Potensi hemat: $18/hari (estimasi). Owner: @andi (berdasarkan tag/CMDB).”
Yang bikin ini beda dari laporan billing biasa: AI Agent menghubungkan spike → kandidat resource → rekomendasi aksi dan n8n langsung mengeksekusi yang aman (tagging + ticket), bukan cuma “dashboard cantik”.
Insight/strategi paling penting (bagian “aha moment”)
1) Jangan mulai dari “hemat biaya”, mulai dari “biaya punya siapa”
Hampir semua kebocoran biaya berakar dari satu hal: resource tanpa owner. Maka strategi pertama bukan anomaly detection, tapi tag governance.
- Define minimal tags: Owner, Environment, Service, CostCenter
- Buat AI Agent yang tugasnya menebak owner dari konteks (repo name, naming convention, security group name), lalu minta konfirmasi lewat Slack.
Begitu ownership jelas, penghematan jadi proses sosial yang gampang: tinggal ping orangnya.
2) AI Agent workflow automation harus punya “guardrails”, bukan cuma prompt bagus
Kalau kamu kasih AI akses untuk stop/terminate, kamu harus bikin pagar:
- Allowlist: hanya environment non-prod yang boleh auto-stop
- Time window: eksekusi hanya di jam tertentu
- Two-person rule: approval dari 2 orang untuk tindakan destruktif
- Dry-run mode: 1–2 minggu pertama hanya rekomendasi + ticket
Guardrails ini lebih penting daripada memilih model paling baru.
3) Vibe coding yang benar: mulai dari alert harian, baru evolusi ke auto-remediation
Banyak yang pengen langsung “auto-healing cost”. Realitanya, tim butuh trust dulu. Urutan yang biasanya berhasil:
- Phase 1: Slack daily digest + rekomendasi (no execution)
- Phase 2: auto-tagging + auto-ticketing
- Phase 3: auto-stop non-prod di luar jam kerja
- Phase 4: rightsizing semi-otomatis (approval)
Ini gaya build SaaS cepat dengan AI: shipping kecil tapi konsisten, bukan big-bang.
4) Simpan semua “temuan → keputusan → hasil” untuk feedback loop
Kalau kamu cuma kirim alert, kamu nggak belajar. Simpan ke database sederhana (Postgres/Supabase/Notion):
- finding_id, tanggal, service, estimasi hemat
- aksi yang diambil (approved/rejected)
- hemat aktual setelah 7 hari
Nanti AI Agent bisa makin tajam: dia belajar rekomendasi mana yang sering ditolak, dan memperbaiki kualitasnya. Ini workflow automation yang benar-benar “hidup”.
Penutup: build “FinOps Bot” kamu minggu ini
Kalau kamu punya cloud bill yang mulai bikin deg-degan, bikin 1 workflow n8n sederhana dulu: tarik cost harian → hitung spike → kirim Slack. Setelah itu, tambahin AI Agent untuk nulis rekomendasi + auto-tagging. Dalam 2–3 iterasi kamu sudah punya AI Agent workflow automation yang ngasih dampak nyata.
Call to action: coba build versi MVP-nya hari ini. Kalau kamu mau, balas dengan stack kamu (AWS/GCP/Azure + tool tiket + Slack/Teams) dan target penghematan, nanti aku bikinin outline workflow node-by-node yang lebih spesifik (termasuk contoh payload API dan struktur output JSON untuk AI Agent).