AWS Lambda 完全ガイド 2026

初心者から実務者向けの包括的解説

概要

Lambda は イベント駆動型のマネージドコンピュートサービスです。サーバーの管理なしにコードを実行でき、実行時間と実行回数に対してのみ課金される従量課金モデルが特徴です。短命な処理・API バックエンド・イベント処理・バッチジョブなど、断続的に発生するワークロードに最適化されています。

初心者向けメモ： Lambda は「サーバーレス」と呼ばれますが、実際にはサーバーが存在し、AWS が管理しているだけです。あなたが見えないだけで、AWS のマシンがあなたのコードを実行しています。

Lambda が解決する課題

主な特徴

• ✅ 完全マネージド: インフラストラクチャ管理ゼロ
• ✅ 自動スケーリング: 同時実行数が秒単位で調整
• ✅ ネイティブ統合: S3・SQS・SNS・DynamoDB・API Gateway など 200 以上の AWS サービス対応
• ✅ 多言語対応: Node.js・Python・Java・.NET・Go・Ruby など
• ✅ コールドスタート対策: SnapStart（Java/.NET）で数百ms 削減可能
• ✅ コスト効率: 実行時間と実行回数のみ課金

アーキテクチャ（Firecracker・MicroVM・Worker）

graph TB
    subgraph AWS["AWS グローバルネットワーク"]
        AZ1["Availability Zone 1"]
        AZ2["Availability Zone 2"]
        AZ3["Availability Zone 3"]
    end
    
    subgraph FC1["Firecracker MicroVM (AZ1)"]
        FC1A["Worker#1<br/>コード実行環境"]
        FC1B["Worker#2<br/>実行時間 Cold/Warm"]
    end
    
    subgraph FC2["Firecracker MicroVM (AZ2)"]
        FC2A["Worker#3<br/>環境キャッシュ"]
    end
    
    subgraph FC3["Firecracker MicroVM (AZ3)"]
        FC3A["Worker#4<br/>リソース隔離"]
    end
    
    Trigger["イベントソース<br/>API Gateway/S3/SQS etc"]
    Control["Lambda Control Plane<br/>関数のメタデータ・権限"]
    
    Trigger --> FC1A
    Trigger --> FC2A
    Trigger --> FC3A
    Control -.管理.-> FC1
    Control -.管理.-> FC2
    Control -.管理.-> FC3
    
    AZ1 -.contains.-> FC1
    AZ2 -.contains.-> FC2
    AZ3 -.contains.-> FC3

実行環境の構成要素

Firecracker
AWS が開発した超軽量ハイパーバイザー。MicroVM 間の分離を保ちながら、オーバーヘッドを最小化します。

Worker
Firecracker MicroVM 内で動作するプロセス。実際にあなたのコードが実行される場所です。

実行環境キャッシュ
コールドスタート（新規起動）を避けるため、デフォルトで 15 分間は Worker が再利用されます。ただし再利用は保証されません。

コアコンポーネント

Function（関数）

実行するコードの最小単位。

• ハンドラー: 関数の入口点（例：index.handler）
• メモリ: 128 MB ～ 10,240 MB（1 MB 刻み）
• タイムアウト: 1 秒 ～ 900 秒（15 分）
• 実行ロール: IAM ロール（何を触れるか）

初心者向けメモ： メモリを増やすと CPU も自動で増加します。メモリ 1,769 MB ≈ 1 vCPU と対応します。

Layer（レイヤー）

複数の関数で再利用できるコード・ライブラリをパッケージング。

Layer 構成:
/nodejs/
  node_modules/  （npm パッケージ）
/python/
  lib/python3.x/site-packages/

Extension（拡張）

関数の実行環境内で動作する軽量エージェント。CloudWatch・X-Ray・監視ツール等をプラグイン。

Container Image（コンテナイメージ）

ZIP デプロイの代替手段。Docker イメージを ECR にプッシュし、Lambda がそれをプル・実行。

• 最大イメージサイズ: 10 GB
• ランタイムインターフェースクライアント（RIC）が必須

