AWS KMS徹底解説：暗号鍵管理の基本から、Google Cloud KMS（CMEK）・Azure Key Vault比較までわかる実務設計
先に要点（忙しい方向けのまとめ）
- AWS Key Management Service（AWS KMS）は、暗号鍵（KMSキー）を安全に作成・管理し、暗号化/復号などの暗号操作を提供するマネージドサービスです。多くのAWSサービスと統合され、保存データの暗号化で「顧客管理キー（customer managed key）」を指定できる場面が多いのが特徴です。
- アクセス制御の中心は「キーポリシー（KMSキーのリソースポリシー）」です。IAMポリシー等を使う場合でも、キーポリシー側がそれを許可している必要がある、という“クセ”があり、設計ミスが起きやすいポイントです。
- 監査は強力で、AWS KMSのAPI呼び出しはCloudTrailに記録されます。鍵の利用（誰がいつ鍵を使ったか）を後から追える体制を作りやすいです。
- ローテーション（鍵素材の入れ替え）は、AWS管理キーは毎年ローテーションされ、顧客管理キーは任意で自動ローテーションを有効化できます（年次が既定）。さらにオンデマンド回転も可能です。
- 料金は「鍵の保管（キーあたり月額）」と「暗号操作リクエスト」などが中心です。鍵は$1/月（按分）という明確な単位があり、設計時にコストの“増え方”を読みやすいです。
- GCPはCloud KMSでCMEK（Customer-managed encryption keys）を提供し、鍵の所有/制御を利用者側に寄せられます。鍵のローテーションスケジュール設定も可能です（非対称鍵には自動ローテーション制限あり）。
- AzureはKey Vaultで鍵/シークレット/証明書を扱い、Key rotation policyで自動ローテーションや通知を設定できます。VaultとManaged HSMの資源タイプ差も押さえると選定がスムーズです。
この記事が役に立つ方（具体的に）
AWS KMSは、暗号の専門家だけの道具ではありません。むしろ「クラウドでシステムを作る人が、最後に必ず向き合う“責任”の受け皿」になりやすいサービスです。次のような方に、特に効く内容にしています。
-
事業開発・プロダクト開発で、データ保護の説明責任が増えてきたバックエンド/インフラの方
「暗号化しています」と言うだけでは足りなくなり、「どの鍵で」「誰が使えるのか」「鍵はどう回転するのか」「ログは残るのか」を問われがちです。KMSは、この説明責任を“構成として”満たしやすい選択肢になります。 -
セキュリティ・監査要件（内部統制、規制対応、顧客要件）を抱えるSRE/セキュリティ担当の方
KMSはCloudTrailにより鍵操作を監査しやすく、アクセスをキーポリシー中心に設計できます。監査の観点から「誰が鍵を使えたか」を言語化しやすいのが強みです。 -
マルチクラウド/移行を見据えて、GCP・Azureの同等機能も同時に理解したいアーキテクトの方
KMS（AWS）・Cloud KMS（GCP）・Key Vault（Azure）はいずれも「鍵管理サービス」ですが、運用の流儀（ポリシー、バージョン、ローテーションの考え方）に差があります。比較軸を揃えることで、移行設計や共通ガバナンスが作りやすくなります。
1. AWS KMSとは：暗号鍵を“サービスとして”扱うための中核
AWS KMSは、暗号鍵（KMSキー）を作成・管理し、暗号化/復号などの暗号操作を提供します。顧客管理キーは自分のアカウントで作成・所有・管理でき、キーポリシー、IAMポリシー、グラント等の設定、鍵の有効/無効、暗号素材のローテーション、削除スケジュールなどを制御できる、と公式に整理されています。
ここで大切なのは、KMSが単なる“鍵置き場”ではなく、クラウド上のデータ暗号化を支える運用の中心点になりやすい、ということです。アプリケーションが直接暗号処理を実装すると、鍵の保管・配布・ローテーション・監査が難しくなります。KMSに寄せることで、鍵のライフサイクル管理と監査可能性を、サービスレベルで整えやすくなります。
2. まず押さえる基礎：KMSキーの種類と「管理の境界」
2-1. “誰が鍵を管理するか”で考える：AWS管理キーと顧客管理キー
AWS KMSの説明では、顧客管理キーは利用者が作成・所有・管理し、暗号操作に使え、CloudTrailで利用状況を監査できることが明記されています。また顧客管理キーには月額と利用（無料枠超過時など）料金が発生する、と整理されています。
実務では、次のように整理すると判断が速くなります。
- “鍵を自分で握る必要がある”データ（顧客要件・規制・内部統制が強い）→ 顧客管理キーを第一候補
- “運用を極力簡略化したい”データ（一般的な暗号化で十分）→ サービス既定の管理鍵を使う余地
この判断を、システムのデータ分類（機密性・保持期間・取り扱い者）と結びつけて文書化すると、チーム内の合意が作りやすいです。
2-2. ローテーションは「鍵を入れ替える」ではなく「鍵バージョンを増やす」感覚
AWS側では、顧客管理キーの自動ローテーションは任意で、AWS管理キーは毎年ローテーションされること、さらにオンデマンドでローテーションを開始できることが説明されています。既定の自動ローテーションは年次（約365日）で、期間の指定もできることがCLIリファレンスに記載されています。
重要なのは、「ローテーション＝既存データが自動で再暗号化される」ではない、という誤解を避けることです。多くの場合、暗号化は“データ鍵（DEK）”と“鍵暗号鍵（KEK＝KMSキー）”を組み合わせるエンベロープ暗号の形で行われます。ローテーション後は、新規暗号化に使われる鍵素材が更新され、復号は旧素材も含めて成立する、という挙動を前提に設計すると、運用が安定します。
3. いちばん事故が多い：アクセス制御（キーポリシー）の設計
3-1. KMSは「キーポリシーが主役」
AWSの公式ドキュメントでは、キーポリシーはKMSキーのリソースポリシーであり、アクセス制御の主要手段で、すべてのKMSキーは必ず1つのキーポリシーを持つ、と明記されています。さらに、IAMポリシーやグラント等も使えるが、キーポリシーがそれらの利用を許可している必要がある、という点が強調されています。
この仕様が、実務で次の“つまずき”を生みます。
- IAM側で許可したのに、KMSがAccessDeniedになる
- 管理者権限っぽいロールでも鍵が使えない
- クロスアカウントで想定通りに共有できない
原因の多くは「キーポリシーが、IAMや他アカウント利用を成立させる形になっていない」ことです。KMSは暗号の根幹なので、他リソースより厳密に“鍵側”で制御する思想が強い、と捉えると理解が楽になります。
3-2. サンプル：チーム運用で揉めにくい“役割分担”の考え方
以下は、よく効く分割例です。文章として合意しておくと、設計がブレません。
- 鍵管理者（Security/Platform）
- キー作成・削除スケジュール・ローテーション設定
- キーポリシーの管理
- 鍵利用者（Application）
- 暗号化/復号を実行する権限（必要最小限）
- ただしキーポリシーの変更はしない
KMSは「鍵を使う権限」と「鍵を管理する権限」を分けやすいサービスです。分けるほど、事故が減ります。
4. 監査と可観測性：CloudTrailで“鍵の利用”を追える
AWS KMSはCloudTrailと統合され、ユーザー/ロール/他AWSサービスによるKMSへの呼び出しがイベントとして記録される、と公式に説明されています。コンソール操作、API、CLI、CloudFormation経由などを含めて記録される点が明記されています。
監査の設計では、次を先に決めると運用が楽になります。
- 監査で必要なのは「鍵管理の操作」か「鍵利用の操作」か（両方か）
- どの期間保管するか（ログ保管コストと要件の折り合い）
- “誰が使ったか”の追跡単位をどこまで細かくするか（アプリ単位、環境単位、テナント単位など）
また、CloudTrailのログ暗号化には対称KMSキーのみが使えるなど、組み合わせの前提もドキュメントに明記されています。
このような制約は「あとで詰む」ポイントなので、鍵の種類（対称/非対称）を選ぶ前に、監査ログの要件を確認しておくのが安全です。
5. コスト設計：KMSは“鍵の数”と“リクエスト数”で効いてくる
KMSの料金ページでは、KMSキーは1キーあたり$1/月（時間按分）で、対称/非対称/HMAC/マルチリージョンキー（プライマリ・レプリカそれぞれ）などでも同様であることが明記されています。
実務でのコスト設計は、次の順番にすると読みやすいです。
- まず鍵の数を抑える：環境×用途で必要十分な単位にまとめる
- 次にリクエストを抑える：高頻度サービスでは暗号化呼び出し回数が積み上がる
- 最後に“例外”を吸収する：テナントごと鍵分離など、要件で必要な増加を受け入れる
特に保存系の暗号化でKMSリクエストが増えるケースでは、最適化の手段が用意されていることがあります。たとえば、あるストレージ暗号化のコスト削減として「Bucket KeysによりKMSリクエストコストを最大99%削減できる」と公式に説明されています。
このように、KMS単体ではなく“統合先のサービス側”の最適化機構も含めてコストを見積もるのが現実的です。
6. よくあるユースケース：KMSを「どこで効かせるか」
6-1. 保存データ暗号化で顧客管理キーを指定する（CMEKのAWS版）
顧客管理キーの価値が最も出やすいのは、マネージドサービスの保存データ暗号化に“自分の鍵”を使う場面です。AWS側でも「多くのAWSサービスがKMSと統合し、顧客管理キーを指定できる」ことが説明されています。
このときの設計ポイントは「鍵の責任境界」です。
- 鍵の無効化や削除スケジュールを誤ると、復号ができず業務影響が出ます
- 逆に、鍵が誰でも使える状態だと、暗号化していてもアクセス統制の意味が薄れます
つまり、KMSは暗号化のための機能であると同時に、アクセス統制の最終関門にもなります。
6-2. アプリケーション暗号（エンベロープ暗号）の中核として使う
アプリ側で「特定フィールドだけ暗号化したい」「DBの前に暗号化したい」などの要件が出ることがあります。ここでKMSを直接使って巨大データを暗号化するのではなく、データ鍵を発行し、データ鍵で暗号化し、データ鍵自体はKMSキーで保護する、という設計（エンベロープ暗号）がよく採用されます。
サンプル（考え方の例）
- KMSに「データ鍵を生成して」と依頼
- 返ってくる “平文データ鍵” でアプリがデータを暗号化
- “暗号化されたデータ鍵” をデータと一緒に保存
- 復号時は、暗号化データ鍵をKMSに渡して平文データ鍵を復元し、データを復号
この形にすると、データ鍵は短命で扱え、鍵漏えいリスクを下げやすく、監査ログにもKMS利用が残ります。
7. GCP・Azureとの比較：同じ「鍵管理」でも設計の癖が違う
ここからは、AWS KMSを基準に、GCP・Azureの同等サービスを同じ物差しで並べます。
7-1. GCP：Cloud KMSとCMEK（顧客管理鍵）
GCPのドキュメントでは、Cloud KMSを用いたCMEKは「保存データを保護する鍵を利用者が所有し制御できる」ことが明確に説明されています。
さらにCloud KMSは対称鍵に対してローテーションスケジュールを設定し、一定間隔で新しい鍵バージョンを自動生成でき、暗号化にはプライマリの鍵バージョンが使われ、復号には複数バージョンが使われ得る、という運用モデルが示されています。
注意点として、GCPでは非対称鍵は自動ローテーションをサポートしない（新しい公開鍵の配布など追加手順が必要）ことが明記されています。
このあたりは、鍵種別の選定に直結するので、要件の早い段階で確認しておくと安心です。
7-2. Azure：Key Vault（Vault/Managed HSM）とキーのローテーション
Azure Key Vaultは鍵/シークレット/証明書を扱うセキュアなストアとして説明され、ログをストレージ/イベントハブ/Azure Monitor Logsへ送れるなど監視面も整理されています。
また、Key VaultはVaultとManaged HSMの2種類のリソースタイプがあり、Vaultはソフトウェア保護とHSM保護のキーを扱え、Managed HSMはHSM保護キーのみ、という整理が公式に示されています。
ローテーションは、Key rotation policyにより自動ローテーションや期限前通知を構成できると説明されています（日本語ドキュメントにも明記）。
7-3. 比較の結論：選定は「統合先」と「運用文化」で決まる
- AWSはKMSが多くのサービス統合の中心に居て、キーポリシー主体のアクセス制御が強い
- GCPはCMEKを“鍵の所有と制御”として強く打ち出し、鍵バージョンとローテーションスケジュールの概念が分かりやすい
- AzureはKey Vaultを「鍵＋シークレット＋証明書」の統合ストアとして扱い、Vault/Managed HSMの分岐でコンプライアンス要件を吸収しやすい
つまり「どれが上」ではなく、「自社の統合先（どのクラウドサービスを使うか）」と「運用文化（ポリシー、監査、ローテーションの回し方）」で最適が決まります。
8. ありがちな落とし穴と、先回りの対策
8-1. “管理者なら当然使える”と思ってキーポリシーで詰む
KMSはキーポリシーが主で、IAM等を使う場合でもキーポリシーが許可していなければ成立しません。ここを知らないと、緊急時に復号できずに大きな障害になります。
対策は、鍵管理者ロールの“ブレークグラス（緊急用）”を含めた運用設計を先に作り、定期的に復号できるか検証しておくことです。
8-2. 鍵の削除スケジュールを軽く扱ってしまう
鍵の削除は「復号不能」につながります。鍵の削除・無効化は“データ削除に近い操作”として、変更管理（申請・承認・監査ログ）を強める方が安全です。顧客管理キーは削除スケジュール管理を含めフルコントロールできる、と公式に整理されています。
8-3. ローテーションを“設定しただけ”で満足してしまう
AWSでは顧客管理キーの自動ローテーションは任意です。年次が既定で、必要なら期間変更も可能です。
ただし、ローテーションは「要件」ではなく「運用」です。
- 期限・頻度をどう決めるか
- 例外（停止期間、凍結期間）をどう扱うか
- 影響範囲をどう検証するか
ここまで含めて“回る仕組み”にしないと、形骸化します。
9. 今日から使える最小テンプレ（サンプル）
最後に、チームでそのまま使える最小テンプレの例を置いておきます。小さく始めて、必要に応じて育ててくださいね。
9-1. 鍵の分割方針（例）
prod-app-data-key：本番アプリの保存データ用（顧客管理キー）prod-audit-log-key：監査ログ用（顧客管理キー、アクセスを最小化）dev-shared-key：開発環境共通（必要最小限の統制）
鍵の数を増やしすぎず、でも境界（本番/監査/開発）を明確にするバランスが、運用では効きます。料金は鍵あたり月額なので、“鍵を増やす判断”が説明しやすいのも良い点です。
9-2. 役割分担（例）
- Security/Platform：キーポリシー変更、ローテーション設定、削除/無効化
- Application：暗号化/復号の利用権限（必要最小限）
この分離は、キーポリシー中心のKMSの思想に合い、事故を減らします。
9-3. 監査（例）
- CloudTrailでKMS API呼び出しを必ず記録する
- 監査に必要な期間を定め、保管とアクセス権を固定する
KMSはCloudTrail統合が明記されているため、監査設計の起点にしやすいです。
まとめ：AWS KMSは「暗号化」より「運用と説明責任」を楽にする
AWS KMSは、顧客管理キーを中心に、鍵ポリシー・ローテーション・監査ログまで含めて“鍵の運用”を仕組み化できるサービスです。特に、キーポリシーがアクセス制御の中心である点と、CloudTrailで鍵利用を追える点は、セキュリティと運用品質を底上げしてくれます。
GCPのCloud KMS（CMEK）やAzure Key Vaultも、同じ課題（鍵の所有、ローテーション、監査）を解くための強い選択肢で、それぞれ鍵バージョンやローテーション、リソースタイプの考え方に特徴があります。
最初の一歩としては、「本番データ用の顧客管理キーを1つ用意し、役割分担と監査ログ方針を決める」だけでも十分価値があります。そこから徐々に、鍵の分割、ローテーションの最適化、コスト最適化へと育てていくのが、いちばん失敗しにくい進め方です。