Virtual Machine #

Dalam ekosistem komputasi cloud, Virtual Machine (VM) atau instans virtual adalah fondasi utama yang menyediakan daya komputasi sesuai permintaan. Sebelum lahirnya teknologi kontainerisasi (seperti Docker dan Kubernetes) atau model komputasi serverless, Virtual Machine adalah sarana utama bagi para developer untuk menjalankan beban kerja (workload) mereka di cloud. Hingga hari ini, meskipun teknologi komputasi telah berkembang pesat, VM tetap menjadi pilar infrastruktur yang tidak tergantikan karena hampir semua layanan tingkat tinggi (managed databases, Kubernetes worker nodes, FaaS platform) pada dasarnya berjalan di atas lapisan virtualisasi VM yang tersembunyi. Memahami cara kerja virtualisasi, anatomi instans, siklus hidup, serta optimasi biaya VM sangat krusial bagi kita untuk merancang arsitektur cloud yang efisien dan aman.

Cara Kerja Virtualisasi dan Peran Hypervisor #

Virtual Machine bukanlah server fisik yang berdiri sendiri. VM adalah sebuah komputer berbasis perangkat lunak (software-defined computer) yang berjalan di atas server fisik sesungguhnya melalui perantara lapisan perangkat lunak khusus yang disebut Hypervisor.

Hypervisor memiliki tanggung jawab utama untuk mengabstraksikan hardware fisik (seperti CPU, RAM, storage, dan network card) dan membaginya menjadi beberapa lingkungan virtual terisolasi yang masing-masing bertindak seolah-olah merupakan komputer fisik terpisah.

flowchart TD
    subgraph PhysicalServer ["Server Fisik (Bare Metal Host)"]
        PhysicalHW["Physical Hardware<br>(CPU Cores, System RAM, NIC, SSDs)"]
        HypervisorLayer["Hypervisor Layer<br>(Nitro / KVM / ESXi)"]
        
        PhysicalHW --> HypervisorLayer
    end
    
    subgraph VM_A ["Virtual Machine A"]
        AppA["Aplikasi A"] --> OSA["Guest OS (Linux)"]
    end
    
    subgraph VM_B ["Virtual Machine B"]
        AppB["Aplikasi B"] --> OSB["Guest OS (Windows)"]
    end
    
    subgraph VM_C ["Virtual Machine C"]
        AppC["Aplikasi C"] --> OSC["Guest OS (Linux)"]
    end
    
    HypervisorLayer -->|"Alokasi CPU & RAM Virtual"| VM_A
    HypervisorLayer -->|"Alokasi CPU & RAM Virtual"| VM_B
    HypervisorLayer -->|"Alokasi CPU & RAM Virtual"| VM_C

Jenis-Jenis Hypervisor #

1. Type 1 (Bare-Metal Hypervisor): Hypervisor jenis ini dipasang langsung di atas hardware server fisik tanpa perantara sistem operasi lain. Contohnya adalah AWS Nitro System, KVM (Kernel-based Virtual Machine), VMware ESXi, dan Microsoft Hyper-V. Tipe ini digunakan secara eksklusif oleh provider cloud publik karena menawarkan latensi terendah, performa mendekati mesin fisik (bare-metal speed), dan keamanan isolasi hardware tingkat tinggi.
2. Type 2 (Hosted Hypervisor): Hypervisor jenis ini berjalan sebagai perangkat lunak di atas sistem operasi utama (Host OS) dari komputer fisik. Contohnya adalah VirtualBox atau VMware Workstation yang biasa kita pasang di laptop pribadi untuk kebutuhan pengujian lokal.

Hypervisor modern memanfaatkan instruksi hardware khusus dari produsen CPU (seperti Intel VT-x atau AMD-V) untuk mengarahkan operasi komputasi VM langsung ke CPU fisik tanpa overhead penerjemahan perangkat lunak, sehingga performa CPU virtual (vCPU) hampir identik dengan CPU fisik.

Anatomi dan Komponen Instans Cloud #

Saat kita meluncurkan sebuah instans Virtual Machine di cloud, hypervisor akan merangkai berbagai komponen virtual untuk membentuk sistem komputer yang utuh:

1. vCPU (Virtual Central Processing Unit) #

vCPU adalah unit pemrosesan virtual yang dialokasikan ke VM kita. Secara fisik, satu vCPU biasanya memetakan ke satu hyperthread (utas logis) pada inti prosesor fisik server host. Jika server fisik memiliki prosesor dengan 32 Core dan 64 Threads, hypervisor dapat mendistribusikan maksimum 64 vCPU ke berbagai VM secara paralel.

