はじめに

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

この記事では、S3 + Lambda によるファイルアップロードトリガー処理を、AWS SAM を使ってゼロから構築するハンズオンを紹介します。

ファイルアップロード（aws s3 cp）
  ↓ S3 ObjectCreated イベント発火
S3 バケット（UploadBucket）
  ↓ Lambda を呼び出し
Lambda（Python 3.12 / S3EventFunction）
  ↓ ファイル情報（バケット名・ファイル名・サイズ）をログ出力
CloudWatch Logs

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

• S3 ObjectCreated イベントによる Lambda の自動起動
• URLデコード処理（日本語ファイル名・特殊文字を含むキー名の正しい取得）
• SAMテンプレートで S3 バケット名をグローバルユニークにする !Sub の使い方
• DeletionPolicy と「バケットを先に空にしてから削除」というSAM特有の注意点

この記事の特徴：

• Windows（VSCode + コマンドプロンプト）での実際の手順を詳細に解説
• フォルダ付きキー・日本語ファイル名など実務でよく出る応用テストも含む
• sam delete で失敗しやすいポイントと対処法を詳細に解説

Amazon検索[本 AWS 開発]

S3イベントの仕組みを理解する

キーワード解説

S3イベントの種類

SAMテンプレートで指定できる代表的なイベント：

今回は s3:ObjectCreated:* を使い、アップロード・コピーを問わず全ての作成操作でLambdaを起動します。

前提条件

aws sts get-caller-identity

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

使用するAWSサービス

学習目的の短時間ハンズオンであれば、ほぼ無料枠内で収まります。

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

cd C:\my-aws\aws-learning-projects\s3-event-lambda

フォルダ構造

s3-event-lambda/
├── template.yaml       # SAMテンプレート（S3バケット + Lambda定義）
├── samconfig.toml      # デプロイ設定（gitignore対象・毎回手動作成が必要）
├── docs/
│   ├── 1_console.md    # AWSコンソール版手順
│   └── 2_sam.md        # SAM版手順
└── src/
    └── app.py          # Lambda関数（ファイル情報をCloudWatch Logsに出力）

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

template.yaml がAWSリソース全体の設計図です。S3バケットとLambda関数をこの1ファイルで定義します。

AWSTemplateFormatVersion: '2010-09-09'
Transform: AWS::Serverless-2016-10-31
Description: S3 file upload trigger with Lambda

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

Resources:
  UploadBucket:
    Type: AWS::S3::Bucket
    Properties:
      # アカウントIDを含めることでグローバルユニークを保証
      BucketName: !Sub "${AWS::StackName}-upload-${AWS::AccountId}"
    DeletionPolicy: Delete   # sam delete 時にバケットも削除（空の場合のみ）

  # Lambda 関数
  S3EventFunction:
    Type: AWS::Serverless::Function
    Properties:
      CodeUri: src/
      Handler: app.lambda_handler
      Description: S3アップロードイベントを受信してファイル情報をログ出力する
      Events:
        S3Event:
          Type: S3                          # S3イベントトリガーを設定
          Properties:
            Bucket: !Ref UploadBucket       # 上で作ったバケットを参照
            Events: s3:ObjectCreated:*      # 全ての「作成」イベントをトリガー

Outputs:
  BucketName:
    Description: "アップロード先バケット名"
    Value: !Ref UploadBucket
  S3EventFunctionArn:
    Description: "Lambda 関数 ARN"
    Value: !GetAtt S3EventFunction.Arn
  CloudWatchLogsGroup:
    Description: "CloudWatch Logs グループ名"
    Value: !Sub "/aws/lambda/${S3EventFunction}"

template.yaml のポイント解説

BucketName: !Sub "${AWS::StackName}-upload-${AWS::AccountId}"
S3バケット名はAWS全体（全リージョン・全アカウント）でグローバルユニークである必要があります。スタック名＋アカウントIDを組み合わせることで、他のアカウントと名前が被る可能性を排除しています。コンソール版では手動で一意な名前を考える必要があります。

