AWS KMSとは？仕組み・料金とキーポリシー設計・採用判断を実装者目線で解説

AWS KMS（AWS Key Management Service）は、暗号鍵の生成・保管・利用をAWS側のハードウェアセキュリティモジュール（HSM）に委ね、鍵の平文を取り出さないままアプリケーションから暗号化・復号を呼び出せるようにするマネージドサービスです。S3のサーバーサイド暗号化もEBSボリュームの暗号化も、内部ではKMSのキーを参照しています。

この記事では、エンベロープ暗号化がなぜ二段構えの鍵になるのか、キー3種別とキースペックの選び分け、キーポリシーとIAMポリシーが二重に効く認可の構造、1USD/月と0.03USD/1万リクエストという料金の積み上がり方、東京リージョンのリクエストクォータまでを実装の解像度で整理します。最後に、カスタマーマネージドキーへ切り替えるべき条件と、見送ってよい場面を条件付きで示します。

まとめ：AWS KMSが担う鍵管理の範囲とキー種別・コスト設計の結論

先に結論を置きます。KMSは「データを暗号化するサービス」ではなく、「データを暗号化する鍵を守り、その利用を認可・記録するサービス」です。ここを取り違えると設計もコストも合わなくなります。

• 実データを暗号化するのはアプリ側：KMSが直接暗号化できるのは4KBまでのデータに限られます。実務ではデータキーを受け取り、暗号化自体は自分のプロセスで行うエンベロープ暗号化を使います。
• まず決めるのはキーの種別：AWSマネージドキーは無料で運用も不要ですが、キーポリシーを書けず、アカウントをまたいだ共有もできません。監査や権限分離の要件が出た時点でカスタマーマネージドキーへ移ります。
• コストはキー本数ではなくリクエスト設計で決まる：キー1本は月1USDですが、毎回KMSを叩く実装にすると料金とスロットリングの両方が効いてきます。
• 認可はキーポリシーが起点：キーポリシー側で委任していない権限は、管理者権限を持つIAMユーザーでも通りません。

AWS KMSの定義とエンベロープ暗号化｜鍵が二段構えになる理由

KMSの中心にあるのは、鍵マテリアルを外に出さないという制約です。ここから実装側の使い方が決まります。

AWS KMSの定義｜鍵マテリアルがHSMの外に出ない前提の管理境界

KMSキーは、AWSが運用するHSM内部で生成され、平文のままHSMの外へ出ることはありません。利用者ができるのは、キーIDを指定してHSMに暗号処理を依頼することだけです。内部の鍵は階層化されており、HSMメモリ上のドメインキーは日次でローテーションされます。

KMSキーはリージョナルなリソースです。東京リージョンのキーで暗号化したデータは、そのままでは大阪リージョンで復号できません。リージョンをまたぐなら、キーIDが mrk- で始まるマルチリージョンキーを最初から選びます。共通鍵と公開鍵のどちらを使う場面かという基礎は公開鍵暗号方式と共通鍵暗号方式の違いとは？仕組み・アルゴリズム・使い分けを解説で整理しています。

エンベロープ暗号化の処理フロー｜GenerateDataKeyが2つの鍵を返す理由

KMSの Encrypt が扱えるのは4KBまでです。数百MBのファイルを暗号化するには、鍵を二段に重ねます。

1. アプリが GenerateDataKey を呼ぶ。KMSは平文のデータキーと、KMSキーで暗号化したデータキーの2つを返します。
2. アプリは平文のデータキーで実データを暗号化し、直後にメモリ上の平文データキーを破棄します。
3. 暗号化データと暗号化済みデータキーをセットでS3などに保存します。
4. 復号時は暗号化済みデータキーを Decrypt でKMSに戻し、平文データキーを受け取って実データを復号します。

この形にすると、KMSを通る通信量はデータ本体のサイズに依存しません。鍵を破棄したいときも、保存してある暗号化済みデータキーを消せば実データは復元不能になります。S3のSSE-KMSやEBSの暗号化は、この流れをAWS側が代行している状態です。なお、そのS3バケットに機密データが入っているかどうかを検出する側のサービスはAmazon Macieとは？S3の機密データ検出の仕組み・料金と日本語データの限界を実装者目線で解説で扱っています。

