概要:前提条件クラスターの書き込み制限モード移行の開始移行のロールバックロールバック後のデータ同期

hsm1.medium から hsm2m.medium への移行

AWS CloudHSM クラスターを hsm1.medium から hsm2m.medium に移行できます。このトピックでは、前提条件、移行プロセス、ロールバック手順について説明します。

移行を開始する前に、アプリケーションが高可用性対応のクラスターをアーキテクチャーの推奨事項に従っていることを確認してください。これにより、プロセス中のダウンタイムを回避できます。

注記

hsm2m.medium への自動移行は、2026 年 1 月 20 日に開始されます。

hsm1.medium から hsm2m.medium への移行プロセスの概要

AWS CloudHSM コンソール、、 AWS CLIまたは AWS CloudHSM API を使用して移行を開始できます。どこから開始しても、 AWS CloudHSM クラスター移行は modify-cluster API エンドポイントを使用します。または、AWS CloudHSM はユーザーに代わってクラスターを自動的に移行します。移行が開始されると、クラスター全体が書き込み制限モードになります。詳細については、「クラスターの書き込み制限モード」を参照してください。

影響を最小限に抑えるために、は HSMs hsm1.medium から hsm2m.medium に一度に 1 つずつ AWS CloudHSM 変更します。置き換え後の HSM は同じ IP アドレスを維持するため、移行中も移行後も設定変更は不要です。

移行は次の手順で実行されます。

最初の HSM を移行する前に、はクラスター全体のフルバックアップ AWS CloudHSM を作成します。
このバックアップを使用して、はリクエストされたタイプ (hsm2m.medium) の新しい HSM AWS CloudHSM を作成し、最初の HSM を置き換えます。
後続の各 HSM を移行する前に、はクラスター全体の新しい完全バックアップ AWS CloudHSM を作成します。
AWS CloudHSM はクラスター内の HSM ごとにステップ 3 と 4 を繰り返し、一度に 1 つの HSM を移行します。
各 HSM の移行には、約 30 分かかります。

AWS CloudHSM はクラスターの状態を監視し、移行プロセス全体で検証を実行します。がエラーの増加 AWS CloudHSM を検出した場合、または検証チェックが失敗した場合、自動的に移行を停止し、クラスターを元の HSM タイプに戻します。移行開始後 24 時間以内であれば、手動でロールバックすることも可能です。ロールバックを実行する前に、「HSM タイプのロールバックに関する考慮事項」を参照してください。

hsm2m.medium に移行するための前提条件

hsm2m.medium に移行するには、既存の AWS CloudHSM クラスターがこれらの要件を満たしている必要があります。検証チェックのいずれかの条件を満たさない場合、 AWS CloudHSM は自動的にクラスターを元の HSM タイプに戻します。

移行に関するよくある問題については、「AWS CloudHSM クラスター変更の既知の問題」を参照してください。

過去 7 日間:
- すべてのクライアント接続で SDK 5.9 以降が使用されている。
  - ECDSA Verify を実行する場合、すべてのクライアント接続が SDK 5.13 以上を使用している。
