AWS KMSの料金・クォータとサービス連携
AWS KMSのキーとAPIリクエストにかかる料金、リージョン別クォータとスロットリング、データキーキャッシュの設計、Parameter Store・Secrets Manager・データベース・ストレージでの暗号化を解説します。
AWS KMSの料金・クォータとサービス連携
AWS Key Management Service（AWS KMS）を利用する設計では、暗号化の安全性だけでなく、キーの維持費、暗号APIの呼び出し回数、サービスごとのリクエスト上限も考慮します。暗号化を各AWSサービスに組み込む方法も一様ではありません。ここでは、料金とクォータを見積もる考え方、データキーの再利用を伴うキャッシュ、代表的なAWSサービスでのKMS連携を順に整理します。
KMSの料金を構成する要素
AWS KMSの料金は大きく、キーの維持に関する料金とKMS APIリクエストに関する料金に分けて考えます。実際の金額や無料利用枠、対象となるキーの条件は変更されることがあるため、見積もり時には利用リージョンの最新の料金表を確認してください。
キーの種類と月額料金
利用者が作成・管理するカスタマー管理キーには、キーごとの月額料金がかかります。キーを複数のアプリケーションやデータセットで使い分ける設計では、必要な分離と管理のしやすさに加えて、キー数に応じた固定費も考慮します。
マルチリージョンキーは、プライマリキーだけを課金対象にする仕組みではありません。プライマリキーと各リージョンに作成するレプリカキーは、それぞれキーとして料金の対象になります。複数リージョンへの展開を計画するときは、リージョンごとに作成するキーの数を積み上げて見積もります。
AWS管理キーにはKMSキー自体の月額料金はありません。ただし、キーを使うAWSサービスそのものの利用料や、サービスの料金体系に含まれるその他の費用まで無料になるという意味ではありません。カスタマー管理キーとAWS管理キーでは、利用者が制御できるポリシーやライフサイクルも異なるため、料金だけで選ばずに必要な管理権限を確認します。
APIリクエストの料金
暗号化、復号、データキー生成などのKMS APIリクエストも課金要素です。リクエスト数だけでなく、呼び出すAPIの種類やキーの種類などによって料金の扱いが異なる場合があります。たとえば、大量のオブジェクトや小さなレコードを頻繁に読み書きする処理では、データ量が小さくてもAPIリクエスト数が積み上がる可能性があります。
利用量を見積もるときは、単に「暗号化するデータの容量」を見るのではなく、ワークロードの単位時間あたりのデータキー生成・復号・暗号化などの回数を見積もります。AWSサービスが利用者に代わってKMSを呼び出す統合機能を使う場合も、サービスの動作とKMSリクエスト数、料金上の扱いを確認します。個々のAPIの料金や無料枠の適用条件は固定値として記憶せず、AWS KMSの料金ページで最新情報を確認してください。
リクエストクォータとスロットリング
AWS KMSには、サービスの安定性と可用性を保つため、API操作のリクエストレートに関するクォータがあります。クォータはAWSアカウントとリージョンの組み合わせごとに適用されます。別のリージョンへワークロードを分散すればそれぞれのリージョンでクォータが計算されますが、単一リージョンの上限を自動的に共有・拡張するわけではありません。
上限値はAPI操作、AWSリージョン、KMSキーの種類などによって異なります。暗号操作のクォータは複数の操作で共有される場合もあります。たとえば対称キーを使う暗号操作では、Encrypt、Decrypt、GenerateDataKeyなどが共通のリクエストレート枠を使う分類があります。一方、非対称キーの操作や管理系APIには別の枠が適用される場合があります。正確な上限はリージョンやキー種別で変わり得るため、単一の数値をすべての環境に当てはめないでください。
一部のキー種別では、対称キーを使う暗号操作より低いレートのクォータが設定されます。対称キーによる暗号化操作は比較的高いレートを利用できる場合がありますが、これは無制限を意味しません。実環境のクォータや消費傾向はService QuotasとCloudWatchなどで確認します。
クォータを超えると、KMSはリクエストをスロットリングします。呼び出し元では遅延やスロットリングエラーが発生し、結果としてアプリケーション処理が遅くなったり失敗したりします。短時間にリクエストが集中しないように負荷を平準化し、エラー時は再試行可能な応答を見分けて指数バックオフとランダムな揺らぎを組み合わせた再試行を設計します。再試行を無制限に繰り返すと負荷をさらに高めるため、試行回数や待機時間にも上限を設けます。
デフォルトのクォータで要件を満たせない場合は、Service Quotasから引き上げを申請できます。Service Quotasで変更できないクォータや、そのリージョンで同サービスのクォータ管理が利用できない場合は、AWS Support Centerからケースを作成して問い合わせます。申請だけに依存せず、呼び出し削減、負荷分散、バックオフなどもあわせて検討してください。
データキーキャッシュで呼び出しを抑える
KMS APIの呼び出し回数が多いアプリケーションでは、エンベロープ暗号化で使うデータキーを一定の条件で再利用するデータキーキャッシュが選択肢になります。毎回KMSから新しいデータキーを取得する方式に比べ、条件に合うキャッシュ済みのデータキーを使うことで、KMSリクエストを減らし、コストやクォータへの負荷を抑えられる可能性があります。
キャッシュは無条件に共有されるAWS KMSの仕組みではありません。アプリケーション、またはAWS Encryption SDKなどのクライアントライブラリが、プロセス内などのキャッシュから利用可能なデータキーを探し、キャッシュの有効性や再利用上限を管理します。利用する暗号化ライブラリとキャッシュ実装の仕様に従い、データキーを再利用する主体や範囲を設計します。
キャッシュからキーを利用するときは、その暗号操作のための新たなKMS API呼び出しが発生しない場合があります。キャッシュに利用可能なキーがない場合、キーが期限切れになった場合、または再利用の制限に達した場合は、新しいキーを取得するためにKMSを呼び出し、キャッシュを更新してから処理を行います。キャッシュによって、キーの使用許可や暗号化されたデータキーの保護が不要になるわけではありません。
キャッシュ利用時のセキュリティ境界
キャッシュに保持される平文データキーは、キャッシュの寿命のあいだプロセスのメモリ上に残る可能性があります。キーを再利用するとKMS呼び出しとコストを抑えられる一方、一つのデータキーが保護するデータ量・メッセージ数が増え、侵害時に影響する範囲も広がり得ます。そのため、キャッシュを大きくすること自体を性能最適化の目標にせず、再利用によるリスクと削減効果を比較します。
データキーキャッシュを使う場合は、少なくとも次の制約を具体的に設定します。
- 最大保持時間：平文データキーをキャッシュに置いてよい時間を制限する。
- 最大メッセージ数：一つのキャッシュ済みデータキーを使用できる暗号化メッセージ数を制限する。
- 最大データ量：そのキーで処理できる暗号化データの合計量を制限する。
- キャッシュ容量と分離：異なるアプリケーション、テナント、暗号化コンテキスト、データ分類のキーを不用意に共有しない。
- キーの寿命と廃棄：期限切れや上限到達後に利用できないようにし、プロセス終了・更新時の破棄も設計する。
AWS Encryption SDKのキャッシュを利用する場合は、キャッシュの設定・実装に関する公式ガイダンスを確認し、可能な範囲で再利用の上限を小さくします。暗号文の形式、暗号化コンテキスト、キー識別情報などが異なるリクエストに、誤って同一のキャッシュエントリを適用しないことも重要です。キャッシュの利用は暗号化設計上の選択であり、データキーを新規生成する方式を置き換える前に、脅威モデル、SDKの安全性要件、鍵の有効期間を検討します。
Parameter StoreでのKMS暗号化
AWS Systems Manager Parameter Storeは、アプリケーション設定などの名前付きパラメーターを集中的に保存・取得するサービスです。平文の設定値にはStringやStringListを利用でき、暗号化が必要な値にはSecureStringを使います。SecureStringでは値がKMSキーで暗号化され、取得時には権限に応じて復号できます。
SecureStringの暗号化にはAWS管理キーを利用でき、キーを指定しない場合はアカウントのaws/ssmキーが使われます。アクセス制御や監査をより細かく行う場合は、対称暗号化のカスタマー管理キーを指定できます。Parameter Storeは非対称KMSキーをSecureString用途に使いません。
標準ティアのSecureStringでは、KMSの対称暗号化キーで値を直接暗号化する方式が使われます。アドバンストティアではAWS Encryption SDKを用いるエンベロープ暗号化が使われます。ティアによる容量制限や料金なども異なるため、暗号方式だけでなくParameter Storeの最新のティア仕様も確認します。
Parameter Storeは一般的な設定値をまとめて扱うのに適しています。一方、パスワード、APIトークンなどのシークレットを保管し、自動ローテーションやシークレット管理機能を必要とする場合、AWSはSecrets Managerの利用を推奨しています。保存先はデータの性質と必要なライフサイクル機能に基づいて選びます。
Secrets Managerでのシークレット暗号化
AWS Secrets Managerは、データベース認証情報やAPIキーなどのシークレットを保存・管理するサービスです。シークレット値はAWS KMSを用いて保存時に暗号化されます。KMSキーがシークレット値を直接暗号化するのではなく、Secrets ManagerがKMSにデータキーを要求し、そのデータキーを使うエンベロープ暗号化を行います。暗号化済みデータキーはシークレットのメタデータとともに保持され、Secrets Managerが復号処理を管理します。
新しいシークレット値を保存するときはKMSのデータキーが使われ、読み出し時は必要な許可のもとで暗号化済みデータキーをKMSで復号し、シークレット値を返します。利用者がSecrets ManagerのAPIを使って値を取得する場合、アプリケーション自身がデータキーの平文を管理する構成とは異なります。
キーにはSecrets Manager用のAWS管理キーaws/secretsmanager、または同じアカウント・リージョンの対称暗号化カスタマー管理キーを選べます。カスタマー管理キーを使うと、キーに対する権限設定や監査をより細かく設計できます。その一方で、Secrets Managerを呼び出す権限に加え、選択したKMSキーを利用できることが必要です。シークレットへのアクセス許可とKMSキーの許可の双方を確認します。
データベースとストレージの暗号化
AWSサービスは、サービスが管理するストレージ層、データベースのリソース、アプリケーションが扱う個々のデータなど、異なる粒度で暗号化を提供します。同じ「KMSを使った暗号化」でも、暗号化を実行する主体、鍵を選ぶ時点、復号を意識する範囲はサービスによって異なります。
データベース
Amazon RDSでは、DBインスタンスの保存データだけでなく、関連するログ、自動バックアップ、リードレプリカ、スナップショットも暗号化対象になります。暗号化キーはAWS管理キーまたはカスタマー管理キーから選択できます。DBインスタンス作成後に、そのインスタンスのKMSキーを直接別のキーへ変更することはできません。キーを変更する必要がある場合は、スナップショットのコピー時に別のキーで暗号化するなど、サービスがサポートする移行手順を確認します。
Amazon DynamoDBではテーブルの保存データを暗号化し、AWS所有キー、AWS管理キー、またはカスタマー管理キーによる暗号化を選択できます。データベースのサービス側暗号化は、テーブル内の個々の属性をアプリケーション要件に応じて暗号化することと同じではありません。属性単位でデータベース管理者にも平文を見せない要件がある場合は、アプリケーション側のクライアント暗号化など、別の暗号化層を検討します。
データベースサービスごとに、インスタンス、クラスター、テーブル、ストレージ、バックアップのどの単位で暗号化が適用されるか、作成後に設定を変えられるかが異なります。RDS、Aurora、DynamoDBなどの具体的な仕様を確認せずに、ひとつのサービスの制約を別のサービスへ当てはめないようにします。
EBSとS3
Amazon EBSではボリュームとスナップショットの暗号化を利用できます。暗号化ボリュームでは、保存時のデータだけでなく、サービスが定めるボリューム間のデータ転送やスナップショットにも暗号化が適用されます。デフォルト暗号化やKMSキーの選択を確認し、新しいボリュームの作成元となるスナップショットや共有手順も含めて設計します。
Amazon S3は、新しいオブジェクトに対してサーバー側暗号化を既定で適用します。必要に応じて、S3管理キーによるサーバー側暗号化、AWS KMSキーを使うサーバー側暗号化（SSE-KMS）、二層のSSE-KMSなどを選択します。AWS KMSとの連携やキー単位の制御が必要な場合は、SSE-KMSの設定とオブジェクトに対するS3権限・KMS権限の両方を確認します。
サーバー側暗号化では、クライアントがオブジェクトをアップロードすると、S3が保存時の暗号化を実行し、ダウンロード時の復号もサービスが扱います。これに対してクライアント側暗号化では、データをS3へ送信する前にクライアントやアプリケーションが暗号化し、暗号化処理と鍵を利用者側で管理します。どの方式を選ぶかで、AWSサービス側に平文を渡す範囲、鍵の管理主体、検索や処理の方法が異なります。
暗号化処理の主体とKMS APIを整理する
| 利用形態 | データを暗号化する主体 | KMSの主な役割 | 主な確認事項 |
|---|---|---|---|
| アプリケーションのエンベロープ暗号化 | アプリケーション | データキーの生成・保護と、後のデータキー復号 | 平文キーのメモリ保持、暗号化済みデータキーの保存、kms:GenerateDataKeyやkms:Decryptの権限 |
| データキーキャッシュ | SDKまたはアプリケーション | 必要時のデータキー生成・復号。条件を満たす間はキャッシュから再利用 | 再利用の上限、キャッシュ分離、平文キーの寿命、クォータ削減とリスクの比較 |
Parameter Store SecureString |
Parameter StoreとKMS | パラメーター値の暗号化・復号 | 標準／アドバンストティア、既定のaws/ssmキー、カスタマー管理キーと権限 |
| Secrets Manager | Secrets ManagerとKMS | シークレット値用データキーの保護 | aws/secretsmanagerまたはカスタマー管理キー、シークレットとKMSの両方の権限 |
| RDS、DynamoDB、EBS、S3 | 各AWSサービス、またはクライアント暗号化の場合は利用者 | サービスごとに異なる保存時暗号化用キーの管理 | 暗号化の適用単位、設定可能な時点、バックアップ／スナップショット、サーバー側かクライアント側か |
サービス統合ではアプリケーションからKMS APIを直接呼び出さなくても、AWSサービスが内部でKMS操作を行うことがあります。したがって、料金やクォータを検討するときはアプリケーションのAPI呼び出しだけを数えず、利用するサービスの暗号化仕様も確認します。
DVA試験での判断ポイント
- KMSの料金は、キーの種類・数に応じた費用と、APIリクエストの費用を分けて考える。マルチリージョンキーはプライマリとレプリカを別々に数える。
- AWS管理キーはキー自体の月額料金がないが、関連するAWSサービスの料金がすべて無料になるわけではない。
- API料金は操作の種類などによって異なり、リクエストレートのクォータも操作・リージョン・キー種別で異なる。上限超過時はスロットリングが発生する。
- KMSリクエストクォータはアカウントとリージョンごとに評価される。クォータ引き上げはService Quotasを基本とし、利用できない場合などはAWS Support Centerへ申請する。
- 大量の
GenerateDataKey呼び出しでは、AWS Encryption SDKのデータキーキャッシュがAPI呼び出し削減に役立つ場合がある。ただし、KMS自体が任意のAPI要求を自動でキャッシュするわけではない。 - キャッシュは平文データキーの寿命と再利用範囲を広げる可能性がある。最大経過時間、メッセージ数、データ量、キャッシュの分離を制約し、セキュリティとのトレードオフを評価する。
- Parameter Storeは汎用的な設定値と
SecureStringを扱う。自動ローテーションなどを伴うシークレット管理にはSecrets Managerを選ぶ。 - Parameter Storeの
SecureStringは対称KMSキーを用いる。標準ティアはKMSによる直接暗号化、アドバンストティアはAWS Encryption SDKを用いるエンベロープ暗号化である。 - Secrets ManagerはKMSキーでデータキーを保護し、データキーでシークレット値を暗号化する。キーの指定やアクセス許可はシークレットの利用主体と合わせて確認する。
- データベースやストレージは、サービスごとに暗号化単位、キーの選択時期、バックアップへの適用、作成後の変更可否が異なる。
- S3のサーバー側暗号化はS3が保存時暗号化と復号を扱い、クライアント側暗号化はアップロード前の暗号化と鍵の管理を利用者が担う。
AWS公式ドキュメント
重要ポイント
- ▸カスタマー管理KMSキーはキーごとの月額料金とAPIリクエスト料金が発生し、マルチリージョンキーではプライマリと各レプリカがそれぞれ課金対象になる。AWS管理キーにはキー自体の月額料金はないが、関連サービスの料金は別途確認する
- ▸AWS KMSのAPIリクエスト料金は操作の種類などで異なり、クォータもアカウント・リージョンごとに操作やキー種別に応じて設定される。上限超過はスロットリングにつながり、必要に応じてService Quotas等で引き上げを申請する
- ▸AWS Encryption SDKのデータキーキャッシュはアプリケーション側でデータキーを再利用してKMS呼び出しを抑える設計であり、AWS KMS APIがすべての呼び出しを自動キャッシュするわけではない
- ▸キャッシュには最大保持時間・最大メッセージ数・最大データ量などの制約を設け、平文キーの保持リスクと暗号境界を慎重に評価する
- ▸Parameter StoreのSecureStringはKMSで暗号化し、Secrets ManagerはKMS管理のデータキーを使ってシークレットをエンベロープ暗号化する
- ▸データベースやストレージの暗号化方式はサービスと粒度によって異なる。KMSキー選択の時点、バックアップへの適用、サーバー側暗号化とクライアント側暗号化の違いを確認する
このトピックの学習を完了しますか？
完了状態はいつでも切り替えられます
この試験ドメイン内で次の学習に進む
同じサービスの関連トピック
KMS と暗号化 に関連するトピックを続けて確認できます。