SnapStart（Java・Python・.NET）

コールドスタート削減技術。関数の初期化状態をスナップショットして保存し、再利用時に復元。

• Java: 数百 ms → 数十 ms に短縮
• コスト: SnapStart 有効時は若干追加課金

主要ユースケース（15 パターン以上）

呼び出し経路（同期／非同期／ポーリング）

4.1 同期呼び出し（リクエスト／レスポンス型）

• Caller → Lambda → Result (Success/Error)
• ↑ ↑
• 待つ 即座に返す

特性:

• 呼び出し元が 結果を待つ
• エラーは即座に呼び出し元に返る
• タイムアウト: API Gateway との合成（15 分 vs 29 秒）
• 典型例: API Gateway・ALB・SDK 直接呼び出し

課題: P99 が悪化しやすい（コールド＋VPC＋下流 DB）

4.2 非同期呼び出し

• Caller → Lambda Service → Lambda Worker
• ↓ (即座に返す)
• Event ID

特性:

• 呼び出し元は 即座に Event ID を受け取る
• バックグラウンドで実行
• 失敗時 最大 2 回まで自動リトライ
• Lambda Destinations で成功・失敗先を指定可能

重要: 同一論理イベントが複数回到達しうる → 冪等性が必須

例:

• Lambda → SNS トピック → リスナー
• ↓（非同期）
• Event ID 即座に返す

4.3 ポーリング型（イベントソースマッピング）

Event Source (SQS/Kinesis/DDB Streams)
         ↓
    Lambda Service (バッチ読み込み)
         ↓
    Lambda Function (バッチ処理)

特性:

• Lambda Service が ソースを代読み → バッチで関数に渡す
• バッチサイズ・並列度が重要なチューニングパラメータ
• 部分失敗の扱いで再送戦略が変わる
• IteratorAge（処理遅延）が監視指標

初心者向けメモ： ポーリング型は「Lambda が定期的にイベントソースを覗いて、あったら実行する」イメージです。

イベントソースマッピング詳細

マッピングの組み込み型ソース

バッチサイズとウィンドウの設計

バッチサイズ = 1 → Duration 短、レイテンシ低、呼び出し頻度↑、コスト↑
バッチサイズ = 100 → Duration 長、処理効率↑、呼び出し頻度↓、コスト↓

バッチウィンドウ = 0 → 即座に関数呼び出し
バッチウィンドウ = 5 → 最大 5 秒待ってバッチを満たそうとする

判断基準:

• 低遅延が必須（例：リアルタイム監視）→ バッチサイズ小・ウィンドウ短
• コスト重視（例：夜間バッチ）→ バッチサイズ大・ウィンドウ長

同時実行・スロットリング・プロビジョンド／予約

同時実行数の基礎

同時実行数 = 同時に実行中の関数インスタンス数

例）
- 100 RPS × 1 秒 Duration = 100 同時実行必要
- 1000 RPS × 15 秒 Duration = 15,000 同時実行必要

アカウント上限: リージョンあたり 1,000 同時実行（デフォルト）

予約同時実行 vs プロビジョンド同時実行

graph LR
    subgraph Account["アカウント同時実行 1000"]
        Reserved["予約同時実行<br/>500<br/>（最小保証）"]
        Shared["アカウント共有枠<br/>500"]
    end
    
    subgraph Provisioned["プロビジョンド<br/>Cold なし"]
        Prov["200<br/>常時稼働"]
    end
    
    Reserved -.includes.-> Shared
    Prov -.消費.-> Account

スロットリングの発生条件と対策

スロットリング（429）が発生する場合：

1. アカウント同時実行上限に達した
   → 全関数の予約を見直す、または AWS に上限引き上げを申請

2. 関数の予約同時実行に達した
   → その関数の予約を増やす

3. リージョン内の物理リソース不足
   → リージョン変更・時間帯分散を検討

