AWS LambdaをCloudWatchで監視する方法｜標準メトリクス・ログ・アラーム・Lambda Insights

AWS Lambdaは、追加設定なしでも実行のたびに主要な指標とログをAmazon CloudWatchへ送っています。まず押さえるべきは、無料で自動収集される標準メトリクス（Errors・Throttles・Durationなど）と、関数ごとに自動生成されるロググループの読み方です。そのうえで、メモリやCPUまで見たいときはCloudWatch Lambda Insights、異常を自動で知らせたいときはCloudWatchアラームを足します。本記事はNew RelicのようなSaaSを入れる前に、CloudWatchだけでどこまで監視できるかを、指標名・ログの実体・設定コマンドまで具体的に示す構成です。

まとめ：CloudWatchでのLambda監視の要点

• 標準メトリクスは自動・無料：Lambdaは名前空間 AWS/Lambda に Invocations・Errors・Throttles・Duration・ConcurrentExecutions などを1分間隔で送る。設定は不要。
• 最優先で見るのは3つ：エラー率（Errors÷Invocations）、Duration の p99、Throttles。まずこの3指標のアラームを作る。
• ログは自動でロググループに出る：/aws/lambda/<関数名> に出力され、末尾の REPORT 行に実行時間・課金時間・最大メモリ使用量が載る。深掘りは Logs Insights。
• メモリ・CPU・コールドスタートまで見たいなら Lambda Insights：拡張機能レイヤーを足すとシステムレベル指標が増える。標準では取れない。
• 外部SaaSは「CloudWatchで足りない時だけ」：マルチクラウド横断や高度な分散トレーシングが要る場合にNew Relic/Datadog等を検討する。

CloudWatchがLambdaを監視する仕組みと標準メトリクス

Lambdaは関数が呼び出されるたびに、実行結果の集計値をCloudWatchメトリクスへ自動送信します。エージェントの導入もコード変更も不要で、送信先の名前空間は AWS/Lambda、粒度は1分です。これらの標準メトリクスの閲覧自体に追加料金はかかりません（アラームやカスタムメトリクスは別です）。まずは次の指標の意味を正確に押さえてください。

まず監視すべき3指標と判断基準

すべてを等しく見張る必要はありません。実運用でまず作るべきアラームは、エラー率・Durationのp99・Throttlesの3つに絞ると効きます。エラー率はErrorsの絶対数ではなく Invocations との比で見ます（トラフィックが増えればErrorsも増えるためです）。Durationは平均ではなくp99を見ます。平均が正常でも、コールドスタートや特定入力で一部が張り付き、タイムアウト（既定の関数タイムアウトに達すると打ち切り）に近づくことがあるからです。Throttlesが恒常的に出るなら、それは負荷ではなく同時実行の設計ミスのサインで、予約同時実行やプロビジョニング済み同時実行の設定を見直します。IteratorAgeやAsyncEventAgeは、ストリーム型・非同期型のトリガーを使う関数でのみ追加します。

CloudWatch LogsでLambdaのログを収集・分析する

Lambdaは標準出力・標準エラーへの出力を、関数ごとのロググループ /aws/lambda/<関数名> に自動で書き込む（実行ロールに logs:CreateLogGroup 等の権限が必要です）。各実行の末尾には、監視で最も使う REPORT 行が出ます。

REPORT RequestId: 8f... Duration: 812.44 ms  Billed Duration: 813 ms
Memory Size: 256 MB  Max Memory Used: 121 MB  Init Duration: 402.31 ms

Max Memory Used が Memory Size に近ければメモリ割り当て不足、逆に大きく下回るなら過剰割り当てでコストを払い過ぎています。Init Duration はコールドスタート時だけ現れる初期化時間で、この値が大きい関数はコールドスタート対策の候補になる（Lambda SnapStartの概要とその基本的な特徴とはで初期化時間の短縮手法を扱っています）。

Logs Insightsで実行ログを集計する

1本ずつログを追うのではなく、REPORT行を集計すると関数全体の傾向が一目で分かります。CloudWatch Logs Insightsで次のようなクエリを実行すると、時間帯ごとの課金時間・最大メモリ・実行数を一度にまとめられる点が利点です。

filter @type = "REPORT"
| stats avg(@billedDuration), max(@maxMemoryUsed), count(*) by bin(30m)

クエリ構文や料金、正規表現による絞り込みはCloudWatch Logs Insightsの概要と機能に詳しく書かれています。ログ形式のJSON化やログレベル設定、保持期間によるコスト削減まで含めたログ運用そのものはAWS Lambdaのログ運用ガイド｜CloudWatch Logsの見方・JSON構造化・S3出力とコスト削減で扱っています。エラー調査では filter @message like /ERROR/ のようにメッセージで絞ると原因箇所を素早く特定できます。

Lambda Insightsで拡張メトリクス（メモリ・CPU・コールドスタート）を取る

標準メトリクスとREPORT行だけでは、CPU時間・ネットワーク・ディスクといったシステムレベルの指標までは取れません。ここを埋めるのがCloudWatch Lambda Insightsです。実体はCloudWatchの拡張機能（Lambdaレイヤー）で、関数に追加すると呼び出しごとにシステム指標をまとめた1件のログイベントを出し、CloudWatchが埋め込みメトリクス形式（EMF）でメトリクスへ変換します。