KMSキーの3種別とキースペック｜対称・非対称・HMAC・ML-DSAの選び分け

KMSキーは管理主体で3つに分かれ、さらにキースペックで用途が分かれます。先に種別を決めないと、料金も権限設計も後から覆ります。

カスタマーマネージド・AWSマネージド・AWS所有キーの権限と課金の差

3種別の違いは、キーポリシーを書けるかどうかと、CloudTrailで追えるかどうかに集約されます。

AWSマネージドキーは aws/ebs のようにサービスコードのエイリアスを持ち、そのサービスの文脈でしか使えません。監査ログの取得先についてはAWS CloudTrailとは？監査とセキュリティを強化する仕組みで扱っています。

キースペック別の用途｜対称AES-256から署名用RSA・ML-DSAまで

既定の SYMMETRIC_DEFAULT はAES-256-GCMの対称キーで、暗号化・復号とデータキー生成に使います。データを守るだけならこれで足ります。

非対称キーが要るのは、鍵を渡さずに検証させたい場面です。RSA_2048などの署名用キーは、署名をKMS内で作り、公開鍵だけを配布する構成に向きます。HMACキーはメッセージ認証コードの生成・検証専用です。2025年6月からは、FIPS 204に準拠した耐量子署名のML-DSAが加わりました。ML_DSA_44 / ML_DSA_65 / ML_DSA_87 の3スペックがあり、署名アルゴリズムは ML_DSA_SHAKE_256、鍵と署名操作は FIPS 140-3 セキュリティレベル3 の検証済みHSMで保護されます。署名を後から差し替えにくいコード署名やファームウェアが、移行の検討対象です。

キーポリシーとIAMポリシー・グラント｜KMSの認可が二重に効く構造

KMSのアクセス制御は、IAMだけを見ていると必ず詰まります。判定の起点がキー側にあるためです。

キーポリシーが起点になる理由｜IAMだけでは鍵を使えない既定動作

KMSキーにはリソースベースのキーポリシーが必ず1つ付きます。IAMポリシーで kms:Decrypt を許可しても、キーポリシーがそのプリンシパルへ権限を委任していなければ通りません。マネジメントコンソールで作成したキーの既定ポリシーには、アカウントのroot に対する全権委任が入っており、この記述があるからこそIAMポリシー側の許可が有効になります。

この既定を消すと、IAM経由の管理が一切効かないキーができあがります。復旧にはAWSサポートへの問い合わせが必要になるため、既定文を削るのではなく条件キーで絞るのが定石です。IAMの権限設計そのものはAWS IAMとは？仕組み・ユーザー/ロール/ポリシーの違いと権限設計のベストプラクティスを実装者目線で解説にまとめてあります。

グラントと暗号化コンテキスト｜一時的な委任と用途固定で認可を絞る条件

グラントは、キーポリシーを書き換えずに一時的な利用許可を与える仕組みです。AWSサービスが利用者に代わってKMSを呼ぶ統合の多くはこの経路を使い、不要になれば RetireGrant で失効させます。CreateGrant のクォータは50rpsで、リクエストごとにグラントを作る設計には耐えません。

暗号化コンテキストは、暗号化時に付与するキーと値の組で、AES-GCMの追加認証データ（AAD）として使われます。値が一致しない復号リクエストは通りません。テナントIDやファイルパスを入れておけば、別テナントの暗号文を取り違えて復号する事故が構造的に防げます。値はCloudTrailのログにも記録されるため、どのデータに対する操作だったかを後から追える点も効きます。機密値そのものは入れないでください。

キーローテーションと削除運用｜90日から2560日の任意周期と待機期間の設計

鍵の入れ替えと廃棄は、KMSで最も運用ルールに直結する部分です。仕様が2024年に変わっており、古い前提のままだと余分な費用が出ます。

自動ローテーションの周期設定｜課金が2回目で頭打ちになる仕様

