はじめに

このページは、当ブログで公開しているAWSハンズオン記事のまとめページです。

各ハンズオンは 難易度別（Tier 1〜3） に整理しており、それぞれ以下の2種類の記事を用意しています。

「まずコンソール版で雰囲気をつかんでからSAM版でコード化する」という順番もおすすめです。

今後もハンズオン記事を追加し次第、このページに随時追記していきます。

Amazon検索[本 AWS 開発]

🗺️ ハンズオン難易度マップ

📌 入門編：IaC の第一歩

CloudFormationでWeb自動起動EC2を構築

AWSのインフラをコードで管理する「IaC（Infrastructure as Code）」の入口となるハンズオンです。マネジメントコンソールで手動構築したEC2インスタンスを、CloudFormationテンプレートに置き換えることで、再現性・バージョン管理・チーム共有の価値を体感できます。

難易度: ★☆☆☆☆
学習時間の目安: 60〜90分
課金リスク: 小（t2.micro 無料枠対象）

学べること

• CloudFormation テンプレートの基本構造（YAML）
• EC2インスタンス・セキュリティグループ・KeyPairのコード定義
• VSCode + AWS CLI を使ったデプロイフロー

こんな方におすすめ
「AWSはコンソールで触ったことがあるけど、コードでインフラ管理をしてみたい」という方の最初の一歩に最適です。

🟢 Tier 1：簡単 / 課金リスク極小

1. S3 + CloudFront 静的サイトホスティング

S3バケットにHTMLを配置し、CloudFront経由でCDN配信する静的サイトホスティング環境を構築します。OAC（Origin Access Control）を使ってS3を非公開にしつつCloudFrontからのみアクセスを許可するセキュアな構成を学べます。

難易度: ★★☆☆☆
学習時間の目安: 30〜60分
課金リスク: 極小（CloudFront 無料枠 1TB/月、S3 GET は少額）

学べること

• S3バケットのパブリックアクセスブロック設定
• CloudFront ディストリビューション作成と OAC 設定
• HTTPSリダイレクト、キャッシュ無効化（Invalidation）の操作

こんな方におすすめ
「ウェブサイトをサーバーレスで公開したい」「CDNとキャッシュの仕組みを理解したい」方に最適。CloudFrontの基本を押さえたい方はここから始めてください。

2. EventBridge + Lambda 定期バッチ実行

EventBridgeのスケジュールルールを使って、Lambdaを定期実行する「Cronバッチ」を構築します。rate式（例: 毎5分）とcron式（例: 毎日午前9時）の両方を試し、イベント駆動アーキテクチャの基本を体感できます。

難易度: ★★☆☆☆
学習時間の目安: 30〜60分
課金リスク: 極小（Lambda 無料枠 100万リクエスト/月）

学べること

• EventBridge スケジュールルールの作成（rate / cron式）
• Lambda 関数のIAMロール設定
• CloudWatch Logs でのログ確認

こんな方におすすめ
「定期実行処理をサーバーレスで実装したい」「cron式の書き方を理解したい」方向け。Lambdaの基本と組み合わせて最初のサーバーレスハンズオンとしても最適です。

3. S3 ファイルアップロード → Lambda 非同期処理

S3バケットへのファイルアップロードをトリガーに、Lambdaを自動起動する非同期処理パイプラインを構築します。ファイルアップロードをイベントとして扱う「イベント駆動」の基本パターンです。

難易度: ★★☆☆☆
学習時間の目安: 30〜60分
課金リスク: 極小（S3 PUT + Lambda 実行のみ）

学べること

• S3 ObjectCreated イベント通知の設定
• Lambda トリガーとリソースベースポリシー
• URLデコード処理（日本語ファイル名対応）
• DeletionPolicy によるバケット削除制御

こんな方におすすめ
「ファイルをアップロードしたら自動で何か処理したい」ユースケース（画像変換、CSV取り込みなど）の基礎を学びたい方向け。

4. SQS + Lambda メッセージキュー処理

SQSキューにメッセージを投入し、Lambdaがポーリングして処理するメッセージキューアーキテクチャを構築します。処理失敗時に備えたDLQ（デッドレターキュー）も合わせて実装します。

難易度: ★★★☆☆
学習時間の目安: 60分
課金リスク: 極小（SQS 無料枠 100万リクエスト/月）

学べること

• SQS標準キューとDLQ（デッドレターキュー）の作成
• RedrivePolicy（最大受信数・DLQ連携）の設定
• Lambda SQSポーリングとバッチ処理
• IAM権限（SQSPollerPolicy）の付与

こんな方におすすめ
「非同期処理・リトライ・失敗メッセージ管理を学びたい」方向け。マイクロサービス間の疎結合通信の基礎として重要なパターンです。

🟡 Tier 2：中程度 / 少し設定多め

5. Step Functions + Lambda 受注処理ワークフロー

Step Functionsのステートマシンを使って、注文検証→在庫確認・支払い処理（並列）→注文確定という受注処理ワークフローを構築します。ビジュアルエディタ（Workflow Studio）とASLコードの両面からワークフローを理解できます。

難易度: ★★★☆☆
学習時間の目安: 60〜90分
課金リスク: 小（Step Functions 無料枠 4,000回のステート遷移/月）

学べること

• Task / Parallel / Retry / Catch ステートの定義
• ASL（Amazon States Language）の記述
• DefinitionSubstitutions による Lambda ARN の動的差し込み（SAM版）
• Workflow Studio（ビジュアルエディタ）の操作（コンソール版）