Type: S3 イベント
SAMがS3バケットのイベント通知設定とLambdaのリソースベースポリシー（「S3からの呼び出しを許可する」設定）を自動作成します。コンソール版では「Lambda → トリガーを追加」の画面操作が必要です。

DeletionPolicy: Delete
sam delete 実行時にS3バケットを削除しようとします。ただし、オブジェクトが残っているバケットは削除できないため、sam delete 前に必ずバケットを空にする必要があります（Step 9で詳しく解説）。

S3バケット名についての補足：
一度使われたバケット名は削除後しばらく再利用できないことがあります。
アカウントIDを含める方法が最も確実です。

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

src/app.py がファイル情報取得の本体です。S3イベントからバケット名・ファイル名・サイズ・イベント種別を取得してCloudWatch Logsに記録します。

import json
import urllib.parse


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

    for record in event["Records"]:          # 複数ファイル同時アップロードに対応
        # S3 イベントからファイル情報を取得
        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)}

app.py のポイント解説

event["Records"] のループ処理
S3イベントはリスト形式で渡されます。通常は1件ですが、複数ファイルの同時アップロード時に複数件になる場合があるため、for ループで処理します。

urllib.parse.unquote_plus(key) が必要な理由
S3のキー名（ファイルパス）に日本語や特殊文字・スペースが含まれると、URLエンコードされてLambdaに渡されます。

urllib.parse.unquote_plus はこのデコードを正しく処理します。

外部ライブラリ不使用
標準ライブラリ（json, urllib.parse）のみ使用するため、requirements.txt が不要です。

Step 4: samconfig.toml を作成する

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

s3-event-lambda/samconfig.toml を新規作成して以下を貼り付けてください。

version = 0.1

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

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

【注意】samconfig.toml の置き場所

s3-event-lambda/ フォルダの直下に置く必要があります。

Step 5: sam build（ビルド）

cd C:\my-aws\aws-learning-projects\s3-event-lambda
sam build

Build Succeeded

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

Step 6: sam deploy（デプロイ）

sam deploy

Deploy this changeset? [y/N]: y

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

デプロイ完了の確認

CloudFormation outputs from deployed stack
----------------------------------------------------------------------
Outputs
----------------------------------------------------------------------
Key    BucketName
Value  s3-event-lambda-stack-upload-123456789012

Key    S3EventFunctionArn
Value  arn:aws:lambda:ap-northeast-1:123456789012:function:s3-event-lambda-stack-S3EventFunction-XXXX

Key    CloudWatchLogsGroup
Value  /aws/lambda/s3-event-lambda-stack-S3EventFunction-XXXX
----------------------------------------------------------------------

BucketName を控えておきます。（テスト時に使います）

BucketAlreadyExists エラーが出た場合：
既に同名バケットが他アカウントに存在しています。samconfig.toml の stack_name を別の名前に変更して再デプロイしてください。

Step 7: 動作テスト

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

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

7-2. バケット名を変数にセットする

set BUCKET=s3-event-lambda-stack-upload-123456789012

（BUCKET の値は Outputs の BucketName に表示された実際の値に変更してください）

7-3. ファイルのアップロード

aws s3 cp C:\test.txt s3://%BUCKET%/test.txt --region ap-northeast-1

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

aws logs tail /aws/lambda/s3-event-lambda-stack-S3EventFunction-XXXX --follow

期待するログ出力：

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

確認ポイント：

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

7-5. フォルダ付きキーのテスト（任意）

S3の「フォルダ」はキー名のプレフィックスとして表現されます。

aws s3 cp C:\test.txt s3://%BUCKET%/images/photo.jpg --region ap-northeast-1

ログで "key": "images/photo.jpg" となることを確認します。S3にフォルダ構造でファイルを整理している場合でも、キー名全体（フォルダ名/ファイル名）が取得できます。

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

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

