Contents
スポンサードリンク
1. 基本概念と実行単位の違い
1.1 Lambda の特徴
- デプロイ単位：関数（ハンドラー）。コードは ZIP またはコンテナイメージで登録。
- 実行環境：AWS が自動的にランタイムを用意し、インフラ管理は不要。
- 対象ランタイム：Node.js, Python, Java, Go, .NET, Ruby など公式サポート言語（Lambda ランタイム一覧）。
1.2 Fargate の特徴
- デプロイ単位：ECS/EKS タスクとして実行される Docker コンテナ。
- インフラ抽象化：サーバーやクラスターの管理は不要だが、タスク定義で CPU・メモリ・ポートなどを明示的に指定する必要あり。
- 対応環境：Linux ベースの任意コンテナ（言語・ミドルウェアは制限なし）。
1.3 実装フロー比較
| 項目 | AWS Lambda | AWS Fargate |
|---|---|---|
| デプロイ手順 | aws lambda create-function --package-type Image（ECR イメージ）または ZIP ファイルを S3 経由でアップロード |
Dockerfile 作成 → docker build → docker push（ECR）→ ECS タスク定義作成 |
| 設定例 | メモリ 128‑10,240 MB、タイムアウト最大 15 分 | CPU 0.25‑4 vCPU、メモリ 0.5‑30 GB |
| CI/CD の主なツール | CodePipeline + Lambda Deploy Action、GitHub Actions の aws lambda update-function-code |
CodePipeline + ECS Deploy Action、Copilot CLI、GitHub Actions の ecs-deploy |
ポイント
- シンプルさ が求められるイベント駆動アーキテクチャは Lambda が適しています。
- 柔軟性・既存 Docker ワークフロー活用 が必要な場合は Fargate が有利です。
2. 実行時間上限と長時間ジョブへの対応
2.1 タイムアウト制限
| サービス | 最大実行時間 |
|---|---|
| AWS Lambda | 15 分（900 秒）※Lambda のタイムアウト設定 |
| AWS Fargate | 実質無制限（タスクが停止されない限り実行可能） |
注記：2025 年 7 月の内部ノートに「Fargate タスクは上限なし」と記載がありますが、公式ドキュメントでも同様の説明が掲載されています（ECS タスク実行時間）。
2.2 実運用シナリオ
| シナリオ | 推奨サービス | 理由 |
|---|---|---|
| リアルタイム API（数百 ms 応答） | Lambda | 瞬時にスケールアウトし、Cold Start を最小化できる（プロビジョンドコンカレント利用）。 |
| バッチ ETL（2 h 以上） | Fargate | タスクが長時間実行可能で、Spot インスタンスと組み合わせたコスト削減も容易。 |
| ストリーム処理（Kinesis → Lambda） | Lambda | イベント駆動に最適化されており、再試行ロジックが自動。 |
3. 料金モデル比較と実践的なコストシミュレーション
3.1 料金体系の概要
| 項目 | Lambda（us-east-1） | Fargate（us-east-1） |
|---|---|---|
| 無料枠 | 月 100 万リクエスト + 400,000 GB‑秒 | 対象なし |
| リクエスト単価 | $0.20 / 1M リクエスト | - |
| 計算リソース単価 | $0.0000166667 per GB‑秒 | vCPU $0.04048 / 時間、メモリ $0.004445 / GB‑時間 |
| Spot 割引率（参考） | なし | 最大 70% （Fargate Spot の料金ページ） |
※リージョンごとの価格差 は公式価格表で確認してください。
3.2 シナリオ別概算コスト（30 日間、1 GB メモリ・300 秒実行、100 req/s）
| 項目 | 計算式 | Lambda (USD) | Fargate (オンデマンド, USD) |
|---|---|---|---|
| 総リクエスト数 | 100 × 86,400 s × 30 = 259.2M | $51.84（超過分） | - |
| GB‑秒合計 | 1 GB × 300 s × 259.2M ÷ 1,000 = 77,760,000 GB‑秒 | $1,296.00 | - |
| 合計 (Lambda) | — | $1,347.84（無料枠除く） | - |
| vCPU 時間 | 0.25 vCPU × (300/3,600)h × 259.2M ≈ 5,400 vCPU‑h | - | $218.59 |
| メモリ時間 | 1 GB × (300/3,600)h × 259.2M ≈ 21,600 GB‑h | - | $95.99 |
| 合計 (Fargate, オンデマンド) | — | - | $314.58 |
| Spot 割引（30%） | 上記×0.3 | - | 約 $220 |
ポイント
- 短時間・高頻度のリクエストは Lambda が割安になる傾向があります。
- CPU とメモリを一定量長時間確保するバッチ処理は Fargate の方がコスト効率的です（特に Spot 利用時）。
4. パフォーマンス特性：Cold Start とスケーラビリティ
4.1 Cold Start の実測値（2024‑10 時点）
| 言語 | プロビジョンドコンカレントなし | プロビジョンドコンカレント有効 |
|---|---|---|
| Node.js 14/16 | ≈ 800 ms | ≈ 150 ms |
| Python 3.9/3.10 | ≈ 600 ms | ≈ 120 ms |
| Java 11 (OpenJDK) | ≈ 2,200 ms | ≈ 300 ms |
出典: AWS Compute Blog 「Measuring Lambda Cold Start Times」および公式ドキュメント「Provisioned Concurrency」。
4.2 Fargate のタスク起動遅延
| 条件 | 起動に要する時間 |
|---|---|
| 初回イメージプル（キャッシュなし） | ≈ 35 秒 |
| 再利用可能なタスクプールから取得 | ≈ 10 秒 |
備考：タスク起動遅延はコンテナサイズ・ネットワーク環境に依存します。
4.3 スケーリング速度比較
| 項目 | Lambda | Fargate |
|---|---|---|
| 同時実行上限（デフォルト） | 1,000 並列リクエスト/リージョン（増加申請可） | タスク数は Service の最大設定に依存、実質無制限 |
| バースト能力 | 瞬時に 3 倍のスパイクを処理可能（同時実行上限まで自動拡張） | Auto Scaling ポリシーで秒単位の増減が可能だが、タスク起動遅延分だけレイテンシが発生 |
結論
- リアルタイム API では Cold Start が数百ミリ秒以内に抑えられる Lambda が有利。
- 長時間実行かつスループット安定性が重要 なバックエンドは、起動遅延を許容できる Fargate の方が予測しやすい。
5. 運用・セキュリティ・移行ベストプラクティス
5.1 監視とロギング
| 項目 | Lambda | Fargate |
|---|---|---|
| 標準メトリクス | Invocations, Errors, Duration, Throttles（CloudWatch） | CPUUtilization, MemoryUtilization（ECS Service メトリクス） |
| ログ集約 | CloudWatch Logs（自動生成） | FireLens → CloudWatch Logs / Amazon OpenSearch Service |
| 分散トレース | AWS X‑Ray SDK（自動インストゥルメント） | OpenTelemetry エージェントをサイドカーとしてデプロイ |
5.2 IAM の最小権限設計
- Lambda：
AWSLambdaBasicExecutionRoleに加えて、必要なサービス（例: S3, DynamoDB）へのアクセス権だけを個別に付与。 - Fargate：
ecs:RunTask,logs:CreateLogStream,ecr:GetAuthorizationTokenなど、タスク実行に必須なアクションのみ許可。
5.3 CI/CD パイプラインのポイント
| フェーズ | Lambda 用 | Fargate 用 |
|---|---|---|
| ビルド | ZIP 作成または Docker イメージビルド → ECR プッシュ | Dockerfile ビルド → ECR プッシュ |
| デプロイ | aws lambda update-function-code または CloudFormation の AWS::Lambda::Function |
ECS タスク定義更新 → Service ロールアウト（aws ecs update-service --force-new-deployment） |
| テスト | SAM CLI (sam local invoke) でローカル実行検証 |
LocalStack か、ECS Exec でコンテナ内部にシェル接続して動作確認 |
5.4 移行シナリオ
5.4.1 Lambda → Fargate
- コードのコンテナ化：Dockerfile を作成しローカルで
docker runテスト。 - イメージプッシュ：ECR にプッシュし、タスク定義に
imageパラメータを設定。 - サービス構築：ECS Service（ALB/NLB 経由）を作成し、必要なら Auto Scaling ポリシーを追加。
- エンドポイント切替：API Gateway の統合先を Lambda から ALB に変更し、段階的にトラフィックを移行。
5.4.2 Fargate → Lambda（軽量化が可能なケース）
- ロジック抽出：コンテナ内のビジネスロジックだけを関数ハンドラーとして切り出す。
- デプロイパッケージ作成：必要最小限の依存ライブラリだけを含む ZIP か、軽量コンテナイメージに変換。
- Lambda デプロイ：CodePipeline の Lambda Deploy Action を使用し、関数設定（メモリ・タイムアウト）を調整。
- トラフィック移行：API Gateway の統合先を再度 Lambda に戻すか、Stage 別に分割して A/B テスト実施。
ベストプラクティス
- 移行前に必ず ステージング環境で負荷テスト（k6, Artillery 等）を実施し、レイテンシ・コストの差異を定量化。
- IAM ロールは 段階的に権限削減 し、CloudTrail でアクセスログを監査。
6. まとめ（要点）
| 項目 | Lambda | Fargate |
|---|---|---|
| 実行単位 | 関数 | コンテナタスク |
| 最大実行時間 | 15 分 | 無制限 |
| 料金モデル | リクエスト + GB‑秒 | vCPU 時間 + メモリ時間（Spot で最大 70% 削減） |
| Cold Start | 言語別数百〜数千 ms（プロビジョンドコンカレントで大幅短縮） | タスク起動に約 30–45 秒 |
| スケーラビリティ | 瞬時のバーストが可能、同時実行上限はデフォルト 1,000 | Auto Scaling による秒単位増減、タスク起動遅延あり |
| 運用ツール | CloudWatch Metrics / X‑Ray | ECS メトリクス / FireLens + OpenTelemetry |
| 移行のハードル | コードサイズ・ランタイム制限が主 | タスク定義とコンテナイメージ管理が必要 |
次のアクション
1. 自社ユースケース（リアルタイム vs バッチ）を明確化。
2. 小規模 PoC を実施し、実測コスト・レイテンシ を取得。
3. 結果に基づき、本番環境での Lambda と Fargate の組み合わせ（例：フロントは Lambda、バックエンドは Fargate）を設計。
この比較とベストプラクティスを活用し、最適なサーバーレス実行基盤を選定してください。
スポンサードリンク