こんな方におすすめ
「複数処理のオーケストレーションを学びたい」「並列処理やエラーハンドリングを含む業務フローをAWSで実装したい」方向け。

6. Lambda + API Gateway + DynamoDB メモアプリAPI

Lambda・API Gateway・DynamoDBを組み合わせて、メモの作成・取得・更新・削除（CRUD）ができるREST APIをサーバーレスで構築します。実用的なCRUD APIの実装パターンを一通り学べます。

難易度: ★★★☆☆
学習時間の目安: 60〜90分
課金リスク: 小（DynamoDB 無料枠 25GBストレージ・25RCU/WCU）

学べること

• DynamoDB テーブル設計（パーティションキー・ソートキー）
• Lambda からの boto3 による DynamoDB 操作（CRUD）
• API Gateway REST API のリソース・メソッド設定
• Lambda プロキシ統合とレスポンス形式

こんな方におすすめ
「サーバーレスでWebAPIを作りたい」「DynamoDBの基本操作を覚えたい」方向け。フロントエンドと組み合わせるバックエンドAPI開発の基礎として最適です。

7. Cognito + API Gateway + Lambda 認証付きAPI

Amazon CognitoのUser Poolを使ってJWT認証付きAPIを構築します。API Gatewayに Cognito Authorizer を設定することで、Lambdaコードを変更せずに認証を追加できる設計パターンを学べます。

難易度: ★★★☆☆
学習時間の目安: 90〜120分
課金リスク: 小（Cognito 無料枠 5万MAU/月）

学べること

• Cognito User Pool・User Pool Client の作成
• IDトークン（JWT）の取得と検証フロー
• API Gateway Cognito Authorizer の設定
• DefaultAuthorizer によるAPI全体への認証適用

こんな方におすすめ
「ログイン機能付きAPIを作りたい」「JWT認証の仕組みを理解したい」方向け。独自の認証基盤を実装するより安全で、スケーラブルな認証設計を学べます。

8. SNS + SQS + Lambda 通知システム（Pub/Sub・ファンアウト）

SNSトピックに発行したメッセージを複数のSQSキューに配信するファンアウトパターンを構築します。フィルターポリシーを使って「全ログ記録用」と「アラート用」でメッセージを振り分ける実践的な通知システムです。

難易度: ★★★☆☆
学習時間の目安: 90分
課金リスク: 小（SNS 無料枠 100万リクエスト/月）

学べること

• SNS Topic の作成と SQS サブスクリプション設定
• FilterPolicy によるメッセージ振り分け
• SQSQueuePolicy の明示的な設定（SAM版）
• 複数Lambda によるファンアウト処理パターン

こんな方におすすめ
「Pub/Subパターンやマイクロサービス間のイベント通知を学びたい」方向け。複数の処理を並列で起動するファンアウト設計はモダンなシステムの定番パターンです。

🔴 Tier 3：少し複雑 / AWSらしいユースケース

9. S3 + Lambda + Rekognition 画像認識パイプライン

S3に画像をアップロードするとLambdaが起動し、Amazon RekognitionのDetectLabels APIでAI/ML画像認識を行うパイプラインを構築します。特別な機械学習の知識なしにAI機能を組み込める体験ができます。

難易度: ★★★★☆
学習時間の目安: 60〜90分
課金リスク: 小（Rekognition 無料枠 5,000枚/月）

学べること

• Amazon Rekognition DetectLabels API の使い方
• S3 + Lambda イベント駆動パイプラインの実装
• RekognitionDetectOnlyPolicy / S3ReadPolicy 組み込みポリシー（SAM版）
• 最小権限原則に基づいたIAM設計

こんな方におすすめ
「AWSのAI/MLサービスを試してみたい」「画像に写っているものを自動分類したい」方向け。機械学習の実装不要でAI機能を組み込める体験は必見です。

10. API Gateway + Lambda + CloudWatch Logs チャットボットログAPI

チャットボットの会話ログをAPIで受け取り、CloudWatch Logsに保存・集計する仕組みを構築します。Metric Filterを使ってJSONログからカスタムメトリクスを自動生成する監視基盤の実装です。

難易度: ★★★★☆
学習時間の目安: 90〜120分
課金リスク: 小（CloudWatch Logs 無料枠 5GB/月）

学べること

• CloudWatch Log Group の作成とログ保存
• Metric Filter（JSONフィルター）によるカスタムメトリクス生成
• boto3 logs.put_log_events() を使ったログ書き込み
• IAM インラインポリシーの Statement 直接記述（SAM版）

こんな方におすすめ
「ログ管理・監視基盤に興味がある」「メトリクスの自動収集の仕組みを理解したい」方向け。CloudWatch の活用度を上げたいエンジニアに特におすすめです。

🔧 実務ハンズオン編

S3 + CloudFront + WAF IP制限付き静的サイト配信

S3 + CloudFrontの静的サイト構成にWAFを追加し、特定IPアドレスのみアクセスを許可するセキュリティ構成を構築します。実務でよくある「社内向け静的サイト」や「ステージング環境のIP制限」に対応した実践的な内容です。

難易度: ★★★★☆
学習時間の目安: 90〜120分
課金リスク: 中（WAF WebACL: 約$5/月 + $0.60/100万リクエスト）

学べること

