はじめに

「ログインしたユーザーだけが使えるAPIを作りたい」——そんな要件を、Amazon Cognito + API Gateway + Lambda はサーバー側の認証コードをほぼ書かずに実現します。

この記事では、AWSコンソールのみを使って、以下の構成の認証付き REST API をゼロから構築するハンズオンを紹介します。

クライアント（curl）
  │
  ├─ GET /hello  → 認証不要 → Lambda → 200 OK
  │
  └─ GET /profile
        ├─ Authorizationヘッダーなし → API Gateway が 401 を返す（Lambda は呼ばれない）
        └─ Authorization: <IDトークン>
              → Cognito Authorizer が JWT を検証（Lambda 不要）
              → Lambda → email / sub を返す → 200 OK

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

• Amazon Cognito User Pool によるユーザー管理と JWT 発行
• API Gateway の Cognito Authorizer を使ったエンドポイントごとの認証制御
• Lambda 側で認証コードを書かずに claims（ユーザー情報）を取得するパターン
• 新UI対応 — Cognito コンソールの大幅変更点と、操作でハマりやすいポイント

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

Amazon検索[本 AWS 開発]

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

操作を始める前に、2026年時点の新UIで戸惑いやすい変更点を把握しておきましょう。

最大のハマりポイント（クライアントシークレット）：
新UIの「アプリケーションを作成」で「従来のウェブアプリケーション」を選ぶと、クライアントシークレットが自動で付与されます。シークレットありのクライアントで initiate-auth を実行すると SECRET_HASH was not received エラーが出て詰まります。
このハンズオンでは②の手順でシークレットなしのクライアントを別途作成します。

キーワード解説

前提条件

AWS CLI がない場合は、テスト操作に AWSコンソールの CloudShell を代用できます（後述）。

使用するAWSサービス

全体の作業順序

① Cognito User Pool を作成する（新UI対応）
      ↓
② テスト用アプリクライアントを作成する（シークレットなし）
      ↓
③ Lambda 関数を作成する
      ↓
④ API Gateway REST API を作成する
  （/hello・/profile エンドポイント + Cognito Authorizer 設定）
      ↓
⑤ テストユーザーを作成する
      ↓
⑥ 動作テスト（401確認 → JWTトークン取得 → 認証成功）
      ↓
⑦ リソースの削除

① Cognito User Pool を作成する

AWSコンソール → Cognito → 「アプリケーションを作成」

新UIの注意：
旧UIにあった「ユーザープールを作成」ボタンは廃止されています。現在は「アプリケーションを作成」からウィザードで User Pool とクライアントをまとめて作成します。

1-1. アプリケーションを定義する

1-2. オプションを設定する

サインイン識別子は作成後に変更不可。 「メールアドレス」のみ選択しておくことを推奨します。

1-3. リターン URL（スキップ）

「リターン URL を追加」は入力不要（今回はマネージドログインページを使わないため）。

画面下部の「ユーザーディレクトリを作成する」をクリック。

控えておく情報

作成後、User Pool の概要ページが開きます。

• ユーザープール ID（例: ap-northeast-1_XXXXXXXX）
  → 概要ページの「ユーザープール情報」欄に表示
• クライアント ID（例: XXXXXXXXXXXXXXXXXXXXXXXXXX）
  → 左サイドバー「アプリケーション」→「アプリケーションクライアント」→ MyWebApp をクリック → 「クライアント ID」欄

注意： 概要ページの「レコメンデーション」欄にも MyWebApp のリンクが表示されますが、これは Quick Setup ガイドへの誘導です。クライアント ID は左サイドバーから辿ってください。

User Pool 名について：
新UIでは、アプリ名の前に User pool - が自動で付きます（例: User pool - MyWebApp）。以降の手順では「作成した User Pool」と表記します。

② テスト用アプリクライアントを作成する

新UIの「アプリケーションを作成」で自動作成された MyWebApp クライアントにはクライアントシークレットが自動付与されています。シークレットありのクライアントで CLI から initiate-auth を実行すると SECRET_HASH was not received エラーが出ます。

