📌 結論：KMSスロットリングを防ぐ3つのポイント
問題：スロットリング
KMSにはリクエスト制限がある
超えると「拒否」されてエラーに！
🏦 銀行窓口の行列と同じ
超えると「拒否」されてエラーに！
🏦 銀行窓口の行列と同じ
解決：データキーキャッシュ
Encryption SDKで
データキーを再利用
🏦 合鍵を作って使い回す
データキーを再利用
🏦 合鍵を作って使い回す
効果：劇的な改善
KMSリクエストを
最大99%削減可能！
🏦 窓口に行く回数が激減
最大99%削減可能！
🏦 窓口に行く回数が激減
😱 そもそもスロットリングって何？
🏦 銀行の金庫室で例えると超わかりやすい！
KMS = 銀行の金庫室｜暗号化キー = 金庫の鍵｜リクエスト = 窓口での手続き
👥 お客さん（リクエスト）
✅ 処理中
✅ 処理中
✅ 処理中
⏳ 待機中
❌ 拒否！
❌ 拒否！
➡️
KMS（金庫室）
⚠️ 窓口は3つだけ！
「窓口が満員なので対応できません」= ThrottlingException
リージョンごとに 5,500〜30,000リクエスト/秒 の上限あり
リージョンごとに 5,500〜30,000リクエスト/秒 の上限あり
😵 スロットリングが起きると...
⚠️
エラー発生
アプリが動かない！
🐌
レイテンシ増加
リトライで遅延
💸
コスト増加
リトライ分も課金
💡 解決策：Encryption SDK のキャッシュ機能
🔑 「合鍵」を作って使い回す戦略！
ポイント：毎回KMSに行くのではなく、データキーをキャッシュして再利用する
アプリケーション
暗号化したいデータ
① 初回のみ
➡️
Encryption SDK
キャッシュ
キャッシュ
データキーを保存
① 初回のみ
➡️
AWS KMS
マスターキー管理
🎯 2回目以降は？
キャッシュからデータキーを取得 → KMSへのアクセス不要！
🏦 銀行に行かずに「合鍵」で金庫を開ける感覚
🔄 Before / After で見る効果
📊 1,000件のデータを暗号化する場合
❌ キャッシュなし
😱
従来の方法
データ1件目を暗号化
KMS呼出 1回
データ2件目を暗号化
KMS呼出 1回
データ3件目を暗号化
KMS呼出 1回
...1,000件目まで続く
合計 1,000回！
💸
コスト：$0.03
1,000回 × $0.00003
✅ キャッシュあり
🚀
Encryption SDK使用
データ1件目を暗号化
KMS呼出 1回
データキーをキャッシュに保存
保存完了
2〜1,000件目はキャッシュ利用
KMS呼出 0回！
🎉
コスト：$0.00003
1回 × $0.00003 = 99.9%削減！
⚙️ キャッシュの設定パラメータ
🔧 セキュリティとパフォーマンスのバランスを取る3つの設定
Max Age（最大有効期限）
キャッシュしたデータキーの有効期限を設定。
期限切れ後は新しいキーを取得。
期限切れ後は新しいキーを取得。
# 推奨: 300秒（5分）以下
max_age = 300
max_age = 300
🏦 たとえ：合鍵の有効期限
Max Messages Encrypted
1つのデータキーで暗号化できる最大件数。
上限に達したら新しいキーを取得。
上限に達したら新しいキーを取得。
# 推奨: 用途に応じて設定
max_messages = 1000
max_messages = 1000
🏦 たとえ：合鍵の使用回数上限
Max Bytes Encrypted
1つのデータキーで暗号化できる最大バイト数。
大容量データ処理時に重要。
大容量データ処理時に重要。
# 推奨: 用途に応じて設定
max_bytes = 10737418240 # 10GB
max_bytes = 10737418240 # 10GB
🏦 たとえ：合鍵で開けられる金庫の総額上限
⚠️ セキュリティ上の注意
キャッシュを長く設定しすぎると、同じデータキーが長期間使われセキュリティリスクが増加します。
推奨：Max Ageは300秒以下に設定し、定期的にキーをローテーションしましょう。
📝 Python での実装例（AWS Encryption SDK）
import aws_encryption_sdk
from aws_encryption_sdk.caches.local import LocalCryptoMaterialsCache
from aws_encryption_sdk.key_providers.kms import KMSMasterKeyProvider
# 1. キャッシュを作成（メモリ内に100エントリまで保持）
cache = LocalCryptoMaterialsCache(capacity=100)
# 2. キャッシュ付きマスターキープロバイダーを作成
key_provider = KMSMasterKeyProvider(
key_ids=['arn:aws:kms:ap-northeast-1:123456789012:key/xxxxx']
)
# 3. キャッシング暗号化マテリアルマネージャーを作成
caching_cmm = aws_encryption_sdk.caching.CachingCryptoMaterialsManager(
master_key_provider=key_provider,
cache=cache,
max_age=300.0, # 最大300秒（5分）キャッシュ
max_messages_encrypted=1000 # 最大1000メッセージまで同じキー使用
)
# 4. 暗号化（2回目以降はキャッシュからキーを取得！）
for data in data_list:
ciphertext, header = aws_encryption_sdk.encrypt(
source=data,
materials_manager=caching_cmm
)
🛡️ その他のスロットリング対策
キャッシュ以外にも効果的な対策があります！
指数バックオフリトライ
エラー時に待ち時間を徐々に増やしてリトライ。
AWS SDKにはデフォルトで組み込み済み。
AWS SDKにはデフォルトで組み込み済み。
効果：一時的なスロットリングから自動回復
クォータ引き上げ申請
Service Quotasから上限緩和を申請。
ビジネス要件に応じて増加可能。
ビジネス要件に応じて増加可能。
効果：根本的な上限を引き上げ
マルチリージョン戦略
複数リージョンのKMSを使って負荷を分散。
マルチリージョンキーが便利。
マルチリージョンキーが便利。
効果：リージョン単位のスロットリング回避
CloudWatchモニタリング
ThrottleCountメトリクスを監視。
アラームで早期検知。
アラームで早期検知。
効果：問題発生前に対処可能
✅ ベストプラクティス5選
🏆 本番環境で守るべきルール
1
Encryption SDKを必ず使う
生のKMS APIを直接呼ぶのではなく、Encryption SDK経由でキャッシュ機能を活用。
Java、Python、C、JavaScript版が公式提供されています。
Java、Python、C、JavaScript版が公式提供されています。
2
Max Ageは短めに設定（300秒以下）
セキュリティとパフォーマンスのバランス。長すぎると同じキーが使われ続けてリスク増加。
推奨値：60〜300秒
推奨値：60〜300秒
3
CloudWatchでスロットリングを監視
ThrottleCountとRequestCountメトリクスにアラーム設定。
スロットリング発生率が1%を超えたら通知を出す。
スロットリング発生率が1%を超えたら通知を出す。
4
バッチ処理は分散させる
大量データの一括処理は時間を分散してスパイクを避ける。
SQSやStep Functionsで処理を平準化。
SQSやStep Functionsで処理を平準化。
5
事前にクォータを確認・申請
本番リリース前にService Quotasで現在の上限を確認。
予想リクエスト数が上限の70%を超えるなら事前に引き上げ申請。
予想リクエスト数が上限の70%を超えるなら事前に引き上げ申請。
📊 対策方法の比較
| 対策方法 | 効果 | 実装難易度 | コスト削減 | おすすめ度 |
|---|---|---|---|---|
| 💾 Encryption SDKキャッシュ | ◎ 最大99%削減 | ◎ 簡単 | ◎ 大幅削減 | ⭐⭐⭐⭐⭐ |
| 🔄 指数バックオフリトライ | ○ 自動回復 | ◎ SDK標準 | △ 変わらず | ⭐⭐⭐⭐ |
| 📈 クォータ引き上げ | ◎ 根本解決 | ◎ 申請のみ | × 増加 | ⭐⭐⭐⭐ |
| 🌍 マルチリージョン | ○ 分散効果 | △ 複雑 | × 増加 | ⭐⭐⭐ |
| 📊 CloudWatch監視 | ○ 早期検知 | ◎ 簡単 | △ 変わらず | ⭐⭐⭐⭐⭐ |
❓ よくある質問
🤔
キャッシュするとセキュリティは大丈夫？
適切な設定なら問題ありません。
• Max Ageを短く設定（300秒以下）することでキーの露出リスクを最小化
• キャッシュはメモリ内に暗号化された状態で保持
• アプリケーション終了時にキャッシュは自動的に消去
• AWS公式が推奨するベストプラクティスに沿った設計です
• Max Ageを短く設定（300秒以下）することでキーの露出リスクを最小化
• キャッシュはメモリ内に暗号化された状態で保持
• アプリケーション終了時にキャッシュは自動的に消去
• AWS公式が推奨するベストプラクティスに沿った設計です
🤔
どのくらいのリクエスト数からキャッシュを使うべき？
秒間100リクエスト以上ならキャッシュ導入を検討しましょう。
• 少量でもコスト削減効果はある
• バッチ処理で大量データを扱う場合は必須
• リアルタイム処理でレイテンシが重要な場合も有効
• 導入コストが低いので、迷ったら導入をおすすめ
• 少量でもコスト削減効果はある
• バッチ処理で大量データを扱う場合は必須
• リアルタイム処理でレイテンシが重要な場合も有効
• 導入コストが低いので、迷ったら導入をおすすめ
🤔
Lambda関数でもキャッシュは使える？
はい、使えます！ただし注意点があります。
• Lambda関数の実行コンテナが再利用される間はキャッシュ有効
• コールドスタート時は新しいキャッシュを作成
• Provisioned Concurrencyを使うとキャッシュの効果が安定
• 関数のグローバルスコープでキャッシュを初期化するのがベスト
• Lambda関数の実行コンテナが再利用される間はキャッシュ有効
• コールドスタート時は新しいキャッシュを作成
• Provisioned Concurrencyを使うとキャッシュの効果が安定
• 関数のグローバルスコープでキャッシュを初期化するのがベスト
🤔
KMSのクォータ上限はどこで確認できる？
Service Quotasコンソールで確認できます。
1. AWS コンソール → Service Quotas
2. 「AWS Key Management Service (KMS)」を選択
3. 「Cryptographic operations (symmetric) request rate」を確認
リージョンによって5,500〜30,000リクエスト/秒が上限です。
1. AWS コンソール → Service Quotas
2. 「AWS Key Management Service (KMS)」を選択
3. 「Cryptographic operations (symmetric) request rate」を確認
リージョンによって5,500〜30,000リクエスト/秒が上限です。
🎓 まとめ
問題
KMSには
リクエスト制限があり
超えるとスロットリング
リクエスト制限があり
超えるとスロットリング
解決策
Encryption SDKの
キャッシュ機能で
データキーを再利用
キャッシュ機能で
データキーを再利用
効果
KMSリクエストを
最大99%削減
コストも大幅カット
最大99%削減
コストも大幅カット