有効化はコンソールから対象関数の「拡張されたモニタリング」をオンにするだけで、対応ランタイムならLambdaがInsightsレイヤーを付与し、実行ロールに CloudWatchLambdaInsightsExecutionRolePolicy をアタッチします。取得できるのはCPU時間・ピークメモリ・ディスク読み書き・ネットワーク送受信、さらにコールドスタートやワーカー終了といった診断情報です。ただしInsightsエージェントはAmazon Linux 2／Amazon Linux 2023ベースのランタイムに限られます。常時全関数に入れる必要はない：メモリ最適化やコールドスタート分析など、標準メトリクスで原因が切り分けられない関数に絞って有効化するのが、追加ログコストを抑える現実的な運用になります。

CloudWatchアラームでLambdaの異常を検知・通知する

メトリクスを見られるだけでは監視になりません。閾値を超えたら自動で気づく仕組みが要ります。CloudWatchアラームを標準メトリクスに対して作り、通知先にはSNSトピックを指定してください。例えばErrorsに対するアラームはCLIで次のように作れます。

aws cloudwatch put-metric-alarm --alarm-name lambda-myfunc-errors \
  --namespace AWS/Lambda --metric-name Errors \
  --dimensions Name=FunctionName,Value=myfunc \
  --statistic Sum --period 300 --evaluation-periods 1 \
  --threshold 1 --comparison-operator GreaterThanOrEqualToThreshold \
  --alarm-actions arn:aws:sns:ap-northeast-1:123456789012:alerts

エラー率で監視したい場合は、ErrorsとInvocationsを使ったメトリクス数式（Errors÷Invocations×100）でアラームを組む形になります。Throttlesは1件でも継続して出れば設計見直しの合図なので閾値を低くし、Durationは関数タイムアウトの手前（例：タイムアウトの80%）にp99でアラームを置くと、打ち切りが起きる前に気づける設定です。

もう一つの「cloudwatch lambda」：アラームからLambdaを起動する

「cloudwatch lambda」で検索する人には、監視とは逆向きの意図――CloudWatchアラームをトリガーにLambdaを実行して自動対応させたい――も混ざります。CloudWatchアラームのアクションは元来SNS通知が基本だが、SNSにLambdaをサブスクライブする、またはEventBridgeでアラーム状態変化をルール化してLambdaをターゲットにすることで、閾値超過時に復旧処理を走らせられる構成です。使い分けの基準は明確だ：人に知らせて判断を仰ぐならSNS通知、あらかじめ決まった復旧（インスタンス再起動・スケール調整・キュー退避など）を自動実行するならLambda起動が適しています。監視対象のLambdaと、復旧を担うLambdaを混同しないよう、役割を分けて設計してください。

CloudWatchで足りる範囲と、外部SaaSを選ぶ基準

ここまでの標準メトリクス・Logs Insights・Lambda Insights・アラームを組み合わせれば、単一AWSアカウント内でのLambda監視はCloudWatchだけで完結します。New RelicやDatadogなどの外部SaaSが効くのは、CloudWatchの守備範囲を超える次の場合に限られる：複数クラウドやオンプレを横断した一元監視、サービス間をまたぐ本格的な分散トレーシング、長期のAPM的な相関分析です。逆に言えば、Lambda単体の稼働監視のために最初から有料SaaSを入れるのは過剰で、ログ転送量ぶんのコストが増えます。

AWSの中で分散トレーシングまで踏み込むなら、まずはAWS X-Rayとは｜CloudWatchとの違いとOpenTelemetry移行後の使い方【2026年版】でCloudWatchメトリクスとの役割分担を押さえてください。マイクロサービスのSLO監視まで広げる場合はApplication Signalsとは何か？概要と基本機能をやさしく解説が入口になります。

よくある質問

Lambdaの標準メトリクスの閲覧に料金はかかりますか？

Invocations・Errors・Duration等の標準メトリクスの閲覧に追加料金はかかりません。課金対象になるのはアラーム、カスタムメトリクス、CloudWatch Logsの取り込み・保存、Lambda Insights（追加のログ出力）などです。

Lambda Insightsと標準メトリクスの違いは何ですか？

標準メトリクスはInvocationsやDurationなど呼び出し結果の集計で、追加設定なしに取得できます。Lambda Insightsは拡張機能レイヤーを足して、CPU時間・ピークメモリ・ネットワークなどシステムレベルの指標とコールドスタート情報まで取得する拡張監視で、対応ランタイムと実行ロールへのポリシー付与が必要です。

Lambdaのログはどこに出力され、いつまで残りますか？

関数ごとのロググループ /aws/lambda/<関数名> に出力されます。保持期間は既定で無期限のため、ロググループごとに保持日数を設定して不要なログを自動失効させ、保存コストを抑えるのが基本です。

エラーのアラームはどの指標に設定すべきですか？

Errorsの絶対数だけでなく、Errors÷Invocationsのエラー率で監視すると、トラフィック変動に強くなります。あわせてThrottles（1件でも継続すれば設計見直し）とDurationのp99（タイムアウト手前）にアラームを置くのが定番です。

「cloudwatch lambda」でLambdaを起動するとはどういう意味ですか？

CloudWatchアラームの状態変化をきっかけにLambdaを実行し、自動復旧などの処理を走らせる使い方です。SNS経由やEventBridgeのルールでLambdaをターゲットに指定します。監視対象のLambdaとは別の、対応処理としてのLambdaです。

関連記事

• AWS Lambdaのログ運用ガイド｜CloudWatch Logsの見方・JSON構造化・S3出力とコスト削減
• CloudWatch Logs Insightsの概要と機能
• AWS X-Rayとは｜CloudWatchとの違いとOpenTelemetry移行後の使い方【2026年版】
• Application Signalsとは何か？概要と基本機能をやさしく解説
• Lambda SnapStartの概要とその基本的な特徴とは