そのため、シークレットなし・ALLOW_USER_PASSWORD_AUTH 有効の新しいクライアントを別途作成します。

Cognito → 作成した User Pool → 左サイドバー「アプリケーション」→「アプリケーションクライアント」→「アプリケーションクライアントを作成」

2-1. アプリケーションを定義する

「SPA」を選ぶ理由：
新UIでは「従来のウェブアプリケーション」を選ぶとクライアントシークレットが必須になります。「SPA」を選ぶとシークレットなしで作成できます。CLI テスト目的ではこちらを使います。

2-2. リターン URL（スキップ）

入力不要。

2-3. Client secret configuration

SPA を選択した場合、この欄は表示されません（シークレットなしで自動確定）。

「アプリケーションクライアントを作成」をクリック。

2-4. 認証フローを確認する

作成後、MyWebAppClient をクリックして詳細画面を開きます。

「認証フロー」セクションに ALLOW_USER_PASSWORD_AUTH が含まれていることを確認します。

含まれていない場合は「編集」→「ALLOW_USER_PASSWORD_AUTH」にチェック → 「変更を保存」。

ALLOW_USER_PASSWORD_AUTH とは：
CLI から username と password を直接指定して認証する「ユーザーパスワード認証」フローです。テスト用に有効化します（本番環境では SRP フローが推奨）。

控えておく情報（更新）：

• クライアント ID → 新しく作成した MyWebAppClient のクライアント ID を使う（① の MyWebApp のクライアント ID は使わない）

③ Lambda 関数を作成する

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

「関数の作成」をクリック。

コードの入力

関数ページ → 「コード」タブ → lambda_function.py を開いて既存の内容を全て置き換えて以下を貼り付けます。

import json


def lambda_handler(event, context):
    resource = event.get("resource", "/")  # API Gateway プロキシ統合: リクエストパスが "resource" に入る

    if resource == "/hello":
        return {
            "statusCode": 200,
            "headers": {"Content-Type": "application/json"},
            "body": json.dumps({"message": "Hello! This is a public endpoint."}),
        }

    if resource == "/profile":
        # event["requestContext"]["authorizer"]["claims"] に JWT ペイロードが格納される
        claims = (
            event.get("requestContext", {})
            .get("authorizer", {})
            .get("claims", {})
        )
        return {
            "statusCode": 200,
            "headers": {"Content-Type": "application/json"},
            "body": json.dumps(
                {
                    "message": "認証成功",
                    "email": claims.get("email"),
                    "sub": claims.get("sub"),          # Cognito が生成したユーザーの一意 ID
                    "token_use": claims.get("token_use"),  # "id" が返る（IDトークンを使っているため）
                },
                ensure_ascii=False,
            ),
        }

    return {
        "statusCode": 404,
        "headers": {"Content-Type": "application/json"},
        "body": json.dumps({"message": "Not Found"}),
    }

「Deploy」ボタンをクリックしてコードを保存します。

Lambda 側で認証コードが不要な理由：
API Gateway の Cognito Authorizer が IDトークン（JWT）の検証をすべて担っています。Lambda が呼ばれた時点では認証済みであることが保証されており、検証済みの claims だけを受け取って使えばよい設計です。

④ API Gateway REST API を作成する

AWSコンソール → API Gateway → 「APIを作成」

4-1. API タイプの選択

「REST API」の「構築」をクリック。

「APIを作成」をクリック。

4-2. リソース /hello を作成する

左のリソースツリーで /（ルート）を選択 → 「リソースを作成」ボタンをクリック

新UIの注意点：
「リソースパス」はリソースを作成する親パスの選択（/ = ルート配下という意味）です。/hello と入力する欄ではありません。「リソース名」に hello と入力するだけで OK です。

「リソースを作成」をクリック。

/hello を選択した状態で → 「メソッドを作成」→ メソッドタイプ GET を選択

「保存」→「OK」（Lambda 呼び出し権限の追加確認）。

4-3. リソース /profile を作成する

左のリソースツリーで /（ルート）を選択 → 「リソースを作成」

