サーバーレス実装
LambdaのログをCloudWatchで確認する方法
Lambda実行時のログをCloudWatch Logsで確認し、問い合わせAPIのエラー調査に使う流れを整理します。
LambdaでAPIを作ったら、CloudWatch Logsでログを確認できる状態にします。問い合わせAPIの障害調査では、最初に見る場所の1つです。
結論
Lambdaの実行ログはCloudWatch Logsに出力されます。エラー時は、Lambdaのロググループを開き、requestIdやエラーメッセージから原因を調査します。
CloudWatch Logsで見るもの
問い合わせAPIでは、次のようなログを確認します。
- Lambdaが呼び出されたか
- バリデーションエラーが出ているか
- DynamoDB PutItemで失敗していないか
- CORSやJSONパースで失敗していないか
- タイムアウトしていないか
ロググループ
Lambdaを実行すると、通常 /aws/lambda/関数名 のロググループにログが出ます。このプロジェクトなら、contact-submit-prodのロググループを確認します。
ログストリームは実行単位や時間単位で分かれます。直近の実行を探し、エラーメッセージを確認します。
出してよいログ
出してよいログは、処理成功、バリデーションエラーのフィールド名、DynamoDB保存失敗、requestId、contactIdなどです。
例として、INFO contact submitted contactId=contact-xxxx のようなログは調査に役立ちます。
出してはいけないログ
メールアドレス全文、問い合わせ本文全文、AWS認証情報、APIキー、JWTなどはログに出しません。
ログは運用者が見るものですが、保存期間が長くなると情報漏えいリスクになります。個人情報を出さない設計が必要です。
保存期間
CloudWatch Logsは無期限保存にするとログ量が増えます。個人MVPでは、短めの保存期間を設定し、コストと情報管理のリスクを下げます。
障害調査の流れ
- フロントエンドのエラーメッセージを確認する
- API Gatewayのステータスコードを確認する
- LambdaのCloudWatch Logsを見る
- DynamoDB保存有無を確認する
- CORS、環境変数、IAM権限を確認する
ログを障害対応の記録として整える
デプロイ直後には、正常送信、必須項目不足、不正な JSON の3ケースを実行し、それぞれの request ID を控えます。正常時には contactId と処理時間、入力不備では検証エラーコード、障害時には例外分類が残ることを確認します。これをリリースチェックにすると、ログの出力先やフィールド名を変えたときに、実際に調査できる状態かを確認できます。
障害報告を受けたときは、利用者が見た時刻と画面のHTTPステータスから始め、API Gateway、Lambda、DynamoDB の順に記録をたどります。Lambda のログに START が見つからない場合も、関数未到達とは断定せず、リージョン、関数名、エイリアス、ロググループ、実行ロールのログ書き込み権限を確認します。そのうえで、ルート、認可、CORS、統合設定も順番に見ます。Lambda に例外があれば request ID とデプロイバージョンを確認し、同じ時刻に設定変更がなかったかを見ます。調査の入口を決めておくと、ログ検索が単なる文字列探しになりません。
ログ閲覧権限は、実行ロールの書込み権限とは別に考えます。開発者が障害調査できても、問い合わせ本文やSecretsを含むログまで誰もが読める必要はありません。ログに機微情報を出さないことを基本とし、閲覧者・保存期間・エクスポート先を必要な範囲に絞ります。特に一時的なデバッグ出力は、問題解決後に消すか粒度を戻す運用を決めます。
ログの保存量、検索頻度、保持設定はワークロードとリージョンで変わります。コストを固定値で見積もるのではなく、公開後の実際のログ量を確認し、通常時の情報量と障害時に必要な情報量の釣り合いを見直します。
運用手順には、誰がログを確認し、いつ利用者へ状況を返すかも含めます。ログを読める担当者が不在の場合や、個人情報を含む可能性がある場合の連絡経路を決めておくと、技術的な復旧と情報管理を切り離さずに対応できます。定期的に検索手順を試し、古いフィールド名や削除済みのロググループを参照していないかを確認します。
アラームを追加する場合も、通知後に最初に見るロググループ、検索する request ID、確認するIAM変更を手順化します。通知を受けるだけで終わらず、再現、影響範囲、復旧確認まで同じ記録で追える状態を保ちます。
ロググループとログストリームを理解する
Lambda が標準出力または標準エラーへ書いた内容は CloudWatch Logs に送られます。通常は関数ごとのロググループに、実行環境や実行時間帯ごとのログストリームが作られます。1回の送信だけを調べたいときは、時刻から候補を絞り、開始、アプリケーションログ、終了、実行レポートの順に確認します。
Lambda 関数のログ記録 には Lambda のログ出力と送信の前提が、CloudWatch Logs とは にはログの保存・検索・監視の基本がまとまっています。ログストリームは利用者やAPIルートと一対一ではないため、ストリーム名だけで判断せず、識別子で実行を追います。
ログが増えていない場合は、まず見ているリージョン、関数名、エイリアス、ロググループ、実行ロールの CloudWatch Logs 権限が正しいかを確認します。次に、HTTP メソッドとパスが API Gateway のルートに一致しているか、CORS の preflight で止まっていないか、統合先が意図した関数・エイリアスかを順番に確認します。ログの不在だけで原因を決めつけず、ログの出力経路と API の到達経路を分けて調べることが重要です。
request IDで1回の処理を追跡する
調査用のログは文章だけでなく、検索できるフィールドを持たせます。level、event、requestId、contactId、statusCode、durationMs を JSON として出力すると、同じ失敗を集計し、成功時との差分を見つけやすくなります。Lambda のコンテキストで得られる request ID と、アプリケーションが発行した contactId を合わせると、API Gateway、Lambda、DynamoDB の記録を関連付けられます。
問い合わせ本文、メールアドレス、Authorization ヘッダー、Cookie を丸ごとログに出すのは避けます。再現に必要な場合も、文字数、必須項目の有無、ハッシュ化した識別子などに置き換えます。個人情報をログに複製すると、閲覧権限や保持期間が増えたときの取り扱い範囲も広がります。
利用者へのエラー応答に request ID を含める場合は、内部構造や認証情報を含まない値だけにします。画面で表示する一般的なエラーと、運用者がログで見る詳細を分けると、情報を必要以上に公開せずに問い合わせ対応できます。
API Gatewayの4xxと5xxを分けて調べる
API Gateway の 4xx は、JSON の形式不正、必須項目不足、認可、ルート、CORS に近い失敗を確認する入口です。Lambda が入力検証した結果なら、検証ルール名と request ID をログに残し、本文全体は残しません。急増している場合は、フロントエンドのリリースで送信形式が変わっていないかも照合します。
5xx は、Lambda の例外、タイムアウト、DynamoDB の権限不足、統合設定の不整合を疑います。AccessDeniedException なら IAM ポリシー、タイムアウトなら外部呼び出しや処理量、502 なら API Gateway が期待する statusCode、headers、JSON文字列の body を返しているかを確認します。ステータスだけで断定せず、API Gateway のアクセスログと Lambda の request ID を照合します。
スタックトレースを API のレスポンスへ返すのは失敗例です。ブラウザには必要最小限のエラーコードを返し、詳細は request ID を起点にログで確認します。問い合わせAPIのリクエスト全体はAPI Gateway + Lambda + DynamoDBで問い合わせAPIを作る流れで確認できます。
IAMでログ出力の権限を確認する
Lambda の実行ロールには、CloudWatch Logs でログストリームを作成し、イベントを書き込む権限が必要です。ログが出ないときはアプリケーションコードの前に、実行ロールと対象ロググループへの許可を確認します。DynamoDB の PutItem 権限と CloudWatch Logs の書込み権限は別の目的なので、どちらが不足しているかをエラーから切り分けます。
権限エラーを解消するために管理者権限を付けるのは避けます。必要な Action と対象 Resource を限定し、デプロイ用ロールと Lambda 実行ロールも分離します。デプロイ後の確認項目に「成功ログを1件確認する」「入力エラーが期待する分類で残る」を入れると、権限変更の影響を早く見つけられます。
保存期間とコストを運用で決める
CloudWatch Logs は無制限に保管する前提にせず、障害調査に必要な期間とデータの性質に合わせて保持設定を決めます。トラフィック、ログ量、リージョン、設定で費用や制限に関わる条件は変わるため、「この構成なら必ず無料」「何日なら必ず安全」と固定値で断定しません。
成功時の詳細ログやリクエスト本文を大量に出すと、調査価値より保存量が大きくなります。通常時は要約ログにし、障害調査時だけ追加の診断ログを有効にする方法もあります。ロググループの保持設定とアクセス権をインフラ定義に含めると、新しい環境での設定漏れを減らせます。
失敗例から確認手順を作る
「関数は成功しているのにブラウザで CORS エラーになる」場合は、Lambda の成功ログだけで完了とせず、Network タブで OPTIONS と POST の応答を確認します。許可 Origin、メソッド、ヘッダーが環境に合っているかを照合します。
「ログにエラーがないのに 502 が返る」場合は、Lambda の戻り値が API Gateway の期待する形式かを確認します。「ログが見つからない」場合は、リージョン、関数名、エイリアス、時刻のタイムゾーンを確認します。別環境のロググループを見ている設定ミスは、コード不具合に見える典型例です。
正常送信、必須項目不足、不正JSON、DynamoDB権限不足のケースで、期待するHTTPステータス、ログ項目、アラートの有無を記録します。リリース後に一度再現し、request ID から保存結果まで追えることを確認します。基本的な監視の位置づけはCloudWatchの基本をCloud Practitioner向けに解説も参照してください。
関連用語
次に読む記事
次に学ぶ内容
ブログ記事だけでなく、AWS用語集・サービス比較・模擬問題・構成図を組み合わせると、資格知識と実装イメージをつなげて理解できます。