• CloudFront OAC（Origin Access Control）のセキュアな設定
• WAF WebACL の作成と IP セットによるアクセス制御
• IPv4 / IPv6 デュアルスタック対応
• 実務的なトラブルシューティング（キャッシュ・ルール反映の遅延など）

こんな方におすすめ
「CloudFront + WAFによるセキュリティ強化を実装したい」「実務でIP制限付きサイトを構築する予定がある」方向け。Tier 1の「S3 + CloudFront 静的サイトホスティング」を先にやっておくとスムーズです。

📊 全ハンズオン一覧

Amazon検索[本 AWS 開発]

さいごに

各ハンズオンは難易度順に進めるとスムーズに学習できます。ただし、興味のあるテーマから始めても問題ありません。

学習の進め方の例:

1. IaC入門 → CloudFormation EC2でコードによるインフラ管理を体験
2. Tier 1 → EventBridge + Lambda の定期実行でサーバーレスの基本を把握
3. Tier 2 → メモアプリAPIやCognitoで実用的なAPIを構築
4. Tier 3 / 実務 → 画像認識やWAFを追加して本格的な構成へ

また、同じテーマのコンソール版で全体像をつかんでからSAM版でコード化するという進め方もおすすめです。IaC化の効率性と再現性を実感できます。

引き続きハンズオン記事を追加予定ですので、ぜひブックマークしてご活用ください！

The post 【保存版】AWS実践ハンズオン記事まとめ｜サーバーレス・インフラ・AIを難易度別に完全網羅 first appeared on CayTech Lab.

はじめに

「複数のLambda関数をオーケストレーションするワークフローを、コードで管理したい」という要件に、AWS SAM（Serverless Application Model） は最適な選択肢のひとつです。

この記事では、AWS SAM を使って、受注処理ワークフロー（注文検証 → 在庫確認・支払い並列処理 → 注文確定）をゼロから構築するハンズオンを紹介します。

入力: {"order_id": "ORD-001", "item_id": "item-001", "quantity": 2}
  ↓
[ValidateOrder] 注文検証（Retry + Catch）
  ↓ 成功
[ProcessInParallel] 並列処理（Catch）
  ├─ [CheckInventory] 在庫確認
  └─ [ProcessPayment] 支払い処理
  ↓ 成功（結果リスト: [inventory_result, payment_result]）
[ConfirmOrder] 注文確定
  ↓
終了（成功）

[HandleError] エラー処理（Catch 先）
  ↓
終了（エラー通知済み）

このハンズオンで体験できること：

• AWS::Serverless::StateMachine を使った Step Functions の SAM 定義
• DefinitionSubstitutions で ASL 内の Lambda ARN を 自動差し込みする仕組み
• LambdaInvokePolicy による1行での権限付与（コンソール版ではIAMロールを自動生成）
• CLI でのテスト実行 + コンソールの実行グラフで視覚的に確認

このハンズオンの特徴：

• sam build + sam deploy の 2コマンドで全リソースをデプロイ
• Step Functions（ステートマシン）+ Lambda × 5 + IAM ロール × 6 を template.yaml 1ファイルで管理
• sam delete で全リソースを一括削除（コンソール版では5つのLambda・ステートマシン・IAMロールを個別に削除）

Amazon検索[本 AWS 開発]

SAM vs コンソール：どれだけ違うか

キーワード解説

前提条件

aws sts get-caller-identity

アカウントIDが表示されれば認証設定済みです。

使用するAWSサービス

Step 1: プロジェクトフォルダを開く

cd C:\my-aws\aws-learning-projects\step-functions-lambda

フォルダ構造

step-functions-lambda/
├── template.yaml           # SAMテンプレート（Step Functions + Lambda 定義）
├── samconfig.toml          # デプロイ設定（gitignore 対象・毎回手動作成が必要）
├── docs/
│   ├── 1_console.md        # AWSコンソール版手順
│   └── 2_sam.md            # SAM版手順
└── src/
    ├── validate.py         # 注文検証 Lambda
    ├── inventory.py        # 在庫確認 Lambda
    ├── payment.py          # 支払い処理 Lambda
    ├── confirm.py          # 注文確定 Lambda
    └── error_handler.py    # エラー処理 Lambda

Step 2: SAMテンプレートの確認（template.yaml）

template.yaml は全 AWSリソースの設計図です。ポイントを確認しておきます。

Lambda 関数の定義

Globals:
  Function:
    Runtime: python3.12
    Timeout: 10
    MemorySize: 128

Resources:
  ValidateFunction:
    Type: AWS::Serverless::Function
    Properties:
      CodeUri: src/           # src/ 配下の全 .py を1つのパッケージとしてデプロイ
      Handler: validate.lambda_handler

  InventoryFunction:          # 在庫確認（Parallel ブランチ 1）
  PaymentFunction:            # 支払い処理（Parallel ブランチ 2）
  ConfirmFunction:            # 注文確定
  ErrorHandlerFunction:       # エラー処理（Catch 先）

ポイント: 5つの Lambda 関数が全て CodeUri: src/ を共有しています。SAM は src/ フォルダを1つの ZIP パッケージとして S3 にアップロードし、各関数は Handler でどのファイル・関数を使うかを指定します。