ログで "key": "テスト.txt" と正しくデコードされていることを確認します。urllib.parse.unquote_plus がなければ %E3%83%86%E3%82%B9%E3%83%88.txt のままになります。

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

• S3: S3 → s3-event-lambda-stack-upload-XXXX → アップロードしたファイルが存在することを確認
• Lambda: Lambda → 関数 → s3-event-lambda-stack-S3EventFunction-XXXX → 「設定」→「トリガー」でS3トリガーを確認
• CloudWatch Logs: Lambda → 対象関数 → 「モニタリング」タブ → 「CloudWatch Logs を表示」

Step 9: リソースの削除

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

重要: sam delete の前に必ずバケットを空にしてください。
S3バケットにオブジェクトが残った状態で sam delete を実行すると、CloudFormation のスタック削除が失敗します。

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

aws s3 rm s3://%BUCKET% --recursive --region ap-northeast-1

② スタックを削除する

sam delete --stack-name s3-event-lambda-stack --region ap-northeast-1

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

削除完了の確認

aws cloudformation describe-stacks --stack-name s3-event-lambda-stack --region ap-northeast-1

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

バケット削除を忘れて sam delete が失敗した場合

Error: Failed to delete the stack: s3-event-lambda-stack, ...
The following resource(s) failed to delete: [UploadBucket]

このエラーが出た場合は、バケットを空にしてから再度 sam delete を実行します。

aws s3 rm s3://%BUCKET% --recursive --region ap-northeast-1
sam delete --stack-name s3-event-lambda-stack --region ap-northeast-1

トラブルシューティング

まとめ

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

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

• !Sub "${AWS::StackName}-upload-${AWS::AccountId}" でバケット名のグローバルユニークを自動保証（コンソール版では手動で一意な名前を考える必要がある）
• Type: S3 の1行でS3イベント通知設定とLambdaリソースベースポリシーを自動作成（コンソール版では「トリガーを追加」の手動操作が必要）

このハンズオンの発展形

• S3からファイルの中身を読み取る — Lambda の実行ロールに s3:GetObject 権限を追加して、CSVやJSONを読み込む処理に拡張
• DynamoDBへの記録 — ファイル情報をDynamoDBに書き込んで一覧管理
• 特定のフォルダ・拡張子のみトリガー — Prefix: images/ や Suffix: .csv でフィルタリング
• 画像リサイズ — Pillow ライブラリと組み合わせてアップロード時に自動リサイズ

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

SAMが裏で何をやっているか、全く同じ構成をAWSコンソールのみで構築する手順をまとめました。「バケット名のグローバルユニーク問題」や「再帰呼び出しの警告」など、コンソールならではのつまずきポイントが体験できます。

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

関連記事

Amazon検索[本 AWS 開発]

The post AWSハンズオン - S3へのファイルアップロードをトリガーにLambdaを自動起動しよう【SAM版 / Windows対応】 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.

はじめに

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

今回のハンズオンでは、AWS SAM（Serverless Application Model） を使って以下の構成を実装します。

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

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

• メッセージの送信・受信の仕組み（キューとLambdaのポーリング構造）
• バッチ処理（最大5件まとめてLambdaに渡す）
• デッドレターキュー（DLQ）（失敗メッセージを退避・後処理できる仕組み）
• SAMテンプレート1ファイルでSQS・DLQ・Lambda・IAM権限を一括管理

この記事の特徴：

• Windows（VSCode + コマンドプロンプト）での実際の手順を詳細に解説
• DLQが動くまでの待機時間など、つまずきやすいポイントに注意書きあり
• ハンズオン完了後の sam delete による完全クリーンアップ手順まで含む

Amazon検索[本 AWS 開発]

SQS（メッセージキュー）とは

キューが解決する問題

SQSがない場合、送信者（API・バッチ）は処理者（Lambda）に直接データを渡します。処理者が落ちていたり過負荷だと、データが失われます。

SQSを挟むと、送信者はキューに投げるだけ。処理者は自分のペースでキューからメッセージを取り出せます。これが非同期処理の基本形です。