カスタマーマネージドキーの自動ローテーションは、2024年4月から90日〜2560日（約7年）の範囲で周期を指定できます。それ以前の固定365日から変わった部分です。加えて RotateKeyOnDemand による手動ローテーションが用意され、自動ローテーションの有効・無効にかかわらず実行できます。回数は1キーあたり最大25回までです。

費用の考え方も変わりました。ローテーションで増える保管料は1回目と2回目で各1USD/月が加算され、3回目以降は加算されません。つまり長期運用するキーの上限は月3USDです。「ローテーションするほど課金が積み上がる」という前提で止めている構成は、見直す価値があります。なおローテーションは新しい鍵マテリアルを追加するだけで、過去のデータは古い鍵マテリアルで復号され続けます。再暗号化は自動では行われません。

削除待機期間7〜30日の設計｜マルチリージョンキーの削除順序

KMSキーは即時削除できません。ScheduleKeyDeletion で7〜30日の待機期間（既定30日）を設定し、その間はキャンセルできます。実際の削除は予定時刻から最大24時間遅れる場合があるため、正確な時刻は DescribeKey で確認します。待機中のキーには保管料が発生しません。

削除の判断で重い制約はマルチリージョンキーです。プライマリキーを削除するには先に全てのレプリカキーの削除をスケジュールし、実際に削除され終わるのを待つ必要があります。プライマリの待機期間が動き出すのは、最後のレプリカが消えた時点からです。逆にレプリカ単体の削除に制約はなく、誤って消しても同じプライマリから同一リージョンへ再レプリケートすれば復旧できます。

AWS KMSの料金体系とリクエストクォータ｜東京リージョンの上限から逆算するコスト

KMSの費用は保管料よりリクエスト料で膨らみます。スロットリングが起きる理由も同じです。両方を1つの設計判断で潰せます。

キー保管1USDとリクエスト0.03USDの内訳｜無料枠2万件の扱い

2026年7月時点の公開価格では、カスタマーマネージドキーは1本あたり1USD/月（時間按分）で、対称・非対称・HMAC・マルチリージョン・インポート鍵のいずれでも同額です。APIリクエストは10,000件あたり0.03USD、非対称キーによる署名・検証は10,000件あたり0.15USDになります。

無料枠は全リージョン合計で月20,000リクエストですが、GenerateDataKeyPair と非対称キーを参照する操作は対象外です。AWSマネージドキーは保管料が無料でリクエスト分だけ課金され、削除予定のキーには課金されません。キー100本なら保管料は月100USD。対してAPIを毎秒100回叩けば月約2.6億回で780USDに達します。桁が逆転する境目はここです。

東京リージョン20,000rpsの共有クォータ｜データキーキャッシュでの削減

リクエストレートにはアカウント・リージョン単位の共有クォータがあります。対称キーの暗号化オペレーションは ap-northeast-1（東京）で20,000rps、us-east-1・us-west-2・eu-west-1 が100,000rps、その他のリージョンは10,000rpsです。非対称キー（RSA・ECC・ML-DSA）は1,000rpsまで下がります。

特に詰まりやすいのが GenerateDataKeyPair で、ECC_NIST_P256=100rps、RSA_2048=20rps、RSA_3072=4rps、RSA_4096=1rps という値です。管理系も CreateKey=5rps、DescribeKey=2,000rps と幅があります。対策は明快です。リクエストごとにデータキーを取り直さないこと、これに尽きます。AWS Encryption SDKのデータキーキャッシュのように、生成したデータキーを一定時間・一定回数の範囲で再利用すれば、料金とスロットリングが同時に下がります。キャッシュ上限を長く取るほど鍵の使い回し範囲は広がるため、期間はデータの機密度と突き合わせて決めてください。

CloudHSM・Secrets Managerとの違い｜鍵と機密値の担当領域の切り分け

KMSと混同されやすいサービスは、預けるものが違います。

鍵を預けるKMSと機密値を預けるSecrets Managerの境界

