Lambda のロググループが作られるタイミングについて権限と LoggingConfig の4パターンで検証してみた

はじめに

こんにちは、クラスメソッドの長澤です。

以前 Lambda 関数をコンソールで作成した際、設定画面のロググループへのリンクをクリックしても「ロググループが存在しません」と表示され、戸惑いました。AWS ドキュメントには「実行ロールに logs:CreateLogGroup 権限があれば初回呼び出し時に自動作成される」とあります。では、実際にいつ・どの条件で作られるのか、マネジメントコンソールで4パターンに分けて検証してみました。

先に結論

ロググループが作られるかどうかは、デフォルト/カスタムの別ではなく logs:CreateLogGroup 権限の有無だけで決まり、作られるタイミングは常に初回実行時でした。

前提知識

• ロググループ(デフォルト名: /aws/lambda/関数名)は関数作成時ではなく、初回呼び出し時に実行ロールの logs:CreateLogGroup 権限で自動作成される、というのが公式仕様です
• 2023年のアップデートで LoggingConfig によるロググループ名のカスタマイズ が可能になりました
• 公式ドキュメント: CloudWatch ロググループの設定

検証環境

• リージョン: ap-northeast-1
• ランタイム: Python 3.14(コンソール作成時のデフォルトコードに print を1行追加)
• 操作・確認はすべてマネジメントコンソール

準備1: IAM ロールを2つ作成

まず検証用の実行ロールを2つ作ります。

権限ありロール lambda-loggroup-role-full(パターンA・C用)

1. IAM コンソール > ロール一覧から「ロールを作成」を選択

2. 信頼されたエンティティタイプは「AWS のサービス」、ユースケースで Lambda を選択して次へ

3. 許可の追加では「Use existing policy」のまま、マネージドポリシー AWSLambdaBasicExecutionRole を検索して選択。プレビューを見ると logs:CreateLogGroup / logs:CreateLogStream / logs:PutLogEvents が Resource: * で含まれていることがわかります

4. ロール名 lambda-loggroup-role-full で作成

権限なしロール lambda-loggroup-role-nocreate(パターンB・D用)

同じ手順でステップ2まで進み、許可の追加で「インラインポリシーを作成」を選択して、以下の JSON を貼り付けます(AWSLambdaBasicExecutionRole から logs:CreateLogGroup だけを除いた内容)。

{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Effect": "Allow",
      "Action": [
        "logs:CreateLogStream",
        "logs:PutLogEvents"
      ],
      "Resource": "arn:aws:logs:ap-northeast-1:*:log-group:*"
    }
  ]
}

ロール名 lambda-loggroup-role-nocreate で作成します。

準備2: Lambda 関数を4つ作成

以下の4関数を作ります。

1. Lambda コンソール > 関数一覧から「関数を作成」を選択

2. 「一から作成」を選び、関数名(例: loggroup-test-a)とランタイム Python 3.14 を指定します。アクセス許可の説明にあるとおり、デフォルトでは CloudWatch Logs への書き込み権限を持つ実行ロールが自動生成されます。ただし、この自動生成ロールは CreateLogStream/PutLogEvents が /aws/lambda/関数名 にスコープされていて、カスタムロググループ(パターンC)への書き込み権限が足りません。条件を「CreateLogGroup の有無」だけに揃えるため、今回は4関数とも自作のロールを使用します

3. 「カスタム設定」>「その他の設定」を展開し、「カスタム実行ロール」をオンにします。右に表示されるパネルで実行ロール(A・C は lambda-loggroup-role-full、B・D は lambda-loggroup-role-nocreate)を選択して保存し、「関数を作成」をクリック

ソースコード

コードは4関数とも共通で、コンソール作成時のデフォルトコードに print を1行追加しただけのものを使います。実は print がなくても Lambda は START / END / REPORT 行をログ出力するのでロググループ作成の検証は成立しますが、アプリケーションログが出ていることをわかりやすくするために追加しています。

import json

def lambda_handler(event, context):
    print("Hello from loggroup-test")
    return {
        'statusCode': 200,
        'body': json.dumps('Hello from Lambda!')
    }

コードエディタに貼り付けたら「Deploy」を忘れずにクリックします。

C・D のカスタムロググループ設定

C・D は作成後に「設定」タブ >「モニタリングおよび運用ツール」のロギング設定を開き、「編集」をクリックします。

ログ記録設定の編集画面で、「CloudWatch ロググループ」を「カスタム」に切り替え、カスタムロググループ名に /custom/loggroup-test-c(D は -d)を入力します。あわせて、C・D とも画面下部の「アクセス許可」を展開し、「必要なアクセス許可を追加」のチェックを外してから保存します(理由は次の補足のとおり)。以下は C の設定例です。

補足: コンソールでログ設定を変更すると実行ロールに権限が自動追加される

Lambda コンソールでログの送信先を CloudWatch Logs に設定する際、実行ロールにログアップロード権限がないと判断されると、Lambda が権限をロールに自動でアタッチします(公式ドキュメント)。上のキャプチャの「アクセス許可」欄にも「関数の実行ロールに Amazon CloudWatch Logs へのログアップロード権限がない場合、Lambda はこの権限をロールに追加します」と書かれています。

