普段AWS資格試験で触れるが、触らないサービス筆頭のCloudHSMについて解説します。
AWS CloudHSMとは?
暗号鍵の保管と処理を安全に行う物理的なデバイスであるハードウェアセキュリティモジュール(HSM)をクラウド上で使用できるサービスです。
マネージドサービスとして、高可用性に加えバックアップなどのHSM管理機能をセットで提供しています。
なんでHSMが必要なの?
暗号鍵をハードウェアの外に出すことなく、暗号化処理をリクエストに応じて行うデバイスがHSMです。HSMの基準を満たす耐タンパ性(暗号処理や署名処理を行うソフトウェア&ハードウェアに対する外部からの解読攻撃に対する耐性)のあるハードウェア上で暗号鍵を保管することで、暗号鍵外部流出を防ぐことができます。
AWS CloudHSMの特徴
AWS CloudHSM でのHSMは、FIPS 140-2 レベル3 または FIPS 140-3 レベル3で検証されたハードウェアから構成されます。
CloudHSM クラスターと、CloudHSMインスタンスにて構成され、インスタンスはhsm1.medium と hsm2m.medium がありますが2025年12月1日に hsm1.medium はサポートが終了しました。
インスタンスにプライベートネットワーク上からアクセスし、鍵管理を行います。
CloudHSM上での鍵管理は、IAMとは別の認証方式にてユーザー管理を行います。独立したHSM内部のユーザー管理で運用する必要があります。
使用可能アルゴリズム
AWS CloudHSMは、FIPSモード、非FIPSモードの2種類の動作が可能です。
FIPSモードでは、連邦情報処理標準 (FIPS) で検証されたキーとアルゴリズムのみを使用できます。非 FIPS モードでは、FIPS の承認に関係なく、AWS CloudHSM でサポートされるすべてのキーとアルゴリズムが提供されます。
なお、CloudHSMを使って、AWS上のリソース暗号化を行いたい場合は、KMSとの連携の関係でFIPSモードにて作成が必要です。
非 FIPSモードで作成するのは、FIPSで承認されていないアルゴリズムを使うときのみにしましょう。
KMSとの比較
同じ鍵管理サービスとしてAWS KMSと比較されるケースが多いので、改めてまとめます。
| 項目 | AWS CloudHSM | AWS KMS |
|---|---|---|
| ハードウェア | FIPS 140-2/140-3 レベル3 | FIPS 140-3 レベル3(中国リージョン以外) |
| テナント | シングルテナント(専有) | マルチテナント(共有) |
| 鍵の管理 | ユーザーが完全管理 | AWSがインフラを管理、ユーザーが鍵のライフサイクルとポリシーを管理 |
| アクセス制御 | HSM内部ユーザー認証 | IAM ポリシー、キーポリシー |
| 対応アルゴリズム | 柔軟(RSA、ECC、AES、HMAC など) | 主要な暗号化アルゴリズムをサポート(AES-256、RSA、ECCなど) |
| 鍵のエクスポート | 可能 | 非対称鍵の公開鍵部分のみ可 |
| 高可用性 | 手動でクラスター構成 | 自動(マネージド) |
| 料金 | 高額(HSM インスタンス時間課金) | 低額(鍵数 + API コール課金) |
| 運用負荷 | 高い(バックアップ、ユーザー管理など) | 低い(フルマネージド) |
| 統合サービス | 限定的(カスタム統合が必要) | 100以上のAWSサービスとネイティブ統合 |
| ユースケース | 規制要件が厳しい、鍵の完全管理が必要 | 一般的な暗号化ニーズ |
| パフォーマンス | 高スループット | 制限あり(API レート制限) |
| 監査 | CloudTrail + HSM ログ | CloudTrail |
| 鍵の所有権 | 完全にユーザー管理 | AWSマネージドキー、カスタマー管理キー両方可能 |
| オンプレ連携 | 可能(鍵のエクスポート) | Custom Key Store/External Key Store利用で可能 |
| 鍵管理、暗号化機能以外の機能 | ウェブサーバーの SSL/TLS 処理のオフロード | なし |
鍵を完全にユーザー管理する必要がある場合にはAWS CloudHSMを採用する必要があります。運用面ではKMSの方が圧倒的に便利なため、暗号化要件によって決めるケースが多いです。
AWS CloudHSM 構築方法
CloudHSMは、VPC内にCloudHSMインスタンスを準備し、VPCエンドポイント経由で物理HSMとプライベートネットワークで通信し使用するサービスです。
構築手順は以下の通りです。
- VPC内に、2つ以上のアベイラビリティゾーンにまたがるプライベートサブネットを構築する(耐障害性を考慮する場合は3つ以上を推奨)
- VPCにCloudHSM用VPCエンドポイント(
com.amazonaws.<region>.cloudhsmv2)を作成する - CloudHSMクラスターを作成する
- CloudHSM内の証明書署名リクエスト(CSR)を取得し、AWS Private CAまたは外部CAで署名する
- 署名済み証明書をCloudHSMクラスターに登録し、初期化する
- CloudHSMインスタンスをクラスターに追加する
- EC2を別途作成し、CloudHSMクライアント(SDK5※)をインストール、CloudHSM用セキュリティグループ(2223 - 2225ポート)設定、クラスター証明書の配置(
/opt/cloudhsm/etc/customerCA.crt)を行う -
/opt/cloudhsm/bin/configure-cli --cluster-id cluster-xxxxxxx --region <region>にてログイン用設定ファイルを作成 - EC2からCloudHSMインスタンスにログイン
/opt/cloudhsm/bin/cloudhsm-cli interactiveする -
cluster activateにて、初期管理者パスワードを設定する - 高可用性のため、異なるAZに管理コンソールから2つ目以降のCloudHSMインスタンスを追加する
- adminユーザーにログイン
login --username admin --role adminする - KMS用ユーザー
user create --username kmsuser --role crypto-userを作成する
※CloudHSMクライアントは、hsm2m.mediumインスタンスの場合、SDK5のクライアント(CloudHSM CLI)を使用してください。
https://docs.aws.amazon.com/ja_jp/cloudhsm/latest/userguide/w20aac23c15c13b7.html
AWSドキュメント上にある他の管理ツール AWS CloudHSM key_mgmt_util は hsm1(SDK3)用です。
なお、CloudHSMクライアントをインストールするEC2は、VPC内CloudShellでも操作可能ですが、クライアントインストールや証明書は/opt/ 配下に配置する必要がある関係で、セッション終了後には削除されてしまいます。 別途構築するEC2での操作を推奨します。インスタンスタイプは小さいもので構いません。
CloudShellは ホームディレクトリ($HOME)配下のみが永続化され、それ以外はセッション終了時に削除されます。
AWS CloudHSM 運用方法
CloudHSMを作成し終わったら、使ってみましょう。
KMSとの連携 鍵発行 & KMSカスタムキーストア作成
CloudHSM内の鍵は単独で他AWSサービスと連携し使用できるサービスが少ないため、KMS経由で使用できるように、KMSのカスタムキーストアを作成します。カスタムキーストアユーザーを作成します。
カスタムキーストア設定
KMSに移動し、AWS CloudHSMキーストアメニューから、キーストアの作成を行います。
信頼アンカー証明書とは、初期化時に使用した、クラスター証明書です。
ここで非FIPSモードのCloudHSMを選択すると、エラーになります。
次に、キーストアのアクションからCloudHSM クラスターと接続を行います。
上の青い進行バーが見えなくなったら接続完了です。
鍵発行
KMS上で設定したカスタムキーストアを使用し、カスタマー管理型のキーを作成します。
こちらが作成したカスタマー管理型のキーです。
CloudHSM上で kmsuserにてログインし、キー一覧を参照すると、labelにKMS上で作成されたARNのキーが確認できます。
[root@ip-XX-XX-XX-XX ~]# /opt/cloudhsm/bin/cloudhsm-cli interactive
aws-cloudhsm > login --username kmsuser --role crypto-user
Enter password:
{
"error_code": 0,
"data": {
"username": "kmsuser",
"role": "crypto-user"
}
}
aws-cloudhsm >
aws-cloudhsm > key list
{
"error_code": 0,
"data": {
"matched_keys": [
{
"key-reference": "0x00000000000XXXXXX",
"attributes": {
"label": "arn:aws:kms:<リージョン>:<AccountID>:key/XXXXXXX-a167-46c2-9ecf-05effa6cb1c7"
}
}
],
"total_key_count": 1,
"returned_key_count": 1
}
}
aws-cloudhsm >
このカスタムキーストアで、CloudHSM上で作成できることが確認できました。
このカスタマー管理型のキーを使用し、使いたいサービスの暗号化を行うことで、CloudHSM上の鍵で管理ができます。
CloudHSM - KMSカスタムキーストア暗号化の注意点
カスタムキーストアとCloudHSM クラスターの接続が何らかの不具合で解除、もしくは意図的に切断をした場合を見てみましょう。

接続が遮断されたカスタムキーストア上で作成したカスタマー管理型のキーは、即時使用不可になります。

そのため、CloudHSM障害の考慮が検討必要になります。
障害 - AZ障害
KMS- CloudHSM連携は、2AZ以上のhsmインスタンス運用が必要です。
AZ障害は数年に数回レベルで起こりえる障害です。
そのため、万が一hsmインスタンスが稼働しているアベイラビリティゾーンで障害が起こった場合に備えましょう。
- 3AZのサブネットをCloudHSMクラスターに準備
- 必要に応じてhsmインスタンスを非稼働、非障害アベイラビリティゾーンにて起動
これで接続が復旧します。
障害 - リージョン障害
CloudHSMと連携したカスタムキーストアを使ったカスタマー管理型のキーは、マルチリージョンキーとして使用することができません。
そのため、リージョン障害、CloudHSMまたはKMSの障害で、すべての暗号化利用サービスが使用不可になります。
バックアップとして定期的に他リージョンへデータを使えるようにした状態で保管しておくことが大事になります。
CloudHSM クラスター切断
CloudHSM クラスター切断は、CloudHSM クラスターのセキュリティグループ設定の変更、CloudHSM VPCエンドポイントの設定変更時にあり得ます。
その他、人為的に切断された際に起こりえます。
そのため、ネットワークの変更が可能な権限は、正しく管理しましょう。
なお、CloudHSM クラスターの接続の解除、この機能は万が一暗号化キーが漏れてしまった場合の即時暗号化キー使用不可化対応には便利です。
非常時のセキュアな運用用に、切断手順を覚えておくと良いでしょう。
KMS以外での鍵発行、AWS外での利用
AWS外での利用は、AWS CloudHSMから持ち出すことで実現できます。
別のアカウント上のAWS CloudHSMへ持ち込む用途でも、同手順で対応できます。
まず、Crypto User(CU)ユーザーでログインします。
鍵管理ユーザー毎に暗号鍵が管理できるため、KMS以外の使用では、kmsuserとは別にユーザーを作成する方が、セキュアな運用です。
/opt/cloudhsm/bin/cloudhsm-cli interactive
aws-cloudhsm > login --username <鍵管理ユーザー名> --role crypto-user
Crypto User(CU)ユーザーで鍵を発行します。
以下は対称キーの発行コマンドです。
key generate-symmetric aes \
--label example-aes \
--key-length-bytes 24
対称キーを持ち込みたい環境上で、非対称キーを作成します。
非対称キーは公開鍵、秘密鍵のセットが作成されますので、公開鍵(例: rsa-wrap-pub.pem)をCloudHSMクライアント上に持ち込み、インポートします。
key import-public \
--path rsa-wrap-pub.pem \
--label rsa-wrap-pub-from-other \
--encoding pem \
--attributes wrap=true
持ち込んだ公開鍵で、エクスポートしたい対称キーをWrapします。
key wrap rsa-aes \
--payload-filter attr.label=example-aes \
--wrapping-filter rsa-wrap-pub-from-other \
--hash-function sha256 \
--mgf mgf1-sha256 \
--path wrapped_example_aes_for_other.bin
出力された wrapped_example_aes_for_other.bin を他環境に持ち込んで、秘密鍵を使ってWrapを解き、使用することができます。
万が一輸送途中でも、対になる秘密鍵が対称キーを持ち込みたい環境上にしかないため、安全に運ぶことができます。
バックアップ
CloudHSMは、自動バックアップがされますので、通常運用時に特に何かする必要はありません。
リストア
CloudHSMのリストアは、新しくクラスターを作成する形になります。
最新のバックアップを選択し、バックアップからクラスターを作成で、新規クラスターとしてCloudHSM クラスターが作成できます。
バックアップからなので初期化も不要で、作成できます。
他リージョンにCloudHSMバックアップを持っていき、他リージョン上でクラスターを作成することも可能なので、AWS外の鍵発行用途としてCloudHSMが必要な際は、適宜最新バックアップを別リージョンにコピーし、リージョン障害に備えることも可能です。
コストの抑え方
CloudHSMは、バージニア北部リージョンで1ヵ月運用すると、hsm2m.medium ごとの合計時間料金 1.60米ドル (2026年2月現在) × 24 ×30日×2インスタンス = $2,304 かかります。
非常に高コストなサービスです。
もちろんセキュリティ要件で必要な際には、代替の効かないサービスではありますが、用途によっては金額を抑えたいですよね。
コスト削減案について紹介します。
シングルAZでの運用
CloudHSMは、CloudHSMインスタンス毎にコストがかかるため、マルチAZからシングルAZに可用性を削減すると、AWS利用料半減が可能です。
CloudHSMクライアントから以下のコマンドを実行し、可用性チェックを無効化します。
sudo /opt/cloudhsm/bin/configure-cli --disable-key-availability-check
このコマンドを実行し、実際にHSMクラスターから、インスタンスを1つ削減すれば完了です。
ただし、シングルAZ構成にすると、KMSとの連携は使用できません。
あくまでもHSM上での鍵発行を目的とし、AWSサービスと外部へ持ち出す用途にのみシングルAZで使用してください。
通常時インスタンス削除運用
シングルAZよりも更にインスタンスを減らす方法です。
これについても、インスタンス削除中は、KMSとの連携は使用できません。HSM上での鍵発行のみを目的とする際に使用してください。
シングルAZからさらに注意すべきは2点あります。
- バックアップ保管期限
クラスター作成時に、バックアップの保管期限を設定すると思いますが、保管期限以上のhsmインスタンス削除をしてしまうと、元に戻せなくなります。
そのため、CloudHSM上で必要な鍵を作成した最終タイミングで、バックアップの有効期限を無効化を押すことを忘れないようにしてください。
- IPアドレスの変更
/opt/cloudhsm/bin/configure-cli にてCloudHSMのログイン設定ファイルを作る際、
/opt/cloudhsm/etc/cloudhsm-cli.cfgにIPアドレスが自動登録されます。
hsmインスタンスを削除 → 鍵追加が必要な時にhsmインスタンスを再度起動でIPアドレスが変更になるため、再度CloudHSMクライアントに対し、ログイン設定を行う必要がある点注意してください。
まとめ・使いどころ
暗号化要件でHSMが必要な場合に、AWS CloudHSMの使用を検討してください。
AWSサービスと連携しない、ハードウェアとしてのHSMが必要な際には、都度、(1)hsmインスタンスの作成 → (2)鍵の作成とエクスポート → (3)hsmインスタンスの削除、というステップを踏むことで、コストを抑え、HSM運用が可能です。