「リソースを作成」をクリック。

/profile を選択した状態で → 「メソッドを作成」→ メソッドタイプ GET を選択

「保存」をクリック。

4-4. Cognito Authorizer を作成する

左側メニューの「オーソライザー」→「オーソライザーを作成」

新UIの注意点：
「トークンのソース」はデフォルトで空欄になっています。Authorization と入力しないと動作しません。入力を忘れると全リクエストが 401 になります。

「オーソライザーを作成」をクリック。

動作確認：

「オーソライザーのテスト」→ テスト用トークン欄に適当な文字を入力 → 「テスト」→ 401 が返れば正常（正しいトークンがないため 401 が正解）。

4-5. /profile GET メソッドに Authorizer を設定する

左のリソースツリーで /profile → GET を選択 → 「メソッドリクエストの設定」セクションの「編集」ボタンをクリック

「認可」ドロップダウンを開き、Cognito ユーザープールオーソライザー の配下にある CognitoAuthorizer を選択 → 「保存」

新UIの注意点：
選択肢は なし / AWS IAM / Cognito ユーザープールオーソライザー（カテゴリ）→ CognitoAuthorizer の階層構造になっています。
CognitoAuthorizer はカテゴリ名ではなく、その下にインデントされた項目を選んでください。

ポイント：
/hello GET には Authorizer を設定しない（認証不要）。
/profile GET にのみ CognitoAuthorizer を設定することで、エンドポイントごとに認証要件を分けます。

4-6. API をデプロイする

「アクション」→「API のデプロイ」

「デプロイ」をクリック。

控えておく情報：

「Prod ステージエディター」に表示される URL の呼び出し（例: https://XXXXXXXXXX.execute-api.ap-northeast-1.amazonaws.com/Prod）をコピーします。

⑤ テストユーザーを作成する

Cognito → 作成した User Pool → 左サイドバー「ユーザー管理」→「ユーザー」→「ユーザーを作成」

パスワードポリシー（新UIのデフォルト）：
最小8文字 / 数字・小文字・大文字・特殊文字をそれぞれ1文字以上含むこと。
TestPass1 は特殊文字がないため不可。TestPass1! を使ってください。

「ユーザーを作成」をクリック。

ユーザーの「確認ステータス」列に 「パスワードを強制的に変更」 と表示されます（= FORCE_CHANGE_PASSWORD 状態）。
この状態で initiate-auth を実行してもトークンが返らず NEW_PASSWORD_REQUIRED チャレンジが返されます。
次の CLI コマンドで永続パスワードを設定して「確認済み」（CONFIRMED）に変更します。

CLI で永続パスワードを設定する：

方法 A: CloudShell（コンソール版ハンズオンにおすすめ）

AWSコンソール画面下部の「CloudShell」をクリックして起動します。コンソールと同じ認証情報が自動で使われるため追加設定は不要。

aws cognito-idp admin-set-user-password \
  --user-pool-id ap-northeast-1_XXXXXXXX \
  --username test@example.com \
  --password 'TestPass1!' \
  --permanent \
  --region ap-northeast-1

CloudShell は Linux シェルのため \ で改行します。! を含むパスワードはシングルクォート '...' で囲んでください（ダブルクォートだと bash がエラーになる場合があります）。

方法 B: ローカルの AWS CLI（コマンドプロンプト）

aws cognito-idp admin-set-user-password ^
  --user-pool-id ap-northeast-1_XXXXXXXX ^
  --username test@example.com ^
  --password TestPass1! ^
  --permanent ^
  --region ap-northeast-1

ap-northeast-1_XXXXXXXX を ① で控えたユーザープール ID に置き換えてください。

コマンドが出力なしで返れば成功です。コンソールでユーザーの「確認ステータス」が**「確認済み」**に変わったことを確認してください。

⑥ 動作テスト

テスト1: 公開エンドポイント（/hello）→ 200

curl https://XXXXXXXXXX.execute-api.ap-northeast-1.amazonaws.com/Prod/hello

期待するレスポンス:

{"message": "Hello! This is a public endpoint."}