対策：
✅ Application Auto Scaling で予約を時間帯で増減
✅ 上流でレート制限（SQS 可視性タイムアウト等）
✅ リトライ回路遮断器パターン

VPC アタッチとネットワーク

VPC 内実行時の ENI 割り当て

graph TB
    Internet["インターネット<br/>AWS API"]
    VPC["VPC<br/>プライベート"]
    Lambda["Lambda 関数<br/>ENI 経由"]
    NAT["NAT Gateway<br/>or Endpoint"]
    DB["RDS/DynamoDB<br/>プライベートサブネット"]
    
    Internet --"NAT 必須"--> NAT
    NAT --> Lambda
    Lambda --> DB
    Lambda --"エンドポイント"--> Internet

VPC 設計のチェックリスト

• ✅ インターネット向け API 呼び出し → NAT Gateway or VPC Endpoint
• ✅ S3・DynamoDB プライベート接続 → ゲートウェイエンドポイント
• ✅ RDS・ElastiCache → セキュリティグループの「戻りトラフィック」許可
• ✅ DNS 解決 → VPC 内ホストゾーン or Route53 プライベートゾーン
• ✅ クロス AZ 通信 → データ転送料金を見積もり

初心者向けメモ： VPC 内実行すると、Lambda が「VPC のエージェント」になります。インターネットに出るには NAT が必要です。

コールドスタートへの影響

VPC 付与 → ENI 割り当て（約 100 ms） → コールドスタート悪化
対策: プロビジョンド同時実行 or メモリ増加

パッケージング（ZIP・Container・Layers）

ZIP デプロイ

Lambda-package.zip
├── index.js（ハンドラー）
├── node_modules/（依存）
└── config.json

制限:

• ZIP サイズ: 最大 250 MB（圧縮）
• 展開後: 最大 250 MB（with Layers）
• Layer 合計: 最大 5 層

メリット: シンプル・高速デプロイ
デメリット: ネイティブ依存（OpenCV 等）は OS 互換に注意

コンテナイメージデプロイ

FROM public.ecr.aws/lambda/python:3.12

COPY app.py ${LAMBDA_TASK_ROOT}/
COPY requirements.txt ${LAMBDA_TASK_ROOT}/

RUN pip install -r requirements.txt

CMD ["app.lambda_handler"]

メリット: 依存物・OS パッケージを自由に載せられる
デメリット: イメージサイズ（最大 10 GB）・ビルド時間・ECR 保管料

Layer の設計

Layer: python-libs-layer
├── python/lib/python3.12/site-packages/
│   ├── numpy/
│   ├── pandas/
│   └── boto3/

関数が複数あれば、共通ライブラリを一度だけ保管・再利用

ランタイムと言語サポート

2026 現在のランタイム

初心者向けメモ： EOL 後もコードは動きますが、セキュリティパッチが当たらなくなります。

SnapStart（Java・Python・.NET）とコールドスタート最適化

SnapStart の仕組み

初回デプロイ時:
1. 関数の初期化（ハンドラー外のコード実行）
2. DB 接続確立・ライブラリ読み込み
3. スナップショット取得 → 保存

再デプロイ後:
1. スナップショット復元（数十 ms）
2. すぐにリクエスト処理開始

効果:

• Java: 800 ms → 200 ms（75% 削減）
• Python 3.12+: 類似効果（実装段階）
• .NET: 1000 ms → 300 ms

コスト: SnapStart 有効時は若干追加（スナップショット保管・復元）

コールドスタート最適化の階段図

1000ms
 |    コールド時間
 |  ┌─────────────┐
 |  │ (Lambda)   │
 |  ├─────────────┤  ← SnapStart で 75% 削減
500ms│             │
 |  │ Runtime init│
 |  ├─────────────┤
 |  │  VPC ENI    │
 |  ├─────────────┤
100ms│  Code init  │
 |  └─────────────┘
   Warm 再利用

セキュリティ（実行ロール・Resource Policy・シークレット・コード署名）

実行ロールの設計