KMSが預かるのは鍵であり、任意の文字列を出し入れする置き場ではありません。データベースのパスワードやAPIトークンを保存したいなら Secrets Manager か Systems Manager パラメータストアを使い、それらの保管データを裏で暗号化する側にKMSが入ります。

Secrets Manager はローテーション用Lambdaで認証情報を自動更新でき、パラメータストアは標準パラメータなら追加料金なしです。この2つの選択基準はパラメータストアとは？AWS Parameter Storeの料金・使い方・Secrets Managerとの違いを解説で比較しています。設定値は安いほうへ、自動ローテーションが要る認証情報はSecrets Managerへ、という振り分けが実務的な落としどころです。

専有HSMと外部キーストア｜Azure Key Vaultとの構造差

CloudHSM はシングルテナントのHSMクラスタを自分で運用する形態で、時間課金（HSM1台あたり1.60USD/時間程度）が発生します。KMSのAPIを保ったまま鍵マテリアルをCloudHSM側へ寄せる仕組みが、KMSのカスタムキーストアです。さらに外部キーストア（XKS）を使うと、AWS外部の鍵管理基盤に鍵を置いたままKMS経由で呼び出せます。いずれもKMSキー自体は1USD/月のままで、HSM側の費用が上乗せされる構造です。

Azure側で対応するのは Key Vault ですが、こちらは鍵・シークレット・証明書を1つのボールトで扱い、専有HSMが要る場合は Managed HSM を選ぶ設計です。KMSが「鍵だけ」を担い、機密値は別サービスへ分けるのと構成が異なります。詳細はAzure Key Vaultとは？シークレット・キー・証明書の一元管理とRBAC・Managed HSMの違いを実装者目線で解説を参照してください。この差はマルチクラウド構成のIaCモジュール分割にも効いてきます。

受託開発でAWS KMSを採用する条件と見送る場面｜キー分割の判断基準

判断に移ります。論点はKMSを使うかどうかではなく、どこまでカスタマーマネージドキーで作り込むかにあります。

カスタマーマネージドキーへ切り替える3つの条件｜監査要件と分離境界

次のいずれかに当てはまるなら、AWSマネージドキーからカスタマーマネージドキーへ切り替えます。

• 鍵の利用者を絞る要件がある：特定のIAMロールだけがS3バケットの暗号文を復号できる、という制御はキーポリシーでしか書けず、AWSマネージドキーでは編集自体ができません。
• アカウントをまたいでデータを渡す：別アカウントのLambdaに復号させる構成は、キーポリシーでのクロスアカウント委任が前提です。
• 鍵の停止で有事対応をしたい：DisableKey で暗号文へのアクセスを即座に止める運用は、自分が管理するキーでしか成立しません。

切り替えの粒度は、環境（本番・検証）と機密度で分けるところから始めます。マイクロサービスごとに1本ずつ作れば、保管料も管理対象も本数に比例します。分離の境界は「侵害されたときに巻き添えにしたくない範囲」で引くと過不足が出ません。

AWSマネージドキーで足りる場面｜カスタマーマネージド化を見送る判断

逆に見送ってよいのは、単一アカウント・単一チームで完結し、暗号化の目的が保管時暗号化の要件充足だけで、鍵単位の権限分離も監査上のキーポリシー提出も要らない場合です。この状態でカスタマーマネージドキーを大量に作ると、月1USD×本数の固定費と、キーポリシーのレビュー工数だけが増えます。

PoCや数週間で破棄する検証環境も同様で、削除待機期間が最短でも7日ある以上、作っては消す運用とは相性がよくありません。もう1つ避けたいのは、リクエストごとに GenerateDataKey を呼ぶ実装のまま本番に出すことです。東京リージョンの20,000rpsへ自力で届かなくても、他システムと共有クォータを食い合ってThrottlingExceptionが出ます。キャッシュ設計を決める前の本番投入は見送ってください。

鍵設計を含むAWS基盤構築を外部委託する際に確認する要件と成果物