テスト2: 未認証でプライベートエンドポイント（/profile）→ 401

curl https://XXXXXXXXXX.execute-api.ap-northeast-1.amazonaws.com/Prod/profile

期待するレスポンス（API Gateway が返す。Lambda は呼ばれていない）:

{"message": "Unauthorized"}

テスト3: IDトークンを取得する

aws cognito-idp initiate-auth ^
  --auth-flow USER_PASSWORD_AUTH ^
  --auth-parameters "USERNAME=test@example.com,PASSWORD=TestPass1!" ^
  --client-id XXXXXXXXXXXXXXXXXXXXXXXXXX ^
  --region ap-northeast-1

XXXXXXXXXXXXXXXXXXXXXXXXXX を ② で控えた MyWebAppClient のクライアント ID に置き換えてください（① の MyWebApp のクライアント ID ではありません）。

レスポンス例（抜粋）:

{
    "AuthenticationResult": {
        "AccessToken": "eyJra...",
        "ExpiresIn": 3600,
        "TokenType": "Bearer",
        "RefreshToken": "eyJjb...",
        "IdToken": "eyJra..."
    }
}

IdToken の値をコピーしておきます（次のテストで使用）。

IdToken と AccessToken の違い：

トークン	用途	含まれる情報
IdToken	ユーザー認証（今回使用）	email / sub など
AccessToken	Cognito API へのアクセス	sub / scope など

API Gateway の Cognito Authorizer に渡すのは IdToken。AccessToken を渡しても 403 になります。

テスト4: 認証ありでプライベートエンドポイント（/profile）→ 200

IdToken は非常に長いため、変数に格納してから実行します。

方法 A: CloudShell（おすすめ）

TOKEN="eyJra...（IdToken全体を貼り付ける）"
curl -H "Authorization: $TOKEN" https://XXXXXXXXXX.execute-api.ap-northeast-1.amazonaws.com/Prod/profile

方法 B: Windows CMD（変数使用）

set TOKEN=eyJra...（IdToken全体を貼り付ける）
curl -H "Authorization: %TOKEN%" https://XXXXXXXXXX.execute-api.ap-northeast-1.amazonaws.com/Prod/profile

重要： CMD では変数展開に %TOKEN% を使います。$TOKEN（bash 構文）を CMD で使うと文字列 $TOKEN がそのまま送られ 401 になります。
また Bearer プレフィックスは不要です。raw JWT をそのまま Authorization ヘッダーに指定してください。

期待するレスポンス:

{
  "message": "認証成功",
  "email": "test@example.com",
  "sub": "xxxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxxxx",
  "token_use": "id"
}

sub は Cognito が自動生成したユーザーの一意 ID です。
token_use: "id" は IDトークンを使っていることを示します。

⑦ リソースの削除

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

1. API Gateway を削除する

API Gateway → APIs → CognitoSampleApi を選択 → 「アクション」→「APIの削除」

2. Lambda 関数を削除する

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

3. Cognito User Pool を削除する

Cognito → 作成した User Pool → 右上の「ユーザープールを削除」ボタン → ユーザープール名を入力 → 「削除」

ユーザーとアプリクライアントも一緒に削除されます。

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

IAM → ロール → CognitoApiFunction-role-XXXX を検索して削除

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

CloudWatch → ロググループ → /aws/lambda/CognitoApiFunction → 削除

SAMとの対比

トラブルシューティング

まとめ

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

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

コンソールでCognitoとAPI Gatewayの連携を理解したら、SAMで同じ構成をコードで定義することで「SAMが何を自動化しているか」が明確になります。DefaultAuthorizer によるワンライン認証設定や、ALLOW_USER_PASSWORD_AUTH の自動有効化など、コンソールでの手動操作がコードに対応しています。

関連記事

Amazon検索[本 AWS 開発]

The post AWSコンソールだけでCognito + API Gateway + Lambda の認証付きAPIを構築する手順【SAM版との比較付き / 新UI対応】 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.

はじめに

この記事は、SAM版ハンズオン記事の比較版です。