{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Effect": "Allow",
      "Action": [
        "s3:GetObject",
        "dynamodb:Query"
      ],
      "Resource": [
        "arn:aws:s3:::my-bucket/data/*",
        "arn:aws:dynamodb:us-east-1:123456789012:table/Users"
      ],
      "Condition": {
        "StringEquals": {
          "aws:SourceVpc": "vpc-xxxxx"
        }
      }
    }
  ]
}

ベストプラクティス:

• ✅ 最小権限：不要な * を避ける
• ✅ リソース限定：ARN を具体的に
• ✅ 条件キー：SourceVpc・SourceAccount で多層防御

Resource Policy（誰がこの関数を呼べるか）

{
  "Effect": "Allow",
  "Principal": {
    "Service": "apigateway.amazonaws.com"
  },
  "Action": "lambda:InvokeFunction",
  "Resource": "arn:aws:lambda:us-east-1:123456789012:function:MyFunc"
}

シークレット管理

❌ 悪い例:
export DB_PASSWORD="hardcoded-secret-123"

✅ 良い例:
- AWS Secrets Manager で保管
- 関数の実行ロールで読み取り権限を付与
- コード内：boto3 で動的取得

コード署名

デプロイパイプライン:
Code → Sign (KMS) → ZIP → S3 → Lambda
              ↑
        署名検証
        未署名は本番実行不可

観測（CloudWatch・X-Ray・ADOT・Powertools）

CloudWatch メトリクス監視

graph LR
    Lambda["Lambda<br/>関数実行"]
    Metrics["CloudWatch<br/>メトリクス"]
    Dashboard["Dashboard"]
    Alarm["Alarm<br/>SNS 通知"]
    
    Lambda --> Metrics
    Metrics --> Dashboard
    Metrics --> Alarm
    
    style Metrics fill:#ffcc99

X-Ray・ADOT による分散トレース

Request
  ├─ API Gateway (10ms)
  ├─ Lambda init (50ms)
  ├─ DynamoDB Query (200ms)
  ├─ S3 GetObject (150ms)
  └─ Response (30ms)
  
Total: 440ms ← ボトルネック可視化

Powertools（Python・Node.js）

from aws_lambda_powertools import Logger, Tracer, Metrics

logger = Logger()
tracer = Tracer()
metrics = Metrics()

@tracer.capture_lambda_handler
@logger.inject_lambda_context
def lambda_handler(event, context):
    logger.info("Processing event", extra={"event": event})
    metrics.add_metric(name="ProcessedMessages", unit="Count", value=1)
    return {"statusCode": 200}

メリット:

• 構造化ログ自動出力
• X-Ray の自動トレース記録
• CloudWatch Metrics の簡潔な API

コスト最適化（Power Tuning・Graviton・Tier 価格）

Power Tuning の考え方

メモリ     Duration   コスト(GB-秒)
128 MB  ×  10 秒   = 1.28 GB-秒
512 MB  ×  3 秒    = 1.54 GB-秒  ← CPU 増で Duration 短縮
1024 MB ×  2 秒    = 2.05 GB-秒

最適点: 512 MB が 1.54 で最安

実装:

aws lambda update-function-configuration \
  --function-name MyFunc \
  --memory-size 512
  
→ 複数値で並列実行 → 結果を比較

Graviton2（ARM ベース）

• x86-64 比 20% 安い
• 言語によっては若干遅い（Java・Python は影響小）
• API Gateway・SQS など軽い処理に推奨

aws lambda create-function \
  --function-name MyFunc \
  --architectures arm64  # ← Graviton
  --package-type Zip

Function URL vs API Gateway

graph LR
    Client["クライアント"]
    
    subgraph FunctionURL["Function URL"]
        URL["HTTPS エンドポイント"]
    end
    
    subgraph APIGW["API Gateway"]
        Auth["認証"]
        RateLimit["レート制限"]
        Cache["キャッシュ"]
        WAF["WAF 連携"]
    end
    
    Client --"直接"--> URL
    Client --"多機能"--> Auth
    
    style FunctionURL fill:#ccffcc
    style APIGW fill:#ffcccc