2. RAM (Random Access Memory) virtual #

Alokasi memori fisik server host yang diisolasi secara ketat oleh hypervisor untuk digunakan oleh satu VM tertentu. Hypervisor menjamin bahwa sistem operasi di dalam VM A tidak dapat melihat atau membaca sektor memori milik VM B demi keamanan data.

3. Virtual Storage (Disk Volumes) #

VM membutuhkan media penyimpanan untuk sistem operasi (boot volume) dan data aplikasi.

• Root Volume: Persistent block storage yang memuat sistem berkas sistem operasi. Biasanya di-mount melalui jaringan storage private.
• Ephemeral Storage (Instance Store): Disk fisik SSD yang terpasang langsung di dalam server host fisik VM. Disk ini menawarkan performa I/O yang sangat cepat untuk file temporer, namun data di dalamnya akan terhapus selamanya saat instans VM di-stop atau dipindahkan.

4. VNIC (Virtual Network Interface Card) #

Kartu jaringan virtual yang menempel pada VM, menghubungkannya ke jaringan privat VPC kita. VNIC ini memiliki alamat IP privat tetap (private IP) dan dapat memiliki alamat IP publik opsional.

5. Metadata Service dan IMDS #

Setiap instans VM di cloud memiliki akses ke server metadata internal melalui alamat IP link-local khusus: http://169.254.169.254. Metadata service menyimpan informasi dinamis mengenai VM tersebut, seperti nama instans, peran keamanan IAM role, alamat IP, dan konfigurasi start-up script (user-data).

# BENAR: Melakukan query metadata menggunakan IMDSv2 (Secure Token-based) di Linux
# Langkah 1: Dapatkan Token Keamanan
TOKEN=$(curl -s -X PUT "http://169.254.169.254/latest/api/token" -H "X-aws-ec2-metadata-token-ttl-seconds: 21600")

# Langkah 2: Gunakan token untuk mengambil detail instance ID
curl -s -H "X-aws-ec2-metadata-token: $TOKEN" http://169.254.169.254/latest/meta-data/instance-id

Catatan Keamanan: Selalu gunakan IMDSv2 (berbasis token) seperti contoh di atas daripada IMDSv1 lama untuk mencegah celah keamanan SSRF (Server-Side Request Forgery) pada aplikasi kita.

Klasifikasi Tipe Instans Cloud #

Penyedia cloud membagi instans VM ke dalam berbagai kategori keluarga (families) untuk memudahkan kita mencocokkan spesifikasi hardware dengan karakteristik beban kerja aplikasi.

Siklus Hidup Instans dan Implikasi Biaya #

Memahami siklus hidup (lifecycle states) VM sangat krusial bagi kita untuk mengendalikan biaya tagihan cloud operasional. Banyak organisasi melakukan kesalahan dengan tetap membiarkan VM berjalan 24 jam sehari, padahal VM tersebut hanya digunakan untuk pengujian selama jam kerja kantor.

stateDiagram-v2
    [*] --> Pending: Launch / Run Instance
    Pending --> Running: Booting Selesai
    
    Running --> Stopping: Stop request
    Stopping --> Stopped: Proses shutdown selesai
    
    Stopped --> Pending: Start request
    
    Running --> Terminating: Terminate / Delete request
    Stopped --> Terminating: Terminate / Delete request
    
    Terminating --> Terminated: Cleanup & Hapus disk
    Terminated --> [*]: Objek dihapus dari konsol
    
    Running --> Rebooting: OS Restart
    Rebooting --> Running: Booting Selesai

Detail Siklus Hidup dan Aturan Tagihan: #

1. Pending: Instans sedang disiapkan oleh kontroler cloud, termasuk mencari host server fisik yang memiliki kapasitas hardware kosong. Aturan Biaya: Gratis.
2. Running: OS di dalam VM aktif berjalan. Aturan Biaya: Kita dikenakan tagihan penuh per detik untuk kapasitas compute (vCPU & RAM), sewa sistem operasi komersial (seperti Windows Server atau RHEL), storage disk, serta alamat IP publik statis.
3. Stopped: Instans dimatikan secara bersih (shutdown). Memori RAM fisik dilepaskan kembali ke host pool. Aturan Biaya: Kita tidak dikenakan biaya compute (vCPU & RAM). Namun, kita tetap wajib membayar biaya sewa untuk volume penyimpanan (root block storage) yang menempel pada VM tersebut karena data kita tetap dipertahankan secara utuh.
4. Terminated: Instans dihapus secara permanen dari sistem cloud. Aturan Biaya: Biaya sewa langsung berhenti total. Root disk akan ikut terhapus secara otomatis secara default, sedangkan data volume sekunder dapat kita pertahankan berdasarkan konfigurasi tag Delete on Termination.