ここで注意したいのが、追加される権限の範囲です。公式ドキュメントに明記されているのは「logs:PutLogEvents 権限を追加する」ことだけですが、検証当初、誤ってチェックを付けたまま D のログ設定を変更してしまったところ、nocreate ロールに AWSLambdaBasicExecutionRole-xxxx というカスタマー管理ポリシーが自動アタッチされ、その中には logs:CreateLogGroup(アカウント内 * が対象)も含まれていました。この結果、同じロールを共有する B にまで権限が波及し、「権限なしのはずの B でロググループが作られる」という事故が起きました。

権限を厳密に管理しているロールをコンソール操作で汚してしまう可能性がある点は要注意です。なお、公式ドキュメントに明記されているとおり、AWS CLI(update-function-configuration)からロググループを変更した場合はこの自動追加は行われません。

検証1: 関数作成直後

まだ一度も実行していない状態で確認します。

CloudWatch コンソール > ロググループを開くと、ロググループは1つもありません。4関数を作成しただけでは、デフォルト/カスタムいずれのロググループも作られないことがわかります。

次に Lambda の「設定」タブ >「モニタリングおよび運用ツール」を見ると、ロギング設定には CloudWatch ロググループへのリンクが表示されています。

このリンクをクリックすると「ロググループが存在しません」というエラーが表示されました。関数を作っただけの段階では、このリンクはデッドリンクです。

検証2: 初回実行後

各関数の「テスト」タブでテストイベントを作成し(設定はデフォルトのまま)、「テスト」ボタンで1回ずつ実行します。

4関数とも実行自体は成功し、statusCode: 200 が返ります。注目すべきは、logs:CreateLogGroup 権限のない B・D でも関数の実行はエラーにならない点です。

それでは、実行後のロググループを確認していきます。

パターンA: デフォルト + 権限あり → 自動作成された

/aws/lambda/loggroup-test-a が作成されていました。ロググループの詳細を見ると、作成時刻は関数の初回実行のタイミング、保持は「失効しない」(=無期限)、ログクラスは「スタンダード」です。

ログストリームを開くと、INIT_START / START に続いてコードに仕込んだ Hello from loggroup-test が出力されています。

パターンB: デフォルト + 権限なし → 作られない

実行後も /aws/lambda/loggroup-test-b は存在しません。つまりログが保持されていない状態でした。エラーにならない分、権限不足に気づきにくいのが怖いところです。

パターンC: カスタム指定 + 権限あり → 自動作成された

公式ドキュメントの「指定した名前のロググループが存在しない場合、Lambda が自動作成する」のとおり、/custom/loggroup-test-c が自動作成されていました。カスタム指定でも挙動はデフォルトと同じで、保持は「失効しない」です。

ログもきちんと出力されています。なお、ログストリーム名がデフォルトの 2026/07/14/[$LATEST]xxx ではなく 2026/07/14/loggroup-test-c[$LATEST]xxx と関数名入りになっている点も面白いところです。カスタムロググループは複数の関数で共有できるため、どの関数のストリームか判別できるようになっています。

パターンD: カスタム指定 + 権限なし → 作られない

B と同様、実行後も /custom/loggroup-test-d は作られませんでした。

検証3: ロググループを先に作っておいた場合

今度は逆に、ロググループを先に作ってから関数を作ります。

まず CloudWatch コンソール > ロググループ >「ロググループを作成」で、ロググループ名 /aws/lambda/loggroup-test-e、保持期間を 1日 に設定して作成します。

続いて Lambda コンソールで関数 loggroup-test-e を作成(実行ロールは自動生成のままで OK)し、テスト実行します。

実行後にロググループを確認すると、保持期間は 1日 のまま維持され、ログストリームも作られていました。自動作成に任せると保持期間が「失効しない」になるのに対し、事前作成なら最初から保持期間をコントロールできます。

また、関数作成直後でも同名ロググループが既に存在するため、設定画面のロググループリンクは最初から正常に表示されます。検証1で見たデッドリンク問題も、事前作成なら発生しません。

まとめ

検証からわかったことをまとめます。

• ロググループが作られるタイミングは常に初回実行時。関数を作っただけでは作られず、設定画面のリンクもデッドリンクになる
• 作られるかどうかは実行ロールの logs:CreateLogGroup 権限の有無だけで決まり、デフォルト/カスタムの別は関係ない
• 権限がない場合でも関数の実行はエラーにならず、ログは保持されない
• 自動作成されたロググループの保持期間は「失効しない」(無期限)になる
• コンソールでログ設定を変更すると、実行ロールに logs:CreateLogGroup を含むポリシーが自動アタッチされることがある(ロールを共有していると他関数にも波及)

実務上は、保持期間を決めてロググループを先に作っておく(IaC ならロググループもコード管理する)のが安全です。自動作成に任せると保持期間が無期限になり、コストにも効いてきます。

• 保持期間の一括変更: https://dev.classmethod.jp/articles/loggroup-retention-policy-lambda/
• CDK でロググループを自動生成する仕組み: https://dev.classmethod.jp/articles/cdk-auto-generate-log-group/
• CloudFormation で先に作る場合は依存関係に注意: https://zenn.dev/dannykitadani/articles/c9f47fb89cef6b

どなたかのお役に立てば幸いです。