はじめに

「S3に画像をアップロードしたら、自動で中身を分析してほしい」——そんな仕組みを、AWSコンソールのみでゼロから構築するハンズオンです。

Amazon Rekognition の DetectLabels API を使うと、画像に写っている物体・シーン・動物などを自動で検出できます。犬の写真をアップロードすれば「Dog（信頼度98%）」「Animal（97%）」といったラベルが返ってきます。

ユーザー
  ↓ JPEG / PNG をアップロード
S3 バケット（UploadBucket）
  ↓ ObjectCreated イベント（自動）
Lambda（DetectFunction）
  ↓ rekognition:DetectLabels（S3Object を指定）
Amazon Rekognition
  ↓ [{"name": "Dog", "confidence": 98.5}, ...] を返す
Lambda
  ↓ print（JSON）
CloudWatch Logs

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

• S3 トリガー — S3 へのアップロードを契機に Lambda を自動起動する仕組み
• Rekognition DetectLabels — 画像内の物体・シーン・動物を検出してラベルと信頼度を返す API
• IAM 権限管理 — Lambda から S3・Rekognition を呼び出すために必要な権限の追加手順
• S3Object 参照 — 画像データを Lambda に転送せず S3 の場所を直接 Rekognition に渡す効率的な方法

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

Amazon検索[本 AWS 開発]

キーワード解説

使用するAWSサービス

全体の作業順序

① S3 バケットを作成する
      ↓
② Lambda 関数を作成する（コード入力・タイムアウト設定）
      ↓
③ Lambda の実行ロールに権限を追加する
  （S3: GetObject / Rekognition: DetectLabels）
      ↓
④ Lambda に S3 トリガーを追加する
      ↓
⑤ 動作テスト（画像をアップロード → ログを確認）
      ↓
⑥ リソースの削除

① S3 バケットを作成する

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

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

控えておく情報:

• バケット名（削除時・IAMポリシー設定時に使用）

バケット名のグローバルユニークについて：
S3 のバケット名は全 AWS アカウントで一意である必要があります。my-rekognition-upload- に自分のアカウントIDや日付を追加すると重複を避けられます。

② Lambda 関数を作成する

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

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

タイムアウトの設定

「設定」タブ → 「一般設定」→「編集」

「保存」をクリック。

タイムアウトを 30 秒にする理由：
Rekognition API の呼び出しには数秒かかることがあります。デフォルト（3秒）では Rekognition のレスポンスを待ちきれずタイムアウトするため、余裕を持って 30 秒に設定します。

コードの入力

「コード」タブ → lambda_function.py を開いて既存の内容を全て置き換える。

import json
import urllib.parse
import boto3

rekognition = boto3.client("rekognition")


def lambda_handler(event, context):
    for record in event["Records"]:
        bucket = record["s3"]["bucket"]["name"]
        key = urllib.parse.unquote_plus(record["s3"]["object"]["key"])

        print(json.dumps({"status": "start", "bucket": bucket, "key": key}))

        response = rekognition.detect_labels(
            Image={
                "S3Object": {
                    "Bucket": bucket,
                    "Name": key,
                }
            },
            MaxLabels=10,
            MinConfidence=70,
        )

        labels = [
            {
                "name": label["Name"],
                "confidence": round(label["Confidence"], 1),
            }
            for label in response["Labels"]
        ]

        result = {
            "bucket": bucket,
            "key": key,
            "label_count": len(labels),
            "labels": labels,
        }
        print(json.dumps(result, ensure_ascii=False))

    return {"processedCount": len(event["Records"])}

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

コードのポイント:

③ Lambda の実行ロールに権限を追加する

デフォルトの実行ロールは CloudWatch Logs への書き込みのみ。
S3 からの読み取りと Rekognition の呼び出し権限を追加する。

Lambda → DetectFunction → 「設定」タブ → 「アクセス権限」→ 実行ロール名のリンクをクリック

（例: DetectFunction-role-XXXX）→ IAM コンソールのロール画面が開く。

3-1. Rekognition 権限を追加する

「許可を追加」→「ポリシーをアタッチ」

検索ボックスに Rekognition と入力 → AmazonRekognitionReadOnlyAccess にチェック → 「許可を追加」。

AmazonRekognitionReadOnlyAccess に含まれる主な権限:

• rekognition:DetectLabels — ラベル検出（今回使用）
• rekognition:DetectFaces — 顔検出
• rekognition:DetectText — テキスト検出

3-2. S3 GetObject 権限を追加する

「許可を追加」→「インラインポリシーを作成」

「JSON」タブを選択して以下を入力する（my-rekognition-upload を ① のバケット名に変更）:

{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Effect": "Allow",
      "Action": "s3:GetObject",
      "Resource": "arn:aws:s3:::my-rekognition-upload/*"
    }
  ]
}

「次へ」→ ポリシー名: S3ReadForRekognition → 「ポリシーを作成」。

なぜ S3 の権限が必要か:
Rekognition に S3Object を指定した場合、Rekognition が Lambda の IAM ロールを借りて
S3 からオブジェクトを取得します。Lambda ロールに s3:GetObject がないと 403 エラーになります。

SAM版では S3ReadPolicy（SAM 組み込みポリシー）が特定バケットのみに s3:GetObject を自動付与します。
コンソール版では手動でインラインポリシーを作成する必要があります。

④ Lambda に S3 トリガーを追加する

Lambda → DetectFunction → 「設定」タブ → 「トリガー」→「トリガーを追加」

「再帰呼び出し」の確認チェックボックスにチェック → 「追加」をクリック。

再帰呼び出しについて：
Lambda の実行結果を同じバケットに書き込む構成にすると、S3 イベントが再発火して無限ループになります。
今回は S3 への書き込みを行わないため問題ありません。

⑤ 動作テスト

テスト用画像の準備

任意の JPEG または PNG 画像を用意する（例: 犬・猫・風景など）。
ファイルサイズは 15MB 以下 であることを確認する。

画像をアップロードする

方法 A: S3 コンソール

S3 → my-rekognition-upload → 「アップロード」→ ファイルをドラッグ＆ドロップ → 「アップロード」

方法 B: AWS CLI

aws s3 cp "C:\Users\yourname\Pictures\dog.jpg" s3://my-rekognition-upload/ --region ap-northeast-1

CloudWatch Logs でラベル検出結果を確認する

Lambda → DetectFunction → 「モニタリング」タブ → 「CloudWatch Logs を表示」

最新のロットストリームを開いて以下のような出力を確認する。

{"status": "start", "bucket": "my-rekognition-upload", "key": "dog.jpg"}
{
  "bucket": "my-rekognition-upload",
  "key": "dog.jpg",
  "label_count": 8,
  "labels": [
    {"name": "Dog", "confidence": 98.5},
    {"name": "Pet", "confidence": 98.5},
    {"name": "Animal", "confidence": 98.5},
    {"name": "Canine", "confidence": 98.5},
    {"name": "Mammal", "confidence": 97.2},
    {"name": "Golden Retriever", "confidence": 85.3},
    {"name": "Grass", "confidence": 76.1},
    {"name": "Outdoors", "confidence": 71.4}
  ]
}
{"processedCount": 1}

MinConfidence: 70 の効果：
信頼度 70% 未満のラベルは結果に含まれません。
全ラベルを確認したい場合は MinConfidence=0 に変更して「Deploy」する。

複数枚でテストする

aws s3 cp "C:\Users\yourname\Pictures\cat.jpg"  s3://my-rekognition-upload/ --region ap-northeast-1
aws s3 cp "C:\Users\yourname\Pictures\city.jpg" s3://my-rekognition-upload/ --region ap-northeast-1

各ファイルのアップロードごとに Lambda が起動し、それぞれのラベル検出結果がログに記録される。

無料枠の管理：
AWS コンソール → Billing → 無料利用枠 → 「Amazon Rekognition」で当月の使用枚数を確認できます。
月5,000枚まで無料のため、学習目的のハンズオンでは通常課金されません。

⑥ リソースの削除

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

1. S3 バケットのオブジェクトを全て削除する

aws s3 rm s3://my-rekognition-upload --recursive --region ap-northeast-1

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

S3 → my-rekognition-upload → 「削除」→ バケット名を入力 → 「削除」

3. Lambda のトリガーを削除する

