Cara memperkirakan tagihan AWS Client VPN dari konsol

Bulan lalu saya membuat perkiraan Client VPN di spreadsheet, mengirimnya ke klien, lalu merevisinya dua kali: sekali karena saya mengalikan asosiasi dengan subnet, dan sekali karena saya memakai jumlah orang alih-alih data sesi. Versi yang lolos tinjauan bertumpu pada dua meter per jam dan daftar pendek biaya sampingan. Anda bisa membangunnya ulang dari konsol dan satu ekspor log, tanpa kalkulator harga.

Dua meter, dan tidak ada yang lain di endpoint

AWS menagih endpoint Client VPN berdasarkan jam asosiasi dan jam koneksi. Jam asosiasi berjalan untuk setiap jaringan target yang terpasang ke endpoint, sepanjang hari, entah ada yang terhubung atau tidak. Jam koneksi berjalan per klien yang terhubung, selama sesi itu tetap aktif.

Dua konsekuensi langsung muncul dari tabel itu. Endpoint yang tidak dipakai siapa pun tetap memakan biaya, dan satu orang yang menjalankan laptop dan ponsel sekaligus menghasilkan dua koneksi.

Hitung asosiasi di konsol, bukan subnet di VPC

Buka VPC, lalu Client VPN endpoints, lalu endpoint Anda, lalu tab Associations. Setiap baris di sana adalah lampiran subnet, dan jumlah baris itulah pengali asosiasi Anda. Jumlah subnet aplikasi di belakang VPC tidak ada hubungannya.

Satu asosiasi cukup untuk menjangkau jaringan VPC yang diizinkan begitu rute endpoint dan aturan otorisasi mencakup tujuannya. Asosiasi tambahan membeli ketahanan zona ketersediaan, bukan jangkauan tambahan. Jadi desain dua AZ menggandakan jam asosiasi, sedangkan VPC aplikasi dengan delapan subnet tidak menggandakan apa pun dengan delapan.

Perhatikan jenis asosiasi selagi Anda di halaman itu. Asosiasi subnet VPC dan asosiasi langsung Transit Gateway adalah susunan berbeda dengan baris biaya berbeda, jadi jangan membawa satu model ke penawaran yang lain. Dan jangan menguji jumlahnya dengan melepas hal-hal: menghapus jaringan target terakhir menghentikan sesi aktif dan memblokir koneksi baru sampai ada yang diasosiasikan lagi.

Turunkan jam koneksi dari data sesi

Jumlah orang adalah input yang salah, dan salah di kedua arah. Sepuluh orang yang masing-masing menjaga tiga perangkat terhubung adalah tiga puluh koneksi. Seratus orang yang masing-masing terhubung dua puluh menit sehari jauh dari seratus sesi bersamaan.

Log koneksi Client VPN mencatat peristiwa terhubung dan terputus per klien, yang persis pasangan yang Anda butuhkan. Ekspor satu minggu perwakilan, cocokkan peristiwanya, lalu jumlahkan durasinya:

connection-hours = sum of (disconnect_time - connect_time) per session
sessions         = one per client connection, not per person

Lalu koreksi dua kebiasaan. Sesi yang dibiarkan terhubung sepanjang makan siang, malam, atau lewat tidur laptop yang tak pernah memutus terowongan tetap ditagih, dan tak terlihat dalam hitungan orang. Pengukurannya juga per jam, jadi anggarkan sesi dua puluh menit sebagai satu jam penuh alih-alih mengasumsikan penagihan proporsional; kalau tagihannya lebih rendah, anggap itu margin, bukan masukan perencanaan.

Hitung dengan tarif wilayah Anda

Tarif berbeda per wilayah, jadi ambil dari halaman harga AWS VPN untuk wilayah tempat Anda men-deploy dan tempelkan ke spreadsheet sebagai masukan. Hanya sebagai ilustrasi, ambil tarif asosiasi 0.10 dolar per jam dan tarif jam koneksi 0.05 dolar, lalu hitung bulan 30 hari dengan dua asosiasi sepanjang bulan dan 100 orang terhubung enam jam pada 20 hari kerja:

association-hours = 2 * 24 * 30     = 1,440
association fee   = 1,440 * 0.10    = 144.00

connection-hours  = 100 * 6 * 20    = 12,000
connection fee    = 12,000 * 0.05   = 600.00

Client VPN subtotal                 = 744.00

Sekarang geser satu masukan setiap kali dan lihat baris mana yang bereaksi. Menggandakan asosiasi menambah 144 dolar di sini; menggandakan durasi sesi rata-rata menambah 600. Rasio itu biasanya menyelesaikan perdebatan desain untuk Anda: pangkas redundansi yang tak bisa Anda pertanggungjawabkan, atau kejar sesi menganggur, mana pun yang angkanya lebih besar. Tulis wilayah dan tanggal tarif di samping hasil, karena penawaran tanpanya tidak bisa direproduksi enam minggu kemudian.

Tambahkan biaya yang dilewatkan subtotal

Biaya endpoint membayar endpoint. Semua yang disentuh lalu lintas setelahnya punya meter sendiri, dan di baris itulah perkiraan VPN yang optimistis berantakan.

• Egress internet untuk lalu lintas yang keluar lewat endpoint, ditagih per GB.
• Alamat IPv4 publik, yang membawa biaya per jam sendiri terlepas dari VPN.
• Ingesti dan penyimpanan CloudWatch Logs untuk log koneksi yang baru Anda ekspor.
• Pemanggilan Lambda jika Anda menjalankan handler client-connect.
• Directory Service atau penyedia identitas SAML Anda, jika begitulah pengguna diautentikasi, ditambah biaya ACM Private CA jika Anda menerbitkan sertifikat di sana.
• Jam NAT Gateway dan pemrosesan data, serta jam keterkaitan Transit Gateway plus pemrosesan data, setiap kali jalur memakainya.

Tidak satu pun dari ini tumbuh dengan jumlah asosiasi, karena itu angka per pengguna yang hanya disusun dari tarif endpoint terlihat bagus di atas kertas lalu membesar begitu lalu lintas nyata muncul. Taruh di baris terpisah bahkan saat Anda harus memperkirakannya, agar pembaca melihat bagian mana yang diukur dan mana yang dugaan.

Periksa spreadsheet sebelum mengirimnya

Empat pemeriksaan menangkap kesalahan yang benar-benar saya buat: jumlah asosiasi cocok persis dengan tab Associations, jam koneksi berasal dari peristiwa log berpasangan bukan hitungan orang, wilayah dan tanggal tarif tertulis, dan setiap biaya sampingan punya baris sendiri. Jika salah satu dari empat itu hilang, Anda punya dugaan dengan format.

Tarik dulu ekspor log. Itu satu-satunya masukan yang tak bisa Anda rekonstruksi dari ingatan nanti, dan itu juga memberi tahu apakah masalah sesi menganggur layak diperbaiki sebelum tagihan pertama datang.