ステートマシンの定義

  OrderWorkflow:
    Type: AWS::Serverless::StateMachine
    Properties:
      Type: STANDARD
      Definition:
        StartAt: ValidateOrder
        States:
          ValidateOrder:
            Type: Task
            Resource: "${ValidateFunctionArn}"   # DefinitionSubstitutions で実際の ARN に置換
            Next: ProcessInParallel
            Retry:
              - ErrorEquals: [States.ALL]
                IntervalSeconds: 2
                MaxAttempts: 1
                BackoffRate: 2.0
            Catch:
              - ErrorEquals: [States.ALL]
                Next: HandleError
                ResultPath: "$.error"

          ProcessInParallel:
            Type: Parallel
            Branches:
              - StartAt: CheckInventory
                States:
                  CheckInventory:
                    Type: Task
                    Resource: "${InventoryFunctionArn}"
                    End: true
              - StartAt: ProcessPayment
                States:
                  ProcessPayment:
                    Type: Task
                    Resource: "${PaymentFunctionArn}"
                    End: true
            Next: ConfirmOrder
            Catch:
              - ErrorEquals: [States.ALL]
                Next: HandleError
                ResultPath: "$.error"

          ConfirmOrder:
            Type: Task
            Resource: "${ConfirmFunctionArn}"
            End: true

          HandleError:
            Type: Task
            Resource: "${ErrorHandlerFunctionArn}"
            End: true

      DefinitionSubstitutions:           # ${変数名} を実際の ARN に自動置換
        ValidateFunctionArn: !GetAtt ValidateFunction.Arn
        InventoryFunctionArn: !GetAtt InventoryFunction.Arn
        PaymentFunctionArn: !GetAtt PaymentFunction.Arn
        ConfirmFunctionArn: !GetAtt ConfirmFunction.Arn
        ErrorHandlerFunctionArn: !GetAtt ErrorHandlerFunction.Arn

      Policies:                          # ステートマシンが Lambda を呼び出す IAM 権限
        - LambdaInvokePolicy:
            FunctionName: !Ref ValidateFunction
        - LambdaInvokePolicy:
            FunctionName: !Ref InventoryFunction
        - LambdaInvokePolicy:
            FunctionName: !Ref PaymentFunction
        - LambdaInvokePolicy:
            FunctionName: !Ref ConfirmFunction
        - LambdaInvokePolicy:
            FunctionName: !Ref ErrorHandlerFunction

template.yaml のポイント解説

Step 3: Lambda コードの確認（src/）

各ファイルの役割を確認しておきます。

各 Python コードの全文はコンソール版記事を参照してください。
SAM版・コンソール版で使用する Lambda コードは共通です。コンソール版では各関数ごとにコードを貼り付ける手順とあわせて全文を掲載しています。

→ AWSコンソールだけでStep Functions + Lambdaワークフローを構築する手順【SAM版との比較付き / 新UI対応】

confirm.py の event[0] / event[1] について：
Parallel ステートが成功すると、各ブランチの出力が**配列（リスト）**にまとめられて次のステートに渡されます。このため ConfirmFunction は event[0] で在庫確認結果、event[1] で支払い結果にアクセスしています。この仕様を知らないと list indices must be integers エラーで詰まります。

Step 4: samconfig.toml を作成する

samconfig.toml は .gitignore で管理外のため、毎回手動で作成する必要があります。

step-functions-lambda/samconfig.toml を新規作成して以下を貼り付けます。

version = 0.1

[default.deploy.parameters]
stack_name = "step-functions-lambda-stack"
resolve_s3 = true
s3_prefix = "step-functions-lambda-stack"
region = "ap-northeast-1"
confirm_changeset = true
capabilities = "CAPABILITY_IAM"
disable_rollback = true
image_repositories = []

[default.global.parameters]
region = "ap-northeast-1"

samconfig.toml の置き場所：
step-functions-lambda/ フォルダの直下に置く必要があります。

Step 5: sam build（ビルド）

cd C:\my-aws\aws-learning-projects\step-functions-lambda
sam build

成功すると以下のように表示されます。

Build Succeeded

Built Artifacts  : .aws-sam/build
Built Template   : .aws-sam/build/template.yaml

sam build が行っていること：

• src/ フォルダを ZIP パッケージ化して .aws-sam/build/ に配置
• template.yaml を .aws-sam/build/template.yaml にコピー
• Lambda デプロイの準備を整える

Step 6: sam deploy（デプロイ）

sam deploy

変更内容が表示されて確認を求められます。

Deploy this changeset? [y/N]: y

y を入力して進めます。数分でデプロイが完了します。

デプロイ完了の確認

ターミナルに Outputs が表示されます。

Outputs
----------------------------------------------------------------------
Key    OrderWorkflowArn
Value  arn:aws:states:ap-northeast-1:123456789012:stateMachine:step-functions-lambda-stack-order-workflow

Key    OrderWorkflowName
Value  step-functions-lambda-stack-order-workflow
----------------------------------------------------------------------

OrderWorkflowArn を控えておきます。（テスト実行コマンドで使用）

デプロイされるリソース一覧

Step Functions ステートマシン × 1  : step-functions-lambda-stack-order-workflow
Lambda 関数 × 5                    : step-functions-lambda-stack-ValidateFunction-XXXX 他
IAM ロール × 6                     : ステートマシン用 × 1 / Lambda 用 × 5
S3                                 : SAM デプロイパッケージ
CloudWatch Logs                    : Lambda 自動生成ログ × 5

Step 7: 動作テスト

事前準備: ARN を変数に設定する

set SM_ARN=arn:aws:states:ap-northeast-1:123456789012:stateMachine:step-functions-lambda-stack-order-workflow