Lambda → DetectFunction → 「設定」→「トリガー」→ S3 トリガーを選択 → 「削除」

4. Lambda 関数を削除する

Lambda → 関数 → DetectFunction → 「アクション」→「削除」

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

IAM → ロール → DetectFunction-role-XXXX を削除

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

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

SAM版との大きな違い（SAMのメリット）：
SAM版では sam delete 1コマンドで上記すべてのリソースを一括削除できます。

SAMとの対比

コンソール版のつまずきポイント：
AccessDeniedException が出た場合、S3 の GetObject 権限（インラインポリシー）と Rekognition の DetectLabels 権限（AmazonRekognitionReadOnlyAccess）の両方が揃っているか確認しましょう。どちらか一方が欠けていてもエラーになります。

トラブルシューティング

まとめ

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

コンソール版で実感できたポイント

• S3 → Lambda → Rekognition という3つのサービスのデータの流れが視覚的に理解できる
• 実行ロールに必要な権限を1つずつ追加することで、IAM の仕組みが身につく
• リソースを個別に作成・削除することで、各サービスの独立性と依存関係が明確になる

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

コンソールで S3・Lambda・Rekognition の連携を理解したら、SAM で同じ構成をコードで定義することで「SAM が何を自動化しているか」が明確になります。S3ReadPolicy や RekognitionDetectOnlyPolicy による1行での権限付与など、コンソールでの手動操作がコードに対応しています。

関連記事

Amazon検索[本 AWS 開発]

The post AWSコンソールだけで画像認識パイプラインを構築する手順【S3 + Lambda + Rekognition / SAM版との比較付き】 first appeared on CayTech Lab.

はじめに

「1回メッセージを送るだけで、複数のシステムに同時に通知したい」——そんな要件を実現する設計パターンが Pub/Sub（パブリッシュ・サブスクライブ） と ファンアウト です。

この記事では、AWSコンソールのみを使って、SNS + SQS + Lambda による通知システムをゼロから構築するハンズオンを紹介します。

Publisher（aws sns publish）
  ↓ メッセージを1回発行するだけ
SNS Topic（NotificationTopic）
  │
  ├─ サブスクリプション（フィルターなし）
  │    → LogQueue → LogFunction → CloudWatch Logs（全メッセージを記録）
  │
  └─ サブスクリプション（level=warning/critical のみ）
       → AlertQueue → AlertFunction → CloudWatch Logs（アラート処理）
                          ↓ 処理失敗（3回）
                        AlertDLQ

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

• Pub/Sub パターン — Publisher と Subscriber が疎結合で通信する仕組み
• ファンアウト — 1回の publish で複数の Lambda が並行して動作する体験
• SNS フィルターポリシー — メッセージ属性で配信先を絞り込む設定
• DLQ（デッドレターキュー） — 処理失敗メッセージの退避先を実際に確認

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

Amazon検索[本 AWS 開発]

キーワード解説

使用するAWSサービス

全体の作業順序

① SNS Topic を作成する
      ↓
② SQS キューを3つ作成する（AlertDLQ / LogQueue / AlertQueue）
      ↓
③ SNS → SQS サブスクリプションを2つ作成する
  （LogQueue: フィルターなし / AlertQueue: フィルターあり）
      ↓
④ Lambda 関数を2つ作成する
      ↓
⑤ SQS トリガーを各 Lambda に追加する
      ↓
⑥ 動作テスト（3パターン）
      ↓
⑦ リソースの削除

AlertDLQ を先に作成する理由：
AlertQueue の作成時に DLQ として AlertDLQ の ARN を指定するため、AlertDLQ を先に作る必要があります。

① SNS Topic を作成する

AWSコンソール → SNS → 「トピック」→「トピックを作成」

その他の設定はデフォルトのまま。「トピックを作成」をクリック。

控えておく情報:

• トピック ARN（例: arn:aws:sns:ap-northeast-1:123456789012:NotificationTopic）

スタンダードとFIFOの違い：
スタンダードは順序保証なし・高スループット。FIFO は順序保証あり・1回限りの配信が必要な場合に使用します。今回のログ/アラート通知にはスタンダードが適しています。

② SQS キューを3つ作成する

AWSコンソール → SQS → 「キューを作成」

2-1. AlertDLQ（デッドレターキュー）を先に作成する

「キューを作成」をクリック。

控えておく情報:

• AlertDLQ の ARN（例: arn:aws:sqs:ap-northeast-1:123456789012:AlertDLQ）

2-2. LogQueue を作成する（フィルターなし・全メッセージ用）

「キューを作成」をクリック。

可視性タイムアウトを 180 秒にする理由：
Lambda のデフォルトタイムアウト（3秒）より長く設定することで、処理中に他のコンシューマーがメッセージを二重取得するのを防ぎます。DLQ テストでは 180秒 × 3回 ≒ 9分待つことになります。

2-3. AlertQueue を作成する（フィルターあり・アラート用）

「デッドレターキュー」セクション:

「キューを作成」をクリック。

控えておく情報:

• LogQueue の ARN
• AlertQueue の ARN

③ SNS → SQS サブスクリプションを2つ作成する

SQS キューポリシーの自動追加について：
コンソールで SNS → SQS サブスクリプションを作成すると、
SNS が SQS キューのアクセスポリシーに sns.amazonaws.com からの sqs:SendMessage 権限を自動追加します。
手動でのポリシー設定は不要です（SAM版では AWS::SQS::QueuePolicy を明示的に定義する必要があります）。

3-1. LogQueue サブスクリプション（フィルターなし）

SNS → NotificationTopic → 「サブスクリプション」タブ → 「サブスクリプションを作成」

「サブスクリプションを作成」をクリック。

3-2. AlertQueue サブスクリプション（フィルターあり）

SNS → NotificationTopic → 「サブスクリプション」タブ → 「サブスクリプションを作成」

「サブスクリプションフィルターポリシー」セクション:

{
  "level": ["warning", "critical"]
}

フィルターポリシーの意味：
level メッセージ属性の値が "warning" または "critical" のメッセージのみ AlertQueue に配信します。
level=info のメッセージは AlertQueue に届かない（LogQueue には届く）。

よくある間違い（フィルターが動作しない場合）：

• スコープが「メッセージ本文」になっている → **「メッセージ属性」**に変更する
• JSON のスペルミス（"warning" のクォートが抜けている等）

「サブスクリプションを作成」をクリック。

④ Lambda 関数を2つ作成する

AWSコンソール → Lambda → 「関数の作成」（共通設定）

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

4-1. LogFunction（全ログ処理）

関数名: LogFunction

コードエディタで lambda_function.py を開き、以下を貼り付けて「Deploy」をクリック。

import json


def lambda_handler(event, context):
    results = []

    for record in event["Records"]:
        sns_envelope = json.loads(record["body"])
        message = sns_envelope["Message"]  # 実際のメッセージ本文
        attributes = sns_envelope.get("MessageAttributes", {})
        level = attributes.get("level", {}).get("Value", "info")

        result = {
            "queue": "log",
            "level": level,
            "message": message,
        }
        print(json.dumps(result, ensure_ascii=False))
        results.append(result)

    print(json.dumps({"processedCount": len(results)}, ensure_ascii=False))
    return {"processedCount": len(results)}

json.loads(record["body"]) が必要な理由：
SNS → SQS 配信では、SQS のメッセージボディに SNS エンベロープ（JSON文字列）が格納されます。
そのため record["body"] はそのまま使えず、json.loads でパースする必要があります。

{
  "Type": "Notification",
  "TopicArn": "arn:aws:sns:...:NotificationTopic",
  "Message": "警告メッセージ",
  "MessageAttributes": {
    "level": {"Type": "String", "Value": "warning"}
  }
}

4-2. AlertFunction（アラート処理・DLQ テスト機能付き）

関数名: AlertFunction

import json


def lambda_handler(event, context):
    results = []

    for record in event["Records"]:
        sns_envelope = json.loads(record["body"])
        message = sns_envelope["Message"]
        attributes = sns_envelope.get("MessageAttributes", {})
        level = attributes.get("level", {}).get("Value", "unknown")

        # DLQテスト用: "error" というメッセージを受信したら意図的に例外発生
        if message.strip().lower() == "error":
            raise ValueError(
                f"アラート処理に失敗: level={level}, message={message}"
            )

        result = {
            "queue": "alert",
            "level": level,
            "message": message,
            "alert_triggered": True,
        }
        print(json.dumps(result, ensure_ascii=False))
        results.append(result)

    print(json.dumps({"processedCount": len(results)}, ensure_ascii=False))
    return {"processedCount": len(results)}

