Virtual Machine #
Virtual Machine (VM) adalah unit komputasi paling fundamental di cloud. Sebelum container, serverless, dan managed services ada, VM adalah cara utama menjalankan workload di cloud — dan sampai hari ini ia masih menjadi fondasi dari hampir semua yang berjalan di atasnya. Memahami VM bukan hanya tentang “cara membuat instance” tapi tentang bagaimana virtualisasi bekerja, bagaimana memilih tipe yang tepat, dan bagaimana mengelola siklus hidupnya secara efisien.
Cara Kerja Virtualisasi #
VM bukan server fisik — ia adalah abstraksi software yang berjalan di atas hypervisor, sebuah lapisan software yang mengelola pembagian sumber daya hardware fisik ke banyak VM secara bersamaan.
Tanpa Virtualisasi (Bare Metal):
┌─────────────────────────┐
│ Satu Aplikasi │
├─────────────────────────┤
│ OS │
├─────────────────────────┤
│ Hardware Fisik │
└─────────────────────────┘
→ Utilisasi hardware sering rendah (10-20%)
→ Satu OS, satu workload per server
Dengan Virtualisasi:
┌──────────┐ ┌──────────┐ ┌──────────┐
│ App A │ │ App B │ │ App C │
├──────────┤ ├──────────┤ ├──────────┤
│ OS │ │ OS │ │ OS │
├──────────┘ ├──────────┘ ├──────────┘
│ VM A, B, C (virtual hardware)
├─────────────────────────────────────────
│ Hypervisor (KVM, VMware ESXi, Hyper-V)
├─────────────────────────────────────────
│ Hardware Fisik (satu server)
└─────────────────────────────────────────
→ Utilisasi hardware naik ke 60-80%
→ Beberapa OS dan workload berjalan bersamaan
→ Isolasi: VM A tidak bisa mengakses memori VM B
Hypervisor memastikan setiap VM mendapat alokasi CPU, memori, dan storage yang dijanjikan, dan bahwa satu VM tidak bisa memengaruhi atau mengakses resource VM lain — inilah yang membuat model multi-tenant cloud aman.
Anatomi Instance Cloud #
Ketika kamu membuat VM di cloud, ada beberapa komponen yang membentuknya.
Komponen Instance Cloud:
Compute:
vCPU — virtual CPU core yang dialokasikan
RAM — memori yang dialokasikan
Arsitektur — x86 (Intel/AMD) atau ARM
Storage:
Root volume — disk untuk OS (persistent block storage)
Data volume — disk tambahan untuk data (bisa di-attach/detach)
Instance store — ephemeral storage lokal (hilang saat stop)
Networking:
Network interface — koneksi ke VPC
Private IP — selalu ada
Public IP — opsional, di-assign jika di public subnet
Metadata:
Instance ID — identifier unik
Instance type — spesifikasi hardware virtual
AMI/Image ID — template OS yang digunakan
Tags — label untuk organisasi dan cost allocation
Memilih Tipe Instance yang Tepat #
Cloud provider menawarkan ratusan tipe instance. Memahami kategorinya membantu memilih yang paling efisien untuk workload spesifik.
Kategori Tipe Instance (vendor-agnostic):
General Purpose:
→ Keseimbangan antara CPU, RAM, dan network
→ Cocok untuk: web server, application server, dev/test
→ Pilihan default yang baik jika tidak ada kebutuhan khusus
Compute Optimized (CPU-heavy):
→ Rasio CPU tinggi relatif terhadap RAM
→ Cocok untuk: batch processing, video encoding, gaming server,
scientific computing, high-performance web server
→ Saat CPU jadi bottleneck, bukan RAM
Memory Optimized (RAM-heavy):
→ Rasio RAM tinggi relatif terhadap CPU
→ Cocok untuk: in-memory database (Redis, Memcached),
real-time analytics, large dataset processing,
SAP HANA, high-performance database
→ Saat RAM jadi bottleneck, bukan CPU
Storage Optimized (I/O-heavy):
→ High throughput I/O dengan local NVMe storage
→ Cocok untuk: NoSQL database, data warehousing,
Elasticsearch, high-frequency OLTP
→ Butuh latensi storage sangat rendah
Accelerated Computing (GPU/FPGA):
→ GPU untuk parallel processing
→ Cocok untuk: ML training, deep learning inference,
3D rendering, video transcoding
→ Sangat mahal, hanya jika benar-benar butuh GPU
Siklus Hidup VM #
Memahami state-state yang mungkin dimiliki VM dan transisi di antaranya penting untuk mengelola instance secara efisien dan menghindari biaya yang tidak perlu.
State VM dan Implikasi Biaya:
Running:
→ VM aktif berjalan
→ Dibayar: compute (CPU+RAM) + storage + network
→ Semua data aman di persistent storage
Stopped (Instance Stop):
→ VM dimatikan, tidak berjalan
→ Dibayar: HANYA storage (disk tetap ada)
→ Data di persistent volume AMAN
→ Data di instance store (ephemeral) HILANG
→ Bisa di-start kembali kapan saja
→ IP publik biasa HILANG (Elastic IP tetap)
→ Berguna untuk: dev instance yang tidak perlu jalan 24/7
Terminated (Instance Terminate):
→ VM dihapus secara permanen
→ Tidak dibayar lagi
→ Root volume dihapus (jika delete on termination aktif)
→ Data volume bisa di-retain atau dihapus
→ TIDAK bisa di-recover setelah terminate
Rebooted:
→ VM restart
→ Dibayar selama proses reboot
→ Data di persistent storage AMAN
→ Data di ephemeral AMAN (tidak seperti stop)
→ IP tidak berubah
Implikasi biaya:
Running → bayar penuh
Stopped → bayar storage saja (~10-20% dari running)
Terminated → tidak bayar apa-apa
Banyak tim tidak mematikan dev/test instance di luar jam kerja. Instance yang running 24/7 padahal hanya dipakai 8 jam/hari membuang 67% biaya compute. Implementasikan scheduled start/stop atau Instance Scheduler untuk otomatis matikan instance di luar jam kerja — penghematan bisa 50-60% untuk environment non-produksi.
Cara Akses Instance #
Metode Akses Instance (dari yang paling aman ke paling berisiko):
Session Manager / Instance Connect (paling direkomendasikan):
→ Akses shell tanpa SSH port terbuka
→ Dikontrol via IAM — siapa boleh akses instance mana
→ Semua sesi di-audit dan di-log
→ Tidak butuh key pair management
SSH dengan Key Pair (umum, aman jika dikonfigurasi benar):
→ Port 22 hanya terbuka ke IP spesifik (VPN/bastion)
→ Key pair tidak boleh di-share antar tim
→ Private key tidak boleh tersimpan di tempat yang tidak aman
✗ Port 22 terbuka ke 0.0.0.0/0 = berbahaya
Password-based (tidak disarankan):
→ Mudah di-brute force
✗ Hindari kecuali terpaksa
Ringkasan #
- VM adalah abstraksi software di atas hypervisor — berbagi hardware fisik dengan VM lain tapi terisolasi sepenuhnya; ini fondasi model multi-tenant cloud.
- Pilih tipe instance berdasarkan bottleneck workload — general purpose untuk kebanyakan kasus, compute-optimized jika CPU jadi bottleneck, memory-optimized jika RAM yang habis duluan.
- Stop ≠ Terminate — stopped instance masih bayar storage dan bisa di-start ulang; terminated instance hilang selamanya.
- Instance store ephemeral hilang saat stop — hanya simpan data penting di persistent block volume, bukan di instance store.
- Dev/test instance tidak perlu jalan 24/7 — scheduled stop di luar jam kerja bisa menghemat 50-60% biaya compute.
- Gunakan Session Manager untuk akses instance — lebih aman dari SSH tradisional, dikontrol via IAM, dan semua sesi ter-audit.
← Sebelumnya: Lifecycle & Data Tiering Berikutnya: Container →