123456789012 を自分のアカウントIDに置き換えてください（Outputs の値をそのままコピーすればよいです）。

テスト1: 正常処理

aws stepfunctions start-execution ^
  --state-machine-arn %SM_ARN% ^
  --name "test-normal-1" ^
  --input "{\"order_id\": \"ORD-001\", \"item_id\": \"item-001\", \"quantity\": 2}" ^
  --region ap-northeast-1

レスポンス例:

{
    "executionArn": "arn:aws:states:ap-northeast-1:123456789012:execution:...:test-normal-1",
    "startDate": "2026-03-01T10:00:00.000000+09:00"
}

実行結果を確認（数秒後）:

aws stepfunctions describe-execution ^
  --execution-arn "上記の executionArn" ^
  --region ap-northeast-1

"status": "SUCCEEDED" と以下のような出力が表示されます。

{
  "order_id": "ORD-001",
  "item_id": "item-001",
  "quantity": 2,
  "amount": 2000,
  "confirmed_at": "2026-03-01T01:00:00.000000+00:00",
  "status": "confirmed"
}

AWSコンソールで実行グラフを確認（任意）:

Step Functions → ステートマシン → step-functions-lambda-stack-order-workflow → 実行一覧 → test-normal-1 をクリックすると、全ステートが緑色になり ProcessInParallel の2ブランチが同時に実行されたことを視覚的に確認できます。

テスト2: 在庫切れエラー（ProcessInParallel Catch の確認）

aws stepfunctions start-execution ^
  --state-machine-arn %SM_ARN% ^
  --name "test-inventory-error" ^
  --input "{\"order_id\": \"ORD-002\", \"item_id\": \"item-999\", \"quantity\": 1}" ^
  --region ap-northeast-1

期待する動作:

1. ValidateOrder → 成功
2. ProcessInParallel → CheckInventory が ValueError（在庫切れ）を発生させる
3. ProcessInParallel の Catch が動作 → HandleError へ遷移
4. 実行ステータス: SUCCEEDED（HandleError が正常完了）

出力例:

{
  "status": "error",
  "error_type": "ValueError",
  "error_cause": "在庫不足: item_id=item-999",
  "original_input": {
    "order_id": "ORD-002",
    "item_id": "item-999",
    "quantity": 1,
    "validated": true
  }
}

実行ステータスが SUCCEEDED になる理由：
HandleError 関数が正常終了（return result）しているため、ステートマシン全体としては「成功」扱いになります。エラーが「処理されずに残った」場合は FAILED になります。

テスト3: 支払い失敗エラー（ProcessInParallel Catch の確認）

aws stepfunctions start-execution ^
  --state-machine-arn %SM_ARN% ^
  --name "test-payment-error" ^
  --input "{\"order_id\": \"ORD-003\", \"item_id\": \"item-001\", \"quantity\": 2, \"fail_payment\": true}" ^
  --region ap-northeast-1

ProcessPayment が RuntimeError を発生させ、同様に HandleError へ遷移します。

テスト4: 検証エラー（ValidateOrder Retry + Catch の確認）

aws stepfunctions start-execution ^
  --state-machine-arn %SM_ARN% ^
  --name "test-validate-error" ^
  --input "{\"item_id\": \"item-001\", \"quantity\": 2}" ^
  --region ap-northeast-1

order_id を省略しているため ValidateOrder が ValueError を発生させます。

Retry の確認（AWSコンソール）:

Step Functions コンソールの実行グラフで ValidateOrder を選択 → 「イベント」タブ で以下の順序を確認します：

TaskStateEntered → TaskScheduled → TaskStarted → TaskFailed
  → TaskScheduled（リトライ1回目）→ TaskStarted → TaskFailed
  → TaskStateExited（Catch 発動）→ HandleError へ

ValidateFunction が合計2回呼ばれてから HandleError へ遷移することが分かります。

Step 8: AWSコンソールで確認（任意）

SAMでデプロイしたリソースはコンソールで確認できます。

• Step Functions: ステートマシン一覧 → step-functions-lambda-stack-order-workflow → 各実行のグラフを確認
• Lambda: Lambda → 関数 → step-functions-lambda-stack-ValidateFunction-XXXX → 「モニタリング」→ 呼び出し回数を確認
• CloudWatch Logs: Lambda → 対象関数 → 「モニタリング」タブ → 「CloudWatch Logs を表示」

Step 9: リソースの削除

課金を止めるために、ハンズオン完了後は必ずリソースを削除してください。

sam delete --stack-name step-functions-lambda-stack --region ap-northeast-1

対話式で確認が入ります。両方 y で進めます。

Are you sure you want to delete the stack step-functions-lambda-stack? [y/N]: y
Are you sure you want to delete the folder step-functions-lambda-stack in S3? [y/N]: y

削除完了の確認

aws cloudformation describe-stacks --stack-name step-functions-lambda-stack --region ap-northeast-1

An error occurred (ValidationError): Stack with id step-functions-lambda-stack does not exist

このメッセージが表示されれば削除完了です。

sam delete で削除されるリソース一覧

コンソール版との大きな違い（SAMのメリット）：
コンソール版では Lambda × 5 / ステートマシン / IAM ロール × 6 / ロググループを個別に削除する必要があります。
SAMでは sam delete 1コマンドで全リソースを一括削除できます。

トラブルシューティング

まとめ