DLQ テストのしくみ：
message == "error" のとき意図的に ValueError を発生させています。
SQS は処理失敗を検知してメッセージをキューに戻し、可視性タイムアウト（180秒）後に再試行します。
これを3回繰り返すと AlertDLQ に移動します。

⑤ SQS トリガーを各 Lambda に追加する

5-1. LogFunction に LogQueue トリガーを追加する

Lambda → LogFunction → 「設定」タブ → 「トリガー」→「トリガーを追加」

「追加」をクリック。

権限の追加:

Lambda → LogFunction → 「設定」タブ → 「アクセス権限」→ 実行ロール名をクリック（IAM コンソールへ）
→「許可を追加」→「ポリシーをアタッチ」→ AWSLambdaSQSQueueExecutionRole をアタッチ。

AWSLambdaSQSQueueExecutionRole が必要な理由：
Lambda が SQS からメッセージを受信（sqs:ReceiveMessage）・削除（sqs:DeleteMessage）するために必要な権限がまとまったポリシーです。これがないと Lambda がメッセージを取得できません。

5-2. AlertFunction に AlertQueue トリガーを追加する

Lambda → AlertFunction → 「設定」タブ → 「トリガー」→「トリガーを追加」

「追加」をクリック。権限の追加（AWSLambdaSQSQueueExecutionRole）も同様に実施する。

AlertFunction のバッチサイズを 1 にする理由：
1件ずつ処理することで、1件が失敗しても他のメッセージに影響が出ません。
DLQ へ移動するメッセージを1件に限定できるため、テストが分かりやすくなります。

⑥ 動作テスト

3つのシナリオで SNS フィルター・ファンアウト・DLQ の動作を確認します。

テスト1: level=info（LogFunction のみ受信）

aws sns publish ^
  --topic-arn arn:aws:sns:ap-northeast-1:123456789012:NotificationTopic ^
  --message "情報メッセージ" ^
  --message-attributes "{\"level\":{\"DataType\":\"String\",\"StringValue\":\"info\"}}" ^
  --region ap-northeast-1

123456789012 を自分のアカウントIDに置き換えてください。

期待する動作:

• LogFunction が処理 → CloudWatch Logs にログが記録される
• AlertFunction は動作しない（フィルターで除外）

CloudWatch Logs で確認:

Lambda → LogFunction → 「モニタリング」タブ → 「CloudWatch Logs を表示」

{"queue": "log", "level": "info", "message": "情報メッセージ"}
{"processedCount": 1}

テスト2: level=warning（両 Lambda が受信 ＝ ファンアウト）

aws sns publish ^
  --topic-arn arn:aws:sns:ap-northeast-1:123456789012:NotificationTopic ^
  --message "警告メッセージ" ^
  --message-attributes "{\"level\":{\"DataType\":\"String\",\"StringValue\":\"warning\"}}" ^
  --region ap-northeast-1

期待する動作:

• LogFunction が処理（level=warning を受信）
• AlertFunction も処理（フィルターを通過）
• 1回の publish で 2つの Lambda が並行して動作する ← ファンアウトのポイント

LogFunction のログ:

{"queue": "log", "level": "warning", "message": "警告メッセージ"}

AlertFunction のログ:

{"queue": "alert", "level": "warning", "message": "警告メッセージ", "alert_triggered": true}

テスト3: level=warning + body=error（AlertFunction 失敗 → DLQ）

aws sns publish ^
  --topic-arn arn:aws:sns:ap-northeast-1:123456789012:NotificationTopic ^
  --message "error" ^
  --message-attributes "{\"level\":{\"DataType\":\"String\",\"StringValue\":\"warning\"}}" ^
  --region ap-northeast-1

期待する動作:

• LogFunction → 正常処理（message=error でも例外なし）
• AlertFunction → ValueError 発生
• AlertQueue の可視性タイムアウト（180秒）後に再試行 × 3回 → AlertDLQ に移動

DLQ に移動するまでの待機時間: 最大 180秒 × 3回 ≒ 9分かかります。
CloudWatch Logs で AlertFunction に [ERROR] ValueError が 3回記録されたことを確認してから DLQ をポーリングするとよいです。

DLQ にメッセージが届いたか確認:

SQS → AlertDLQ → 「メッセージを送受信」→「メッセージをポーリング」

"error" のメッセージ（SNS エンベロープ形式）が表示されれば DLQ 動作確認完了。

⑦ リソースの削除

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

1. Lambda のトリガーを削除する

• Lambda → LogFunction → 「設定」→「トリガー」→ SQS トリガーを削除
• Lambda → AlertFunction → 同様に削除

2. Lambda 関数を削除する

• LogFunction / AlertFunction を削除

3. SNS サブスクリプションを削除する

SNS → NotificationTopic → 「サブスクリプション」タブ → 2つのサブスクリプションを削除

4. SNS Topic を削除する

SNS → トピック → NotificationTopic → 「削除」

5. SQS キューを3つ削除する

SQS → LogQueue / AlertQueue / AlertDLQ を各々削除

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

IAM → ロール → LogFunction-role-XXXX / AlertFunction-role-XXXX を削除

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

CloudWatch → ロググループ → /aws/lambda/LogFunction / /aws/lambda/AlertFunction を削除

SAM版との大きな違い（SAMのメリット）：
SAM版では sam delete 1コマンドで上記すべてのリソースを一括削除できます。

SAMとの対比

コンソール版の最大のつまずきポイント：
SNS の「サブスクリプション」を作り忘れると、SNS publish しても SQS キューにメッセージが届きません。
「キューにメッセージが来ない」と感じたら、まずサブスクリプションが正しく作成されているか確認しましょう。

トラブルシューティング

まとめ

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

コンソール版で実感できたポイント

• SNS Topic / SQS キュー / Lambda という3つのリソースの組み合わせ方が視覚的に理解できる
• SNS サブスクリプションのフィルターポリシーJSON を直接入力することで、ルールの書き方が身につく
• リソースを1つずつ作成することで、各サービスの役割と依存関係が明確になる

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

コンソールで SNS + SQS + Lambda の連携を理解したら、SAM で同じ構成をコードで定義することで「SAM が何を自動化しているか」が明確になります。AWS::SQS::QueuePolicy の明示的な記述や SQSPollerPolicy によるワンライン権限付与など、コンソールでの手動操作がコードに対応しています。

関連記事

Amazon検索[本 AWS 開発]

The post AWSコンソールだけでSNS + SQS + Lambda 通知システムを構築する手順【Pub/Sub・ファンアウト・DLQ / SAM版との比較付き】 first appeared on CayTech Lab.

はじめに

「ログインしたユーザーだけが使える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.

はじめに

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

SAM版ではコマンド数本でS3バケット・Lambda・イベント通知設定が完了しましたが、「SAMが裏で何をやっているのか？」「バケット名のグローバルユニーク問題はどう解決する？」「再帰呼び出しの警告って何？」 といった疑問を実際のコンソール操作を通じて体験できるのがこの記事です。

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

• S3・Lambda を個別に設定する順序と依存関係
• SAMの !Sub "${AWS::StackName}-upload-${AWS::AccountId}" が解決していること（バケット名のグローバルユニーク問題）
• 「再帰呼び出し」警告の意味と、今回は無視してよい理由
• S3バケット削除時に「先に空にする」が必要な理由

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

Amazon検索[本 AWS 開発]

構築するもの

SAM版と全く同じ構成・機能のファイルアップロードトリガー環境を構築します。

ファイルアップロード（コンソール / AWS CLI）
  ↓ S3 ObjectCreated イベント発火
S3 バケット（my-s3-event-upload）
  ↓ Lambda を呼び出し
Lambda（S3EventFunction / Python 3.12）
  ↓ ファイル情報（バケット名・ファイル名・サイズ）をログ出力
CloudWatch Logs

全体の作業順序

① S3 バケット作成
      ↓
② Lambda 関数作成（コード入力）
      ↓
③ S3 トリガーを Lambda に追加（リソースベースポリシーも自動設定）
      ↓
④ ファイルアップロードして動作テスト
⑤ リソースの削除（S3を先に空にする）

