Terjemahan disediakan oleh mesin penerjemah. Jika konten terjemahan yang diberikan bertentangan dengan versi bahasa Inggris aslinya, utamakan versi bahasa Inggris.
AWS CloudHSM praktik terbaik manajemen cluster
Ikuti praktik terbaik di bagian ini saat membuat, mengakses, dan mengelola AWS CloudHSM cluster Anda.
Menskalakan cluster Anda untuk menangani lalu lintas puncak
Beberapa faktor dapat mempengaruhi throughput maksimum yang dapat ditangani cluster Anda, termasuk ukuran instance klien, ukuran cluster, topografi jaringan, dan operasi kriptografi yang Anda perlukan untuk kasus penggunaan Anda.
Sebagai titik awal, lihat topik AWS CloudHSM informasi kinerja untuk perkiraan kinerja pada ukuran dan konfigurasi cluster umum. Sebaiknya Anda menguji beban cluster Anda dengan beban puncak yang Anda antisipasi untuk menentukan apakah arsitektur Anda saat ini tangguh dan pada skala yang tepat.
Arsitek cluster Anda untuk ketersediaan tinggi
Tambahkan redundansi untuk memperhitungkan pemeliharaan: AWS dapat menggantikan HSM Anda untuk pemeliharaan terjadwal atau jika mendeteksi masalah. Sebagai aturan umum, ukuran cluster Anda harus memiliki setidaknya +1 redundansi. Misalnya, jika Anda memerlukan dua HSM agar layanan Anda beroperasi pada waktu puncak, ukuran cluster ideal Anda akan menjadi tiga. Jika Anda mengikuti praktik terbaik terkait ketersediaan, penggantian HSM ini seharusnya tidak memengaruhi layanan Anda. Namun, operasi yang sedang berlangsung pada HSM yang diganti mungkin gagal dan harus dicoba lagi.
Sebarkan HSM Anda di banyak Zona Ketersediaan: Pertimbangkan bagaimana layanan Anda akan dapat beroperasi selama pemadaman Zona Ketersediaan. AWS menyarankan agar Anda menyebarkan HSM Anda di sebanyak mungkin Zona Ketersediaan. Untuk cluster dengan tiga HSM, Anda harus menyebarkan HSM di tiga Zona Ketersediaan. Tergantung pada sistem Anda, Anda mungkin memerlukan redundansi tambahan.
Memiliki setidaknya tiga HSM untuk memastikan daya tahan untuk kunci yang baru dihasilkan
Untuk aplikasi yang memerlukan daya tahan kunci yang baru dibuat, sebaiknya Anda memiliki setidaknya tiga HSM yang tersebar di Zona Ketersediaan yang berbeda di suatu wilayah.
Akses aman ke cluster Anda
Gunakan subnet pribadi untuk membatasi akses ke instans Anda: Luncurkan HSM dan instans klien Anda di subnet pribadi VPC Anda. Ini membatasi akses ke HSM Anda dari dunia luar.
Gunakan titik akhir VPC untuk mengakses API: Bid AWS CloudHSM ang data dirancang untuk beroperasi tanpa memerlukan akses ke internet atau AWS API. Jika instance klien Anda memerlukan akses ke AWS CloudHSM API, Anda dapat menggunakan titik akhir VPC untuk mengakses API tanpa memerlukan akses internet pada instans klien Anda. Untuk informasi selengkapnya, lihat AWS CloudHSM dan titik akhir VPC.
Kurangi biaya dengan menskalakan sesuai kebutuhan Anda
Tidak ada biaya di muka untuk digunakan AWS CloudHSM. Anda membayar biaya per jam untuk setiap HSM yang Anda luncurkan sampai Anda menghentikan HSM. Jika layanan Anda tidak memerlukan penggunaan terus menerus AWS CloudHSM, Anda dapat mengurangi biaya dengan mengurangi (menghapus) HSM Anda menjadi nol saat tidak diperlukan. Ketika HSM diperlukan lagi, Anda dapat memulihkan HSM Anda dari cadangan. Jika, misalnya, Anda memiliki beban kerja yang mengharuskan Anda menandatangani kode sebulan sekali, khususnya pada hari terakhir setiap bulan, Anda dapat meningkatkan skala cluster sebelumnya, menguranginya dengan menghapus HSM setelah pekerjaan selesai, dan kemudian memulihkan cluster Anda untuk melakukan operasi penandatanganan lagi pada akhir bulan berikutnya.
AWS CloudHSM secara otomatis membuat backup berkala dari HSM di cluster. Saat menambahkan HSM baru di kemudian hari, AWS CloudHSM akan mengembalikan cadangan terbaru ke HSM baru sehingga Anda dapat melanjutkan penggunaan dari tempat yang sama saat Anda meninggalkannya. Untuk menghitung biaya AWS CloudHSM arsitektur Anda, lihat AWS CloudHSM Harga
Sumber daya terkait: