AWS Service Comparison Matrix (Batch)¶
バッチ処理・ジョブ実行サービスの選定判断材料。
History¶
| 日付 | 内容 |
|---|---|
| 2026-05-28 | 初版作成 |
| 2026-10-10 | 初版から更新なし。AWS公式ドキュメント・サービス仕様との整合を再確認する必要あり（要レビュー、#911） |
| 2026-10-10 | AWS 公式ドキュメントで Lambda durable functions (AWS 公式) が GA 済みであることを確認。非同期実行時は最大 1 年までチェックポイント・再開が可能であり、Step Functions との使い分け判断に影響するため Batch Processing 比較に追記 (#936) |
Batch Processing: AWS Batch vs ECS Scheduled Task vs Step Functions vs Lambda¶
ℹ️ Lambda durable functions (AWS 公式) が GA 済み。関数コード内でチェックポイント・再開を伴う複数ステップのオーケストレーションを記述でき、非同期実行では最大 1 年まで実行可能 (同期実行は従来どおり最大 15 分)。Step Functions を使わずに Lambda の開発体験のまま長時間・多段階ワークフローを実装したい場合に検討する。
| 比較項目 | AWS Batch | ECS Scheduled Task | Step Functions | Lambda |
|---|---|---|---|---|
| ドキュメント | Batch | ECS | Step Functions | Lambda |
| 課金モデル | 基盤リソース (Fargate/EC2) のみ (料金) | Fargate/EC2 課金 (料金) | 状態遷移 \$0.025/1000 (料金) | リクエスト + 実行時間 (料金) |
| 主用途 | 大量並列バッチ、HPC | 定期実行コンテナタスク | 複数ステップのワークフロー | 軽量イベント駆動処理 |
| SLA | 99.99% | 99.99% (ECS SLA) | 99.99% | 99.95% |
| 学習コスト | 中程度 | 低い (ECS + EventBridge) | 中程度 (ASL 定義) | 低い |
| スケーリング | 自動 (ジョブキュー + Compute Environment) | タスク数手動指定 | Map State (最大 10,000 並列) | 自動 (同時実行数制御) |
| 主要サービス制限 | ジョブキュー 50/アカウント (Quotas) | ECS サービス制限に準拠 (Quotas) | ペイロード 256KB、実行履歴 25,000 イベント、Standard 1 年/Express 5 分 (Quotas) | 実行時間 15 分、ペイロード 6MB、同時実行 1000 (Quotas) |
| コスト (常時高負荷) | 安い (Spot 活用) | 中程度 | 遷移数依存 | 高い |
| コスト (バースト) | 安い (使った分だけ + Spot) | 中程度 | 安い (従量課金) | 安い (従量課金) |
| 最大実行時間 | 無制限 | 無制限 | 1 年 (Standard) / 5 分 (Express) | 15 分 |
| 並列実行 | ✅ Array Job (数千並列) | ⚠️ (タスク数手動指定) | ✅ Map State (最大 10,000) | ✅ (同時実行数制御) |
| ジョブ依存関係 | ✅ (ジョブ間依存定義) | ❌ | ✅ (ステート間遷移) | ❌ (単体実行) |
| リトライ | ✅ (自動リトライ + 戦略設定) | ⚠️ (EventBridge リトライ) | ✅ (Retry/Catch 定義) | ⚠️ (非同期呼び出し時のみ) |
| スケジュール実行 | ❌ (EventBridge 連携で可能) | ✅ (EventBridge ルール) | ✅ (EventBridge 連携) | ✅ (EventBridge 連携) |
| GPU サポート | ✅ | ✅ (EC2 起動タイプ) | ❌ (呼び出し先に依存) | ❌ |
| Spot 利用 | ✅ (Spot Fleet 自動管理) | ✅ (Fargate Spot) | - (呼び出し先に依存) | - |
| エラーハンドリング | ジョブ単位リトライ | タスク単位 | Catch/Retry で詳細制御 | DLQ |
| 可観測性 | CloudWatch Logs + メトリクス | CloudWatch Logs + メトリクス | 実行履歴 + X-Ray | CloudWatch Logs + X-Ray |
| Terraform 対応 | ✅ | ✅ | ✅ | ✅ |
Guidelines¶
→ ワークロード特性に応じて使い分ける。 単一の推奨はなく、以下の判定基準で選定する。
- 定期実行の単一コンテナタスク → ECS Scheduled Task (ecschedule で管理)
- 複数ステップの依存関係があるワークフロー → Step Functions
- 大量並列 (数百〜数千) のバッチ処理、GPU/HPC → AWS Batch
- 15 分以内で完了する軽量イベント駆動処理 → Lambda
- 複数ステップにまたがる長時間処理を Lambda の開発体験のまま実装したい場合は Lambda durable functions (非同期実行、最大 1 年) を検討。AWS サービス間の直接連携や可視化された実行グラフが必要な場合は Step Functions を優先する
- Step Functions + Lambda/ECS の組み合わせで複雑なバッチパイプラインを構築するパターンが最も汎用的
Workflow Orchestration: Step Functions vs MWAA (Airflow) vs EventBridge Scheduler¶
| 比較項目 | Step Functions | MWAA (Airflow) | EventBridge Scheduler |
|---|---|---|---|
| ドキュメント | Step Functions | MWAA | Scheduler |
| 課金モデル | 状態遷移課金 (料金) | 環境時間 最小 \$0.49/h (料金) | 呼び出し \$1/100 万 (料金) |
| 主用途 | AWS サービス連携ワークフロー | データパイプライン、複雑な DAG | 単一ターゲットの定期呼び出し |
| SLA | 99.99% | 99.9% | 99.99% |
| 学習コスト | 中程度 (ASL 定義) | 高い (Airflow 知識必要) | 低い |
| スケーリング | 自動 (状態遷移数に応じて) | Worker Auto Scaling | 自動 (スケジュール数に応じて) |
| 主要サービス制限 | ペイロード 256KB、Standard 1 年/Express 5 分、状態遷移 25,000/実行 (Quotas) | DAG 数/Worker 数は環境クラスに依存 (Quotas) | スケジュール数 1,000,000/アカウント/リージョン (Quotas) |
| コスト (常時高負荷) | 遷移数依存 (Express で安い) | 高い (~\$350/月〜) | 安い |
| コスト (バースト) | 安い (従量課金) | 高い (環境常時課金) | 安い (従量課金) |
| ワークフロー定義 | ASL (JSON/YAML) | Python DAG | スケジュール式 (cron/rate) |
| DAG 複雑度 | 中程度 (分岐・並列・Map) | 高い (任意の DAG 構造) | なし (単一ターゲット) |
| AWS サービス統合 | ✅ 200+ サービス直接呼び出し | ⚠️ (Operator/Hook 経由) | ✅ 270+ ターゲット |
| 外部システム連携 | ⚠️ (Lambda/ECS 経由) | ✅ (豊富な Provider) | ⚠️ (API Destination 経由) |
| UI/可視化 | ✅ コンソール実行グラフ | ✅ Airflow Web UI | ❌ (スケジュール一覧のみ) |
| バックフィル | ❌ | ✅ | ❌ |
| Terraform 対応 | ✅ | ✅ | ✅ |
Guidelines¶
→ Step Functions を標準採用する。 AWS サービスとの直接統合が豊富で、サーバーレスかつ従量課金のためコスト予測が容易。
- データパイプラインで複雑な DAG、バックフィル、外部システム連携が多い場合は MWAA を検討
- 単一ターゲットの定期呼び出し (cron ジョブ) は EventBridge Scheduler で十分
- MWAA は最小コストが高いため、小規模チームでは Step Functions + EventBridge Scheduler の組み合わせを推奨