本アドベントカレンダー 「AWS Lambda 実践入門」 は、Lambda を “動かす” だけでなく 「壊れない運用」まで含めて実務投入できる状態にする ことを目的に、基礎から段階的に積み上げるシリーズです（対象：AWS Lambda 初心者〜中級者）。
Day1〜Day5：Phase 1（基礎）— まず“動く”と“わかる”を作る
| Day | Phase | 学ぶ観点 | 読者のアウトプット |
|---|---|---|---|
| Day1 | 1 | Lambda 全体像（何ができるか／何が難所か） | 「Lambda の実務での使い所」メモを作る |
| Day2 | 1 | 実行モデル（init/invoke、環境が残る） | handler 外初期化の理由を説明できる |
| Day3 | 1→2 | イベント駆動（S3/SQS/EventBridge など入口） | 自分のユースケースで“入口”を1つ選べる |
| Day4 | 0 | IAM 基礎（実行ロールと権限） | IAM の切り分け（誰が何にアクセス）表を作る |
| Day5 | 1 | ログの基本（見方・出し方） | 失敗時に CloudWatch Logs から原因を追える |
Day6〜Day10：Phase 3（IaC/設計）— “増えても壊れない”土台作り
| Day | Phase | 学ぶ観点 | 読者のアウトプット |
|---|---|---|---|
| Day6 | 3 | SAM/IaC の基本（手作業卒業） | 最小の SAM テンプレでデプロイできる |
| Day7 | 3 | template.yaml 設計原則（保守性） | Globals/Parameters/Conditions を整理できる |
| Day8 | 3 | Layer 運用（依存管理の型） | Layer を“分類・命名・責務分離”できる |
| Day9 | 3 | Layer 設計（増えても破綻しない） | Layer の README 必須項目を定義できる |
| Day10 | 3 | Layer を CI/CD で自動追従 | “最新 ARN 取得→デプロイ”が自動化できる |
Day11〜Day15：Phase 3（DevOps）— 壊れないデプロイと変更追跡
| Day | Phase | 学ぶ観点 | 読者のアウトプット |
|---|---|---|---|
| Day11 | 3 | CI/CD（OIDC・安全な権限移譲） | AccessKey なしでデプロイできる |
| Day12 | 3 | 環境分離（STG/PROD の切替） | ブランチ/環境で同一 IaC を運用できる |
| Day13 | 3 | Version/Alias/Canary/Rollback | $LATEST 直叩き卒業、戻せる設計にする |
| Day14 | 4 | Deploy Marker（変更を可視化） | “いつ・何が・なぜ”をログで追える |
| Day15 | 4 | 構造化ログ（観測可能性の型） | JSON ログ＋Insights で集計できる |
Phase 3 の注意書き（Day6〜Day15 全体に適用）
sam local invoke 等のローカル実行に固執しすぎない：統合は AWS 上で検証し、モック地獄を避ける。
Day16〜Day18：Phase 5（セキュリティ）— 実務で落とせない必須ライン
| Day | Phase | 学ぶ観点 | 読者のアウトプット |
|---|---|---|---|
| Day16 | 5 | IAM/KMS/Secrets/EOL（守るべき型） | “秘密情報を平文で扱わない”運用ができる |
| Day17 | 5 | Inspector（CVE と脆弱性運用） | 依存（Layer）起因の脆弱性を管理できる |
| Day18 | 5→4 | 監査（誰がいつ何を変更したか） | CloudTrail/Config で変更追跡できる |
Day19〜Day21：Phase 6（性能・最適化）— “速い・安い・事故らない”
| Day | Phase | 学ぶ観点 | 読者のアウトプット |
|---|---|---|---|
| Day19 | 6 | メモリ×CPU×並列（性能チューニング） | p95/p99 を見て改善判断できる |
| Day20 | 6 | tmp10GB / Layer / fan-out（重処理最適化） | 大容量処理の分割・並列化ができる |
| Day21 | 6→5 | VPC 接続（閉域・NAT-less・Endpoint） | VPC 構成で詰まらずに運用できる |
Day22〜Day25：Phase 7（総点検・実運用）— Well-Architected で仕上げる
| Day | Phase | 学ぶ観点 | 読者のアウトプット |
|---|---|---|---|
| Day22 | 7 | Well-Architected（Serverless Lens で棚卸し） | 未対応項目を改善計画に落とせる |
| Day23 | 7 | 運用設計（SLO/アラート/Runbook） | 監視→通知→対応の手順を文章化できる |
| Day24 | 7 | コスト・性能の継続改善（定例化） | 定例レビュー観点（指標）を持てる |
| Day25 | 7 | 総まとめ（設計原則の再統合） | 自分のプロジェクトへ移植できる |