AWS Lambda

解決する課題

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

主要概念と用語

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

仕様・制限・クォータ

• 最大実行時間 15分（超えるならStep Functionsで分割やECS/Batchへ）
• メモリ 128MB〜10GB。メモリに比例してCPUも増える
• デプロイパッケージサイズ上限、/tmp の一時領域あり
• 同時実行はアカウント単位の上限（引き上げ可）

内部の仕組み

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

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

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

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

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

コスト

• リクエスト数 ＋ 実行時間（GB秒 = メモリ×ミリ秒） で課金。無料枠が大きい
• メモリを上げるとCPUも上がり、速くなって総額が下がることも（要計測）

セキュリティ

• 最小権限の実行ロールを割り当てる
• 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