順序の理由：
③でS3トリガーを追加する際に「どのバケットを対象にするか」を選択するため、①でバケットを先に作成しておく必要があります。SQSハンズオンのようにARNのコピーが必要な場面はありませんが、バケットが存在しないとトリガー設定画面で選択できません。

① S3 バケット作成

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

1-1. バケットの設定

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

バケット名のルール（SAMとの違いが出るポイント）：

S3のバケット名はAWS全体（全リージョン・全アカウント）でグローバルユニークである必要があります。

• 小文字・数字・ハイフンのみ使用可（大文字・アンダースコアは使えない）
• my-s3-event-upload だと他のユーザーがすでに使っている可能性がある

一意にする推奨の方法：

• my-s3-event-upload-自分のAWSアカウントID（最も確実）
• my-s3-event-upload-20260222（日付を付ける）

SAMでは !Sub "${AWS::StackName}-upload-${AWS::AccountId}" で自動的にアカウントIDを付加しています。コンソールではこのルールを頭の中で考えて手動入力する必要があります。

控えておく情報：

• バケット名（例: my-s3-event-upload）

② Lambda 関数作成

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

2-1. 基本設定

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

実行ロールについて：
今回の Lambda はS3イベントのメタデータ（バケット名・ファイル名・サイズ）を受け取るだけで、S3からファイルの中身を読み取る処理は行いません。
そのため、基本実行ロール（CloudWatch Logs への書き込み権限のみ）で動作します。
ファイルの中身を読み取りたい場合は、実行ロールに s3:GetObject 権限を追加する必要があります。

2-2. コードの入力

関数ページ → 「コード」タブ → コードエディタで lambda_function.py を開きます。

既存の内容を全て置き換えて以下を貼り付けます。

import json
import urllib.parse


def lambda_handler(event, context):
    results = []

    for record in event["Records"]:          # 複数ファイル同時アップロードに対応
        bucket = record["s3"]["bucket"]["name"]
        # キー名は URL エンコードされているためデコードが必要（日本語・スペース対応）
        key = urllib.parse.unquote_plus(record["s3"]["object"]["key"])
        size = record["s3"]["object"]["size"]
        event_name = record["eventName"]     # 例: "ObjectCreated:Put"
        event_time = record["eventTime"]     # 例: "2026-02-22T10:00:00.000Z"

        info = {
            "eventName": event_name,
            "bucket": bucket,
            "key": key,
            "sizeBytes": size,
            "eventTime": event_time,
        }

        print(json.dumps(info, ensure_ascii=False))
        results.append(info)

    print(json.dumps({"processedCount": len(results)}, ensure_ascii=False))
    return {"processedCount": len(results)}

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

③ S3 トリガーを Lambda に追加

Lambdaコンソールからトリガーを追加する方法と、S3コンソールからイベント通知を設定する方法の2つがありますが、ここではLambdaコンソールから行います。

Lambda → S3EventFunction → 「設定」タブ → 「トリガー」→「トリガーを追加」

「追加」をクリックします。

「再帰呼び出し」の警告とは：

S3バケットへのアップロードをトリガーに同じバケットへ書き込む Lambda を設定すると、無限ループが発生します。例えば「画像をアップロード → Lambdaがリサイズして同じバケットに保存 → それがまたトリガーになる → …」というパターンです。

今回の Lambda はS3への書き込みを行わず、ログを出力するだけなので問題ありません。「このトリガーを確認しました」にチェックして続行してください。

SAMとの差分： SAMの Type: S3 イベントでも同じ構成になっています。SAMは警告なしに設定されますが、同じリスクが存在します。

自動設定されること：
Lambdaのリソースベースポリシーに「S3からの呼び出しを許可するポリシー」が自動追加されます。
S3がLambdaを呼び出すためのIAM設定を手動で行う必要はありません。

④ 動作テスト

4-1. テスト用ファイルの準備

echo テストファイルです > C:\test.txt

4-2. ファイルのアップロード

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

S3 → my-s3-event-upload → 「アップロード」→「ファイルを追加」→ test.txt を選択 → 「アップロード」

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

aws s3 cp C:\test.txt s3://my-s3-event-upload/test.txt --region ap-northeast-1

4-3. CloudWatch Logs でログを確認

Lambda → S3EventFunction → 「モニタリング」タブ → 「CloudWatch Logs を表示」→ 最新のログストリームを開きます。

期待するログ出力：

{"eventName": "ObjectCreated:Put", "bucket": "my-s3-event-upload", "key": "test.txt", "sizeBytes": 28, "eventTime": "2026-02-22T10:00:00.000Z"}
{"processedCount": 1}

確認ポイント：

• "eventName": "ObjectCreated:Put" — S3の Put（アップロード）が検知されている
• "key": "test.txt" — アップロードしたファイル名が正しく取得されている
• "sizeBytes" — ファイルサイズが記録されている

4-4. 日本語ファイル名のテスト（任意）

echo 日本語テスト > "C:\テスト.txt"
aws s3 cp "C:\テスト.txt" "s3://my-s3-event-upload/テスト.txt" --region ap-northeast-1

ログで "key": "テスト.txt" と正しくデコードされていることを確認します。

⑤ リソースの削除

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

S3バケット削除の重要な注意点：
オブジェクトが残っているバケットは削除できません。
先にバケット内のファイルをすべて削除してからバケットを削除してください。

SAMの sam delete でも同じ理由から「先にバケットを空にする」手順が必要です。この仕様はSAMを使っても変わりません。

1. S3 バケット内のオブジェクトをすべて削除する

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

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

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

aws s3 rm s3://my-s3-event-upload --recursive --region ap-northeast-1

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

S3 → my-s3-event-upload を選択 → 「削除」→ バケット名を入力 → 「バケットを削除」

3. Lambda 関数を削除する

Lambda → 関数 → S3EventFunction を選択 → 「アクション」→「削除」→ 確認テキストを入力 → 「削除」

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

IAM → ロール → S3EventFunction-role-XXXX を選択 → 「削除」→ ロール名を入力 → 「削除」

Lambda を削除してもIAMロールはそのまま残ります。不要なら手動で削除します。

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

CloudWatch → ロググループ → /aws/lambda/S3EventFunction → 「アクション」→「ロググループの削除」

SAMとの対比まとめ

トラブルシューティング

まとめ

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

どちらを使うべきか

関連記事

• SAM版ハンズオン — コマンド数本でS3 + Lambdaトリガー環境を構築

AWSハンズオン - S3へのファイルアップロードをトリガーにLambdaを自動起動しよう【SAM版 / Windows対応】

はじめに「S3にファイルが上がったら自動で処理したい」というのは、AWSを使う現場でよく出てくる要件です。画像のリサイズ、CSVの集計、ログファイルの解析など、ファイルアップロードを起点にした自動処理はサーバーレス構成の代表的なユースケース...

caymezon.com

2026.02.23

Amazon検索[本 AWS 開発]

The post AWSコンソールだけでS3 + Lambdaファイルアップロードトリガーを構築する手順【SAM版との比較付き】 first appeared on CayTech Lab.

はじめに

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

SAM版ではコマンド数本でSQS・DLQ・Lambda・IAM権限がまとめてデプロイできましたが、「SAMが裏で何をやっているのか？」「コンソールで手動操作するとどれだけ手間がかかるのか？」 を実感してもらうために、全く同じ構成をAWSコンソールのみで手作業で構築する手順を解説します。

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

• SQS・DLQ・Lambda・IAMを個別に設定する依存関係と順序
• SAMが SQSPollerPolicy 1行で解決している IAM 権限設定の実態
• DLQをメインキューに紐づける RedrivePolicy 設定の実際の操作

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

コンソール操作で学べることの価値：

• IAMロールが「どのサービスが何の権限を持っているか」の具体的なイメージが掴める
• DLQとメインキューの紐付け（RedrivePolicy）の設定画面を実際に見ることができる
• トラブル時に「どのリソースの設定を確認すればよいか」がわかるようになる

Amazon検索[本 AWS 開発]

構築するもの

SAM版と全く同じ構成・機能のメッセージキュー処理環境を構築します。

送信者（コンソール / AWS CLI）
  ↓ メッセージ送信
SQS キュー（BatchQueue）
  ↓ Lambda がポーリング（自動）
