概要
AWS Lambda関数を本番環境で運用する際、「いつ・誰が・どの設定を変更したか」を把握することはセキュリティとガバナンスの観点で重要です。ランタイムの変更、IAMロールの差し替え、VPC設定の変更といった構成の変化を見逃すと、意図しないセキュリティリスクにつながる可能性があります。
AWSでは、Lambda関数の監視に AWS Config と AWS CloudTrail という2つのサービスを組み合わせて使用します。AWS Configはリソースの構成変更を継続的に記録し、CloudTrailはAPI呼び出しを監査証跡として記録します。本記事では、この2つのサービスの役割の違いを理解した上で、Lambda関数に対する設定変更の追跡とAPI操作の監査を実践します。
AWS Configによるリソース設定の監視の基礎についてはAWS Configによるリソース設定の監視を、CloudTrailログの分析については漏洩したアクセスキーの調査をそれぞれ参照してください。

クラウドおさるLambda 関数の設定が「何から何に変わったか」は AWS Config、「誰がその API を呼んだか」は CloudTrail でござる。この記事では、実際に設定を変えてから両方で痕跡をたどり、役割の違いを確かめるでござるな。
この記事のメリット
- AWS Config と CloudTrail の役割の違い(構成追跡 vs API監査)を正確に理解できる
- AWS Config で Lambda 関数の構成変更(ランタイム、メモリ、タイムアウト、IAMロール、VPC設定など)を追跡する方法を習得できる
- AWS Config ルールを使って Lambda 関数の設定がポリシーに準拠しているかを自動チェックする方法を学べる
- CloudTrail で Lambda 関数に対する API 呼び出し(CreateFunction、UpdateFunctionConfiguration など)を確認する方法を実践できる
- SCS試験で「Lambda関数の設定変更の監視」や「API操作の監査」を問われた際に正確に判断できるようになる
執筆者とキャラクター紹介
執筆者:土肥(とひ)
株式会社ジェニュインの代表であり元エンジニア。これまでオンプレミスと AWS 環境のインフラ業務を担当。AWS 認定資格の学習で得た知識を、ハンズオンとともに解説するのが得意。直近では新人の教育も行っており、これから技術を学ぶ方が納得できる解説を心がけています。基礎編・Cloud Practitioner の記事では、解説役としても登場します。


クラウドおさる



はじめましてでござる。弊猿はクラウドおさる。IT インフラが異常に発達した猿山から、雲に乗って地上の AWS を学びに降りてきたのでござる。



基礎編や Cloud Practitioner の記事では、とひさんに素朴な疑問をぶつける役でござるな。Security - Specialty などの記事では、要所でワンポイントや注意点をひとこと添えるでござる。



猿山にもデータセンターや監視当番があって、地上で起きることはだいたい猿山にも同じ仕組みがあるのでござる。例え話がつい猿山に寄るのは、弊猿の癖でござる。
技術解説
AWS Config と CloudTrail の違い
Lambda関数の監視において、AWS ConfigとCloudTrailはそれぞれ異なる観点の情報を提供します。
| 観点 | AWS Config | AWS CloudTrail |
|---|---|---|
| 記録対象 | リソースの構成状態(設定値の変化) | API呼び出し(操作の証跡) |
| 確認できること | Lambda関数のランタイムが何から何に変わったか | 誰がUpdateFunctionConfiguration APIを呼び出したか |
| 主な用途 | コンプライアンス評価、構成ドリフトの検出 | ガバナンス、セキュリティ監査、運用上のトラブルシューティング |
| データの形式 | 構成アイテム(Configuration Item) | イベントレコード(JSON) |
| 時間軸 | 構成変更のタイムライン | API呼び出しの履歴 |





