TL

Cloud Service

AWS Step Functions

複数サービスをステートマシンとして可視化・連携させるサーバーレスなワークフロー基盤。状態遷移とリトライを宣言的に定義する。

中級DVA-C02SAA-C03DOP-C02運用上の優秀性信頼性
最終更新: 2026-06-13公式ドキュメント ↗
TL;DR要点だけ先に
  • 1.処理の流れを状態の図として定義し各サービスを順に呼ぶ。
  • 2.リトライ・分岐・並列・待機を自前コードなしで宣言できる。
  • 3.実行履歴が可視化され失敗箇所と入出力を後から追える。

解決する課題

  • 複数サービスをまたぐ処理の順序・分岐・待機をLambdaのコードに埋め込むと複雑化する
  • 失敗時のリトライやエラー処理を一貫したルールで持ちたい
  • 長時間かかる業務フローの進行状況や失敗箇所を後から追えるようにしたい
  • 「人手の承認待ち」や「外部処理の完了待ち」を安全に待機したい

主要概念と用語

  • ステートマシン: ワークフロー全体の定義。状態(ステート)の集合と遷移で表す
  • ステート(状態): 1つの処理単位。種類により役割が異なる
  • Task: 実際の処理を呼ぶ状態。Lambdaや他のAWSサービスを実行する
  • Choice: 入力の値で分岐する状態
  • Parallel / Map: 複数の処理を並列実行する状態(Mapは配列要素ごとに繰り返す)
  • Wait: 指定時間または時刻まで待つ状態
  • ASL: ステートマシンを定義するJSONベースの言語(Amazon States Language)
  • 実行(Execution): ステートマシンを1回走らせた単位。入出力と履歴が記録される

仕様・制限・クォータ

  • ワークフローには2つのタイプがある。**標準(Standard)**は長時間・完全な実行履歴向け、Expressは高頻度・短時間向け
  • 標準は実行が最大1年程度の長期間にわたれる一方、Expressは短時間の実行に最適化されている
  • 状態定義の入出力ペイロードには上限サイズがあり、大きなデータはS3に置いて参照を渡すのが定石
  • 多数のAWSサービスを直接呼び出せる(サービス統合)ため、Lambdaを介さずに連携できる

内部の仕組み

ステートマシンを実行すると、Step Functionsは現在の状態の出力を次の状態の入力として渡しながら、定義された遷移をたどります。各状態はTaskならサービスを呼び、Choiceなら条件分岐し、ParallelMapなら複数の枝を同時に進めます。各状態にはRetry(再試行)Catch(エラー捕捉)を宣言でき、一時的な失敗は自動でリトライし、回復不能なエラーは別の状態へ遷移して後始末できます。すべての状態遷移は記録され、入出力とともに実行履歴として残ります。

リトライはコードに書かない

一時的なエラーへの指数バックオフ付きリトライは、各状態のRetry定義で宣言するのが基本。Lambda内に再試行ループを書くより、ワークフロー側に寄せると意図が可視化され運用も楽になります。

設計パターン / ベストプラクティス

  • オーケストレーション: 注文処理など複数ステップの業務フローを1つのステートマシンに集約
  • Mapで並列処理: 配列の各要素を並列に処理し、スループットを上げる
  • コールバックで待機: タスクトークンを使い、外部処理や人手の承認の完了通知を待つ
  • Sagaパターン: 途中で失敗したらCatch補償処理(ロールバック相当)へ遷移
  • 大きなデータはS3経由: 状態間で渡すのは参照だけにしてペイロード上限を回避
標準とExpressの選び方

標準は実行履歴が完全で長時間処理・監査向け、Expressは大量・短時間のイベント処理向けで料金体系も異なります。要件(実行頻度・所要時間・履歴の必要性)で選び分けます。

運用・監視

  • 各実行のステータス(成功・失敗・中断)と、どの状態で止まったかをコンソールのグラフ表示で確認できる
  • CloudWatchメトリクスで実行数・失敗数・実行時間を監視する
  • 失敗が増えたら、該当する状態のRetry/Catch定義と、呼び出し先サービスの権限・入力フォーマットを確認する
  • EventBridgeから定期起動したり、実行状態の変化をイベントとして受け取ったりできる