Lambda（ProcessFunction / Python 3.12）
  ↓ 処理成功 → メッセージ削除（自動）
  ↓ 処理失敗（3回）→ DLQに移動
SQS デッドレターキュー（BatchDLQ）
  ↓ ログ出力
CloudWatch Logs

全体の作業順序

コンソールでは依存する順番通りに作成する必要があります。

① DLQ（BatchDLQ）作成
      ↓（DLQのARNが必要）
② メインキュー（BatchQueue）作成 + DLQを設定
      ↓（キューARNが必要）
③ Lambda 関数（ProcessFunction）作成 + コード入力
      ↓
④ Lambda 実行ロールに SQS 権限を追加
      ↓
⑤ SQS トリガーを Lambda に追加
      ↓
⑥ 動作テスト（正常処理 / DLQ振り分け）
⑦ リソースの削除

順序が重要な理由：
メインキューの作成時に DLQ の ARN が必要です。
SAMでは !GetAtt BatchDLQ.Arn で自動解決されますが、コンソールでは DLQ を先に作成してARNをコピーしておく必要があります。

① DLQ（デッドレターキュー）作成

AWSコンソール → SQS → 「キューを作成」

1-1. キューの設定

「設定」セクション（メッセージ保持期間のみ変更）：

「キューを作成」をクリックします。

控えておく情報：

• DLQ の ARN（例: arn:aws:sqs:ap-northeast-1:123456789012:BatchDLQ）

SAMとの差分： SAMの BatchDLQ: Type: AWS::SQS::Queue の部分をコンソールで手動作成しています。SAMでは !GetAtt BatchDLQ.Arn でARNを自動参照できますが、コンソールではここで控えたARNを次のステップで手動入力します。

② メインキュー作成

AWSコンソール → SQS → 「キューを作成」

2-1. キューの設定

「設定」セクション（可視性タイムアウトのみ変更）：

可視性タイムアウトについて：
Lambda 関数のタイムアウト（30秒）× 6 以上を設定することがAWS推奨です。
処理中にタイムアウトが切れると、同じメッセージが再度キューに現れて二重処理が発生します。
今回は Lambda タイムアウト 30秒 × 6 = 180秒 に設定します。

SAMでは VisibilityTimeout: 180 の1行ですが、コンソールでは手動入力が必要です。

2-2. デッドレターキュー（DLQ）の設定

「デッドレターキュー」セクション：

最大受信数（maxReceiveCount）について：
同じメッセージが3回処理を試みて全て失敗した場合、DLQに移動します。
「1回目の失敗 → 可視性タイムアウト後に再試行 → 2回目の失敗 → 再試行 → 3回目の失敗 → DLQへ」という流れです。
SAMでは maxReceiveCount: 3 の1行で同じ設定が完了します。

「キューを作成」をクリックします。

控えておく情報：

• BatchQueue の URL（例: https://sqs.ap-northeast-1.amazonaws.com/123456789012/BatchQueue）

③ Lambda 関数作成

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

3-1. 基本設定

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

3-2. タイムアウトの設定

関数ページ → 「設定」タブ → 「一般設定」→「編集」

「保存」をクリックします。

3-3. コードの入力

関数ページ → 「コード」タブ → コードエディタで lambda_function.py を開きます。

既存の内容を全て置き換えて以下を貼り付けます。

import json
import datetime


def lambda_handler(event, context):
    results = []

    for record in event["Records"]:       # SQSからの各メッセージを順番に処理
        message_id = record["messageId"]
        body = record["body"]

        if body.strip().lower() == "error":
            raise ValueError(f"意図的なエラー: messageId={message_id}, body={body}")

        now = datetime.datetime.now(datetime.timezone.utc)

        result = {
            "messageId": message_id,
            "body": body,
            "processedAt": now.isoformat(),
            "status": "processed",
        }

        print(json.dumps(result, ensure_ascii=False))
        results.append(result)

    print(json.dumps({"processedCount": len(results)}, ensure_ascii=False))
    return {"processedCount": len(results), "results": results}

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

④ Lambda 実行ロールに SQS 権限を追加

デフォルトの実行ロールは CloudWatch Logs への書き込みしか持っていません。SQSからメッセージを取り出す権限を手動で追加する必要があります。

Lambda → ProcessFunction → 「設定」タブ → 「アクセス権限」→ 実行ロール名のリンクをクリック

（例: ProcessFunction-role-XXXX）→ IAMコンソールのロール画面が開きます。

「許可を追加」→「ポリシーをアタッチ」

検索ボックスに SQS と入力 → AWSLambdaSQSQueueExecutionRole にチェック → 「許可を追加」をクリックします。

AWSLambdaSQSQueueExecutionRole に含まれる権限：

• sqs:ReceiveMessage — キューからメッセージを取り出す
• sqs:DeleteMessage — 処理完了後にメッセージを削除する
• sqs:GetQueueAttributes — キューの属性情報を取得する

SAMとの差分：
SAMでは SQSPollerPolicy: QueueName: !GetAtt BatchQueue.QueueName の2行で上記3権限が自動付与されます。コンソールでは IAMコンソールへの画面遷移 → ポリシー検索 → アタッチの操作が必要です。

⑤ SQS トリガーを Lambda に追加

Lambda → ProcessFunction → 「設定」タブ → 「トリガー」→「トリガーを追加」

「追加」をクリックします。

バッチサイズとバッチウィンドウについて：

設定	意味
バッチサイズ=5	キューに溜まったメッセージを最大5件まとめてLambdaに渡す
バッチウィンドウ=0	メッセージが来たらすぐにLambdaを呼び出す（待機なし）

バッチサイズを大きくするとLambdaの呼び出し回数が減りコスト節約になりますが、1件でも失敗するとバッチ全体が再試行される点に注意してください。

SAMとの差分：
SAMの Type: SQS / BatchSize: 5 の設定がここに対応しています。コンソールではこの「トリガーを追加」画面で手動設定します。

⑥ 動作テスト

6-1. 正常処理テスト

方法A: コンソールからメッセージ送信

SQS → BatchQueue → 「メッセージを送受信」→「メッセージを送信」

「メッセージを送信」をクリックします。

方法B: AWS CLI でメッセージ送信

aws sqs send-message ^
  --queue-url https://sqs.ap-northeast-1.amazonaws.com/123456789012/BatchQueue ^
  --message-body "こんにちは、SQS！" ^
  --region ap-northeast-1

CloudWatch Logs でログを確認（数秒後）：

Lambda → ProcessFunction → 「モニタリング」タブ → 「CloudWatch Logs を表示」

期待するログ出力：

{"messageId": "xxxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxxxx", "body": "こんにちは、SQS！", "processedAt": "2026-02-22T10:00:00.000000+00:00", "status": "processed"}
{"processedCount": 1}

"status": "processed" が表示されれば正常処理完了です。

6-2. DLQテスト（失敗メッセージの振り分け確認）

メッセージ本文を error にして送信すると、Lambda が例外を発生させてDLQに移動します。

aws sqs send-message ^
  --queue-url https://sqs.ap-northeast-1.amazonaws.com/123456789012/BatchQueue ^
  --message-body "error" ^
  --region ap-northeast-1

処理の流れ：

1. Lambda が error を受信 → 例外発生（処理失敗）
2. 可視性タイムアウト（180秒）が切れると再度キューに現れる
3. 3回失敗 → BatchDLQ に移動

注意：DLQに移動するまで最大180秒 × 3回 = 最大9分かかります。
すぐに確認したい場合は、BatchQueue の可視性タイムアウトを一時的に短く（例: 10秒）して再試行するとよいです。

DLQにメッセージが届いたか確認：

SQS → BatchDLQ → 「メッセージを送受信」→「メッセージをポーリング」

error のメッセージが表示されれば DLQ動作確認完了です。

⑦ リソースの削除

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

1. Lambda のトリガー（SQSイベントソースマッピング）を削除する

Lambda → ProcessFunction → 「設定」タブ → 「トリガー」→ SQSトリガーを選択 → 「削除」

2. Lambda 関数を削除する

Lambda → 関数 → ProcessFunction を選択 → 「アクション」→「削除」→ 確認テキストを入力 → 「削除」

3. SQS キューを削除する（メインキューを先に、次にDLQ）

SQS → BatchQueue を選択 → 「削除」→ キュー名を入力 → 「削除」