猿山のバナナ倉庫でいえば、棚の中身が変わるたびに書き留める台帳が Config、扉を開けた猿の名前と時刻を記す入退室簿が CloudTrail でござる。同じ変更を、別の角度から残しているのでござるな。
AWS Config で追跡できる Lambda の構成情報
AWS Configは、Lambda関数の以下の構成情報を記録します。構成が変更されるたびに新しい構成アイテム(Configuration Item)が作成され、変更前後の値を比較できます。
| 構成項目 | 説明 | セキュリティ上の意味 |
|---|---|---|
| Runtime | 実行環境(Python 3.12、Node.js 20.x など) | サポート切れランタイムの使用はセキュリティリスク |
| Handler | エントリポイント | 意図しないハンドラーへの変更は不正コード実行の兆候 |
| MemorySize | 割り当てメモリ | 不必要な増加はクリプトマイニングの兆候の可能性 |
| Timeout | タイムアウト値 | 大幅な延長は不正処理の兆候の可能性 |
| Role | 実行ロール(IAM) | 権限の強いロールへの変更は権限昇格のリスク |
| VpcConfig | VPC設定(サブネット、セキュリティグループ) | VPC設定の変更はネットワークアクセス範囲の変化を意味する |
| ReservedConcurrentExecutions | 予約済み同時実行数 | 制限の解除はリソース枯渇攻撃のリスク |
| Environment Variables | 環境変数 | 機密情報の平文保存やエンドポイント変更のリスク |
AWS Config ルールによるコンプライアンスチェック
AWS Configには、Lambda関数の設定を自動的に評価する マネージドルール が用意されています。ルールに違反した場合、リソースは「非準拠(NON_COMPLIANT)」として記録されます。
| マネージドルール | チェック内容 |
|---|---|
lambda-function-settings-check | ランタイム、メモリサイズ、タイムアウト値が指定した範囲内か |
lambda-function-public-access-prohibited | Lambda関数がパブリックアクセスを許可していないか |
lambda-inside-vpc | Lambda関数がVPC内に配置されているか |
lambda-dlq-check | デッドレターキュー(DLQ)が設定されているか |
本記事の実践では lambda-function-settings-check ルールを使用して、Lambda関数のランタイムやタイムアウト値がポリシーに準拠しているかを確認します。
CloudTrail で記録される Lambda 関連の API 呼び出し
CloudTrailは、Lambda関数に対するすべての管理API呼び出しを記録します。主なイベント名は以下のとおりです。
| イベント名 | 操作内容 |
|---|---|
| CreateFunction20150331 | Lambda関数の作成 |
| UpdateFunctionConfiguration20150331v2 | 関数の設定変更(ランタイム、メモリ、タイムアウトなど) |
| UpdateFunctionCode20150331v2 | 関数コードの更新 |
| DeleteFunction20150331 | Lambda関数の削除 |
| AddPermission20150331v2 | リソースベースポリシーへの権限追加 |
| CreateEventSourceMapping20150331 | イベントソースマッピングの作成 |
CloudTrailのイベントレコードには、操作を実行したIAMプリンシパル(userIdentity)、操作日時(eventTime)、ソースIPアドレス(sourceIPAddress)などが含まれるため、「誰が・いつ・どこから操作したか」を特定できます。
実践
前提条件
以下のリソースが作成済みであること。
| リソース種別 | リソース名 | 用途 |
|---|---|---|
| Lambda関数 | config-audit-test-function | 監視対象のテスト用Lambda関数 |
| IAMロール | config-audit-test-lambda-role | Lambda関数の実行ロール(基本的なLambda実行権限) |
ステップ1: AWS Config の記録を有効化する
AWS ConfigでLambda関数の構成変更を追跡するには、AWS Configの記録が有効になっている必要があります。
- AWSマネジメントコンソールにログインし、リージョンが
ap-northeast-1(東京)であることを確認します - 上部の検索バーに
Configと入力し、表示された「Config」を選択します
記録の状態と記録対象の確認
- 左側ナビゲーションの「設定」を選択します
- 「顧客管理レコーダー」タブの「レコーダー」で、ステータスが「記録はオン」になっていることを確認します
- 「記録方法」の「記録戦略」を確認します。「カスタマイズ可能なオーバーライドのあるすべてのリソースタイプを記録」であれば、除外指定していないかぎり
AWS::Lambda::Functionも記録対象です - 特定のリソースタイプだけを記録する設定になっている場合は、「編集」から
AWS Lambda Functionを記録対象に追加します


AWS Config がまだ有効になっていないアカウントでは、Configコンソールの開始画面から記録を有効化します。その際、記録するリソースタイプ(すべて/特定のタイプ)、AWS Config が使用するIAMロール、設定スナップショットの送信先S3バケットを指定します。AWS Config は記録した構成アイテムの件数に応じて課金されるため、検証用アカウント以外で有効化するときは記録対象の範囲に注意してください。
ステップ2: AWS Config でLambda関数の構成タイムラインを確認する
AWS Configが記録を開始した後、Lambda関数の構成変更履歴を確認します。まず、テスト用Lambda関数の設定を変更して構成変更イベントを発生させます。
Lambda関数の設定を変更する
- 上部の検索バーに
Lambdaと入力し、表示された「Lambda」を選択します - 「関数」ページで
config-audit-test-functionをクリックします - 「設定」タブを選択します
- 「一般設定」セクションの「編集」をクリックします(「基本設定を編集」画面が開きます)
- 以下の設定を変更します
- メモリ:
256MB(デフォルトの128 MBから変更) - タイムアウト: 「分」を
0、「秒」を30に変更(デフォルトは0分3秒) - 「保存」をクリックします