前提条件

以下のツールがインストール・設定済みであることを確認してください。

AWS認証の確認

aws sts get-caller-identity

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

使用するAWSサービス

学習目的の短時間ハンズオンであれば、ほぼ無料枠内で収まります。

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

VSCodeでプロジェクトフォルダを開きます。

cd C:\my-aws\aws-learning-projects\sqs-lambda-queue

フォルダ構造

sqs-lambda-queue/
├── template.yaml       # SAMテンプレート（SQS + DLQ + Lambda定義）
├── samconfig.toml      # デプロイ設定（gitignore対象・毎回手動作成が必要）
├── docs/
│   ├── 1_console.md    # AWSコンソール版手順
│   └── 2_sam.md        # SAM版手順
└── src/
    └── app.py          # Lambda関数（メッセージ処理・DLQテスト用エラー機能）

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

template.yaml がAWSリソース全体の設計図です。SQS・DLQ・Lambda・IAM権限をすべてこのファイル1つで定義します。

AWSTemplateFormatVersion: '2010-09-09'
Transform: AWS::Serverless-2016-10-31
Description: SQS + Lambda message queue processing

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

Resources:
  BatchDLQ:
    Type: AWS::SQS::Queue
    Properties:
      MessageRetentionPeriod: 86400   # メッセージ保持期間: 1日（86400秒）

  # メインキュー
  BatchQueue:
    Type: AWS::SQS::Queue
    Properties:
      VisibilityTimeout: 180          # Lambda タイムアウト(30s) × 6 = 180s
      RedrivePolicy:
        deadLetterTargetArn: !GetAtt BatchDLQ.Arn   # DLQのARNを自動参照
        maxReceiveCount: 3            # 3回失敗でDLQに移動

  # Lambda 関数
  ProcessFunction:
    Type: AWS::Serverless::Function
    Properties:
      CodeUri: src/
      Handler: app.lambda_handler
      Description: SQSからメッセージを受信して処理するLambda関数
      Policies:
        - SQSPollerPolicy:            # SQS から読み取る権限を自動付与
            QueueName: !GetAtt BatchQueue.QueueName
      Events:
        SQSEvent:
          Type: SQS
          Properties:
            Queue: !GetAtt BatchQueue.Arn   # メインキューと自動連携
            BatchSize: 5              # 一度に最大5件まとめて処理

Outputs:
  BatchQueueUrl:
    Description: "メインキューのURL"
    Value: !Ref BatchQueue
  BatchDLQUrl:
    Description: "DLQのURL"
    Value: !Ref BatchDLQ
  ProcessFunctionArn:
    Description: "Lambda 関数 ARN"
    Value: !GetAtt ProcessFunction.Arn

template.yaml のポイント解説

SQSPollerPolicy（SAM組み込みポリシー）
sqs:ReceiveMessage / sqs:DeleteMessage / sqs:GetQueueAttributes の3つの権限が1行で自動付与されます。コンソール版では AWSLambdaSQSQueueExecutionRole を IAM コンソールで手動アタッチする必要があります。

RedrivePolicy: !GetAtt BatchDLQ.Arn
DLQのARNをSAMが自動参照します。コンソール版ではDLQを先に作成してARNをコピー・貼り付けする必要がありますが、SAMではその手間が不要です。

VisibilityTimeout: 180
Lambda タイムアウト（30秒）× 6 = 180秒。これはAWSの推奨値です。処理中にタイムアウトが切れると、同じメッセージが再度キューに現れて二重処理が発生するため、Lambda タイムアウト × 6 以上を設定するのがベストプラクティスです。

Type: SQS イベント
SQS と Lambda のイベントソースマッピング（「トリガー」）を自動作成します。コンソール版では Lambda の「トリガーを追加」画面で手動設定が必要です。