SQS → BatchDLQ を選択 → 「削除」→ キュー名を入力 → 「削除」

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

IAM → ロール → ProcessFunction-role-XXXX を選択 → 「削除」→ ロール名を入力 → 「削除」

Lambda を削除しても自動作成された IAM ロールはそのまま残ります。厳密に削除したい場合は IAM コンソールで手動削除します。

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

CloudWatch → ロググループ → /aws/lambda/ProcessFunction → 「アクション」→「ロググループの削除」

SAMとの差分：
SAMの sam delete はCloudFormationスタックを削除することで、SQS×2・Lambda・IAMロール・S3を一括削除します。コンソールでは上記5手順を個別に実行する必要があります。

SAMとの対比まとめ

トラブルシューティング

まとめ

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

コンソール操作を通じて、SAMが裏側で自動処理している内容が明確になりました：

どちらを使うべきか

関連記事

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

AWSハンズオン - SQS + Lambdaでメッセージキュー処理を実装しよう【SAM版 / Windows対応】

はじめに「メッセージキューって何に使うの？」「エラーが起きたメッセージをどうやって管理するの？」という疑問を持っている方向けに、Amazon SQS + Lambda によるメッセージキュー処理をゼロから構築するハンズオンを紹介します。今回...

caymezon.com

2026.02.23

Amazon検索[本 AWS 開発]

The post AWSコンソールだけでSQS + Lambdaキュー処理を構築する手順【SAM版との比較付き】 first appeared on CayTech Lab.

はじめに

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

SAM版ではコマンド数本でインフラが完成しましたが、「その裏で何が起きているのか？」「SAMを使わない場合はどれだけ手間がかかるのか？」 を実感してもらうために、全く同じEventBridge + Lambda定期バッチ構成をAWSコンソールのみで手作業で構築する手順を詳細に解説します。

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

• AWS各サービス（Lambda・EventBridge）を個別に設定する流れ
• SAMが裏側で自動処理していること（IAMロール・EventBridgeターゲット設定・権限付与など）
• SAMとコンソール手動操作、それぞれの使いどころ

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

まず差分を数字で確認します。

「それでもコンソール操作を知っておく価値はあるか？」という問いに対して、答えは Yes です。

コンソール操作が特に有効な場面：

• 障害調査 — 実際にどのリソースがどう設定されているか目視確認する
• SAMのデバッグ — SAMでデプロイしたリソースをコンソールで確認・修正する
• 初学習 — 各サービスの設定項目を理解するための最初の一歩

Amazon検索[本 AWS 開発]

構築するもの

SAM版と全く同じ構成・機能のバッチ実行環境を構築します。

EventBridge スケジュールルール（rate: 1分ごと）
  ↓ イベント発火
Lambda（BatchFunction / Python 3.12）
  ↓ ログ出力
CloudWatch Logs

全体の作業順序

SAMは依存関係を自動解決しますが、コンソールでは依存する順番通りに作成する必要があります。

① Lambda 関数作成（コードをコンソールで直接入力）
      ↓（関数ARNが必要）
② EventBridge スケジュール作成・ターゲット設定
      ↓
③ CloudWatch Logs で動作確認

この順序を守らないと、設定画面で参照先リソースが見つからずエラーになります。

① Lambda 関数作成

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

1-1. 基本設定

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

実行ロールについて：
デフォルトで BatchFunction-role-XXXX という IAM ロールが自動作成されます。
このロールには AWSLambdaBasicExecutionRole が付与されており、CloudWatch Logs への書き込み権限が含まれます。
今回は DynamoDB などの外部サービスを使わないため、このデフォルトロールで十分です。

SAMとの差分： SAMでは AWSLambdaBasicExecutionRole はすべての AWS::Serverless::Function に自動付与されます。コンソールでは「基本的なアクセス権限で新しいロールを作成」を選択することで同じ設定が適用されます。

1-2. コードの入力

関数ページ → 「コード」タブ → コードエディタが表示されます。

lambda_function.py に以下のコードを貼り付けます（既存の内容を全て置き換えてください）。

import json
import datetime
import random


def lambda_handler(event, context):
    now_utc = datetime.datetime.now(datetime.timezone.utc)

    # JST（UTC+9）に変換
    jst = datetime.timezone(datetime.timedelta(hours=9))
    now_jst = now_utc.astimezone(jst)

    # バッチ処理のシミュレーション（ランダムな処理件数）
    processed_count = random.randint(10, 100)

    result = {
        "status": "success",
        "executedAt": {
            "utc": now_utc.isoformat(),
            "jst": now_jst.strftime("%Y-%m-%d %H:%M:%S JST"),
        },
        "processedCount": processed_count,
        "message": f"{processed_count}件の処理が完了しました",
        "triggeredBy": event.get("source", "manual"),
    }

    print(json.dumps(result, ensure_ascii=False))
    return result

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

1-3. 動作確認（テスト実行）

EventBridge のスケジュール設定前に、Lambda 単体で動くか確認します。

「テスト」タブ → 「テストイベントを作成」

「テスト」ボタンをクリックします。

期待する結果（実行結果の展開）：

{
  "status": "success",
  "executedAt": {
    "utc": "2026-02-22T10:00:00.000000+00:00",
    "jst": "2026-02-22 19:00:00 JST"
  },
  "processedCount": 42,
  "message": "42件の処理が完了しました",
  "triggeredBy": "manual"
}

Status: Succeeded が表示されれば Lambda 関数は正常に動作しています。

控えておく情報：

• 関数 ARN（例: arn:aws:lambda:ap-northeast-1:123456789012:function:BatchFunction）

② EventBridge スケジュール作成

EventBridge Scheduler と EventBridge ルールの違い：
コンソールには「スケジュール」と「ルール」の2種類があります。

• スケジュール (EventBridge Scheduler): 新しいサービス。タイムゾーン設定・フレックスタイムウィンドウあり
• ルール (EventBridge Events): 旧サービス。SAMの Type: Schedule はこちらを内部で使用

このコンソール手順では新しい「スケジュール」を使います。

AWSコンソール → EventBridge → スケジュール → 「スケジュールを作成」

2-1. スケジュールの名前と説明

「次へ」をクリックします。

2-2. スケジュールパターンの設定

フレックスタイムウィンドウについて：
「オフ」を選択すると指定した時刻に正確に実行されます。
「5分」などを設定すると、指定時刻から5分以内のランダムな時刻に実行されます（大量スケジュールの負荷分散用）。
ハンズオン目的ではオフでよいです。

rateベースとcronベースの違い：

• rateベース: 「X分ごと」などシンプルな繰り返し → 1 分 と入力するだけ
• cronベース: 「毎日9時」など複雑なスケジュール → 分・時・日・月・曜日・年を全て入力する必要がある

1分ごとの繰り返しにはrateベースが最もシンプルです。
cronベースで「1分ごと」を設定するには全フィールドへの入力が必要で複雑になります。

「次へ」をクリックします。

2-3. ターゲットの選択

ペイロードに以下を入力します（どこから実行されたかをログで確認できるようにするための設定です）。

{"source": "eventbridge-scheduler"}

「次へ」をクリックします。

SAMとの差分： SAMの Type: Schedule では EventBridge → Lambda のターゲット設定と権限付与が自動で行われます。コンソールでは2-3の「ターゲット選択」画面で手動設定します。

2-4. 設定

「次へ」をクリックします。

実行ロールについて：
EventBridge Scheduler が Lambda を呼び出すための IAM ロール（Amazon_EventBridge_Scheduler_LAMBDA_XXXX）が自動作成されます。削除時に一緒に削除します。

2-5. 確認と作成

内容を確認して「スケジュールを作成」をクリックします。

③ CloudWatch Logs で動作確認

3-1. ログの確認

スケジュール作成後、最大1分待つとLambdaが自動実行されます。

確認方法 1: Lambda コンソールから

Lambda → BatchFunction → 「モニタリング」タブ → 「CloudWatch Logs を表示」

確認方法 2: CloudWatch Logs コンソールから

CloudWatch → ロググループ → /aws/lambda/BatchFunction → 最新のログストリームを開く

期待するログ出力：

{"status": "success", "executedAt": {"utc": "2026-02-22T10:00:00.000000+00:00", "jst": "2026-02-22 19:00:00 JST"}, "processedCount": 57, "message": "57件の処理が完了しました", "triggeredBy": "eventbridge-scheduler"}