判断基準:

• 内部利用・プロトタイピング → Function URL
• 公開 API・認証・キャッシュ必須 → API Gateway

Step Functions 連携

Lambda ベースのワークフロー

{
  "StartAt": "ProcessData",
  "States": {
    "ProcessData": {
      "Type": "Task",
      "Resource": "arn:aws:lambda:us-east-1:123456789012:function:ProcessFunc",
      "Next": "CheckResult"
    },
    "CheckResult": {
      "Type": "Choice",
      "Choices": [
        {
          "Variable": "$.status",
          "StringEquals": "SUCCESS",
          "Next": "Notify"
        }
      ],
      "Default": "Error"
    },
    "Notify": {
      "Type": "Task",
      "Resource": "arn:aws:sns:us-east-1:123456789012:MyTopic",
      "End": true
    }
  }
}

メリット:

• ✅ Lambda の 15 分制限を超える長期処理
• ✅ 複雑な分岐・並列・リトライロジック
• ✅ 可視化・デバッグ UI

他の類似ツールとの比較

初心者向けメモ： AWS 内なら Lambda が最強。Cloudflare Workers は地理的分散が得意。

クライアントとエコシステム

デプロイツール

Lambda Layers マーケットプレイス

公開 Layer を発見・再利用:

• AWS Lambda Extensions（CloudWatch・Datadog Agent）
• 一般的なライブラリ（numpy・pandas・boto3）

ベストプラクティス

コーディング編

# ✅ ベストプラクティス
import json
import boto3
from aws_lambda_powertools import Logger

logger = Logger()
s3 = boto3.client('s3')  # ハンドラー外：再利用

@logger.inject_lambda_context
def lambda_handler(event, context):
    try:
        key = event.get('key')
        obj = s3.get_object(Bucket='my-bucket', Key=key)
        return {
            'statusCode': 200,
            'body': json.dumps({'data': obj['Body'].read().decode()})
        }
    except Exception as e:
        logger.exception("Error processing request")
        return {'statusCode': 500, 'body': json.dumps({'error': str(e)})}

# ❌ 悪い例
def bad_handler(event, context):
    import boto3  # ハンドラー内：毎回ロード（遅い）
    s3 = boto3.client('s3')
    
    password = "hardcoded-secret"  # ❌ コードに埋め込み

設定編

• ✅ タイムアウト: 関数の最大 Duration + 余裕
• ✅ メモリ: Power Tuning で最適化
• ✅ 環境変数: ロジック変更の閾値は外部化
• ✅ VPC: 必須な場合のみ付与（ENI 割り当てコスト）

運用編

• ✅ エイリアス・バージョン: Blue-Green デプロイ
• ✅ 構造化ログ: JSON 形式で CloudWatch Logs Insights 検索
• ✅ Canary デプロイ: 新バージョンを段階的にトラフィック
• ✅ 定期的な EOL 言語チェック

トラブルシューティング・Runbook

スロットリング（429）

症状: Lambda Throttles メトリクス > 0

原因特定:
1. cloudwatch metrics ConcurrentExecutions → 予約に達している？
2. アカウント全体の予約 → 1000 に達している？
3. リージョン物理リソース枯渇？

対策（優先順）:
✅ 関数の予約を増やす（コスト最小）
✅ Application Auto Scaling で時間帯対応
✅ 上流でレート制限（SQS 可視性タイムアウト）
✅ リージョン追加

Duration 急増

症状: Average Duration が 2 倍以上

原因特定:
1. メモリ？ → メトリクス Duration vs メモリ相関
2. 下流 DB？ → X-Ray で各ステップ時間確認
3. VPC？ → ENI 割り当て遅延か
4. コード変更？ → 直近のデプロイ時刻を確認

対策:
✅ メモリ増（CPU 向上）
✅ DB 接続プール化
✅ キャッシング層（ElastiCache）追加

非同期滞留

症状: Lambda Destinations で未処理が溜まる