SAM版ではコマンド数本でS3・OAC・CloudFront・バケットポリシーが一括デプロイできましたが、実際にコンソールで操作してみると思わぬハマりポイントがいくつかあります。

特に CloudFront コンソールは 2026年に大きくUIが刷新 され、6ステップのウィザード形式に変わりました。ネット上の古い手順書と画面が全く違って戸惑う人が多いはずです。この記事では 2026年の新UI に対応した手順を詳しく解説します。

この記事を読むとわかること：

• CloudFront 新UI（6ステップウィザード）の各ステップで何を設定するか
• 「Allow private S3 bucket access to CloudFront」チェックボックスで何が自動化されるのか
• 削除時に新登場した「Pricing plan キャンセル」手順（これを知らないと削除できない）
• キャッシュ削除（旧: 「無効化」）の操作と注意点

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

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

「Pricing plan キャンセル」が最大のハマりポイント：
新UIで作成したディストリビューションは「Pricing plan（プライシングプラン）」に加入しています。
削除する前にプランをキャンセルする操作が必要で、しかもキャンセルは月末（翌月1日）に有効になるため、すぐに削除できません。
知らないと「subscribed to a pricing plan」エラーで詰まります（後述）。

Amazon検索[本 AWS 開発]

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

構築するもの

SAM版と全く同じ構成・機能の静的サイトホスティング環境を構築します。

ブラウザ
  ↓ HTTPS（HTTPは自動リダイレクト）
CloudFront（CDN・エッジキャッシュ）
  ↓ OAC（署名付きリクエスト）
S3 バケット（非公開・パブリックアクセスブロック）
  └── index.html / error.html

全体の作業順序

① S3 バケット作成（非公開）
      ↓
② CloudFront ディストリビューション作成（6ステップウィザード）
      ↓（自動でOAC設定・バケットポリシー更新）
③ S3 バケットポリシーの確認（自動設定を確認）
      ↓
④ HTML ファイルをアップロード
      ↓
⑤ CloudFront URL でアクセス確認
      ↓
⑥ キャッシュの動作確認（任意）
⑦ リソースの削除（要注意: 月末まで待機が必要）

順序の理由：
② でCloudFrontディストリビューションを作成する際に「どのS3バケットをオリジンにするか」を指定するため、① でバケットを先に作成しておく必要があります。

① S3 バケット作成

AWSコンソール → S3 → 「バケットを作成」

「バケットを作成」をクリックします。

パブリックアクセスをブロックしたまま使う理由：
従来の静的サイトホスティングではS3バケットを公開する方法もありましたが、現在の推奨は S3を非公開にしてCloudFront OAC経由でのみアクセスさせる構成です。直接S3 URLからのアクセスを防ぎ、CloudFrontのHTTPS・キャッシュ・WAFの恩恵を受けられます。

バケット名のルール：

• グローバルで一意（AWS全体で重複不可・削除後しばらく再利用不可）
• my-cloudfront-website-自分のAWSアカウントID のように末尾にアカウントIDを付けると一意にしやすい
• SAMでは !Sub "${AWS::StackName}-website-${AWS::AccountId}" で自動的に一意化しています

控えておく情報：

• バケット名（例: my-cloudfront-website）

② CloudFront ディストリビューション作成（新UI・6ステップウィザード）

AWSコンソール → CloudFront → 「ディストリビューションを作成」

CloudFrontはグローバルサービスのため、コンソール右上のリージョン表示は「グローバル」になります。
S3バケットのリージョンは東京（ap-northeast-1）のままで問題ありません。

ステップ1: Choose a plan（プランを選択）

「Next」をクリックします。

無料プランの内容（1ヶ月あたり）：

• リクエスト数: 100万（1M）
• データ転送: 100GB
• DDoS保護・グローバルCDN・デフォルトキャッシュルールが含まれる

ハンズオン目的では無料枠で十分です。有料プランは本番サービスで大量トラフィックが想定される場合に選択します。

SAMとの差分： SAM（CloudFormation）で作成したディストリビューションにはPricing planの概念がありません。「月額$0」のプランでも加入状態になるため、削除時にキャンセル手続きが必要になります（後述）。

