AWS Lambda

解決する課題

• サーバーを常時立てておくのはもったいない/面倒 → イベント時だけ動かす
• 急なスパイクに自動でスケールしてほしい
• 「画像がアップされたら縮小」「キューにメッセージが来たら処理」を接着剤的に書きたい

主要概念と用語

• 関数: 実行単位のコード（＋設定）
• トリガー / イベントソース: S3・API Gateway・SQS・EventBridge など
• ハンドラ: 入口の関数（event を受け取る）
• 実行ロール: 関数に与えるIAM権限
• 同時実行数（Concurrency）: 同時に走るインスタンス数
• コールドスタート: 新しい実行環境の初期化にかかる初回遅延

仕様・制限・クォータ

設計の前に効いてくる境界値だけを挙げます。数値は引き上げ申請で変わるもの（ソフトリミット）と、 変えられないもの（ハードリミット）が混ざっているので、分けて覚えると設計判断が速くなります。

項目	値	引き上げ
最大実行時間	15分	不可
メモリ	128MB〜10GB（1MB刻み）	—
/tmp	512MB（最大10GBまで設定可）	—
同時実行数	リージョンあたり既定1,000	可
zip 直接アップロード	50MB（圧縮時）	不可
zip（S3経由・解凍後）	250MB	不可
コンテナイメージ	10GB	不可
環境変数の合計	4KB	不可
同期呼び出しのペイロード	6MB（リクエスト・レスポンス各）	不可
非同期呼び出しのペイロード	256KB	不可

15分とペイロード上限は動かせません。 ここに当たる設計は Lambda では成立しないので、 長時間処理は Step Functions で分割するか ECS / AWS Batch へ、大きなデータは本体を S3 に置いて キーだけを渡す形に変えます。

コールドスタートの正体

「コールドスタート」と一語で呼ばれますが、中では2つの段階が動いています。切り分けないと対策を間違えます。

1. 実行環境の準備 — マイクロVM を起こし、ランタイムを読み込む。ここは AWS 側の時間で、こちらから縮められません。
2. INIT フェーズ — ハンドラの外に書いたコードが動きます。import、DB接続の確立、設定の読み込み。 ここは自分のコード次第で、数十msから数秒まで振れます。

したがって効くのは 2 を削ることです。使わないライブラリを import しない、初期化の重い処理を ハンドラ内へ移して遅延実行にする、といった手当てが直接効きます。

言語による差も大きく、Python / Node.js は軽く、Java / .NET は重い傾向です。 Java には INIT 済みのスナップショットから復元する SnapStart があります。

INIT を事前に済ませておきたい場合は Provisioned Concurrency で、指定した数の実行環境を 温めた状態で確保します。ただし確保している間は課金され続けるため、 「アイドル時は無料」という Lambda の利点とは引き換えになります。

同時実行とスロットリング

Lambda のスケールは「1リクエスト＝1実行環境」です。同時に来た数だけ環境が増えます。

• アカウント同時実行数 — リージョンあたり既定 1,000。全関数の合計に対する上限です。
• 予約済み同時実行（Reserved Concurrency） — 関数ごとに枠を確保します。上限としても働くのがポイントで、 下流の RDS を守るために「この関数は最大50まで」と絞る使い方が実務では多いです。
• バースト — 0からいきなり1,000へは伸びず、一定の増加率で追いつきます。急峻なスパイクでは この立ち上がりの途中でスロットリングが出ます。

上限に当たると Throttles メトリクスが立ち、同期呼び出しでは 429 TooManyRequestsException が返ります。 非同期呼び出しとイベントソースマッピングでは内部で再試行されるため、呼び出し側からは 「遅い」としか見えません。Throttles を監視していないと気づけないのはこのためです。

呼び出し方式でリトライの挙動が変わる

同じ関数でも、誰が呼ぶかでエラー時の扱いが違います。ここを取り違えると、 「失敗したはずのデータが二重に処理される」「消えたのに気づかない」が起きます。