原因特定:
1. DLQ 監視 → ポイズンメッセージ内容確認
2. 再試行ポリシー → 最大回数に達した？
3. 下流リソース → 宛先の SQS/SNS が詰まり？

対策:
✅ ポイズンメッセージ手動リプレイ
✅ 下流リソーススケール
✅ 再試行時間を長くする

アンチパターン

2025-2026 最新動向

Lambda Durable Functions（2025年12月GA）

実行時間最大 1 年間のステートフルワークフロー対応

従来：Lambda 最大 15 分制限
新規：Durable Functions で状態保存、中断・再開可能（最大 1 年）

用途：
  ✅ Order Processing（複数ステップの注文処理）
  ✅ Approval Workflows（人間承認待機）
  ✅ Human-in-the-Loop（人間判断挟む処理）
  ✅ Long-running Data Pipelines（長期 ETL）

特性：
  - ローカル変数を暗号化・保存
  - 実行中断中は課金なし
  - Lambda SnapStart / Concurrency / DLQ / Powertools 統合

SnapStart 拡張（Python 3.12+・.NET）

• Java/C# での コールドスタート 75% 削減（800ms → 200ms）
• Python 3.12+ でも SnapStart 対応（同等効果検証中）
• 初期化コスト：若干追加課金

Response Streaming 標準化

大規模ペイロード（10GB+）を 段階的に返却。リアルタイム処理向け。

def lambda_handler(event, context):
    for chunk in generate_large_response():
        yield chunk  # 段階的に返却

AI 統合（Amazon Q・Bedrock・Claude）

import boto3
bedrock = boto3.client('bedrock-runtime')

# Anthropic Claude 3 統合
response = bedrock.invoke_model(
    modelId='anthropic.claude-3-5-sonnet-20241022',
    body=json.dumps({
        'prompt': 'Process this data...',
        'max_tokens': 1000
    })
)

Resource Policy 簡潔化・管理向上

JSON フォーマット最適化・AWS Console での視認性向上。

Recursive Loop Detection（自動インシデント検知）

無限ループ（Lambda → SNS → Lambda）を自動検知・停止。アラート発火。

学習リソース

• 公式 Developer Guide
• Lambda Deep Dive（YouTube）
• AWS Well-Architected Framework - Serverless
• Lambda Performance Tuning - Datadog
• Serverless Stack（チュートリアル）

実装例・活用シーン

例 1: REST API + DynamoDB

import json
import boto3
from aws_lambda_powertools import Logger

dynamodb = boto3.resource('dynamodb')
table = dynamodb.Table('Users')
logger = Logger()

def lambda_handler(event, context):
    try:
        user_id = event['pathParameters']['userId']
        response = table.get_item(Key={'userId': user_id})
        user = response.get('Item', {})
        
        return {
            'statusCode': 200,
            'body': json.dumps(user)
        }
    except Exception as e:
        logger.exception("Error")
        return {'statusCode': 500, 'body': json.dumps({'error': str(e)})}

例 2: S3 トリガーで画像処理

import boto3
from PIL import Image
from io import BytesIO

s3 = boto3.client('s3')

def lambda_handler(event, context):
    bucket = event['Records'][0]['s3']['bucket']['name']
    key = event['Records'][0]['s3']['object']['key']
    
    obj = s3.get_object(Bucket=bucket, Key=key)
    img = Image.open(BytesIO(obj['Body'].read()))
    
    # リサイズ
    img.thumbnail((200, 200))
    
    # 保存
    output_key = f"thumbs/{key}"
    buffer = BytesIO()
    img.save(buffer, format='JPEG')
    s3.put_object(Bucket=bucket, Key=output_key, Body=buffer.getvalue())

例 3: EventBridge スケジューラ + バッチ

import boto3
import json
from datetime import datetime

s3 = boto3.client('s3')
logger = print  # または CloudWatch Logs Insights

