Cara Menggunakan Azure Pricing Calculator (Langkah demi Langkah)

Pengeluaran cloud mudah diremehkan sampai tagihan pertama datang. Untungnya, ada Azure Pricing Calculator, yaitu alat gratis dari Microsoft tanpa perlu login untuk memperkirakan biaya layanan Azure sebelum Anda menerapkan apa pun.

Masalahnya, Azure tidak memiliki satu harga per layanan. Misalnya, mesin virtual memiliki biaya berbeda bergantung pada wilayah, ukuran, berapa jam per bulan berjalan, dan paket harga yang Anda pilih. Kalikan itu pada arsitektur nyata dengan lima atau enam layanan, maka satu harga daftar menjadi hampir tidak berguna.

Dalam artikel ini, saya akan membangun estimasi dari nol, memandu Anda melalui contoh mesin virtual secara detail, dan membahas kesalahan yang diam-diam merusak estimasi yang sebenarnya sudah dibuat hati-hati.

Jawaban Cepat: Cara Menggunakan Azure Pricing Calculator

Buka Azure Pricing Calculator dan ikuti langkah-langkah berikut:

1. Cari layanan Azure yang ingin Anda hitung harganya di product picker, seperti Virtual Machines.
2. Pilih untuk menambahkannya ke estimasi Anda dengan konfigurasi default.
3. Tetapkan wilayah, tier, ukuran, dan opsi spesifik layanan lainnya yang akan Anda gunakan.
4. Masukkan perkiraan penggunaan Anda, seperti jam per bulan, penyimpanan dalam GB, atau permintaan per detik, apa pun yang menjadi dasar penagihan layanan tersebut.
5. Pilih opsi harga, seperti Pay-As-You-Go, Reserved Instance, atau Azure Savings Plan.
6. Tinjau biaya bulanan dan, bila relevan, biaya di muka yang ditampilkan untuk produk tersebut.
7. Ulangi untuk setiap layanan lain dalam arsitektur Anda, seperti database, akun penyimpanan, dan load balancer.
8. Tambahkan paket dukungan di dekat bagian bawah halaman.

Total akan diperbarui secara langsung ketika Anda mengubah bidang apa pun. Di sinilah sebagian besar estimasi gagal di produksi: tim hanya menghitung harga satu layanan yang menjadi fokus dan lupa layanan yang menjadi dependensinya.

Membaca Estimasi Anda

Kalkulator memiliki tiga bagian yang paling penting, dan akan membantu jika Anda memahami fungsi masing-masing sebelum mulai memasukkan angka.

• Product picker: Ini adalah fitur pencarian dan penelusuran kategori di bagian atas halaman. Kategorinya meliputi komputasi, penyimpanan, database, jaringan, serta AI dan pembelajaran mesin. Jika Anda tidak tahu nama produk yang tepat, menelusuri berdasarkan kategori biasanya lebih cepat daripada menebak istilah pencarian.
• Konfigurasi layanan: Setiap produk yang Anda tambahkan akan mendapatkan blok konfigurasinya sendiri, dan isi blok tersebut bergantung pada layanannya. Misalnya, VM meminta OS, ukuran, dan wilayah. Sementara akun penyimpanan meminta tier redundansi dan frekuensi akses. Tidak ada formulir universal, jadi Anda mengonfigurasi setiap layanan sesuai ketentuannya masing-masing.
• Perkiraan penggunaan: Di sinilah proyeksi konsumsi, seperti jam, GB, dan transaksi, diubah menjadi angka dolar. Ini juga bidang yang paling sering dibiarkan pada nilai default, sebuah kesalahan yang saya bahas nanti di artikel ini.

Beberapa layanan menampilkan biaya di muka dan biaya bulanan. Pembagian ini terutama muncul pada reservasi, di mana Anda membayar sebagian sekarang untuk mengunci tarif berulang yang lebih rendah. Angka bulanan tanpa biaya di muka biasanya berarti Anda menggunakan Pay-As-You-Go.

Langkah Demi Langkah: Menghitung Harga Virtual Machine

Pertimbangkan VM general-purpose untuk lingkungan staging. 

