AWS認定資格 WEB問題集&徹底解説
クラウドプラクティショナー
AWSサービスの一つであるAWS Step Functionsはどんな内容なのでしょうか?また、AWS認定資格のクラウドプラクティショナー(CLF)に合格するためには、サービスのどんなポイントを押さえておけばよいのでしょうか?
ここでは、そんなあなたの疑問に回答していきたいと思います
1. サービス概要
AWS Step Functions は、複数の AWS サービスや独自ロジックをビジュアルワークフロー(状態機械)として定義・オーケストレーションするサーバーレスサービスです。 Amazon States Language(ASL: JSON ベース)でワークフローを記述し、Lambda・ECS・DynamoDB・SageMaker・SNS 等を接続します。
手動でのエラー処理コード・リトライロジック・タイムアウト管理が不要になり、複雑なビジネスロジックを可視的かつ信頼性高く構築できます。 主なユースケース: マイクロサービスオーケストレーション、データ処理パイプライン、ML ワークフロー、ヒューマンアプルーバル処理、E コマース注文処理。
2. 主な特徴と機能
2.1 ワークフロータイプ(Standard vs Express)
- Standard ワークフロー:
- 最大実行時間 1年。ステート遷移数に応じて課金。
- 実行履歴を Step Functions コンソールで 90日間保存・可視化。
- At-Most-Once 実行(同一ステートを重複実行しない)。
- 長期実行・複雑フロー・監査が必要なユースケースに最適。
- Express ワークフロー:
- 最大実行時間 5分。実行回数 + GB-秒で課金。高頻度・短時間向け。
- 実行履歴は CloudWatch Logs に出力(コンソールでの詳細表示なし)。
- At-Least-Once 実行(同一ステートが複数回実行される可能性あり)。
- Synchronous(同期)と Asynchronous(非同期)の 2 モードあり。
2.2 ステートタイプ(最頻出)
- Task: AWS サービスまたは Activity を呼び出す。最も基本のステート。
- Choice: 条件分岐。入力値に基づき次のステートを選択。
- Parallel: 複数ブランチを並列実行し、全て完了後に次ステートへ。
- Map: 配列の各要素に対して同じフローを並列・逐次実行(動的並列化)。
- Wait: 指定時間または特定タイムスタンプまで待機。
- Pass: 入力をそのまま(または変換して)出力。デバッグ・プロトタイプ向け。
- Succeed / Fail: ワークフローを正常終了または失敗終了させる。
2.3 サービス統合パターン
- Request-Response(デフォルト): サービスを呼び出し、レスポンスを待たずに次ステートへ進む。
- .sync 統合(同期待機): ジョブ(Glue・ECS タスク・SageMaker 等)の完了を待ってから次ステートへ。
Resource: "arn:aws:states:::glue:startJobRun.sync" - .waitForTaskToken: タスクトークンを渡し、外部システムがコールバック(
SendTaskSuccess)するまで待機。ヒューマンアプルーバルに使用。
2.4 エラーハンドリング
- Retry: エラー名・最大試行回数・バックオフレートを定義。
- Catch: 特定エラー発生時にフォールバックステートへ遷移。
- エラー名:
States.ALL(全エラー)、States.TaskFailed、States.Timeout等。
2.5 データパス操作
- InputPath: 入力 JSON から特定フィールドを抽出してタスクに渡す。
- OutputPath: タスク出力から特定フィールドのみを次ステートに渡す。
- ResultPath: タスク結果を元の入力 JSON のどこに追記するかを指定。
- Parameters: 入力の変換・動的 JSON 構築(
.$参照)。
3. アーキテクチャおよび技術要素
- Amazon States Language(ASL)で状態機械 JSON を記述する。
- ワークフロータイプ(Standard / Express)と IAM 実行ロールを指定して作成。
- 実行開始(StartExecution)するとステートを順次処理。
- 各 Task ステートが AWS SDK 統合で Lambda / ECS / Glue 等を呼び出す。
- 実行履歴・グラフをコンソールでリアルタイム監視(Standard のみ)。
典型パターン: API Gateway → Lambda(StartExecution) → Step Functions(Lambda + DynamoDB + SNS オーケストレーション)。 ML パイプラインでは SageMaker ジョブの .sync 統合で学習完了を待機してから評価ステップへ進む。
4. セキュリティと認証・認可
- IAM 実行ロール: Step Functions が各タスクで呼び出すサービス(Lambda invoke / ECS RunTask 等)への権限を付与。最小権限原則を守る。
- リソースポリシー: 外部 AWS アカウントやサービスからの StartExecution 権限を制限。
- データ暗号化: 実行データは TLS で転送、CloudWatch Logs 出力時は KMS 暗号化を推奨。
- VPC エンドポイント: PrivateLink で VPC 内から Step Functions API にプライベートアクセス可能。
- CloudTrail 統合: API 操作の監査ログを自動記録。
5. 料金形態
- Standard ワークフロー: ステート遷移数(100万遷移単位)で課金。1か月の無料枠あり。
- Express ワークフロー(非同期): 実行回数 + 実行期間 × 使用メモリ(GB-秒)で課金。
- Express ワークフロー(同期): 非同期と同じ課金モデル。呼び出し元がレスポンスを待機できる。
- Step Functions 自体の料金は比較的低い。実際のコストの大部分は呼び出す Lambda・ECS・Glue 等のリソース料金が占める。
6. よくあるアーキテクチャ・設計パターン
- マイクロサービスオーケストレーション: Lambda 群を Choice + Parallel で接続。エラー時の補償トランザクションを Catch で実装。
- データ処理パイプライン: S3 イベント → Step Functions → Glue ETL(.sync)→ Athena クエリ → SNS 通知。
- ML ワークフロー: SageMaker 学習ジョブ(.sync) → 評価 → モデル登録 → エンドポイント更新。
- ヒューマンアプルーバル: .waitForTaskToken でメールに承認リンクを含め、承認クリックで SendTaskSuccess を呼び出す。
- バッチ処理(Map ステート): S3 内のファイル一覧を Map ステートで並列処理。ECS Fargate タスクを動的に起動。
7. 設定・デプロイ手順(ハンズオン例)
- Step Functions コンソールでワークフロービルダーを開き、ステートをドラッグ&ドロップで配置する。
- ASL(JSON)に書き出し、Task ステートのリソース ARN(Lambda 等)を設定する。
- IAM 実行ロールを作成し、Lambda invoke / DynamoDB / SNS 等の権限を付与する。
- Standard ワークフローとして作成し、テスト入力 JSON で StartExecution を実行。
- コンソールのグラフ表示でステート遷移・入出力・エラーを確認する。
- EventBridge スケジュールや API Gateway から StartExecution を呼び出してトリガー設定する。
8. 試験で問われやすいポイント
8.1 Standard vs Express の選択(最頻出)
Q: 「実行履歴を詳細に保存し、最長1年間実行できる」ワークフロータイプは?
A: Standard ワークフロー。ステート遷移数に応じて課金。
Q: 1秒に数千回の高頻度・短時間イベント処理に適するワークフロータイプは?
A: Express ワークフロー。実行回数 + GB-秒課金で低コスト。最大 5分。
8.2 サービス統合パターン
Q: Glue ETL ジョブの完了を待ってから次ステートに進むには?
A: .sync 統合(glue:startJobRun.sync)。完了まで待機後に次ステートへ遷移。
Q: 人間の承認を待機するワークフローを実装するには?
A: .waitForTaskToken パターン。タスクトークンを SNS メール等に含め、承認後に SendTaskSuccess を呼び出す。
8.3 ステートタイプの選択
Q: 配列の各要素に対して同じ処理を並列実行するステートは?
A: Map ステート。Parallel ステートは固定ブランチ数、Map は動的配列処理。
8.4 Step Functions vs SWF
Q: 新規開発でサーバーレスワークフローを構築する場合は?
A: Step Functions。Amazon SWF(Simple Workflow Service)は旧世代サービスで、新規採用は推奨されない。
8.5 エラーハンドリング
Q: 特定のエラー発生時に別のステートに遷移させるには?
A: Catch フィールドにエラー名と Next ステートを定義する。リトライは Retry フィールドで設定。