コスト

  • 標準は主に状態遷移の回数で課金される。遷移が多いほど費用が増える
  • Expressは実行回数と実行時間・使用リソースに応じた課金で、高頻度・短時間の処理に向く
  • 不要な状態遷移を減らす、Choiceで早期に分岐を絞る、といった設計でコストを抑えられる

セキュリティ

  • ステートマシンにはIAMロールを割り当て、呼び出すサービスへの権限を最小限に絞る
  • 実行データはサービス側で暗号化され、必要に応じてKMSによる管理を組み合わせる
  • VPC内のリソースを呼ぶ場合は、呼び出し先(Lambdaなど)側のネットワーク設定で制御する
  • 入出力に機微なデータを含める場合は、ログ出力レベルやS3参照方式の利用を検討する

Well-Architected の観点

  • 運用上の優秀性: ワークフローが可視化され、失敗箇所と入出力を履歴で追える
  • 信頼性: Retry・Catch・並列・待機を宣言的に持ち、部分的な失敗から回復しやすい

試験で問われるポイント

頻出
  • 複数サービスをまたぐオーケストレーションの中心=Step Functions
  • Retry / Catch によるエラー処理を宣言的に定義できる
  • **標準(長時間・履歴重視)vs Express(高頻度・短時間)**の使い分け
  • Mapによる並列処理と、タスクトークンによるコールバック待機

関連サービス・比較

観点Step FunctionsSQS
役割ワークフローの統括メッセージのバッファ
流れの制御順序・分岐・並列を定義順序保証はFIFOのみ
可視化実行履歴をグラフ表示キューの滞留を監視
向く用途多段の業務フロー連携送信側と処理側の疎結合

ハンズオン / CLI例

# ステートマシンの定義(ASL)を渡して作成
aws stepfunctions create-state-machine \
  --name order-flow \
  --role-arn "arn:aws:iam::123456789012:role/StepFunctionsRole" \
  --definition '{
    "Comment": "簡単な順次フロー",
    "StartAt": "Validate",
    "States": {
      "Validate": {
        "Type": "Task",
        "Resource": "arn:aws:lambda:ap-northeast-1:123456789012:function:validate",
        "Retry": [{"ErrorEquals": ["States.ALL"], "MaxAttempts": 2, "BackoffRate": 2.0}],
        "Next": "Charge"
      },
      "Charge": {
        "Type": "Task",
        "Resource": "arn:aws:lambda:ap-northeast-1:123456789012:function:charge",
        "End": true
      }
    }
  }'

# 実行を開始して入力を渡す
aws stepfunctions start-execution \
  --state-machine-arn "arn:aws:states:ap-northeast-1:123456789012:stateMachine:order-flow" \
  --input '{"orderId":"A-1001"}'

AWS Service

AWS Step Functionsを実務で読む

TL;DRは入口です。実際に選ぶ・使う段階では、何を解決するか、何と比較するか、導入後にどこで詰まるかまで見る必要があります。

解決すること

アプリ統合

比較で見る軸

クラウド: AWS / カテゴリ: アプリ統合 / 難易度: intermediate

導入後に効く点

リトライ・分岐・並列・待機を自前コードなしで宣言できる。

先に潰すリスク

サービス単体ではなく、権限、ネットワーク、監視、課金、バックアップを含めて設計する必要がある。

数字・仕様の読み方
クラウド
AWS
カテゴリ
アプリ統合
難易度
intermediate
関連資格
DVA-C02 / SAA-C03 / DOP-C02
設計柱
operational / reliability

判断チェックリスト

  • 自社の用途が「アプリ統合 / operational」に近いか確認する。
  • 強みである「処理の流れを状態の図として定義し各サービスを順に呼ぶ。」が本当に評価軸になるか確認する。
  • 注意点の「サービス単体ではなく、権限、ネットワーク、監視、課金、バックアップを含めて設計する必要がある。」を運用で吸収できるか確認する。
  • 公開値や仕様値は、対象プラン・対象機種・対象リージョンまで確認する。
  • 既存システム、ID、ネットワーク、監視、バックアップとの接続方法を先に洗い出す。
  • 小さく試してから、本番移行、権限設計、障害時手順、コスト監視を決める。

次に確認する観点

アプリ統合operationalreliabilityDVA-C02SAA-C03