Pertama, cari “Virtual Machine” dan tambahkan ke estimasi. Produk akan default ke ukuran dan wilayah preset. Ubah wilayah terlebih dahulu karena memengaruhi setiap harga di halaman, lalu pilih OS dan ukuran VM Anda. Perhatikan bahwa Windows memiliki biaya lisensi tambahan dibandingkan Linux kecuali Anda mengaktifkan Azure Hybrid Benefit.

Sekarang tetapkan penggunaan yang diharapkan. Asumsi default Microsoft adalah 730 jam per bulan, yang merupakan rata-rata jumlah jam dalam sebulan. Dengan kata lain, kalkulator mengasumsikan VM berjalan 24/7. Ini biasanya asumsi yang tepat untuk server produksi, tetapi keliru untuk mesin staging yang hanya perlu aktif selama jam kerja.

Turunkan jam dari 730 menjadi, katakanlah, 200, dan estimasi akan langsung diperbarui. Perubahannya sering kali tidak proporsional, karena beberapa tier harga memiliki minimum atau fungsi bertingkat. Pengurangan 70% pada jam tidak selalu menghasilkan pengurangan biaya 70%. Ketidaklinieran ini adalah alasan mengapa kartu tarif statis tidak dapat memberi Anda biaya sebenarnya, dan menjadi alasan praktis untuk menggunakan kalkulator alih-alih memperkirakan dari harga daftar saja.

Membandingkan Paket Harga

Setelah Anda memiliki estimasi dasar, nilai sebenarnya dari kalkulator muncul. Anda dapat menjalankan VM yang sama dengan tingkat komitmen berbeda dan melihat tepatnya apa yang berubah.

Pay-As-You-Go tidak memerlukan komitmen dan memiliki tarif per jam tertinggi, dengan fleksibilitas penuh untuk mengubah ukuran atau menghapus kapan saja. Reserved Instances memungkinkan Anda berkomitmen pada ukuran VM tertentu di wilayah tertentu selama satu atau tiga tahun dengan imbalan tarif yang secara signifikan lebih rendah. Penghematan pada ukuran general-purpose biasanya berada di kisaran 40–70%, bergantung pada lamanya periode.

Azure Savings Plan memungkinkan Anda berkomitmen pada jumlah pengeluaran per jam alih-alih VM tertentu, dan Azure menerapkan diskon ke semua komputasi yang memenuhi syarat meskipun Anda mengubah ukuran atau memindahkan beban kerja.

Tidak ada satu pilihan yang selalu benar di sini. Itu bergantung pada seberapa stabil beban kerja Anda dan seberapa banyak fleksibilitas yang Anda butuhkan.

Apa yang Benar-Benar Menggerakkan Angka

Sejumlah keputusan arsitektur, bukan finansial, yang mengendalikan sebagian besar tagihan Anda:

Wilayah

Wilayah berperan besar, karena ukuran VM yang sama dapat berharga lebih mahal secara nyata di satu wilayah dibanding wilayah lain. Jika kepatuhan tidak mengikat Anda pada wilayah tertentu, periksa beberapa opsi terdekat.

Tier layanan dan ukuran

Tier layanan dan ukuran juga penting, karena naik satu tier “demi aman” adalah kebiasaan umum yang mahal. Modelkan kebutuhan Anda yang sebenarnya, bukan menambahkan buffer di atasnya.

Sistem operasi dan lisensi

Sistem operasi juga memengaruhi harga, karena lisensi Windows dan SQL Server menambah biaya nyata. Seperti disebutkan, Azure Hybrid Benefit adalah sakelar bagi tim yang sudah memiliki lisensi, dan ini mudah terlewat.

Volume penggunaan dan paket harga

Volume penggunaan dan paket harga, yang dibahas di atas, adalah sumber perubahan biaya terbesar.

Kesalahan Umum yang Merusak Estimasi

Bahkan estimasi yang disusun dengan hati-hati bisa keliru dalam beberapa cara yang dapat diprediksi. Berikut yang perlu diperiksa sebelum Anda mempercayai angka Anda.

Membiarkan penggunaan default tidak berubah

Kesalahan pertama adalah membiarkan penggunaan default apa adanya. Default 730 jam merupakan titik awal yang baik dan jawaban akhir yang buruk untuk apa pun yang tidak berjalan sepanjang waktu. 

Melupakan layanan pendukung

Kedua adalah melupakan layanan pendukung: VM membutuhkan disk, dan aplikasi biasanya membutuhkan database. Estimasi yang hanya menghitung layanan utama dan mengabaikan infrastruktur di sekitarnya akan secara konsisten meremehkan tagihan sebenarnya. 

Memilih wilayah yang salah

Ketiga adalah memilih wilayah yang salah, yang mudah terjadi saat Anda memperkirakan untuk klien atau tim yang lokasinya berbeda dari Anda. 

Mengabaikan biaya transfer data dan jaringan

Keempat adalah mengabaikan biaya transfer data dan jaringan, yang bervariasi sesuai konsumsi Anda. 

Membandingkan harga ritel dengan harga negosiasi

Kelima adalah membandingkan harga ritel dengan harga negosiasi: jika organisasi Anda memiliki perjanjian enterprise, harga daftar publik di kalkulator tidak akan cocok dengan yang sebenarnya Anda bayar kecuali Anda masuk dan menerapkan perjanjian Anda. 

Menganggap estimasi sebagai tagihan akhir

Terakhir, jangan menganggap estimasi sebagai tagihan akhir. Microsoft sendiri mencatat bahwa total estimasi tersimpan dapat berubah seiring perubahan harga yang dipublikasikan Azure, jadi sisipkan margin.

Azure Pricing Calculator vs. Azure Cost Management

Ini adalah dua alat berbeda yang menyelesaikan masalah berbeda. Pricing Calculator memperkirakan biaya sebelum Anda menerapkan apa pun, memungkinkan Anda memodelkan konfigurasi hipotetis dan membandingkan skenario yang belum ada. Di sisi lain, Azure Cost Management menganalisis apa yang sebenarnya Anda belanjakan setelah sumber daya aktif. Ini berurusan dengan penggunaan nyata, tagihan nyata, dan anomali nyata.

Anda memerlukan keduanya, pada waktu yang berbeda. Gunakan kalkulator untuk memperkirakan dan merencanakan anggaran sebelum Anda membangun. Gunakan Cost Management setelahnya untuk memeriksa apakah realitas sesuai rencana dan untuk menangkap penyimpangan yang tak terelakkan ketika trafik nyata mengenai infrastruktur nyata.

Praktik Terbaik untuk Memperkirakan Biaya Azure

Beberapa praktik terbaik secara konsisten menghasilkan estimasi yang lebih andal

• Modelkan penggunaan yang realistis, bukan kapasitas maksimum dan bukan pula minimum.
• Sertakan setiap komponen dalam arsitektur, bukan hanya yang terlihat mahal
• Bandingkan beberapa wilayah jika persyaratan kepatuhan Anda mengizinkannya.
• Jalankan beban kerja yang sama pada Pay-As-You-Go dan pada tingkat komitmen sebelum memilih salah satunya.
• Bangun tiga skenario (penggunaan yang diharapkan, rendah, dan tinggi) alih-alih satu angka saja, sehingga Anda memiliki rentang untuk perencanaan.
• Tinjau kembali estimasi saat arsitektur atau harga Azure berubah, karena keduanya jarang tetap sama dalam waktu lama.

Kesimpulan

Alur kerjanya sederhana: tambahkan layanan yang Anda butuhkan, konfigurasikan agar sesuai dengan cara layanan itu akan berjalan sebenarnya, masukkan angka penggunaan yang realistis, pilih paket harga, dan tinjau totalnya. Kalkulator yang menangani aritmetika.

Akurasi hasil sepenuhnya bergantung pada akurasi input dibandingkan dengan kenyataan. Estimasi yang dihitung secara presisi tetapi dibangun di atas asumsi penggunaan yang keliru tetaplah estimasi yang keliru.

Bangun beberapa skenario sebelum berkomitmen ke suatu arsitektur, dan setelah sumber daya diterapkan, bandingkan estimasi dengan pengeluaran nyata di Azure Cost Management. Setiap selisih di antara keduanya bersifat informatif: itu menunjukkan di mana asumsi awal Anda menyimpang dari penggunaan nyata.