AWS CloudHSM meilleures pratiques en matière de gestion des clusters - AWS CloudHSM

Les traductions sont fournies par des outils de traduction automatique. En cas de conflit entre le contenu d'une traduction et celui de la version originale en anglais, la version anglaise prévaudra.

AWS CloudHSM meilleures pratiques en matière de gestion des clusters

Suivez les meilleures pratiques décrites dans cette section lors de la création, de l'accès et de la gestion de votre AWS CloudHSM cluster.

Adaptez votre cluster pour faire face aux pics de trafic

Plusieurs facteurs peuvent influencer le débit maximal que votre cluster peut gérer, notamment la taille de l'instance client, la taille du cluster, la topographie du réseau et les opérations cryptographiques requises pour votre cas d'utilisation.

Pour commencer, reportez-vous à la rubrique AWS CloudHSM informations sur les performances pour obtenir des estimations de performances sur les tailles et configurations de clusters courantes. Nous vous recommandons de tester la charge de votre cluster avec le pic de charge que vous prévoyez afin de déterminer si votre architecture actuelle est résiliente et à la bonne échelle.

Concevez votre cluster pour une haute disponibilité

Ajoutez de la redondance pour tenir compte de la maintenance : vous AWS pouvez remplacer votre HSM pour une maintenance planifiée ou s'il détecte un problème. En règle générale, la taille de votre cluster doit avoir au moins +1 redondance. Par exemple, si vous en avez besoin de deux HSMs pour que votre service fonctionne aux heures de pointe, la taille idéale de votre cluster sera alors de trois. Si vous suivez les meilleures pratiques en matière de disponibilité, ces remplacements de HSM ne devraient pas avoir d'impact sur votre service. Cependant, les opérations en cours sur le HSM remplacé peuvent échouer et doivent être réessayées.

Répartissez votre activité HSMs sur de nombreuses zones de disponibilité : réfléchissez à la manière dont votre service sera en mesure de fonctionner en cas de panne de zone de disponibilité. AWS vous recommande de HSMs répartir vos informations sur autant de zones de disponibilité que possible. Pour un cluster composé de trois HSMs, vous devez le HSMs répartir sur trois zones de disponibilité. En fonction de votre système, il se peut que vous ayez besoin d'une redondance supplémentaire.

En avoir au moins trois HSMs pour garantir la durabilité des clés nouvellement générées

Pour les applications qui nécessitent la durabilité des clés nouvellement générées, nous recommandons d'en avoir au moins trois HSMs réparties dans différentes zones de disponibilité d'une région.

Accès sécurisé à votre cluster

Utilisez des sous-réseaux privés pour limiter l'accès à votre instance : lancez votre instance HSMs et celle du client dans les sous-réseaux privés de votre VPC. Cela limite l'accès à vous HSMs depuis le monde extérieur.

Utilisez des points de terminaison VPC pour y accéder APIs : le plan de AWS CloudHSM données a été conçu pour fonctionner sans avoir besoin d'accéder à Internet ou à AWS. APIs Si votre instance client a besoin d'accéder à l' AWS CloudHSM API, vous pouvez utiliser des points de terminaison VPC pour accéder à l'API sans avoir besoin d'un accès Internet sur votre instance client. Pour plus d’informations, consultez AWS CloudHSM et points de terminaison VPC.

Réduisez les coûts en adaptant vos besoins

Il n'y a aucun coût initial d'utilisation AWS CloudHSM. Vous payez un tarif horaire pour chaque HSM que vous lancez jusqu'à ce que vous mettiez fin au HSM. Si votre service ne nécessite pas une utilisation continue de AWS CloudHSM, vous pouvez réduire les coûts en réduisant (en supprimant) vos données HSMs à zéro lorsqu'elles ne sont pas nécessaires. Lorsque cela HSMs est à nouveau nécessaire, vous pouvez restaurer votre fichier HSMs à partir d'une sauvegarde. Si, par exemple, votre charge de travail vous oblige à signer du code une fois par mois, en particulier le dernier jour du mois, vous pouvez agrandir votre cluster avant, le réduire en le supprimant une HSMs fois le travail terminé, puis restaurer votre cluster pour effectuer à nouveau les opérations de signature à la fin du mois suivant.

AWS CloudHSM effectue automatiquement des sauvegardes périodiques HSMs du cluster. Lorsque vous ajoutez un nouveau HSM à une date ultérieure, la dernière sauvegarde AWS CloudHSM sera restaurée sur le nouveau HSM afin que vous puissiez reprendre l'utilisation à l'endroit où vous l'avez laissée. Pour calculer vos coûts AWS CloudHSM d'architecture, consultez la section AWS CloudHSM Tarification.

Ressources connexes :