ステップ2: Get started（基本設定）

「Next」をクリックします。

ステップ3: Specify origin（オリジンの指定）

このステップが最も重要です。S3バケットをオリジンとして設定し、OACを自動構成します。

Origin type セクション：

Origin セクション：

Settings セクション：

「Next」をクリックします。

「Allow private S3 bucket access to CloudFront」チェックボックスの重要性：

これが新UIの最大の改善点です。チェックを入れると：

1. CloudFrontが S3 に安全にアクセスするための OAC（Origin Access Control）を自動作成
2. ディストリビューション作成後に S3バケットポリシーを自動で更新

旧UIでの手順（参考）：

1. CloudFront → OAC を手動で作成
2. ディストリビューション作成時にOACを選択・ARNをコピー
3. S3 → バケットポリシーを手動で編集・貼り付け

新UIではこのすべてがチェック1つで完結します。

SAMとの差分： SAMでは Type: AWS::CloudFront::OriginAccessControl リソースと WebsiteBucketPolicy リソースで同じことを明示的に定義しています。

ステップ4: Enable security（セキュリティ設定）

「Security protections from WAF are included in your plan at no additional charge.」と表示されます。無料プランにWAF保護が含まれており、追加料金は発生しません。

「Next」をクリックします。

「Use monitor mode」について：
チェックを入れると「何がブロックされるかを記録するだけ」のモードになります（実際にはブロックしない）。ハンズオンでは不要なのでチェックせずに進みます。

ステップ5: Review and create（確認と作成）

設定内容を確認して「ディストリビューションを作成」をクリックします。

控えておく情報：

• CloudFront ドメイン名（例: xxxxxxxxxxxx.cloudfront.net）
• ディストリビューション ID（例: EXXXXXXXXXXXXXXXXX）

CloudFrontのデプロイには 5〜15分かかります。
ステータスが「有効」になるまで待ってから次のステップに進んでください。

③ S3 バケットポリシーの確認

新UIでは、ステップ3で「Allow private S3 bucket access to CloudFront」にチェックを入れると、ディストリビューション作成時に S3バケットポリシーが自動で更新されます。

自動設定されたポリシーを確認します。

S3 → my-cloudfront-website → 「アクセス許可」タブ → 「バケットポリシー」

以下のようなポリシーが自動で設定されていることを確認します。

{
    "Version": "2012-10-17",
    "Statement": [
        {
            "Sid": "AllowCloudFrontServicePrincipal",
            "Effect": "Allow",
            "Principal": {
                "Service": "cloudfront.amazonaws.com"
            },
            "Action": "s3:GetObject",
            "Resource": "arn:aws:s3:::my-cloudfront-website/*",
            "Condition": {
                "StringEquals": {
                    "AWS:SourceArn": "arn:aws:cloudfront::123456789012:distribution/EXXXXXXXXXXXXXXXXX"
                }
            }
        }
    ]
}

このポリシーのポイント：

• Principal.Service: cloudfront.amazonaws.com — CloudFrontサービスからのアクセスのみ許可
• Condition.AWS:SourceArn — 特定のディストリビューションからのアクセスのみ許可（他のCloudFrontからはアクセスできない）
• Action: s3:GetObject のみ — 読み取り専用。書き込み・削除は不可

SAMとの差分： SAMでは WebsiteBucketPolicy リソースに上記と同じポリシーを明示的に記述しています。コンソールでは自動設定されますが、SAMを読むとその中身が可視化されます。

④ HTML ファイルをアップロード

アップロードするHTMLファイルの内容を確認しておきます。自分で用意したHTMLがあればそちらを使っても構いません。

index.html（トップページ）