鍵管理は、いったん本番データを暗号化すると後から設計を変えにくい領域です。外部に委託する場合、キーの分離境界（環境別・テナント別・データ分類別のどれで分けるか）、ローテーション周期と再暗号化の要否、キーポリシーとIAMの責任分界、削除・失効時の手順の4点を要件として明示しておくと、引き渡し後の運用が詰まりません。

一創ではAWS上の設計・構築を受託し、IAMとKMSを含む権限設計をIaCのコードとして納品しています。インフラ構築（AWS・Google Cloud・Azure）では、既存環境の棚卸しから移行までを相談できます。鍵の設計だけを切り出した依頼でも構いません。

よくある質問

導入検討でよく出る5つの質問に答えます。

AWS KMSとWindowsのKMS（ライセンス認証）は同じものですか？

まったく別物です。Windowsの「KMS」はKey Management Serviceの略でボリュームライセンス認証を行う仕組みを指し、社内サーバーでWindowsやOfficeのライセンスを認証する用途に使われます。AWS KMSは暗号鍵の管理サービスであり、ライセンス認証の機能はありません。検索時に「AWS Key Management Service」という正式名称を使うと取り違えを防げます。

AWSマネージドキーからカスタマーマネージドキーへ後から移行できますか？

新しいカスタマーマネージドキーを作り、対象リソース側の暗号化設定を切り替える形になります。ただし既存データが自動で再暗号化されるわけではありません。S3ならオブジェクトのコピーによる再暗号化、EBSならスナップショットを新しいキーで再暗号化してボリュームを作り直す作業が伴います。旧キーはその暗号文が残る限り削除できないため、移行完了まで無効化せず残してください。

KMSキーを削除するとS3やEBSのデータはどうなりますか？

そのキーで暗号化されたデータは復号できなくなります。S3のオブジェクトは残りますが取得時にエラーとなり、EBSボリュームは暗号化されたスナップショットから復元できません。実質的なデータ消失です。削除前に、そのキーのARNをCloudTrailの過去ログで検索し、直近で Decrypt の呼び出しがないかを確認します。判断がつかないなら、まず DisableKey で無効化し、一定期間エラーが出ないことを確かめてから削除へ進めてください。

マルチリージョンキーと各リージョンで個別に作るキーはどちらを選ぶべきですか？

暗号文をリージョン間で移動させるかどうかで決まります。DynamoDBグローバルテーブルやS3のクロスリージョンレプリケーションのように、片方で暗号化したデータをもう片方で復号する構成ならマルチリージョンキーが必要です。逆に、リージョンごとに独立したシステムが動いていて暗号文が越境しないなら、個別キーのほうが分離境界が明確になります。削除時にレプリカを先に消す制約も付くため、必要がなければ個別キーを既定にしてかまいません。

KMSでThrottlingExceptionが出たときはどう対処しますか？

まず、どのAPIで詰まっているかをCloudTrailで特定します。GenerateDataKey が原因なら、データキーを都度生成せずキャッシュして再利用する実装へ変更するのが第一手です。GenerateDataKeyPair のRSA_4096は1rpsという低い上限のため、鍵ペア生成をリクエストパスから外す設計変更が要ります。実装を変えずに凌ぐ場合は、指数バックオフによるリトライを入れたうえで、Service Quotasからクォータ引き上げを申請します。オンデマンドローテーションの25回上限だけは引き上げできません。

関連記事

• Amazon S3とは？オブジェクトストレージの仕組み・ストレージクラスと料金・採用判断を実装者目線で解説：SSE-KMSでキーを参照する側の仕様。
• Amazon EBSとは？仕組み・ボリュームタイプと料金モデル・採用判断を実装者目線で解説：ボリューム暗号化と再暗号化の前提知識。
• AWS環境構築の手順｜VPC・EC2・IAM・セキュリティグループの初期設計を解説：KMSを組み込む前段のアカウント初期設計。
• 暗号化とは？共通鍵・公開鍵の違いと企業が守るべきデータの判断を解説：暗号化対象を決める上流の判断。
• クラウドセキュリティとは？リスクと責任共有モデルから見た企業の守り方：責任共有モデルにおけるKMSの位置。