DLQ登場の順序について：
SAMテンプレートでは BatchDLQ → BatchQueue → ProcessFunction の順で記述しています。
これは CloudFormation の依存解決の都合上、参照先（DLQ）を先に定義する必要があるためです。
コンソール版も同じ理由で「DLQ → メインキュー → Lambda」の順で作成します。

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

src/app.py がメッセージ処理の本体です。SQSからのメッセージをループ処理し、本文が error の場合は意図的に例外を発生させてDLQへの振り分けをテストできます。

import json
import datetime


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

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

        # DLQテスト用: "error" というメッセージを受信したら意図的に例外を発生させる
        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}

app.py のポイント解説

event["Records"]
SQSからのメッセージはリスト形式で渡されます。BatchSize: 5 の場合、最大5件がまとめて渡されるため、for ループで1件ずつ処理します。

raise ValueError(...)
例外を発生させると Lambda が失敗扱いになり、SQSがメッセージを再試行します。3回失敗するとDLQへ移動します。これがDLQの動作確認に使えます。

外部ライブラリ不使用
標準ライブラリ（json, datetime）のみ使用するため、requirements.txt が不要です。

Step 4: samconfig.toml を作成する

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

sqs-lambda-queue/samconfig.toml を新規作成して以下を貼り付けてください。

version = 0.1

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

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

【注意】samconfig.toml の置き場所

sqs-lambda-queue/ フォルダの直下に置く必要があります。
別のフォルダに置くと以下のエラーが発生します：

Error: Missing option '--stack-name', 'sam deploy --guided' can be used to...

Step 5: sam build（ビルド）

cd C:\my-aws\aws-learning-projects\sqs-lambda-queue
sam build

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

Build Succeeded

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

Step 6: sam deploy（デプロイ）

sam deploy

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

Deploy this changeset? [y/N]: y

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

デプロイ完了の確認

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

CloudFormation outputs from deployed stack
----------------------------------------------------------------------
Outputs
----------------------------------------------------------------------
Key    BatchQueueUrl
Value  https://sqs.ap-northeast-1.amazonaws.com/123456789012/sqs-lambda-queue-stack-BatchQueue-XXXX

Key    BatchDLQUrl
Value  https://sqs.ap-northeast-1.amazonaws.com/123456789012/sqs-lambda-queue-stack-BatchDLQ-XXXX

Key    ProcessFunctionArn
Value  arn:aws:lambda:ap-northeast-1:123456789012:function:sqs-lambda-queue-stack-ProcessFunction-XXXX
----------------------------------------------------------------------

BatchQueueUrl と BatchDLQUrl を控えておきます。（テスト時に使います）

Step 7: 動作テスト

7-1. 正常処理テスト

まず環境変数にキューのURLを設定します。

set QUEUE_URL=https://sqs.ap-northeast-1.amazonaws.com/123456789012/sqs-lambda-queue-stack-BatchQueue-XXXX

メッセージを送信します。

aws sqs send-message ^
  --queue-url %QUEUE_URL% ^
  --message-body "こんにちは、SQS！" ^
  --region ap-northeast-1

レスポンス例：

{
    "MD5OfMessageBody": "...",
    "MessageId": "xxxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxxxx"
}

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

aws logs tail /aws/lambda/sqs-lambda-queue-stack-ProcessFunction-XXXX --follow

期待するログ出力：

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

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

7-2. 複数メッセージテスト（バッチ処理確認）

aws sqs send-message --queue-url %QUEUE_URL% --message-body "メッセージ1" --region ap-northeast-1
aws sqs send-message --queue-url %QUEUE_URL% --message-body "メッセージ2" --region ap-northeast-1
aws sqs send-message --queue-url %QUEUE_URL% --message-body "メッセージ3" --region ap-northeast-1

BatchSize: 5 なので、3件まとめて Lambda に渡される可能性があります（タイミングによる）。まとめて渡された場合のログ：

{"messageId": "...", "body": "メッセージ1", "processedAt": "...", "status": "processed"}
{"messageId": "...", "body": "メッセージ2", "processedAt": "...", "status": "processed"}
{"messageId": "...", "body": "メッセージ3", "processedAt": "...", "status": "processed"}
{"processedCount": 3}

