暗号化EBSを使うEC2が起動しない ── KMSキーの状態と権限を切り分ける

前提条件

1. リージョン: ap-northeast-1（東京）
2. EC2・KMSの操作権限を持つIAMユーザーまたはロールでコンソールにログイン済みであること
3. VPCとサブネットが1つ以上あること。インスタンスは通信しないので、インターネットゲートウェイもパブリックIPも不要です（既定のVPCが削除されているアカウントでは、検証用のVPCとサブネットを1つ作ってから始めます）

このハンズオンで作成するリソースは以下のとおりです。

> [!NOTE] > KMSのカスタマー管理キーは1本あたり月 1 USD の課金対象です。インスタンスは検証中だけ起動し、確認後に終了します。

手順1: カスタマー管理キーを作成する

AWSマネジメントコンソールにログインし、リージョンが ap-northeast-1（東京）であることを確認します。

上部の検索バーに KMS と入力し、「Key Management Service」を選択します。

左側ナビゲーションの「カスタマー管理型のキー」から「キーの作成」をクリックします。キーの作成は6つのステップに分かれています。

1. ステップ1「キーを設定」: キーのタイプ 対称、キーの使用法 暗号化および復号化 が既定で選ばれていることを確認して「次へ」
2. ステップ2「ラベルを追加」: エイリアスに ebs-lab-key を入力して「次へ」
3. ステップ3「キーの管理アクセス許可を定義」/ ステップ4「キーの使用法アクセス許可を定義」: 自分がログインしているIAMユーザーまたはロールにチェックを入れて「次へ」
4. ステップ5「キーポリシーを編集」: 生成されたポリシーをそのまま使うので変更しません
5. ステップ6「確認」: 内容を確認して「完了」

手順2: 暗号化ルートボリュームでインスタンスを起動する

EC2コンソールの「インスタンス」から「インスタンスを起動」をクリックします。

以下を設定します。

1. 名前: ebs-kms-lab-instance
2. AMI: Amazon Linux 2023
3. インスタンスタイプ: t3.micro
4. キーペア: 「キーペアなしで続行」
5. ネットワーク設定: 既定のVPC・サブネットのまま

「ストレージ (ボリューム)」のセクションで表示を「シンプル」から「アドバンスト」に切り替え、「ボリューム 1 (AMI ルート)」を展開して以下を設定します。

1. 暗号化済み: 暗号化済み
2. KMS キー: ebs-lab-key

「インスタンスを起動」をクリックし、インスタンスの状態が 実行中、ステータスチェックが通ることを確認します。

手順3: ボリュームがキーで暗号化されていることを確認する

左側ナビゲーションの「Elastic Block Store」→「ボリューム」を開き、作成されたルートボリュームを選択します。

「暗号化」が 暗号化済み、「KMSキーID」が手順1のキーになっていることを確認します。

手順4: インスタンスを停止してキーを無効化する

EC2コンソールでインスタンスを選択し、「インスタンスの状態」→「インスタンスを停止」で停止します。状態が 停止済み になるまで待ちます。

KMSコンソールに戻り、ebs-lab-key を選択して「キーのアクション」→「無効化」をクリックします。確認のチェックを入れて無効化します。

キーのステータスが 無効 になったことを確認します。

手順5: 起動が失敗することを確認する

EC2コンソールに戻り、インスタンスを選択して「インスタンスの状態」→「インスタンスを開始」をクリックします。

しばらくすると状態が 停止済み に戻ります。インスタンスを選択して「詳細」タブを開き、「インスタンスの詳細」にある次の2つを確認します。

「状態遷移の理由」は Server.InternalError としか言いません。KMSが原因だと分かるのは「状態遷移メッセージ」のほうで、ここに Client.InvalidKMSKey と出ます。どちらの欄にもキーIDまでは出ないので、どのキーかはボリュームの「KMS キー ID」から辿ります。

> [!NOTE] > 「状態遷移の理由」だけを見て Server.InternalError = AWS側の一時的な障害と判断すると、原因にたどり着けません。暗号化ボリュームを使うインスタンスが起動できないときは、必ず「状態遷移メッセージ」まで見るのが切り分けの近道です。

手順6: キーを有効化して復旧させる

KMSコンソールで ebs-lab-key を選択し、「キーのアクション」→「有効化」をクリックします。ステータスが 有効 に戻ったことを確認します。

EC2コンソールでインスタンスを再度開始します。今度は状態が 実行中 になり、ステータスチェックが通ることを確認します。

> [!NOTE] > キーを削除スケジュールに入れた場合（削除保留中）も同じ症状になります。こちらは削除がキャンセルできる猶予期間（7〜30日）のうちに「キー削除のキャンセル」を行えば復旧できますが、削除が完了してしまうと、そのキーで暗号化されたボリュームは二度と復号できません。

手順7: キーポリシーで必要なアクションを確認する

ebs-lab-key の「キーポリシー」タブを開き、「ポリシービューに切り替える」をクリックします。

コンソールが生成したポリシーでは、Allow use of the key のステートメントでキーの使用者に kms:Encrypt kms:Decrypt kms:ReEncrypt* kms:GenerateDataKey* kms:DescribeKey が許可されています（EBSが使う GenerateDataKeyWithoutPlaintext は kms:GenerateDataKey* に含まれます）。

その下の Allow attachment of persistent resources のステートメントでは kms:CreateGrant kms:ListGrants kms:RevokeGrant が許可され、Condition に kms:GrantIsForAWSResource: true が付いていることを確認します。

このうち1つでも欠けると、ボリュームの作成やアタッチが失敗します。キーの状態を確認して問題が無ければ、次はこのポリシーを見る、という順番で切り分けます。