今回のハンズオンで実現したこと：

SAMのメリットを実感できたポイント

• DefinitionSubstitutions により Lambda ARN のコピー貼り付けが不要
• LambdaInvokePolicy × 5 で IAM 権限設定が1行ずつで完結
• sam delete でステートマシン・Lambda 5つ・IAM ロール 6つを一括削除

コンソール版と比較してみる

SAMが裏で何をやっているか、同じ構成をAWSコンソールのみで構築する手順をまとめました。Workflow Studioの新UI（3択モーダル・「{ } コード」タブ）での操作方法や、コンソール版ならではのつまずきポイントを解説しています。

関連記事

Amazon検索[本 AWS 開発]

The post AWSハンズオン - Step Functions + Lambda で受注処理ワークフローをSAMで構築しよう【コンソール版との比較付き】 first appeared on CayTech Lab.

はじめに

「複数のLambda関数を順番に呼び出したい」「エラーが起きたとき自動でリトライして、それでも失敗したら別の処理に切り替えたい」という要件を、AWS Step Functions は視覚的なフロー定義で実現します。

この記事では、AWSコンソールのみを使って、受注処理ワークフロー（注文検証 → 在庫確認・支払い並列処理 → 注文確定）をゼロから構築するハンズオンを紹介します。

入力: 注文データ（order_id / item_id / quantity）
  ↓
[ValidateOrder] 注文検証 ... Task + Retry + Catch
  ↓ 成功
[ProcessInParallel] 並列処理 ... Parallel + Catch
  ├─ [CheckInventory] 在庫確認
  └─ [ProcessPayment] 支払い処理
  ↓ 成功
[ConfirmOrder] 注文確定
  ↓
終了（成功）

[HandleError] エラー処理（Catch 先）
  ↓
終了（エラー通知済み）

このハンズオンで体験できること：

• Step Functions の Task / Parallel / Retry / Catch という基本パターン
• 並列ブランチの結果をリストとして次のステートに渡す仕組み
• Workflow Studio（新UI） の操作方法 — ビジュアルエディタと ASL コードエディタの関係
• ResultPath: "$.error" でエラー情報を元の入力にマージして後続ステートに渡すテクニック

この記事は SAM版ハンズオン の比較記事です。
コンソール操作でStep Functionsの概念を視覚的に学び、SAMと何が違うのかを比較したい方向けです。

Amazon検索[本 AWS 開発]

Step Functions 新UIで戸惑いやすいポイント（先読み）

操作を始める前に、2026年時点の新UIと旧UIの違いを把握しておきましょう。

最大のハマりポイント：
「テンプレートを選択」を押してしまうと36個のテンプレートギャラリーが開きます。今回の目的には 「自分で作成する」 を選ぶ必要があります。これを知らずに迷う人が多いポイントです。

キーワード解説

前提条件

今回はほぼコンソール操作のみで完結します。

使用するAWSサービス

全体の作業順序

① Lambda 関数を5つ作成する
      ↓（各関数の ARN が必要）
② Step Functions ステートマシンを作成する（新UI対応）
      ↓
③ 動作テスト（正常処理 / エラー処理）
      ↓
④ リソースの削除

① Lambda 関数を5つ作成する

共通手順

AWSコンソール → Lambda → 「関数の作成」

各関数でコードを貼り付けたあと、必ず 「Deploy」 ボタンを押してコードを保存します。

1-1. ValidateFunction（注文検証）

関数名: ValidateFunction

コードエディタで lambda_function.py を開き、既存の内容を全て置き換えて以下を貼り付ける。

import json


def lambda_handler(event, context):
    order_id = event.get("order_id")
    item_id = event.get("item_id")
    quantity = event.get("quantity", 0)

    if not order_id:
        raise ValueError("order_id が指定されていません")
    if not item_id:
        raise ValueError("item_id が指定されていません")
    if not isinstance(quantity, int) or quantity <= 0:
        raise ValueError(f"quantity は正の整数である必要があります: {quantity}")

    result = {
        **event,          # 元の入力フィールドをすべて引き継ぐ（テスト用フラグを後続ステートに渡すため）
        "validated": True,
    }
    print(json.dumps({"step": "validate", **result}, ensure_ascii=False))
    return result

ARN を控えておく: 関数ページ右上の「関数の ARN」をコピー（例: arn:aws:lambda:ap-northeast-1:123456789012:function:ValidateFunction）

1-2. InventoryFunction（在庫確認）

関数名: InventoryFunction

import json


def lambda_handler(event, context):
    order_id = event.get("order_id")
    item_id = event.get("item_id")
    quantity = event.get("quantity", 1)

    if item_id == "item-999":
        raise ValueError(f"在庫不足: item_id={item_id}")

    result = {
        "order_id": order_id,
        "item_id": item_id,
        "quantity": quantity,
        "stock_available": True,
    }
    print(json.dumps({"step": "inventory", **result}, ensure_ascii=False))
    return result

ARN を控えておく

1-3. PaymentFunction（支払い処理）

関数名: PaymentFunction

import json


def lambda_handler(event, context):
    order_id = event.get("order_id")
    quantity = event.get("quantity", 1)

    # エラーテスト用: fail_payment=True の場合は例外発生
    if event.get("fail_payment"):
        raise RuntimeError(f"支払い処理に失敗: order_id={order_id}")

    amount = quantity * 1000  # 1個 1,000円

    result = {
        "order_id": order_id,
        "amount": amount,
        "payment_status": "completed",
    }
    print(json.dumps({"step": "payment", **result}, ensure_ascii=False))
    return result