AWS Config で構成変更を確認する
- 上部の検索バーに
Configと入力し、表示された「Config」を選択します - 左側ナビゲーションの「リソース」を選択します
- リソースタイプで
AWS::Lambda::Functionを選択します - 表示されたリソース一覧から
config-audit-test-functionをクリックします - 「リソースタイムライン」をクリックします
リソースタイムラインには、「設定変更」「CloudTrail イベント」「ルールのコンプライアンス」が時系列で表示されます。


変更直後はタイムラインに反映されないことがあります。数分待ってからページを再読み込みしてください。
- 設定変更のイベントをクリックすると、変更前(From)と変更後(To)の構成アイテムがJSON diffで並びます。
memorySizeが128から256に、timeoutが3から30に変更されたことが確認できます


ステップ3: AWS Config ルールでLambda関数の設定をチェックする
Lambda関数の設定がポリシーに準拠しているかを自動的にチェックするConfig ルールを作成します。ここでは lambda-function-settings-check マネージドルールを使用して、ランタイム・メモリ・タイムアウトを検証します。
このルールのパラメータは次のように評価されます。timeout と memorySize は「上限」ではなく「期待値そのもの」である点に注意してください。
| パラメータ | 必須 | 既定値 | 評価のされ方 |
|---|---|---|---|
runtime | 必須 | なし | カンマ区切りで指定したランタイムのいずれかに一致すれば準拠 |
role | 任意 | なし | 実行ロールの名前またはARNが一致すれば準拠 |
memorySize | 任意 | 128 | メモリサイズが指定値と一致すれば準拠 |
timeout | 任意 | 3 | タイムアウトが指定値と一致すれば準拠 |
memorySize と timeout を省略すると既定値(128 / 3)が期待値になるため、手順2でメモリとタイムアウトを変えた関数は非準拠になります。
Config ルールの作成
- AWS Configのコンソールで、左側ナビゲーションの「ルール」を選択します
- 「ルールを追加」をクリックします。3ステップのウィザード(ルールタイプの指定 / ルールの設定 / 確認と作成)が開きます
- ステップ1で「AWS によって管理されるルールの追加」を選択し、一覧から使用するマネージドルールを選びます。一覧は検索ボックスで絞り込めます


- ステップ2でルール名・説明・パラメータ・評価対象の範囲を設定します。今回は以下のようにします
- パラメータ
runtime:python3.12,python3.13,nodejs20.x,nodejs22.x - パラメータ
memorySize:256 - パラメータ
timeout:30 - 変更範囲: タグ
Purpose = config-audit-demo(検証用の関数だけを評価対象にする) - ステップ3で内容を確認し、「ルールを追加」をクリックします
検索しても
lambda-function-settings-checkが一覧に出てこない場合は、AWS CLI でも作成できます。
>
“
bash aws configservice put-config-rule --config-rule '{ "ConfigRuleName": "lambda-function-settings-check", "Scope": {"TagKey": "Purpose", "TagValue": "config-audit-demo"}, "Source": {"Owner": "AWS", "SourceIdentifier": "LAMBDA_FUNCTION_SETTINGS_CHECK"}, "InputParameters": "{\"runtime\":\"python3.12,python3.13,nodejs20.x,nodejs22.x\",\"memorySize\":\"256\",\"timeout\":\"30\"}" }'“
>
変更範囲(Scope)は「リソースタイプ」と「タグ」のどちらか一方しか指定できません。両方を指定すると
Scope cannot be applied to both resource and tagエラーになります。
作成したルールの詳細画面で、パラメータとトリガータイプ(設定変更)を確認できます。


コンプライアンス結果の確認
ルールが作成されると、AWS Configは対象のLambda関数を自動的に評価します。評価には数分かかる場合があります。
- 左側ナビゲーションの「ルール」を選択し、
lambda-function-settings-checkをクリックします - 「対象範囲内のリソース」セクションで、各Lambda関数のコンプライアンスステータスを確認します。このセクションは既定で「非準拠」だけを表示するため、プルダウンを「すべて」に切り替えます
ランタイム・メモリ・タイムアウトがすべて期待値どおりであれば「準拠(COMPLIANT)」と表示されます。1つでも一致しなければ「非準拠(NON_COMPLIANT)」になります。