呼び出し方	例	失敗したとき
同期	API Gateway、ALB、直接 invoke	リトライしない。呼び出し側がエラーを受け取り、再送の判断も呼び出し側
非同期	S3イベント、SNS	Lambda が2回まで再試行。最大イベント保持時間を過ぎたら破棄。失敗先に DLQ / Lambda Destinations を指定できる
イベントソースマッピング	SQS、Kinesis、DynamoDB Streams	Lambda 側がポーリング。成功しない限りキューから消えないので、可視性タイムアウトが切れると再配信される

SQS を使う場合、キューの可視性タイムアウトは関数のタイムアウトより長くします。 逆にすると、処理中のメッセージが再配信されて二重実行になります。

内部の仕組み

LambdaはマイクロVM（Firecracker）上で関数を隔離実行します。リクエストが来ると実行環境を用意（＝コールドスタート）し、処理後しばらくウォーム状態で再利用。同時に多くのリクエストが来れば、その数だけ環境を並列に増やして水平スケールします。

横にスクロール

設計パターン / ベストプラクティス

• ステートレスに作り、状態はDynamoDB/S3へ
• 小さく・速く（依存を減らし初期化を軽く）
• 非同期＋SQS/DLQ で失敗時のリトライ・退避を担保
• 秘密情報は環境変数ではなく Secrets Manager / SSM Parameter Store

運用・監視・トラブルシュート

• ログは CloudWatch Logs、分散トレースは X-Ray
• 監視メトリクス: Invocations Errors Throttles Duration
• スロットリング多発時は同時実行上限やダウンストリーム（DB）の限界を確認

コスト

課金は2本立てです。リクエスト数と、GB秒（確保したメモリ × 実行時間）。 アイドル中は課金されません。

GB秒 = (メモリMB ÷ 1024) × (課金対象時間ms ÷ 1000) × 実行回数

課金対象時間は1ミリ秒単位で切り上げられます。単価はリージョンと構成 （x86 / Arm、標準 / Provisioned Concurrency）で変わるため、実額は必ず公式の料金ページで確認してください。

メモリを上げた方が安くなることがあります。 メモリはCPUの割り当てでもあるため、 512MB で 1,000ms かかる処理が 1,024MB で 400ms になれば、GB秒は 0.5 × 1.0 = 0.5 から 1.0 × 0.4 = 0.4 へ下がります。倍のメモリで2.5倍速くなれば得、という関係です。 CPUバウンドな処理では実測して決める価値があります。逆に I/O 待ちが支配的な処理では メモリを上げても時間は縮まないので、素直に高くつきます。

見落としやすい費用が3つあります。

• Provisioned Concurrency — 確保している間ずっと課金されます。アイドル無料の前提が崩れます。
• CloudWatch Logs — 取り込み量と保管に対して課金されます。デバッグログを出しっぱなしにした関数が 高頻度で回ると、Lambda 本体より Logs の方が高くなることがあります。保持期間は既定で無期限なので、 最初に設定してください。
• 呼び出し先 — API Gateway、NAT Gateway、データ転送。Lambda 単体では安くても、 VPC 内から外部APIを叩く構成では NAT Gateway の処理データ量が積み上がります。

セキュリティ

• 最小権限の実行ロールを割り当てる
• VPC内リソース（RDS等）へはVPC接続。境界はSGで制御
• 入力検証（API Gateway/イベント）でインジェクション対策

Well-Architected の観点

• コスト最適化: アイドル無料・従量課金
• パフォーマンス効率: イベント駆動で自動スケール
• 運用上の優秀性: サーバー管理レス、IaCでデプロイ
• 信頼性: 非同期＋DLQ＋リトライ

試験で問われるポイント

関連サービス・比較

ハンズオン / CLI例

# zipで関数を作成（実行ロールを指定）
aws lambda create-function \
  --function-name resize-image \
  --runtime nodejs20.x \
  --handler index.handler \
  --role arn:aws:iam::123456789012:role/lambda-exec \
  --zip-file fileb://function.zip

# 手動でテスト実行
aws lambda invoke --function-name resize-image \
  --payload '{"key":"photo.jpg"}' out.json