翻訳は機械翻訳により提供されています。提供された翻訳内容と英語版の間で齟齬、不一致または矛盾がある場合、英語版が優先します。

# AWS CloudHSM クラスター管理のベストプラクティス
<a name="bp-cluster-management"></a>

 AWS CloudHSM クラスターを作成、アクセス、管理するときは、このセクションのベストプラクティスに従ってください。

## クラスターをスケールしてピークトラフィックを処理する
<a name="bp-cluster-performance"></a>

クラスターが処理できる最大スループットには、クライアントインスタンスのサイズ、クラスターサイズ、ネットワークトポグラフィー、ユースケースに必要な暗号化オペレーションなど、いくつかの要因が影響する可能性があります。

手始めに、一般的なクラスターのサイズと構成に関するパフォーマンスの見積もりに関するトピック [AWS CloudHSM パフォーマンス情報](performance.md) を参照してください。現在のアーキテクチャが耐障害性に優れていて、適切な規模になっているかを判断するために、予想されるピーク負荷でクラスターの負荷テストを行うことを推奨します。

## 高可用性対応のクラスターをアーキテクチャー
<a name="bp-high-availability"></a>

**メンテナンスを考慮して冗長性を追加します**。スケジュールされたメンテナンスや問題を検出した場合は、HSM を AWS 置き換えることができます。原則として、クラスターサイズには少なくとも \$11 の冗長性が必要です。たとえば、ピーク時にサービスを稼働させるために HSM が 2 つ必要であれば、理想的なクラスターサイズは 3 つになります。可用性に関するベストプラクティスに従えば、HSM を置き換えてもサービスに影響はないはずです。ただし、交換した HSM で進行中のオペレーションは失敗する可能性があるため、再試行する必要があります。

**HSM を複数のアベイラビリティーゾーンに分散させる**: アベイラビリティーゾーンが停止した際に、サービスをどのように運用できるかを検討してください。 AWS では、HSM をできるだけ多くのアベイラビリティーゾーンに分散することを推奨しています。HSM が 3 つあるクラスターでは、HSM を 3 つのアベイラビリティーゾーンに分散する必要があります。システムによっては、追加の冗長性が必要な場合があります。

## 新しく生成されたキーの耐久性を確保するために、HSM を少なくとも 3 つ用意してください
<a name="bp-new-key-durability"></a>

新しく生成されたキーの耐久性が必要なアプリケーションの場合は、リージョン内の異なるアベイラビリティーゾーンに少なくとも 3 つの HSM を分散させることを推奨します。

## クラスターへの安全なアクセス
<a name="bp-secure-access"></a>

**プライベートサブネットを使用してインスタンスへのアクセスを制限する**: HSM とクライアントインスタンスは、VPC のプライベートサブネットで起動します。これにより、外部からの HSM へのアクセスが制限されます。

**VPC エンドポイントを使用して APIs にアクセスする**: AWS CloudHSM データプレーンは、インターネットや AWS APIs にアクセスすることなく動作するように設計されています。クライアントインスタンスが AWS CloudHSM API にアクセスする必要がある場合は、クライアントインスタンスでインターネットアクセスを必要とせずに、VPC エンドポイントを使用して API にアクセスできます。詳細については「[AWS CloudHSM および VPC エンドポイント](cloudhsm-vpc-endpoint.md)」を参照してください。

## ニーズに合わせてスケールすることでコストを削減
<a name="bp-reduce-cost"></a>

 AWS CloudHSMの使用には初期費用はかかりません。HSM を終了するまで、HSM を起動するたびに 1 時間あたりの料金をお支払いいただきます。サービスで の継続的な使用が必要ない場合は AWS CloudHSM、不要な HSMs をゼロにスケールダウン (削除) することでコストを削減できます。HSM が再び必要になった場合は、HSM をバックアップから復元できます。たとえば、月に一度、具体的にはその月の最終日にコードに署名する必要があるワークロードがある場合は、その前にクラスターをスケールアップし、作業完了後に HSM を削除してスケールダウンし、翌月末にクラスターを復元して署名オペレーションを再実行することができます。

AWS CloudHSM は、クラスター内の HSMsの定期的なバックアップを自動的に作成します。後で新しい HSM を追加すると、 AWS CloudHSM は最新のバックアップを新しい HSM に復元し、残したのと同じ場所から使用を再開できるようにします。 AWS CloudHSM アーキテクチャコストを計算するには、[AWS CloudHSM 「 ](https://aws.amazon.com/cloudhsm/pricing/)料金表」を参照してください。

関連リソース:
+ [バックアップの一般的な概要](backups.md)
+ [バックアップの保持ポリシー](manage-backup-retention.md)
+ [AWS リージョン間での AWS CloudHSM クラスターバックアップのコピー](copy-backup-to-region.md)