非準拠を確認するテスト
非準拠の状態を確認するために、Lambda関数のタイムアウト値をルールの期待値(30秒)と異なる値に変更してみます。
- 上部の検索バーに
Lambdaと入力し、表示された「Lambda」を選択します config-audit-test-functionをクリックし、「設定」タブの「一般設定」→「編集」を選択します- タイムアウトを
2分0秒(120秒)に変更し、「保存」をクリックします - AWS Configのコンソールに戻り、
lambda-function-settings-checkルールのページで「アクション」→「再評価」を選択します
数分後、config-audit-test-function のステータスが「非準拠(NON_COMPLIANT)」に変わることが確認できます。





lambda-function-settings-check の memorySize と timeout は上限ではなく、一致すべき期待値でござる。省略すると既定値の 128 と 3 が期待値になるので、設定を変えた関数は非準拠になるのでござるぞ。
ステップ4: CloudTrail でLambda関数に対するAPI呼び出しを確認する
CloudTrailを使用して、Lambda関数に対するAPI呼び出しの履歴を確認します。ステップ2で実施した設定変更が記録されていることを確認します。
イベント履歴の確認
- 上部の検索バーに
CloudTrailと入力し、表示された「CloudTrail」を選択します - 左側ナビゲーションの「イベント履歴」を選択します
- 「ルックアップ属性」のドロップダウンで「リソース名」を選択し、
config-audit-test-functionと入力します


Lambda関数に対する操作が時系列で表示されます。先ほど実施した設定変更は UpdateFunctionConfiguration20150331v2 というイベント名で記録されています。
イベントの詳細を確認する
UpdateFunctionConfiguration20150331v2イベントをクリックして詳細を確認します
イベントレコードには以下の情報が含まれています。
- userIdentity: 操作を実行したIAMプリンシパル(ユーザーまたはロール)
- eventTime: 操作が実行された日時(UTC)
- sourceIPAddress: 操作元のIPアドレス
- requestParameters: リクエストに含まれたパラメータ(変更後の設定値)
{
"eventVersion": "1.11",
"userIdentity": {
"type": "IAMUser",
"arn": "arn:aws:iam::123456789012:user/admin-user",
"sessionContext": {
"attributes": {
"mfaAuthenticated": "true"
}
}
},
"eventTime": "2026-03-22T10:30:00Z",
"eventSource": "lambda.amazonaws.com",
"eventName": "UpdateFunctionConfiguration20150331v2",
"awsRegion": "ap-northeast-1",
"sourceIPAddress": "203.0.113.10",
"requestParameters": {
"functionName": "config-audit-test-function",
"timeout": 120
}
}このように、CloudTrailのイベントレコードから「誰が・いつ・どこから・どのような設定変更を行ったか」を特定できます。


AWS Config と CloudTrail を組み合わせた調査フロー
実際のセキュリティ調査では、AWS ConfigとCloudTrailを以下のように組み合わせて使用します。
- AWS Configで変更を検知: Config ルールの非準拠通知、またはリソースタイムラインで構成変更を発見する
- 変更内容の確認: AWS Configの構成アイテムで、変更前後の設定値を比較する
- 操作者の特定: CloudTrailのイベント履歴で、該当時刻のAPI呼び出しを検索し、操作を実行したIAMプリンシパルとソースIPアドレスを特定する
この組み合わせにより、「何が変わったか」(Config)と「誰が変えたか」(CloudTrail)の両方を把握でき、迅速なインシデント対応が可能になります。



試験では、構成の変化を追いたいのか、操作した人を特定したいのかで、Config と CloudTrail を取り違えないかが問われるでござるな。「何が変わったか」と「誰が変えたか」を組み合わせて調べる流れを押さえておくのでござる。
まとめ
- AWS Config はリソースの構成状態を継続的に記録し、「何が・いつ変わったか」を追跡するサービスである
- AWS CloudTrail はAPI呼び出しを記録し、「誰が・いつ・どこから操作したか」を監査するサービスである
- Lambda関数に対しては、Config でランタイム・メモリ・タイムアウト・IAMロール・VPC設定などの構成変更を追跡できる
lambda-function-settings-checkなどのConfig マネージドルールを使うと、Lambda関数の設定がポリシーに準拠しているかを自動的にチェックできる- CloudTrail では
UpdateFunctionConfigurationやUpdateFunctionCodeなどのAPI呼び出しから操作者やソースIPアドレスを特定できる - セキュリティ調査では、Config で変更内容を確認し、CloudTrail で操作者を特定するという組み合わせが有効である
参照先
- AWS Lambda の設定記録 – AWS Config
- AWS Config マネージドルール – AWS Config
- lambda-function-settings-check – AWS Config
- lambda-function-public-access-prohibited – AWS Config
- AWS Lambda での AWS CloudTrail の使用 – AWS Lambda
- CloudTrail イベントリファレンス – AWS CloudTrail










