こちらの記事はAWS Lambda 実践入門 Advent Calendar 2025 1日目の記事になります。
はじめに
AWS Lambda は、サーバーを意識せずコードを実行できる “関数実行プラットフォーム（FaaS: Function as a Service）” です。
EC2 のように OS を起動してログインし、常駐プロセスを動かすのではなく、 「イベントが来たら関数を起動して処理し、終わったら戻る」 というモデルで動きます。
しかし実務では、次のような誤解が非常に多いです。
- Lambda は「ただコードを置けば動く」わけではない（トリガーと権限が必須）
- イベント駆動・権限・実行環境の理解が前提（特に IAM が壁になりやすい）
- ログを正しく読めないと障害調査ができない（調査の入口は CloudWatch Logs）
この記事では、Lambda をこれから使う人向けに 10分で全体像を掴める入門編 をまとめます。
（次回以降で IAM・Cold Start・運用設計へ段階的に深掘りします）
まず押さえる：Lambda を動かす「5つの要素」
Lambda は「関数」だけで成立しません。最低限、次の 5 点をセットで考えると理解が早いです。
- イベントソース（トリガー）：S3 / SQS / EventBridge / API Gateway など
- 実行ロール（IAM Role）：どの AWS リソースにアクセスできるか（権限）
- 実行コード（デプロイパッケージ）：ソース、依存ライブラリ、設定
- 実行環境（メモリ/CPU/Timeout/VPC など）：性能と制約を決める
- 可観測性（ログ/メトリクス/トレース）：運用と障害対応のための情報源
「動かない」「遅い」「原因不明」の多くは、(2)(4)(5) の理解不足から起きます。
Lambda の実行モデルとは？
Lambda は イベントをトリガーにコードが起動します。代表例：
- S3 ファイルアップロード
- SQS のメッセージ
- EventBridge のスケジュール
- API Gateway の HTTP リクエスト
ここで重要なのは、Lambda が イベント駆動に最適化されたスケールアウト環境だという点です。
アクセスが増えれば並列に起動し、アクセスが減れば落ち着きます（＝常駐サーバーの台数を人が調整しない）。
同期・非同期で「失敗時の挙動」が変わる
初心者が早い段階で知っておくと事故が減るのがこの観点です。
-
同期（例：API Gateway）
呼び出し元が結果を待つ。失敗はその場で返る。タイムアウト設計が重要。 -
非同期（例：EventBridge / S3 通知 など）
呼び出し元が待たない。失敗時に 再試行が起きることがある。
非同期は便利な反面、**同じイベントが複数回処理される（重複実行）**可能性が現実にあります。
したがって実務では、次の考え方が頻出します。
- 冪等性（idempotency）：同じ入力が複数回来ても結果が壊れない設計
- 重複排除：DynamoDB などで処理済み判定を持つ、S3 のキーでガードする、など
ここは Day 2 以降で掘りますが、1日目で「そういう前提がある」と知っているだけで設計の質が変わります。
Lambda の料金モデル
料金は概ね次の要素で決まります。
料金 ≒ 実行時間 × メモリ設定（≒CPU） × リクエスト数
ポイント：
- メモリを上げると CPU も増える（遅い処理が速くなることがある）
- 実行時間が短くなれば、メモリを上げても総額が下がるケースがある
- 50〜100ms の差が、リクエスト数が多いワークロードでは効いてくる
つまり最適化の第一歩は「闇雲にメモリを下げる」ではなく、実行時間とメモリのバランスを見ることです。
（後述の REPORT ログが入口になります）
実行環境の特徴（初学者がつまずくポイント）
Lambda の実行環境は“サーバーレス”ですが、性質を知らないとハマります。
-
/tmp：一時ストレージ（最大 10GB）
画像変換、PDF 分割、ZIP 展開など「一時ファイル」を置けます -
メモリ＝CPU の関係
速さのボトルネックが CPU の場合、メモリ設定が効くことが多いです -
Timeout（最大実行時間）
「いつまでも待つ」はできません。外部 API 連携やリトライ設計に影響します -
同時実行数（Concurrency）
イベントが増えると並列に動きますが、アカウントや関数単位で上限があります -
ネットワーク（VPC 接続）
RDS や社内ネットワークへ接続する場合は VPC が絡みます（設定と設計が変わる）
加えて、実務的に重要な概念が 実行環境の再利用です。
- 1 回の実行ごとに完全に新しいサーバーが起動するとは限らない
- 以前の実行の環境が“温存”され、次の実行で使い回されることがある
この性質は「高速化」にも「バグ」にも繋がります。
例えば DB 接続を毎回張り直すのではなく、グローバルで保持して再利用すると高速化することがあります。一方で、グローバル変数に状態を持ちすぎると意図しない挙動を生むこともあります。
CloudWatch Logs を読む基礎（ここが運用の入口）
Lambda を理解する第一歩は ログを読むことです。最低限、次の 3 行は押さえます。
START RequestId: xxx
END RequestId: xxx
REPORT RequestId: xxx Duration: 123.45 ms Memory Size: 512 MB Max Memory Used: 123 MB
この REPORT だけで、次が分かります。
- 実行時間（Duration）：遅い/速いの一次判断
- メモリ使用量（Max Memory Used）：不足・過剰の判断材料
- （エラー時は）どの RequestId で落ちたか：追跡の起点
実務では「どのログを見れば良いか分からない」が最初の壁になりがちです。そのため、まずは RequestId を軸にログを追う癖をつけるのがおすすめです。
もう一歩：ログは“検索できる形”にしておく
運用が始まると、ログは「眺める」より「検索する」比率が上がります。
可能であれば以下を意識すると、後々の調査が楽になります。
- 重要な項目（ユーザーID、S3キー、注文ID など）を **構造化（JSON）**で出す
- エラーは
ERRORレベルで統一して出す - 例外は握りつぶさず、スタックトレースを残す
よくある勘違い（最短で回避したいポイント）
最後に、初心者が最短で回避したい「あるある」をまとめます。
- 「Lambda が動かない」→ トリガー設定か IAM 権限が不足していることが多い
- 「たまに失敗する」→ タイムアウト、外部APIの不安定、再試行による重複を疑う
- 「遅い」→ メモリを下げるのではなく、まず Duration / Max Memory Used を見る
- 「原因不明」→ まず CloudWatch Logs の RequestId を起点に追う
まとめ
- Lambda はイベント駆動に特化した実行環境（サーバー常駐モデルとは違う）
- Lambda は「関数」単体ではなく トリガー・権限・実行環境・ログまで含めて設計する
- 料金は 実行時間 × メモリ（≒CPU） × リクエスト数。短縮で総額が下がることもある
- 運用の入口は CloudWatch Logs。
REPORTを読む癖がつくと強い - 次回は Lambda を支える IAM 権限と、実行環境（Cold Start など）の理解を深掘りする
実務FAQ：動かない時のチェックリスト（5項目）
「Lambda が動かない」は、原因がだいたい決まっています。まずは次の 5 点を上から潰すのが最短ルートです。
1) トリガー（イベントソース）が本当に発火しているか？
-
S3 / EventBridge / API Gateway など、イベントが来ていないと Lambda は動きません
-
確認ポイント：
- EventBridge ならルールが有効か、スケジュール式が正しいか
- S3 なら対象バケット・プレフィックス・サフィックス条件が合っているか
- API Gateway なら対象ステージにデプロイされているか、統合先が正しいか
2) Lambda の実行ロール（IAM）が足りているか？
-
典型例：S3 から読めない／DynamoDB に書けない／KMS で復号できない
-
確認ポイント：
- Lambda の Execution Role に必要な権限があるか
- KMS を使っている場合、キー側のポリシーも許可しているか
- S3 バケットポリシーやVPCエンドポイントポリシーでブロックされていないか
3) CloudWatch Logs を見て、まずエラー行を特定したか？
-
「原因不明」の多くはログ未確認です
-
確認ポイント：
- 対象の Log group にログが出ているか（そもそも出ない＝権限やトリガー側の問題の可能性）
-
Task timed out/AccessDenied/ResourceNotFoundなどの代表的な文言がないか -
REPORTのDurationとMax Memory Usedが極端でないか
4) タイムアウト・メモリ・依存関係（Layer/ライブラリ）が適切か？
-
実務で多いのは「処理は始まっているが、完走できない」ケースです
-
確認ポイント：
-
Timeoutが短すぎないか（外部API呼び出しやファイル処理で詰まりやすい） - メモリ不足の兆候（
Max Memory UsedがMemory Sizeに張り付く） - Layer の ARN やバージョン、requirements の差分が意図どおりか（ローカルでは動くが本番で落ちる原因になりがち）
-
5) VPC 設定やネットワーク経路で詰まっていないか？
-
「外部APIに繋がらない」「RDS に繋がらない」はネットワーク起因が多いです
-
確認ポイント：
- VPC に入れている場合、NAT Gateway / ルートテーブル / セキュリティグループが正しいか
- 社内向けの宛先なら、名前解決（DNS）や到達性が成立しているか
- “繋がらない”はタイムアウトとして出ることが多い（ログで時間が伸びる）