サーバーレス実装
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権限を確認する
関連用語
次に読む記事
次に学ぶ内容
ブログ記事だけでなく、AWS用語集・サービス比較・模擬問題・構成図を組み合わせると、資格知識と実装イメージをつなげて理解できます。