<!DOCTYPE html>
<html lang="ja">
<head>
  <meta charset="UTF-8">
  <meta name="viewport" content="width=device-width, initial-scale=1.0">
  <title>S3 + CloudFront ハンズオン</title>
  <style>
    body {
      font-family: -apple-system, BlinkMacSystemFont, "Segoe UI", sans-serif;
      max-width: 640px;
      margin: 60px auto;
      padding: 20px;
      color: #333;
    }
    h1 { color: #232f3e; }
    .badge {
      background: #ff9900;
      color: white;
      padding: 3px 10px;
      border-radius: 4px;
      font-size: 0.85em;
      font-weight: bold;
    }
    .info {
      background: #f4f6f8;
      border-left: 4px solid #ff9900;
      padding: 12px 16px;
      margin: 20px 0;
      border-radius: 0 4px 4px 0;
    }
  </style>
</head>
<body>
  <h1>デプロイ成功！</h1>
  <p>
    <span class="badge">CloudFront CDN</span> 経由でこのページが配信されています。
  </p>
  <div class="info">
    <strong>このページの配信構成:</strong><br>
    S3 バケット（オリジン） → CloudFront（CDN）→ あなたのブラウザ
  </div>
  <p>S3 + CloudFront による静的サイトホスティングのハンズオンです。</p>
</body>
</html>

error.html（カスタム404ページ）

<!DOCTYPE html>
<html lang="ja">
<head>
  <meta charset="UTF-8">
  <title>404 - ページが見つかりません</title>
  <style>
    body {
      font-family: -apple-system, BlinkMacSystemFont, "Segoe UI", sans-serif;
      max-width: 640px;
      margin: 60px auto;
      padding: 20px;
      color: #333;
      text-align: center;
    }
    h1 { color: #cc0000; }
    a { color: #ff9900; }
  </style>
</head>
<body>
  <h1>404 - ページが見つかりません</h1>
  <p>お探しのページは存在しないか、移動・削除された可能性があります。</p>
  <p><a href="/">トップページへ戻る</a></p>
</body>
</html>

上記2ファイルをS3にアップロードします。

方法A: S3 コンソールからアップロード

S3 → my-cloudfront-website → 「アップロード」

index.html と error.html を選択してアップロードします。

方法B: AWS CLI でアップロード

aws s3 sync C:\my-aws\aws-learning-projects\s3-cloudfront-hosting\website\ ^
  s3://my-cloudfront-website/ ^
  --region ap-northeast-1

⑤ CloudFront URL でアクセス確認

CloudFrontのステータスが「有効」になったらブラウザでアクセスします。

https://xxxxxxxxxxxx.cloudfront.net

期待する表示: index.html の内容が表示される。

HTTP → HTTPS リダイレクトの確認：

http://xxxxxxxxxxxx.cloudfront.net

HTTPでアクセスすると自動的にHTTPSにリダイレクトされることを確認します。

カスタム404ページの確認：

https://xxxxxxxxxxxx.cloudfront.net/notfound

存在しないページにアクセスすると error.html の内容が表示されることを確認します。

⑥ キャッシュの動作確認（任意）

CloudFront CDNの重要な概念「キャッシュ」と「キャッシュ削除（旧: 無効化）」を体験します。

6-1. index.html を更新してアップロード

index.html のテキストを変更して再度アップロードします。

aws s3 cp C:\my-aws\aws-learning-projects\s3-cloudfront-hosting\website\index.html ^
  s3://my-cloudfront-website/index.html ^
  --region ap-northeast-1

ブラウザでCloudFront URLにアクセスしても古いキャッシュが表示される場合があります（TTLが切れるまで）。

6-2. キャッシュを削除する（新UI: 「キャッシュ削除」タブ）

CloudFront → ディストリビューション → 「キャッシュ削除」タブ → 「キャッシュ削除を作成」

「キャッシュ削除を作成」をクリックします。ステータスが「完了」になったら（1〜3分）ブラウザを強制リロード（Ctrl+Shift+R）して確認します。

旧UIとの名称変更：
旧UIでは「無効化（Invalidation）」タブでしたが、新UIでは「キャッシュ削除」に名称変更されました。機能は同じです。

無効化の料金：
毎月最初の1,000パスは無料。それ以降は $0.005/パス。
/* は1パスとしてカウントされるため、ハンズオン程度なら無料枠内です。

⑦ リソースの削除

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

重要: 新UIで作成したディストリビューションの削除手順（旧UIとは異なります）

旧UIでは「無効化 → 削除」の2ステップでしたが、新UIでは以下の手順が必要です：
無効化 → Pricing plan キャンセル → 月末（翌月1日）まで待機 → 削除

月末まで削除できないのは想定外でハマる人が多いポイントです。

1. CloudFront ディストリビューションを無効化する

CloudFront → ディストリビューション → 対象を選択 → 「無効化」ボタン → 確認 → 「無効化」

ステータスが「有効」→「無効」に変わるまで待ちます（5〜15分）。

無効化が完了しないとディストリビューションを削除できません。（削除ボタンがグレーアウトしたまま）

2. Pricing plan（プライシングプラン）をキャンセルする

ステータスが「無効」になったら、プランをキャンセルします。

無効化したディストリビューションをクリック → 「Billing」セクション → 「Manage plan」→「Cancel plan」（プランをキャンセル）→「Cancel plan」ボタン

キャンセルが受け付けられると「無料プランのキャンセルがスケジュールされています。このプランは [月末日] に終了します。」と表示されます。

「この日を過ぎると、すべての使用は従量制料金で課金されます」という警告について：
これは「もし使い続けた場合」の説明です。ディストリビューションは「無効」状態のためリクエストを受け付けず、使用量ゼロ = 課金ゼロです。無効化済みであれば課金されません。

3. 月末を待ってから削除する

プランキャンセルは月末（翌月1日）に有効になります。それまでディストリビューションは削除できません。

月末以降：

ディストリビューションを選択 → 「削除」→ 確認 → 「削除」

キャンセル前に削除しようとすると：
You can't delete this distribution while it's subscribed to a pricing plan.
というエラーが表示されます。その場合は手順2のプランキャンセルを行ってください。

4. S3 バケット内のファイルをすべて削除する

方法A: AWS CLI で一括削除（推奨）

aws s3 rm s3://my-cloudfront-website --recursive --region ap-northeast-1

方法B: S3 コンソールから

S3 → my-cloudfront-website → ファイルをすべて選択 → 「削除」→ 確認テキストを入力 → 「オブジェクトを削除」

5. S3 バケットを削除する

S3 → my-cloudfront-website を選択 → 「削除」→ バケット名を入力 → 「バケットを削除」

6. CloudFront OAC を削除する（任意）

ステップ3で自動作成された OAC は、ディストリビューション削除後も残ります。不要なら手動で削除します。

CloudFront → 左サイドバー「オリジンアクセスコントロール」→ 作成した OAC を選択 → 「削除」

注意： ディストリビューションの「オリジン」タブではなく、左サイドバーの「オリジンアクセスコントロール」から削除します。ディストリビューションが削除済みでないと削除できません。

SAMとの対比まとめ

削除の大きな違い：
コンソール新UIで作成したディストリビューションはPricing planに加入するため、プランキャンセル後に月末まで削除できない制約があります。
SAMで作成したディストリビューションにはPricing planの概念がないため、sam delete で即座に削除手続きが完了します。
これがSAM版の大きなメリットのひとつです。

トラブルシューティング

まとめ

コンソール操作で確認できたこと

今回のコンソール操作で、SAMが自動化していることと、新UI特有のハマりポイントが明確になりました：

どちらを使うべきか

関連記事

• SAM版ハンズオン — コマンド数本でS3 + CloudFront環境を構築

AWSハンズオン - S3 + CloudFrontで静的サイトをCDN配信しよう【SAM版 / Windows対応】

はじめに「ウェブサイトを公開したいけど、サーバーは持ちたくない」「静的なHTMLサイトを世界中から速く見せたい」という要件に、S3 + CloudFront の組み合わせはベストな選択肢のひとつです。この記事では、AWS SAM（Serve...

caymezon.com

2026.02.23

Amazon検索[本 AWS 開発]

The post AWSコンソールだけでS3 + CloudFront静的サイトホスティングを構築する手順【SAM版との比較付き / 新UI対応】 first appeared on CayTech Lab.