- AWS CloudHSM インスタンスは、サポートされている機能のみを使用しています (非推奨の機能はありません）。詳細については、「非推奨通知」を参照してください。
- 過去 7 日以内に、クラスター内の少なくとも 1 台の HSM に対して、SDK を使用した接続が行われている。
クラスターが ACTIVE 状態である。
クラスターに含まれる HSM が 27 台以下である。
移行中に HSM オペレーションのエラーレートが増加しない。

注記

トークンキーのワークロードを持つお客様が移行できなかった以前の制限は解除されました。

クラスターの書き込み制限モード

クラスターが移行を開始すると、制限付き書き込みモードになります。HSM の状態を変更する可能性のあるオペレーションは拒否されます。読み取りオペレーションはすべて影響を受けません。

移行中、アプリケーションが次のオペレーションを実行しようとすると、HSM からエラーが返されます。

トークンキーの生成および削除 (セッションキーのワークロードは引き続き動作します)。
ユーザーの作成、削除、変更のすべて。
クォーラムオペレーション。
キー属性の変更など、HSM 内のキーの変更。
mTLS の登録。

AWS CloudHSM は、移行中にクラスターを MODIFY_IN_PROGRESS状態にします。この期間中は、クラスターに HSM を追加したり、クラスターから HSM を削除したりすることはできません。

移行の開始

クラスター移行プロセスでは、クラスター内の HSM を 1 台ずつ順番に置き換えていきます。所要時間は、クラスター内の HSM の台数に依存します。平均して HSM 1 台あたり約 30 分かかります。クラスター内の各 HSM の HSM タイプをモニタリングすることで、何台の HSM が新しいタイプへ移行済みかを確認し、進行状況を追跡できます。

Console

HSM タイプを変更するには (コンソール)

https://console.aws.amazon.com/cloudhsm/home で AWS CloudHSM コンソールを開きます。
変更するクラスターの ID の横のラジオボタンを選択します。
[アクション] メニューから、Modify HSM Type を選択し、目的の HSM タイプを選択します。

この手順を実行すると、クラスターは MODIFY_IN_PROGRESS 状態になります。移行が完了すると、クラスターは ACTIVE 状態に戻ります。

AWS CLI

HSM タイプを変更するには (AWS CLI)

コマンドラインプロンプトで、 modify-cluster コマンドを実行します。クラスター ID と目的の HSM タイプを指定します。


$ aws cloudhsmv2 modify-cluster --cluster-id <cluster ID> --hsm-type <HSM Type>
                                                 
 
 {
     "Cluster": {
         "BackupPolicy": "DEFAULT",
         "BackupRetentionPolicy": {
             "Type": "DAYS",
             "Value": 90
          },
         "VpcId": "vpc-50ae0636",
         "SubnetMapping": {
             "us-west-2b": "subnet-49a1bc00",
             "us-west-2c": "subnet-6f950334",
             "us-west-2a": "subnet-fd54af9b"
         },
         "SecurityGroup": "sg-6cb2c216",
         "HsmType": "hsm2m.medium",
         "HsmTypeRollbackExpiration": 1730383180.000,
         "Certificates": {},
         "State": "MODIFY_IN_PROGRESS",
         "Hsms": [],
         "ClusterId": "cluster-igklspoyj5v",
         "ClusterMode": "FIPS",
         "CreateTimestamp": 1502423370.069
     }
 }

この手順を実行すると、クラスターは MODIFY_IN_PROGRESS 状態になります。移行が完了すると、クラスターは ACTIVE 状態に戻ります。

AWS CloudHSM API

HSM タイプを変更するには (AWS CloudHSM API)

ModifyCluster リクエストを送信します。クラスターの ID と目的の HSM タイプを指定します。

この手順を実行すると、クラスターは MODIFY_IN_PROGRESS 状態になります。移行が完了すると、クラスターは ACTIVE 状態に戻ります。

移行のロールバック

AWS CloudHSM は、エラー率の上昇をモニタリングし、移行全体で継続的な検証チェックを実行します。がサービス品質の低下または検証の失敗 AWS CloudHSM を検出すると、クラスターの元の HSM タイプへのロールバックが自動的に開始されます。ロールバック中は、クラスター内の各 HSM に対して次の処理が行われます。

AWS CloudHSM は、その HSM の移行の開始時に取得したバックアップを使用します。
すべての HSM が元のタイプに戻るまで、HSM を 1 台ずつ順番に置き換えます。
ロールバック処理の全期間を通じて、クラスターは書き込み制限モードのまま維持されます。

移行開始から 24 時間以内であれば、移行をロールバックできます。ロールバックの期限を確認するには:

describe-clusters コマンドを実行します。
HsmTypeRollbackExpiration の値を探します。このタイムスタンプはロールバックの期限です。

ロールバックする場合は、この期限までにロールバックしてください。ロールバックでは、元の HSM タイプの最新のバックアップが使用されます。

警告

移行完了後のロールバックには注意が必要です。移行を完了し、 AWS CloudHSM を使用して新しいキーまたはユーザーを作成すると、ロールバックによってデータが失われる可能性があります。ロールバック後のデータ損失を軽減する方法については、ロールバック後のデータ同期を参照してください。

Console

HSM タイプをロールバックするには (コンソール)

https://console.aws.amazon.com/cloudhsm/home で AWS CloudHSM コンソールを開きます。
ロールバックしたいクラスターの ID を選択します。
[アクション] メニューから、Modify HSM Type を選択し、元の HSM タイプを選択します。

この手順を実行すると、クラスターは ROLLBACK_IN_PROGRESS 状態になります。ロールバックが完了すると、クラスターは ACTIVE 状態に戻ります。

AWS CLI

HSM タイプをロールバックするには (AWS CLI)

コマンドラインプロンプトで、 modify-cluster コマンドを実行します。クラスター ID と元の HSM タイプを指定します。


$ aws cloudhsmv2 modify-cluster --cluster-id <cluster ID> --hsm-type <HSM Type>
                                
{
 "Cluster": {
     "BackupPolicy": "DEFAULT",
     "BackupRetentionPolicy": {
         "Type": "DAYS",
         "Value": 90
      },
     "VpcId": "vpc-50ae0636",
     "SubnetMapping": {
         "us-west-2b": "subnet-49a1bc00",
         "us-west-2c": "subnet-6f950334",
         "us-west-2a": "subnet-fd54af9b"
     },
     "SecurityGroup": "sg-6cb2c216",
     "HsmType": "hsm1.medium",
     "HsmTypeRollbackExpiration": 1730383180.000,
     "Certificates": {},
     "State": "ROLLBACK_IN_PROGRESS",
     "Hsms": [],
     "ClusterId": "cluster-igklspoyj5v",
     "ClusterMode": "FIPS",
     "CreateTimestamp": 1502423370.069
 }
}

この手順を実行すると、クラスターは ROLLBACK_IN_PROGRESS 状態になります。ロールバックが完了すると、クラスターは ACTIVE 状態に戻ります。

AWS CloudHSM API

HSM タイプをロールバックするには (AWS CloudHSM API)

ModifyCluster リクエストを送信します。クラスターの ID と元の HSM タイプを指定します。

この手順を実行すると、クラスターは ROLLBACK_IN_PROGRESS 状態になります。ロールバックが完了すると、クラスターは ACTIVE 状態に戻ります。

ロールバック後のデータ同期

移行中、HSM は書き込み制限モードであるため、HSM の状態を変更することはできません。この期間中 (クラスターが MODIFY_IN_PROGRESS の間) にロールバックを行うと、クラスターの内容は元のクラスターと完全に同一の状態になります。

クラスターが ACTIVE 状態に戻ると、書き込み制限モードは解除されます。ACTIVE 状態の間にキーやユーザーを作成し、その後ロールバックを実行した場合、そのキーやユーザーはロールバック後のクラスターには存在しません。

ユーザーの同期に対応するには、CloudHSM CLI を使用したユーザー管理で、ロールバック後のクラスター上に不足しているユーザーを再作成します。これは、user replicate コマンドが hsm2m.medium から hsm1.medium へのユーザー同期をサポートしていないため、ユーザーを手動で再作成する必要があるためです。詳細については、ユーザーレプリケートに関する既知の問題を参照してください。

キーの同期に対応するには、key replicate コマンドを使用して、2 つのクラスター間でキーをレプリケートします。CloudHSM CLI をインストールしていない場合は、コマンドラインインターフェイス (CLI) AWS CloudHSM の開始方法の手順を参照してください。

ロールバック後にキーを同期するには

ロールバック完了後、次の手順に従います。ここでは以下の用語を使用します。

cluster-1: ロールバック後のクラスター (現在 hsm1.medium)
cluster-2: 新たに作成する一時的な hsm2m.medium クラスター

cluster-1 の最新の hsm2m.medium バックアップを使用して、新しい hsm2m.medium クラスター (cluster-2) を作成します。


aws cloudhsmv2 create-cluster --hsm-type hsm2m.medium \
                                --subnet-ids <subnet ID 1> <subnet ID 2> <subnet ID N> \
                                --source-backup-id <backup ID>
                                --mode <FIPS>

cluster-2 に HSM を作成します。


aws cloudhsmv2 create-hsm --cluster-id <cluster-2 ID>

cluster-2 で、レプリケーションが必要なキーを一覧表示します。
```
cloudhsm-cli key list --cluster-id <cluster-2 ID>
```

cluster-2 から cluster-1 へ、各キーをレプリケートします。


cloudhsm-cli key replicate --source-cluster-id <cluster-2 ID> \
                        --destination-cluster-id <cluster-1 ID> \
                        --filter attr.label=<key ID>

コピーが必要なすべてのキーについて、手順 4 を繰り返します。

cluster-2 の HSM を削除します。


aws cloudhsmv2 delete-hsm --cluster-id <cluster-2 ID> --hsm-id <HSM ID>

cluster-2 を削除します。


aws cloudhsmv2 delete-cluster --cluster-id <cluster-2 ID>

ブラウザで JavaScript が無効になっているか、使用できません。

AWS ドキュメントを使用するには、JavaScript を有効にする必要があります。手順については、使用するブラウザのヘルプページを参照してください。

ドキュメントの表記規則

HSM クラスタータイプの移行

HSM ユーザー