"triggeredBy": "eventbridge-scheduler" となっていれば EventBridge Scheduler から自動実行されています。
（2-3でペイロードに {"source": "eventbridge-scheduler"} を設定したため、Lambda がこの値を受け取ります。）

3-2. 実行回数の確認

Lambda → BatchFunction → 「モニタリング」タブ → 「呼び出し」グラフで実行回数が確認できます。
1分ごとに増えていれば正常動作しています。

④ リソースの削除

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

注意： rate(1 minute) は毎分実行されるため、放置すると CloudWatch Logs のログが蓄積します。ハンズオン完了後は速やかに削除してください。

1. EventBridge スケジュールを削除する

EventBridge → スケジュール → batch-schedule-1min を選択 → 「削除」→ 確認テキストを入力 → 「削除」

2. Lambda 関数を削除する

Lambda → 関数 → BatchFunction を選択 → 「アクション」→「削除」→ 確認テキストを入力 → 「削除」

Lambda を削除しても、自動作成された IAM ロール（BatchFunction-role-XXXX）はそのまま残ります。
厳密に削除する場合は IAM → ロール → BatchFunction-role-XXXX も削除します。

3. EventBridge Scheduler の実行ロールを削除する（任意）

IAM → ロール → Amazon_EventBridge_Scheduler_LAMBDA_XXXX を選択 → 「削除」→ ロール名を入力 → 「削除」

2-4 で自動作成された Scheduler 専用の実行ロールです。不要なら削除します。

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

CloudWatch → ロググループ → /aws/lambda/BatchFunction → 「アクション」→「ロググループの削除」

Lambda を削除してもロググループは残るため、不要なら手動で削除します。

SAMとの差分： SAMの sam delete は CloudFormation スタックを削除することで、S3・Lambda・EventBridgeルール・IAMロールを一括で削除します。コンソールでは各リソースを個別に手動削除する必要があります。

SAMとの対比まとめ

SAM版との内部サービスの違い：
SAMの Type: Schedule は旧サービスの「EventBridge ルール（EventBridge Events）」を使用します。
このコンソール版では新しい「EventBridge Scheduler」を使用しており、UIや設定項目が異なります。
どちらも「定期実行」の機能は同じです。

トラブルシューティング

まとめ

今回の手順で確認したこと

コンソール操作を通じて、SAMが裏側で自動処理している内容が明確になりました：

コンソール操作で学べたこと

• IAMロールの自動作成 — Lambda作成時とEventBridgeスケジュール作成時にそれぞれ別のIAMロールが自動作成される仕組み
• EventBridge Schedulerの仕組み — rateベース・cronベースの違いと、フレックスタイムウィンドウの概念
• ペイロードの役割 — EventBridgeからLambdaに渡すパラメータで実行元を識別できる
• リソース間の依存関係 — Lambda作成 → EventBridge設定の順序が決まっている理由

どちらを使うべきか

関連記事

• SAM版ハンズオン — VS Codeでコマンド数本デプロイ

AWSハンズオン - EventBridge + LambdaでCronバッチを自動実行しよう【SAM版 / Windows対応】

はじめに「定期的にデータを処理したい」「夜中に自動でバッチを動かしたい」と思ったことはありませんか？AWSには、定期実行のための仕組みが標準で備わっています。Amazon EventBridgeのスケジュール機能を使えば、Linuxのcro...

caymezon.com

2026.02.22

Amazon検索[本 AWS 開発]

The post AWSコンソールだけでEventBridge + Lambda定期バッチを構築する手順【SAM版との比較付き】 first appeared on CayTech Lab.

はじめに

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

SAM版ではコマンド数本でインフラが完成しましたが、「その裏で何が起きているのか？」「SAMを使わない場合はどれだけ手間がかかるのか？」 を実感してもらうために、全く同じメモアプリAPIをAWSコンソールのみで手作業で構築する手順を詳細に解説します。

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

• AWS各サービス（DynamoDB・IAM・Lambda・API Gateway）を個別に設定する流れ
• SAMが裏側で自動処理していること（IAMロール・API Gatewayルーティング・権限付与など）
• SAMとコンソール手動操作、それぞれの使いどころ

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

まず差分を数字で確認します。

「それでもコンソール操作を知っておく価値はあるか？」という問いに対して、答えは Yes です。

コンソール操作が特に有効な場面：

• 障害調査 — 実際にどのリソースがどう設定されているか目視確認する
• SAMのデバッグ — SAMでデプロイしたリソースをコンソールで確認・修正する
• 初学習 — 各サービスの設定項目を理解するための最初の一歩

Amazon検索[本 AWS 開発]

構築するもの

SAM版と全く同じ構成・機能のAPIを構築します。

インターネット
  ↓ HTTPS
API Gateway（Prod ステージ）
  ↓ Lambdaプロキシ統合
Lambda（MemoFunction / Python 3.12）
  ↓ boto3
DynamoDB（memo-api-dynamodb-stack-Memos テーブル）

全体の作業順序

SAMは依存関係を自動解決しますが、コンソールでは依存する順番通りに作成する必要があります。

① DynamoDB テーブル作成
      ↓（テーブル名が必要）
② IAM ロール作成（Lambda実行用）
      ↓（ロールARNが必要）
③ Lambda 関数作成（zipアップロード・環境変数設定）
      ↓（関数ARNが必要）
④ API Gateway 作成・リソース・メソッド設定・デプロイ
      ↓
⑤ Lambda に API Gateway からの実行許可を確認・付与

この順序を守らないと、設定画面で参照先リソースが見つからずエラーになります。

① DynamoDB テーブル作成

AWSコンソール → DynamoDB → テーブル → 「テーブルの作成」

設定値

「テーブルの作成」ボタンをクリック。作成完了まで数十秒待ちます。

▶ 控えておく情報：

• テーブル名: memo-api-dynamodb-stack-Memos

キャパシティーモードはオンデマンドを選ぶ理由：
デフォルトの「プロビジョンド」はあらかじめ読み書き容量を指定して課金されます。学習目的ではアクセスがない時間も課金されてしまうため、アクセスがあった分だけ課金される「オンデマンド」を選択します。SAMの BillingMode: PAY_PER_REQUEST に相当します。

② IAM ロール作成（Lambda実行用）

AWSコンソール → IAM → ロール → 「ロールを作成」

SAMでは DynamoDBCrudPolicy を1行書くだけで自動生成されていたIAMロールを、ここでは手動で作成します。

2-1. 信頼ポリシーの設定

「次へ」をクリックします。

2-2. 許可ポリシーのアタッチ（CloudWatch Logs 用）

検索ボックスに AWSLambdaBasicExecutionRole と入力してチェックを入れます。

→ 「次へ」

2-3. ロール名を設定して作成

「ロールを作成」をクリックします。

2-4. DynamoDB CRUD 権限をインラインポリシーで追加

作成したロール memo-api-lambda-role を開き → 「許可を追加」→「インラインポリシーを作成」→「JSON」タブ を選択して以下を貼り付けます：

{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Effect": "Allow",
      "Action": [
        "dynamodb:GetItem",
        "dynamodb:PutItem",
        "dynamodb:UpdateItem",
        "dynamodb:DeleteItem",
        "dynamodb:Scan",
        "dynamodb:Query"
      ],
      "Resource": "arn:aws:dynamodb:ap-northeast-1:*:table/memo-api-dynamodb-stack-Memos"
    }
  ]
}

ポリシー名（例: DynamoDBCrudPolicy-Memos）を入力して「ポリシーの作成」をクリックします。

▶ 控えておく情報：

• ロール ARN（例: arn:aws:iam::123456789012:role/memo-api-lambda-role）

SAMとの差分： SAMの DynamoDBCrudPolicy は必要な6つのDynamoDBアクションとCloudWatch Logs権限を1行で自動付与します。コンソールでは「管理ポリシーのアタッチ」と「インラインポリシーの作成」の2手順が必要です。

③ Lambda 関数作成

3-1. Lambdaコードをzipファイルに圧縮する（ローカル作業）

src/app.py と src/requirements.txt を zip 圧縮します。

Windowsエクスプローラーでの操作：

1. src/ フォルダを開く
2. app.py と requirements.txt を両方選択
3. 右クリック → 「ZIPファイルに圧縮」
4. lambda.zip という名前で保存

