SW BBANG J

S3バケットの暗号化設定を検討していると、必ずぶつかるのが「AWS管理キーで十分か、それともCustomer Managed Key（CMK）が必要か」という判断だ。コスト、制御レベル、監査要件——どれを優先するかによって答えが変わる。この記事では、AWS KMSの仕組みを実際の運用視点で整理し、S3暗号化における選択基準とコスト計算の考え方を具体的に解説する。 TL;DR：AWS管理キー vs Customer Managed Key（CMK） 比較項目 AWS管理キー（aws/s3） Customer Managed Key（CMK） キーポリシーの制御 不可（AWSが管理） 可能（完全制御） キーローテーション 1年（約365日）自動・変更不可 有効化すると1年ごとに自動（設定可能） クロスアカウントアクセス 不可 可能（キーポリシーで制御） キーの無効化・削除 不可 可能（削除は7〜30日の待機期間あり） CloudTrail監査 KMS API呼び出しはログに記録される KMS API呼び出しはログに記録される KMSキー料金 無料 月額料金あり（最新料金はAWS公式参照） APIリクエスト料金 発生する 発生する 主なユースケース シンプルな暗号化、コスト優先 コンプライアンス、クロスアカウント、アクセス制御 AWS KMSの仕組み：S3暗号化のデータフロー KMSを理解する上で最も重要な概念は、KMSが直接データを暗号化するわけではないという点だ。KMSはデータキー（Data K...

Lambdaのコードにデータベースエンドポイントをハードコードしたまま本番デプロイしてしまった経験は、エンジニアなら一度はある。設定値が変わるたびにデプロイが必要になり、最悪の場合は認証情報がリポジトリに残る。Lambda環境変数とKMS暗号化を組み合わせることで、この問題を構造的に解決できる。 TL;DR：Lambda環境変数とKMS暗号化の要点 項目 内容 環境変数の設定方法 コンソール・CLI・CloudFormation/CDKで設定可能 デフォルト暗号化 保存時はAWS管理キー（aws/lambda）で自動暗号化 カスタムKMS暗号化 顧客管理キー（CMK）を指定して追加保護が可能 コード側の取得方法 process.env / os.environ など言語標準の環境変数APIで取得 注意点 環境変数の値はLambdaコンソールで平文表示される（CMK指定時はコンソール上で暗号化テキストとして表示可能） Lambda環境変数の仕組みを理解する Lambda環境変数は、関数コードから分離された設定値をランタイム起動時に注入する仕組みだ。コンテナイメージで言えば、 docker run -e KEY=VALUE に相当する。関数が実行されると、設定した環境変数はOSレベルの環境変数としてランタイムプロセスに渡され、コードからは通常の環境変数として読み取れる。 暗号化の層は2段階ある。まず、すべての環境変数はAWSのインフラ側でAWS管理キー（ aws/lambda ）を使って保存時に暗号化される。これはデフォルト動作で、追加設定は不要だ。次に、顧客管理キー（CMK）を指定すると、そのキーで追加の暗号化レイヤーが適用される。CMKを使う場合、コンソール上での値の表示が暗号化テキストになり、復号にはKMSへのアクセス権限が必要になる。 graph TD Dev["開発者 / CI"] -->|update-function-configuration| LambdaService["Lambdaサービス"] ...