Lambda の実行環境（Node.js・Python・Go）使い分け完全ガイド
AWS Lambda の主要ランタイム Node.js・Python・Go を、コールドスタート速度・実行性能・ライブラリ事情・運用負荷・コストの 5 軸で徹底比較。Graviton2（arm64）・SnapStart・Provisioned Concurrency まで含めて、用途別の選択指針を整理する。
Lambda のランタイム選びは「速度・エコシステム・運用負荷・コスト」の四項対立。Node.js と Python が利用シェア 9 割を占める一方、コンパイル言語の Go はコールドスタート 50〜100ms・低メモリで台頭中。用途に合わせて選ぶための判断軸を整理する。
1. 概要（端的に）
AWS Lambda の主要マネージドランタイムは 2026 年時点で Node.js / Python / Java / .NET / Ruby / Go（カスタムランタイム） の 6 系統。実利用ではこのうち Python と Node.js で全体の 9 割を占める（Datadog の State of Serverless より）。
ランタイムの違いは以下の 4 軸で表れる。
- コールドスタート速度 — 実行環境の準備時間。Go が最速、Java が最遅。
- ライブラリ・SDK エコシステム — Python は AI/ML、Node.js は Web、Go は同時実行とインフラ系に強い。
- 運用負荷（EoL 頻度・サポート期間） — Node.js は 1〜2 年で EoL が来るが、Go はバイナリ提供で寿命が長い。
- コスト効率 — メモリ消費と実行時間の積で決まり、Go > Python > Node.js の傾向。
「迷ったら Python」が無難解だが、SLA がシビアな API は Go、**フロントと型を揃えたい現場は TypeScript（Node.js）**が定石になりつつある。
2. 主要ランタイム比較（早見表）
| 評価項目 | Node.js 22 | Python 3.13 推奨 | Go（provided.al2023） |
|---|---|---|---|
| 提供形態 | マネージド | マネージド | カスタムランタイム（バイナリ） |
| コールドスタート (p50) | 200〜350 ms | 200〜400 ms | 50〜100 ms |
| ウォーム実行 | 速い | 速い | 最速・最小メモリ |
| AWS SDK | AWS SDK v3（モジュラー） | boto3（成熟） | aws-sdk-go-v2（堅実） |
| AI／ML ライブラリ | 少 | 極めて多い | 少 |
| 型システム | TypeScript で導入可 | 型ヒント／mypy（任意） | 静的型（強制） |
| ローカルデバッグ | 容易（VS Code） | 容易（VS Code） | やや手間（バイナリ更新） |
| EoL／サポート期間 | 約 2 年で次バージョン強制 | 約 3 年 | AWS の OS LTS 期間（長い） |
| SnapStart 対応 | 未対応（Java/Python/.NET のみ） | 対応（2024-11〜） | 未対応（不要） |
| 推奨ユースケース | BFF・GraphQL・SaaS Webhook | ETL・ML 推論・Bedrock 連携 | 高 TPS API・ストリーム処理 |
3. コールドスタートの構造
コールドスタートは下記 4 段階で構成される。ランタイムにより負担の重い段階が異なる。
- コードダウンロード — S3 から関数 ZIP / ECR からコンテナイメージを取得（パッケージサイズに比例）
- 実行環境の起動 — Firecracker microVM のブート（一律 〜100 ms）
- ランタイム初期化 — V8 / CPython / Go バイナリの読み込み（言語差が大きい）
- コード初期化 —
import／requireと初期化ロジックの実行（依存ライブラリ数に比例）
段階別の傾向
| 段階 | Node.js | Python | Go |
|---|---|---|---|
| 1. ダウンロード | 中（node_modules が肥大化しやすい） | 中（boto3・pandas 等で肥大化） | 小（単一バイナリ） |
| 2. 実行環境 | 同等 | 同等 | 同等 |
| 3. ランタイム | 中（V8 起動） | 中（CPython 起動） | 極小（バイナリ即実行） |
| 4. コード初期化 | 中〜大 | 中〜大（pandas/numpy で重い） | 極小 |
コールドスタートを避ける 3 つの仕組み
- Provisioned Concurrency — 指定数の実行環境を常時ウォームに保つ。追加料金が発生するが、ピーク時の安定性は最高。
- SnapStart — 関数初期化後のメモリ状態をスナップショット化して再利用。Java / Python / .NET で利用可。Node.js / Go は未対応。
- Lambda SnapStart（Python 2024-11〜） — boto3 や ML モデルのロードを SnapStart に乗せると、Python のコールド時間が大幅に縮む。
4. 各ランタイムの仕様と特徴
4-1. Node.js 22（推奨：BFF・GraphQL・Web 系）
- エコシステム — npm の充実度は圧倒的。フロントエンドと型・コード資産を共有できるのが最大の利点。
- AWS SDK v3 — モジュラー化により
@aws-sdk/client-s3だけを取り込めばパッケージサイズを最小化できる。 - 苦手領域 — CPU バウンドな数値処理は Python の numpy / Go の goroutine に劣る。
- EoL の頻度 — 偶数バージョンが LTS だが、Lambda 側のサポートは約 2 年で打ち切られる。強制アップグレード運用を覚悟しておく。
4-2. Python 3.13（推奨：ETL・ML 推論・Bedrock 連携）
- エコシステム — boto3 が事実上のリファレンス実装。pandas / numpy / Polars でデータ処理が圧倒的に書きやすい。
- Bedrock / SageMaker / Comprehend — AWS の AI 系 SDK は Python が一級市民。サンプルコードも Python が最多。
- 苦手領域 — GIL の制約で純粋な並列処理は不得意。CPU 並列が要る場合は ECS / Fargate を選ぶ。
- SnapStart 対応 2024-11〜 — boto3 や ML モデルのロード時間がスナップショット化され、コールドスタートが激減。
4-3. Go（推奨：高 TPS API・ストリーム処理）
- 形態 — マネージドランタイムは 2024 年に廃止され、
provided.al2023上にバイナリを乗せるカスタムランタイムとして運用する。 - 強み — 単一バイナリ・goroutine による高い並行処理性能・最速のコールドスタート（50〜100 ms）。
- メモリ効率 — 同等処理を Node.js 比で メモリ 50〜70%・実行時間 40〜60% に抑えられる事例が多い（One Technology Japan の事例では「コスト 85% 削減」）。
- 苦手領域 — AI/ML 系ライブラリと UI 系ロジック。クライアント SDK の網羅性も Python / Node.js より一段落ちる。
- EoL — 自前バイナリのため、OS（Amazon Linux 2023）の LTS が切れない限り長期運用できる。
5. 用途別の選択指針
5-1. API Gateway 経由のリクエスト処理（同期・低レイテンシ要件）
- 第一候補：Go — コールドスタート 50〜100 ms、ウォーム時のレイテンシも安定。
- 第二候補：Node.js（TypeScript） — フロントと型を共有したい場合。
- 避ける：Java（SnapStart なし） — レイテンシ要件 200 ms 以下なら不利。
5-2. S3 → Lambda → DynamoDB の ETL
- 第一候補：Python — boto3 と pandas でファイル処理を最短記述。
- 第二候補：Node.js — JSON 主体の軽量変換ならこちらも好相性。
- 大量データなら：Lambda ではなく Glue / Step Functions Map / EMR Serverless へ。
5-3. SQS / Kinesis のストリーム処理
- 第一候補：Go — goroutine で 1 レコードずつ並列処理しやすい。
- 第二候補：Python — ParallelizationFactor を上げて並列化する設計が定番。
- コスト最優先：Go の優位が顕著。同一スループットで Lambda 実行時間が半分以下になる事例も。
5-4. Bedrock / SageMaker 連携（生成 AI）
- ほぼ一択：Python — Bedrock 公式 SDK の主言語。LangChain・LlamaIndex 等のラッパーも Python 中心。
- 代替：Node.js —
@aws-sdk/client-bedrock-runtimeで TypeScript 化も可能。本番フロント連動なら有力。
5-5. Cron / 定期実行（EventBridge Scheduler）
- 規模が小さければ Python — 書きやすさ・読みやすさ重視。
- 頻度が高く・処理が短いものは Go — メモリ最小化でコストが激減する。
6. メリット・デメリット
7. ベストプラクティス
- アーキテクチャはまず
arm64— 互換性が取れる関数は最優先で arm64 に変更。料金 20% 減・コールドスタート短縮。 - 「Python は SnapStart、Go はそのまま、Node.js は Provisioned Concurrency」 が 2026 年の定番分担。
- 依存パッケージは最小化 — Lambda Layers で共通依存を分離し、関数本体の ZIP を 50 MB 以下に保つ。
- 計測してから最適化 — まず
Init Durationを CloudWatch でモニタし、本当に遅いのか／頻度はどうかを確認してから対策を打つ。 - 複数ランタイム混在を許容する — 「Web 系は Node.js／ETL は Python／高 TPS は Go」のように関数単位で最適言語を選ぶ。Step Functions で連結すれば運用上の摩擦は小さい。
- EoL カレンダーを CI に組み込む —
aws lambda list-functionsの Runtime をスキャンし、EoL 6 ヶ月前にアラートを出す仕組みを最初に作る。 - コンテナイメージ Lambda の活用 — 250 MB を超える依存（pandas + numpy + ML モデル等）はコンテナ化が現実解。10 GB までイメージサイズに耐える。
8. 関連用語
- AWS Lambda — 本記事のベースサービス
- Lambda の同時実行数・コールドスタート対策 — Provisioned Concurrency の使い所
- Lambda Layers — 共通依存を分離する仕組み
- Lambda の VPC 設定とネットワーク構成 — VPC アタッチ時のランタイム影響
- Lambda@Edge と CloudFront Functions の使い分け — Edge 系の制約が厳しいランタイム選定
- Amazon API Gateway — Lambda の主要呼び出し元
- AWS Step Functions — 複数ランタイムを連結する標準解
- AWS SAM — ローカル開発・ビルド・デプロイの定番ツール
- Amazon DynamoDB — Lambda から最も多く触られるデータストア
9. 関連サイト
AWS 公式
- Lambda runtimes（公式ユーザーガイド）
- Lambda SnapStart の概要
- Provisioned Concurrency の仕組み
- Lambda Custom Runtime（provided.al2023）
参考記事
- Datadog State of Serverless（IT Leaders）：Python 58% / Node.js 31%
- Scanner.dev：Serverless Speed - Rust vs Go vs Java vs Python in AWS Lambda
- Classmethod：Lambda のコールドスタート問題と対策
- KAYAC Engineers’ Blog：Lambda Node.js の EoL に疲れて Go にしている話
- One Technology Japan：Node.js より Golang で Lambda コストを 85% 削減
- iret.media：AWS Lambda のコールドスタート 3 つの対策
🎓 試験での出題傾向
| 試験 | 重要度 | 主な出題パターン |
|---|---|---|
| CLF | 低 | Lambda が複数ランタイム対応であることの理解 |
| SAA | 中 | コールドスタート要件に対する SnapStart / Provisioned Concurrency の選択 |
| DVA | 高 | ランタイム別の特徴・SDK・EoL 管理・Layers 設計 |
| SOA | 中 | EoL 監視、CloudWatch での Init Duration モニタ |
特に DVA では「遅延に厳しい API でコールドスタートを最小化したい」「boto3 を使った大規模 ETL で初期化を高速化したい」のような選択問題が頻出。SnapStart は Python / Java / .NET のみ対応・Node.js と Go は未対応という事実は試験でも実務でもよく問われるため必ず押さえる。