"processedCount": 3 が1回のLambda呼び出しで表示されれば、バッチ処理（まとめて処理）が機能しています。

7-3. DLQテスト（処理失敗 → DLQへの振り分け確認）

aws sqs send-message ^
  --queue-url %QUEUE_URL% ^
  --message-body "error" ^
  --region ap-northeast-1

処理の流れ：

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

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

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

set DLQ_URL=https://sqs.ap-northeast-1.amazonaws.com/123456789012/sqs-lambda-queue-stack-BatchDLQ-XXXX

aws sqs receive-message ^
  --queue-url %DLQ_URL% ^
  --region ap-northeast-1

レスポンス例（メッセージが届いていれば表示されます）：

{
    "Messages": [
        {
            "MessageId": "...",
            "Body": "error",
            "ReceiptHandle": "...",
            "MD5OfBody": "..."
        }
    ]
}

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

receive-message が空を返す場合：
DLQ にまだ届いていないか、すでに一度受信済みの状態です（SQSは受信後に可視性タイムアウトが入る）。
SQS コンソール → BatchDLQ → 「メッセージをポーリング」でも確認できます。

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

デプロイしたリソースをコンソールから目視確認できます。

• SQS（メインキュー）: SQS → sqs-lambda-queue-stack-BatchQueue-XXXX → 「メッセージを送受信」で残件数確認
• SQS（DLQ）: SQS → sqs-lambda-queue-stack-BatchDLQ-XXXX → 「メッセージをポーリング」でDLQの中身確認
• Lambda: Lambda → 関数 → sqs-lambda-queue-stack-ProcessFunction-XXXX → 「設定」→「トリガー」でSQSトリガーを確認
• CloudWatch Logs: Lambda → 対象関数 → 「モニタリング」タブ → 「CloudWatch Logs を表示」

Step 9: リソースの削除

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

sam delete --stack-name sqs-lambda-queue-stack --region ap-northeast-1

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

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

削除完了の確認

aws cloudformation describe-stacks --stack-name sqs-lambda-queue-stack --region ap-northeast-1

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

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

メッセージが残っていた場合：
sam delete で SQS キュー内に残っているメッセージも一緒に削除されます。
DLQ に残ったメッセージの内容を記録しておきたい場合は、削除前に aws sqs receive-message で確認しておいてください。

トラブルシューティング

まとめ

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

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

• SQSPollerPolicy 1行で IAM 権限の設定が完了（コンソール版では手動でポリシーをアタッチ）
• !GetAtt BatchDLQ.Arn でARNの手動コピー不要（コンソール版ではDLQ作成後にARNをコピー・貼り付け）
• sam delete でSQS×2・Lambda・IAMロール・S3を一括削除

このハンズオンの発展形

• SNS との組み合わせ — SQS の前段に SNS を置くと、複数の SQS キューに同時配信（ファンアウト）できる
• メッセージフィルタリング — SQSのメッセージ属性を使って特定のメッセージだけをLambdaに渡す
• 可視性タイムアウトの動的変更 — 処理に時間がかかる場合はLambdaから ChangeMessageVisibility を呼ぶ
• DLQ のアラーム設定 — CloudWatch アラームでDLQにメッセージが届いたらSlack通知

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

SAMが裏で何をやっているか、全く同じ構成をAWSコンソールのみで手作業で構築する手順をまとめました。コンソール版では「DLQ作成 → メインキュー作成 → Lambda作成 → IAM権限追加 → トリガー追加」の順で6つのリソース設定が必要です。

• AWSコンソールだけでSQS + Lambdaキュー処理を構築する手順【SAM版との比較付き】

関連記事

Amazon検索[本 AWS 開発]

The post AWSハンズオン - SQS + Lambdaでメッセージキュー処理を実装しよう【SAM版 / Windows対応】 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.