def lambda_handler(event, context):
    # 毎日深夜 0 時に実行
    timestamp = datetime.now().isoformat()
    
    # 日報データ集計
    data = {
        'timestamp': timestamp,
        'summary': 'Daily report',
        'metrics': {
            'processed': 1000,
            'errors': 5
        }
    }
    
    s3.put_object(
        Bucket='reports-bucket',
        Key=f"daily-reports/{timestamp}.json",
        Body=json.dumps(data)
    )
    
    return {'statusCode': 200, 'message': 'Report saved'}

導入ロードマップ

フェーズ 1: プロトタイピング（1-2 週間）

• ローカルで関数を書く（SAM local）
• AWS CloudFormation で関数・IAM ロールをデプロイ
• 基本的なテストを実施

フェーズ 2: 統合（2-4 週間）

• イベントソース（S3・SQS 等）を接続
• 非同期・ポーリング経路の設定
• CloudWatch メトリクス・ログを確認

フェーズ 3: 最適化（2-4 週間）

• Power Tuning でメモリを最適化
• VPC が必須なら NAT・エンドポイント設計
• コスト異常アラームを設定

フェーズ 4: 本番化（1-2 週間）

• CI/CD パイプライン構築（CodePipeline・GitHub Actions）
• Blue-Green デプロイの検証
• オンコール・アラート設定

実装チェックリスト

設計段階

• [ ] イベントソース一覧（トリガー・スキーマ・頻度）
• [ ] 副作用一覧（どのテーブル・API を触るか）
• [ ] 冪等性戦略（キー・期限・デデュープ）
• [ ] 再試行・DLQ ポリシー（最大回数・リプレイ手順）
• [ ] パフォーマンス SLO（P50/P99・ペイロード上限）

セキュリティ段階

• [ ] IAM ロール設計（最小権限・条件キー）
• [ ] VPC 必須か判定（NAT・エンドポイント・SG）
• [ ] シークレット管理（Secrets Manager・ローテーション）
• [ ] コード署名設定（本番パイプライン）

運用段階

• [ ] CloudWatch アラーム（Errors・Throttles・Duration）
• [ ] ログ保持ポリシー（7-30 日）
• [ ] ランタイム EOL カレンダー
• [ ] ディザスタリカバリプラン

まとめ

Lambda は 短いイベント駆動処理の大量並列実行に最適化されたサービスです。サーバーレスという名のとおり、インフラを見えなくしてくれる一方、同時実行・VPC・コールドスタート・非同期の重複など、従来とは異なる考え方が必要です。

最初は Function URL で REST API を試し、次に S3・SQS トリガーを学び、最後に Step Functions との組み合わせで複雑なワークフローを組むというステップが無難です。

初心者向けメモ： 「Lambda は銀弾ではない」。長期実行・ステートフル処理・GPU が必要なら ECS・EKS を選択します。

参考文献

公式ドキュメント・ガイド

1. AWS Lambda Developer Guide
2. AWS Lambda SnapStart - コールドスタート削減
3. Lambda Durable Functions - 最大 1 年間実行
4. Lambda Response Streaming - 大規模ペイロード処理
5. AWS Lambda Pricing
6. Lambda Event Source Mappings
7. Lambda Concurrency Configuration

ツール・フレームワーク

8. AWS Lambda Power Tuning - メモリ最適化
9. AWS Powertools for Lambda - 構造化ログ・トレース
10. AWS Serverless Application Model (SAM)
11. AWS CDK Lambda Module

ベストプラクティス・ガイド

12. AWS Well-Architected Serverless Applications Lens
13. Serverless Land（パターン・サンプル）
14. Step Functions Tutorials

関連 AWS サービス

15. API Gateway - REST/WebSocket API
16. EventBridge - イベント駆動
17. SQS / SNS - 非同期メッセージング
18. DynamoDB - NoSQL データベース
19. AWS Bedrock - 生成 AI API
20. CloudWatch - ログ・メトリクス・トレース

最終更新：2026-04-26 バージョン：v2.2（Durable Functions・SnapStart 拡張対応） 著者：Claude (Anthropic) — i のメモ拡充プロジェクト