Tips Efisiensi Biaya: scheduled Start/Stop #

Untuk lingkungan non-produksi (seperti Dev, QA, dan Staging), server biasanya hanya dibutuhkan pada hari kerja Senin-Jumat jam 09:00 - 17:00 (40 jam per minggu dari total 168 jam dalam seminggu).

• ANTI-PATTERN: Membiarkan server staging menyala 24/7 membuang anggaran sebesar: $$\frac{168 - 40}{168} \times 100% = 76.1% \text{ anggaran terbuang sia-sia}$$
• Solusi: Terapkan skrip otomasi scheduler (seperti AWS Instance Scheduler atau Azure Automation) untuk mematikan VM secara otomatis pada malam hari dan menyalakannya kembali saat pagi hari. Ini akan langsung mereduksi tagihan compute server non-produksi kita sebesar lebih dari 70%.

Manajemen Keamanan dan Akses Instans #

Mengamankan akses shell administrasi ke VM cloud adalah prioritas keamanan nomor satu. Membuka port administrasi ke jaringan internet publik adalah salah satu kesalahan fatal yang paling sering dimanfaatkan oleh peretas.

Celah Bahaya SSH Tradisional #

Banyak developer membuat aturan firewall (Security Group) yang membuka port SSH (port 22) atau port RDP (port 3389) ke alamat IP 0.0.0.0/0 (semua orang di internet) agar mereka dapat mengelola VM dari mana saja.

// ANTI-PATTERN: Security Group membuka port administrasi ke internet publik
Type: SSH
Port: 22
Source: 0.0.0.0/0          // JANGAN: VM kita akan terus-menerus diserang brute force!

// BENAR: Batasi akses SSH hanya dari IP VPN kantor atau IP privat Bastion Host
Type: SSH
Port: 22
Source: 192.168.10.0/24    // ✓ BENAR: Hanya IP dari jaringan private VPN kita

Solusi Terbaik: Akses Agentless / Session Manager #

Metode modern yang direkomendasikan saat ini adalah meniadakan port SSH publik secara total.

• Sistem Kerja: Kita menginstal agen kecil resmi dari provider cloud di dalam VM (seperti SSM Agent di AWS). Agen ini membuka koneksi keluar (outbound connection) yang aman secara privat ke layanan manajemen cloud.
• Keunggulan: Kita dapat masuk ke terminal Linux VM secara langsung melalui antarmuka web konsol cloud atau menggunakan AWS CLI/Azure CLI yang telah diotorisasi menggunakan IAM policy. Kita tidak perlu membuat kunci SSH (key pairs), tidak perlu mengelola file .pem, dan tidak perlu membuka port 22 di firewall jaringan luar. Semua aktivitas pengetikan perintah shell juga akan di-log secara transparan ke sistem audit terpusat.

Ringkasan #

• Virtual Machine membagi kapasitas hardware fisik server host menjadi beberapa komputer virtual terisolasi menggunakan lapisan Hypervisor Type 1 berlatensi rendah.
• Pilih keluarga instans berdasarkan karakteristik bottleneck workload aplikasi kita — General Purpose untuk server web standar, Compute Optimized untuk transkode/batch processing, dan Memory Optimized untuk database transaksional besar.
• Bedakan status Stop dan Terminate — stopped instance melepaskan alokasi CPU/RAM (biaya compute berhenti, hanya bayar disk storage), sedangkan terminated instance menghapus objek server secara permanen.
• Terapkan kebijakan scheduled start/stop pada lingkungan non-produksi (staging/development) untuk menghindari pemborosan biaya sewa compute pada malam hari dan akhir pekan.
• Gunakan IMDSv2 berbasis token untuk query metadata internal instans secara aman dari risiko eksploitasi celah keamanan SSRF.
• Hindari membuka port SSH (22) atau RDP (3389) ke internet publik — gunakan VPN private tunnel atau layanan seperti Session Manager yang terintegrasi dengan otorisasi IAM.

← Sebelumnya: Lifecycle & Data Tiering   Berikutnya: Container →