ARN を控えておく

1-4. ConfirmFunction（注文確定）

関数名: ConfirmFunction

import json
import datetime


def lambda_handler(event, context):
    # Parallel ステートの後に呼ばれるため、event はリスト形式
    #   event[0]: CheckInventory（在庫確認）の結果
    #   event[1]: ProcessPayment（支払い処理）の結果
    inventory_result = event[0]
    payment_result = event[1]

    order_id = inventory_result.get("order_id")
    now = datetime.datetime.now(datetime.timezone.utc)

    result = {
        "order_id": order_id,
        "item_id": inventory_result.get("item_id"),
        "quantity": inventory_result.get("quantity"),
        "amount": payment_result.get("amount"),
        "confirmed_at": now.isoformat(),
        "status": "confirmed",
    }
    print(json.dumps({"step": "confirm", **result}, ensure_ascii=False))
    return result

ARN を控えておく

Parallel ステート後の event がリストになる理由：
ProcessInParallel の各ブランチの出力が配列でまとめられて次のステートに渡されます。event[0] が在庫確認の結果、event[1] が支払い処理の結果です。この仕様を知らないと list indices must be integers エラーで詰まります。

1-5. ErrorHandlerFunction（エラー処理）

関数名: ErrorHandlerFunction

import json


def lambda_handler(event, context):
    # ResultPath: "$.error" により、エラー情報が元の入力に付加されて渡される
    error_info = event.get("error", {})
    original_input = {k: v for k, v in event.items() if k != "error"}

    result = {
        "status": "error",
        "error_type": error_info.get("Error", "Unknown"),
        "error_cause": error_info.get("Cause", ""),
        "original_input": original_input,
    }
    print(json.dumps({"step": "error_handler", **result}, ensure_ascii=False))
    return result

ARN を控えておく

② Step Functions ステートマシンを作成する

AWSコンソール → Step Functions → 「ステートマシンを作成」

2-1. 作成方法の選択（新UI：3択モーダル）

「ステートマシンを作成」ボタンを押すと 3択のモーダル が表示されます。

「自分で作成する」 をクリックします。

「テンプレートを選択」を押してしまった場合：
テンプレートギャラリーが開きます。左上の「✕」で閉じて、改めてモーダルから「自分で作成する」を選んでください。

2-2. 名前とタイプの設定（モーダル）

「自分で作成する」をクリックすると Workflow Studio が開き、同時に設定モーダルが表示されます。

「続行」をクリックするとモーダルが閉じ、Workflow Studio の編集画面に切り替わります。

標準（Standard）と Express の違い：
標準タイプは「正確に1回実行」「最大1年の実行時間」「実行履歴をコンソールで確認可能」が特徴です。受注処理のような確実な実行が必要なユースケースに適しています。

2-3. ASL の入力（「{ } コード」タブ）

Workflow Studio の画面上部にある 「{ } コード」 タブをクリックしてコードエディタを表示します。

既存の内容を全て削除し、以下の JSON を貼り付けます。

【重要】 REPLACE_WITH_ARN_ValidateFunction などのプレースホルダーを、① で控えた実際の Lambda ARN に置き換えること。

{
  "Comment": "受注処理ワークフロー（検証 → 並列処理 → 確定）",
  "StartAt": "ValidateOrder",
  "States": {
    "ValidateOrder": {
      "Type": "Task",
      "Resource": "REPLACE_WITH_ARN_ValidateFunction",
      "Next": "ProcessInParallel",
      "Retry": [
        {
          "ErrorEquals": ["States.ALL"],
          "IntervalSeconds": 2,
          "MaxAttempts": 1,
          "BackoffRate": 2.0
        }
      ],
      "Catch": [
        {
          "ErrorEquals": ["States.ALL"],
          "Next": "HandleError",
          "ResultPath": "$.error"
        }
      ]
    },
    "ProcessInParallel": {
      "Type": "Parallel",
      "Branches": [
        {
          "StartAt": "CheckInventory",
          "States": {
            "CheckInventory": {
              "Type": "Task",
              "Resource": "REPLACE_WITH_ARN_InventoryFunction",
              "End": true
            }
          }
        },
        {
          "StartAt": "ProcessPayment",
          "States": {
            "ProcessPayment": {
              "Type": "Task",
              "Resource": "REPLACE_WITH_ARN_PaymentFunction",
              "End": true
            }
          }
        }
      ],
      "Next": "ConfirmOrder",
      "Catch": [
        {
          "ErrorEquals": ["States.ALL"],
          "Next": "HandleError",
          "ResultPath": "$.error"
        }
      ]
    },
    "ConfirmOrder": {
      "Type": "Task",
      "Resource": "REPLACE_WITH_ARN_ConfirmFunction",
      "End": true
    },
    "HandleError": {
      "Type": "Task",
      "Resource": "REPLACE_WITH_ARN_ErrorHandlerFunction",
      "End": true
    }
  }
}

貼り付けると 「フロー」タブ に切り替えると、フロー図が自動生成されます。ASL を正しく記述できているかを視覚的に確認できます。

2-4. 実行ロールの確認と作成（「設定」タブ）

画面上部の 「設定」 タブをクリックして実行ロールを確認します。

「新しいロールを作成」を選ぶと、以下のような青いボックスが表示されます。