【注意】フォルダごとではなくファイルを直接zipする

src/ フォルダ自体を右クリックしてzipすると、中身のパスが src/app.py になります。LambdaはCodeUri直下に app.py があることを期待するため、フォルダの中身のファイルを選択してからzipしてください。フォルダごと圧縮するとパスが変わって Handler: app.lambda_handler が見つからずエラーになります。

コードの内容はSAM版ハンズオン記事のStep 3を参照してください。

3-2. Lambda 関数の作成

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

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

3-3. コードのアップロード

関数ページ → 「コードソース」セクション → 「アップロード元」→「.zip ファイル」→ lambda.zip を選択 → 「保存」

3-4. ハンドラーの設定

「コード」タブ → 画面を下にスクロール → 「ランタイム設定」→「編集」

「保存」をクリックします。

ハンドラーを変更する理由：
Lambda のデフォルトハンドラーは lambda_function.lambda_handler（lambda_function.py を参照）。本ハンズオンのコードは app.py なので、変更しないと No module named 'lambda_function' エラーになります。

3-5. 環境変数の設定

「設定」タブ → 「環境変数」→「編集」→「環境変数を追加」

「保存」をクリックします。

SAMとの差分： SAMでは template.yaml の Environment.Variables.TABLE_NAME: !Ref MemosTable が自動でテーブル名を解決して設定します。コンソールでは①で作成したテーブル名を手動でコピーして貼り付ける必要があります。

3-6. タイムアウトの設定

「設定」タブ → 「一般設定」→「編集」

「保存」をクリックします。

▶ 控えておく情報：

• 関数 ARN（例: arn:aws:lambda:ap-northeast-1:123456789012:function:MemoFunction）

④ API Gateway 作成・設定・デプロイ

ここが最も手順が多いセクションです。5エンドポイント × 複数設定 = 大量のクリック作業になります。SAMが Events: セクションの数行で自動処理していた部分を全て手動で設定します。

4-1. REST API の作成

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

「APIを作成」をクリックします。

4-2. リソース /memos の作成

「リソース」→「リソースを作成」

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

4-3. POST /memos メソッドの作成

/memos リソースを選択 →「メソッドを作成」

「メソッドを作成」をクリックします。

「Lambda プロキシ統合」をオンにする理由：
オンにすると、HTTPリクエスト全体（メソッド・パス・ボディ・ヘッダー）がそのままLambdaの event に渡されます。オフにすると、マッピングテンプレートを別途設定する必要があり手順が大幅に増えます。SAMはデフォルトでプロキシ統合を使用します。

4-4. GET /memos メソッドの作成

/memos リソースを選択 →「メソッドを作成」

「メソッドを作成」をクリックします。

4-5. リソース /memos/{id} の作成

/memos リソースを選択 →「リソースを作成」

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

{id} は波括弧ごと入力する
{id} と入力することで API Gateway がパスパラメータとして認識し、Lambda の event['pathParameters']['id'] で受け取れるようになります。

4-6. GET /memos/{id} メソッドの作成

/memos/{id} リソースを選択 →「メソッドを作成」

「メソッドを作成」をクリックします。

4-7. PUT /memos/{id} メソッドの作成

/memos/{id} リソースを選択 →「メソッドを作成」

「メソッドを作成」をクリックします。

4-8. DELETE /memos/{id} メソッドの作成

/memos/{id} リソースを選択 →「メソッドを作成」

「メソッドを作成」をクリックします。

4-9. API のデプロイ

「APIをデプロイ」ボタンをクリックします。

「デプロイ」をクリックします。

ステージ画面の「呼び出し URL」に表示されるURLを控えておきます：

https://xxxxxxxxxx.execute-api.ap-northeast-1.amazonaws.com/Prod

▶ 控えておく情報：

• 呼び出し URL（テストで使います）

⑤ Lambda に API Gateway からの実行許可を確認・付与

API GatewayがLambdaを呼び出す権限を確認します。

Lambda プロキシ統合でメソッドを作成した際に「Lambda関数に権限を追加しますか？」という確認ダイアログが表示されて「OK」をクリックした場合は、この手順は自動で完了しています。

もし 403 Forbidden エラーが出た場合は、以下の手順で手動付与します：

Lambda → 対象関数 → 「設定」タブ → 「リソースベースのポリシーステートメント」→「追加」

テスト（CMDでの動作確認）

テスト手順はSAM版と同じです。コンソールで取得した呼び出し URLを使って実行します。

set API_URL=https://xxxxxxxxxx.execute-api.ap-northeast-1.amazonaws.com/Prod

POST /memos — メモを作成する

curl -s -X POST "%API_URL%/memos" -H "Content-Type: application/json" -d "{\"title\":\"初めてのメモ\",\"content\":\"DynamoDBに保存されます\"}"

レスポンス例：

{
  "memoId": "6150433b-4834-4cfe-81f5-266d3dad9e57",
  "title": "初めてのメモ",
  "content": "DynamoDBに保存されます",
  "createdAt": "2026-02-20T10:00:00.000000+00:00",
  "updatedAt": "2026-02-20T10:00:00.000000+00:00"
}

GET /memos — メモ一覧を取得する

curl -s "%API_URL%/memos"

GET /memos/{id} — メモ1件を取得する

curl -s "%API_URL%/memos/6150433b-4834-4cfe-81f5-266d3dad9e57"

PUT /memos/{id} — メモを更新する

curl -s -X PUT "%API_URL%/memos/6150433b-4834-4cfe-81f5-266d3dad9e57" -H "Content-Type: application/json" -d "{\"title\":\"更新後タイトル\",\"content\":\"内容も更新しました\"}"

DELETE /memos/{id} — メモを削除する

curl -s -X DELETE "%API_URL%/memos/6150433b-4834-4cfe-81f5-266d3dad9e57"

CMDでのテストの詳細な注意点（変数未設定によるCloudFront 400エラーなど）はSAM版ハンズオン記事のStep 9を参照してください。

⑥ リソースの削除（コンソール）

削除する順番が重要です（依存関係の逆順）。 SAMなら sam delete 1コマンドで完了するところを、4サービスを個別に手動削除します。

1. API Gateway を削除する

API Gateway → MemoApi を選択 → 「削除」→ 確認テキストを入力 → 「削除」

2. Lambda を削除する

Lambda → 関数 → MemoFunction を選択 → 「アクション」→「削除」→ 確認テキストを入力 → 「削除」

3. IAM ロールを削除する

IAM → ロール → memo-api-lambda-role を選択 → 「削除」→ ロール名を入力 → 「削除」

4. DynamoDB テーブルを削除する

DynamoDB → テーブル → memo-api-dynamodb-stack-Memos → 「削除」→ テーブル名を入力して確認 → 「削除」

SAMとの差分： SAMの sam delete は CloudFormation スタックを削除することで、S3・Lambda・API Gateway・DynamoDB・IAMロールを一括で削除します。コンソールでは依存関係の逆順に4サービスを個別に削除する必要があります。

まとめ

今回の手順で確認したこと

コンソール操作を通じて、SAMが裏側で自動処理している内容が明確になりました：

コンソール操作で学べたこと

• IAMロールの構造 — 信頼ポリシー（誰がロールを使えるか）とアクセス許可ポリシー（何ができるか）の2層構造
• API Gatewayの仕組み — リソース（パス）とメソッド（HTTPメソッド）を組み合わせてエンドポイントを定義する
• Lambdaプロキシ統合 — リクエスト全体をeventとしてLambdaに渡す仕組み
• リソース間の依存関係 — 作成順序・削除順序が決まっている理由

どちらを使うべきか

関連記事

• SAM版ハンズオン — VS Codeで全自動デプロイ

AWS初心者ハンズオン - Lambda＋API Gateway＋DynamoDBでメモアプリAPIを作ろう【Windows対応】

はじめに「AWSのサーバーレスを試してみたい」「Lambda・API Gateway・DynamoDBを組み合わせて何か作ってみたい」と思っていませんか？この記事では、AWS SAM（Serverless Application Model...

caymezon.com

2026.02.20

Amazon検索[本 AWS 開発]

The post AWSコンソールだけでメモアプリAPIを構築する手順【Lambda＋API Gateway＋DynamoDB / SAMとの比較付き】 first appeared on CayTech Lab.