実行ロールは、完全な許可で作成されます。StepFunctions-OrderWorkflow-role-XXXX という名前の新しい実行ロールが作成されます。ステートマシンで指定されたアクションに必要なすべての許可が自動生成されます。

「自動生成された許可を確認」を展開すると lambda:Invoke が含まれていることを確認できます。

右上の 「作成」 ボタンをクリックします。

IAMロールの自動作成について：
ASL 定義に記述した Lambda ARN に対して lambda:Invoke 権限を持つロールが自動的に作成されます。SAM版では LambdaInvokePolicy ポリシーでこれを明示的に定義しています。

③ 動作テスト

Step Functions → OrderWorkflow → 「実行を開始」

テスト1: 正常処理

入力データ:

{
  "order_id": "ORD-001",
  "item_id": "item-001",
  "quantity": 2
}

「実行を開始」をクリックします。

実行グラフで確認:

• 全ステートが緑色になることを確認する
• ProcessInParallel の2つのブランチが同時に緑になることを確認する（並列処理の視覚化）

出力を確認:

実行完了後、「出力」タブで以下のような JSON が表示されます。

{
  "order_id": "ORD-001",
  "item_id": "item-001",
  "quantity": 2,
  "amount": 2000,
  "confirmed_at": "2026-03-01T10:00:00.000000+00:00",
  "status": "confirmed"
}

テスト2: 在庫切れエラー（Parallel Catch の確認）

入力データ:

{
  "order_id": "ORD-002",
  "item_id": "item-999",
  "quantity": 1
}

期待する動作:

1. ValidateOrder → 成功
2. ProcessInParallel → CheckInventory が ValueError を発生させる
3. ProcessInParallel の Catch が動作 → HandleError へ遷移
4. HandleError → 成功（エラー情報をログに記録して終了）

実行グラフで確認:

• CheckInventory が赤くなる
• ProcessInParallel から HandleError へ遷移するパスが強調される

出力を確認:

{
  "status": "error",
  "error_type": "ValueError",
  "error_cause": "在庫不足: item_id=item-999",
  "original_input": {
    "order_id": "ORD-002",
    "item_id": "item-999",
    "quantity": 1,
    "validated": true
  }
}

テスト3: 支払い失敗エラー（Parallel Catch の確認）

入力データ:

{
  "order_id": "ORD-003",
  "item_id": "item-001",
  "quantity": 2,
  "fail_payment": true
}

期待する動作:

1. ValidateOrder → 成功
2. ProcessInParallel → ProcessPayment が RuntimeError を発生させる
3. ProcessInParallel の Catch が動作 → HandleError へ遷移

テスト4: 検証エラー（ValidateOrder Retry + Catch の確認）

入力データ（order_id を省略）:

{
  "item_id": "item-001",
  "quantity": 2
}

期待する動作:

1. ValidateOrder → ValueError 発生
2. Retry: IntervalSeconds: 2 で2秒後に自動リトライ（合計2回試行）
3. 2回とも失敗 → Catch が動作 → HandleError へ遷移

Retry の確認方法:

実行グラフで ValidateOrder を選択 → 「イベント」タブ で以下の順序を確認します：

TaskStateEntered → TaskScheduled → TaskStarted → TaskFailed
  → TaskScheduled（リトライ1回目）→ TaskStarted → TaskFailed
  → TaskStateExited（Catch 発動）→ HandleError へ

ValidateFunction が合計2回呼ばれていることが分かります。

④ リソースの削除

課金を止めるために、ハンズオン完了後は必ずリソースを削除してください。

1. ステートマシンを削除する

Step Functions → OrderWorkflow → 「削除」→ 確認テキストを入力 → 「削除」

削除後、ステータスが「削除中」に変わります。以下のようなメッセージが表示されます：

ステートマシンに削除のマークが付けられました。すべての実行が停止されると削除されます。

これは正常な動作です。実行中のワークフローがすべて終了するまで完全削除を待つ仕様のため、実行中のものがなければ数秒〜数十秒でリストから消えます。ページをリロードして確認します。

2. Lambda 関数を5つ削除する

Lambda → 関数一覧 → 各関数を選択 → 「アクション」→「削除」

削除対象:

• ValidateFunction
• InventoryFunction
• PaymentFunction
• ConfirmFunction
• ErrorHandlerFunction

3. IAM ロールを削除する（任意）

Step Functions の実行ロール（StepFunctions-OrderWorkflow-role-XXXX）と、Lambda 関数のロール（ValidateFunction-role-XXXX など5つ）を削除します。

IAM → ロール → 各ロールを検索して削除

4. CloudWatch Logs のロググループを削除する（任意）

CloudWatch → ロググループ → 各 Lambda の /aws/lambda/関数名 を削除

SAMとの対比

トラブルシューティング

まとめ

今回のハンズオンで体験できたこと：

コンソール版とSAM版を比較してみる

コンソールでStep Functionsの概念を理解したら、SAMで同じ構成をコードで定義することで「SAMが何を自動化しているか」が明確になります。DefinitionSubstitutions による ARN の自動差し込みや、LambdaInvokePolicy によるワンライン権限付与など、コンソールでの手動操作がコードに対応しています。

関連記事

Amazon検索[本 AWS 開発]

The post AWSコンソールだけでStep Functions + Lambdaワークフローを構築する手順【SAM版との比較付き / 新UI対応】 first appeared on CayTech Lab.