--- title: "EventBridgeからSQS・Lambdaへつなぐ設定｜キューポリシー・FIFO・部分バッチ応答とDLQ【2026年10月】" url: "https://www.issoh.co.jp/tech/details/6034/" published: 2025-03-26 updated: 2026-10-30 categories: ["AWS"] publisher: "株式会社一創" --- # EventBridgeからSQS・Lambdaへつなぐ設定｜キューポリシー・FIFO・部分バッチ応答とDLQ【2026年10月】 EventBridgeのルールでイベントを受け、SQSに溜めてからLambdaで処理する構成は、イベントの発生量と処理能力を切り離すための定番です。つまずきは3つのサービスの境目で起きます。「ルールは一致しているのにキューに届かない」「FIFOにしたら処理が1本しか走らない」「失敗したメッセージがどこにも残らない」の3つが代表例です。 この記事は、EventBridgeからSQS、SQSからLambdaへとつなぐ2つの接続部分に絞り、権限・パラメータ・失敗時の行き先をAWS公式ドキュメント（2026年10月30日時点）の仕様で整理します。2026年9月24日に追加された新しいCustom Event Busでキューへ送る場合の違いも扱います。SQS単体の仕組みは[Amazon SQSの解説記事](/tech/details/17241/)、EventBridge単体の仕組みは[Amazon EventBridgeの解説記事](/tech/details/15513/)に譲ります。 ## まとめ｜EventBridge→SQS→Lambda構成の要点 - SQSを挟む理由は、Lambdaの同時実行数を`MaximumConcurrency`で絞り、処理しきれないイベントをキューの保持期間内で待機させること。直結だとLambdaの非同期呼び出しのリトライ（追加2回・最大6時間）に任せることになる。 - ルールからSQSへ送るには、キューのリソースポリシーで`events.amazonaws.com`に`sqs:SendMessage`を許可し、`aws:SourceArn`をルールのARNに絞る（ターゲットにIAM実行ロールを指定する方法もある）。SSE-KMSならカスタマー管理キーが必要。 - FIFOキューへ送るときは`MessageGroupId`に`$.detail.customerId`のようなJSONパスを書けば、顧客ごとにグループを分けて並列に処理できる。ただし、FIFOが保つのはキューへの到着順であり、Classicのルール経由ではイベントの発生順までは保証されない。固定値にすると全件が1グループに入り、Lambdaは1本ずつしか動かない。 - キューの可視性タイムアウトは「関数タイムアウトの6倍＋バッチウィンドウ」以上にし、`ReportBatchItemFailures`で失敗したメッセージだけを戻す。 - 失敗の退避先は接続部分ごとに違う。SQSに届かなかったイベントはルールのターゲットDLQ、Lambdaで処理に失敗し続けたメッセージはソースキューのDLQに入る。関数に設定するDLQは、この構成では使われない。 - 新しいCustom Event Busのサブスクライバーは、権限がキューポリシーでなく配信ロール、既定の再試行が5回・300秒と短い。従来のルールの感覚で組むと、5分を超える障害でイベントがDLQ行きになる。 ## EventBridgeとLambdaの間にSQSを挟む判断基準 EventBridgeのルールはLambdaを直接ターゲットにできます。この場合の呼び出しは非同期で、関数がエラーを返すとLambdaが既定で追加2回実行し、スロットリングやシステムエラーは既定で最大6時間再試行します。それでも処理できなかったイベントは、関数に設定したon-failure送信先へ送られます。 | 観点 | ルール→Lambda直結 | ルール→SQS→Lambda | | ------- | ---------------- | ------------------------------- | | 流量の制御 | 予約同時実行数のみ | ESMのMaximumConcurrency（2〜1,000） | | 再試行 | 関数エラーは既定で追加2回 | maxReceiveCountまで再受信 | | 滞留できる期間 | 最大6時間 | キューの保持期間（最大14日） | | バッチ処理 | 1イベント1呼び出し | 標準キューで最大10,000件 | | 失敗の保管先 | 関数のon-failure送信先 | ソースキューのDLQ | SQSを挟むべきなのは、下流のDBや外部APIに同時接続数の上限があるとき、処理が数時間止まっても後から追いつかせたいとき、束ねて処理した方が安いときです。逆に、イベントが1日数百件で処理が数秒で終わり、失敗しても発生元から取り直せるなら直結で足ります。キューとDLQという監視対象を2つ増やすだけの価値がありません。 ## EventBridgeルールのターゲットにSQSを設定する手順 ルール側の設定は「イベントパターン」「ターゲット（キューのARN）」「リトライポリシー」「ターゲット用DLQ」の4点です。コンソールで同じアカウントのキューを選ぶとキューポリシーが自動で付きますが、CloudFormationや`PutTargets` APIで作るときは自分で付けます。 ### キューのリソースポリシーとaws:SourceArn条件 EventBridgeがキューへ書き込むには、キューのリソースポリシーでサービスプリンシパル`events.amazonaws.com`に`sqs:SendMessage`を許可します。条件に`aws:SourceArn`を付けてルールのARNに限定しないと、同じアカウントの別のルールからもこのキューへ書き込めてしまいます。ターゲットに`sqs:SendMessage`を持つIAM実行ロール（`RoleArn`）を指定すればキューポリシーは不要になりますが（[EventBridgeのリソースベースポリシー](https://docs.aws.amazon.com/eventbridge/latest/userguide/eb-use-resource-based.html)）、ここではキュー側で送信元を絞れるポリシー方式を使います。次のテンプレートは、キュー、ルール用DLQ、ポリシー、Lambdaのイベントソースマッピング（ESM）までをまとめたものです。cfn-lint 1.46.0で静的検証してエラーが出ないことを確認しています（実環境へのデプロイは未実施）。 前提は3つです。同じリージョンに既存のLambda関数があり、そのARNを`WorkerFunctionArn`に渡すこと。関数の実行ロールに`sqs:ReceiveMessage`・`sqs:DeleteMessage`・`sqs:GetQueueAttributes`があること（AWS管理ポリシー`AWSLambdaSQSQueueExecutionRole`に含まれ、SSE-KMSのキューなら`kms:Decrypt`も要る）。関数タイムアウトが30秒以下であること（可視性タイムアウト180秒の根拠）。 ``` AWSTemplateFormatVersion: "2010-09-09" Parameters: WorkerFunctionArn: Type: String Resources: OrderDLQ: Type: AWS::SQS::Queue Properties: MessageRetentionPeriod: 1209600 OrderQueue: Type: AWS::SQS::Queue Properties: VisibilityTimeout: 180 RedrivePolicy: deadLetterTargetArn: !GetAtt OrderDLQ.Arn maxReceiveCount: 5 RuleTargetDLQ: Type: AWS::SQS::Queue OrderCreatedRule: Type: AWS::Events::Rule Properties: EventBusName: default EventPattern: source: ["com.example.orders"] detail-type: ["OrderCreated"] Targets: - Id: order-queue Arn: !GetAtt OrderQueue.Arn RetryPolicy: MaximumEventAgeInSeconds: 3600 MaximumRetryAttempts: 20 DeadLetterConfig: Arn: !GetAtt RuleTargetDLQ.Arn OrderQueuePolicy: Type: AWS::SQS::QueuePolicy Properties: Queues: [!Ref OrderQueue, !Ref RuleTargetDLQ] PolicyDocument: Version: "2012-10-17" Statement: - Effect: Allow Principal: Service: events.amazonaws.com Action: sqs:SendMessage Resource: [!GetAtt OrderQueue.Arn, !GetAtt RuleTargetDLQ.Arn] Condition: ArnEquals: aws:SourceArn: !GetAtt OrderCreatedRule.Arn OrderQueueMapping: Type: AWS::Lambda::EventSourceMapping Properties: EventSourceArn: !GetAtt OrderQueue.Arn FunctionName: !Ref WorkerFunctionArn BatchSize: 10 MaximumBatchingWindowInSeconds: 0 FunctionResponseTypes: [ReportBatchItemFailures] ScalingConfig: MaximumConcurrency: 20 ``` ルールのターゲットDLQにもEventBridgeが書き込むので、同じポリシーでDLQへの`sqs:SendMessage`も許可しています。`RetryPolicy`を省略すると、再試行できる配信エラーには既定で24時間・最大185回の再試行がかかります（[EventBridgeのリトライポリシー](https://docs.aws.amazon.com/eventbridge/latest/userguide/eb-rule-retry-policy.html)）。ただし権限不足、削除済みのターゲット、見つからないターゲットは再試行せず、ターゲットDLQへ直接送られます。上の例では1時間・20回に縮め、早めにDLQへ落として気づけるようにしています。 ### SSE-KMSで暗号化したキューに届かない原因 ポリシーが正しいのに配信が失敗する典型は暗号化です。EventBridgeは、AWS所有キーで暗号化したSQSキューをターゲットにもDLQにも使えません（[EventBridgeのターゲット仕様](https://docs.aws.amazon.com/eventbridge/latest/userguide/eb-targets.html)）。SSE-KMSでAWS管理キー（`alias/aws/sqs`）を使ったキューも、そのキーポリシーは編集できないため、EventBridgeに鍵の利用を許可できません。 SSE-KMSで暗号化するなら、カスタマー管理キーを作り、キーポリシーで`events.amazonaws.com`に`kms:Decrypt`と`kms:GenerateDataKey`を許可します。鍵の問題でキューに届かないときは、ターゲットDLQに入ったメッセージの属性`ERROR_CODE`に`NO_PERMISSIONS`などの理由が残ります。ルールを作った直後にテストイベントを1件送り、キューに届いたかを確かめる手順を入れておくと切り分けが早くなります。 ### FIFOキューと公平キューへ送るときのMessageGroupId FIFOキューをターゲットにする条件は2つです。ターゲットの`SqsParameters.MessageGroupId`を指定すること（最大100文字）と、キュー側でコンテンツベース重複排除を有効にしておくことです（[API Reference: Target](https://docs.aws.amazon.com/eventbridge/latest/APIReference/API%5FTarget.html)）。コンテンツベース重複排除ではメッセージ本文のハッシュが重複排除IDになり、同じ本文を5分以内に送ると1件として扱われます。EventBridgeのイベントは`id`と`time`を含むので、別のイベントが同じ本文になることは通常ありません。 設計を分けるのは`MessageGroupId`の値です。`SqsParameters`は動的パスパラメータに対応しており、`$.detail.customerId`のように値全体をJSONパスにすると、イベントの中身でグループが決まります。固定文字列を書くと全イベントが1グループに入ります。LambdaはFIFOキューの同時呼び出し数を「グループ数」と「最大同時実行数」の小さい方に抑えるので、固定値では関数が1本ずつしか動きません。順序が要るのは顧客単位・注文単位であることがほとんどなので、その単位のIDをパスで指定します。 2025年11月13日からは、SQSの公平キュー（fair queue）もターゲットに選べます（[AWSの発表](https://aws.amazon.com/about-aws/whats-new/2025/11/amazon-eventbridge-sqs-fair-queue-targets/)）。公平キューは標準キューにメッセージグループIDを付けたもので、順序は保証しない代わりに、1つのテナントが大量に送ってもほかのテナントの処理が待たされにくくなります。マルチテナントのSaaSで特定の顧客のバッチ投入が全体を遅らせているなら、FIFOより公平キューが合います。考え方は[ノイジーネイバー問題の解説](/tech/details/7732/)で扱っています。なお、ルールのターゲットDLQにはFIFOキューを指定できず、標準キューだけが使えます。 ## 新しいCustom Event BusのサブスクライバーでSQSへ送る場合の違い 2026年9月24日、EventBridgeにサブスクライバー型の新しいCustom Event Busが追加されました。従来のバスは「Custom Event Bus – Classic」と表示が変わり、ルールとターゲットの仕組みはそのまま動きます。新しいバスでは、受け手が「サブスクライバー」を作り、フィルタ・届け先・再試行・DLQをその単位で持ちます。SQSへ送る部分の違いは次のとおりです（[サブスクライバーの再試行とDLQ](https://docs.aws.amazon.com/eventbridge/latest/userguide/eb-custom-bus-retry.html)、[SQSキューターゲット](https://docs.aws.amazon.com/eventbridge/latest/userguide/eb-custom-bus-target-sqs.html)）。 | 観点 | Classicのルール | 新バスのサブスクライバー | | --------- | ------------------ | -------------------------- | | 送信の権限 | IAM実行ロールまたはキューポリシー | 配信ロール（RoleArn） | | 既定の再試行 | 24時間・185回 | 300秒・5回 | | 権限不足の扱い | 再試行せずDLQへ | 再試行してからDLQへ | | DLQに入るもの | イベント本体 | 失敗の記録（イベントIDなど） | | 送信単位 | 1イベント1メッセージ | SendMessageBatchで最大10件 | | FIFOの重複排除 | コンテンツベースが必須 | MessageDeduplicationIdも指定可 | 最も事故につながるのは既定の再試行です。上限は`MaxRetryAttempts`（0〜185）と`MaxEventAgeInSeconds`（60〜86,400秒）で、既定は5回・300秒です。従来のルールで1日の再試行に頼っていた設計を移すなら、`MaxEventAgeInSeconds`を86,400、`MaxRetryAttempts`を185に明示します。配信は時間と回数のどちらかの上限に先に達すると終了するため、時間だけを延ばしても既定の5回で再試行が尽きる場合があります。DLQを指定しないと、再試行が尽きたイベントは捨てられ、残る痕跡はメトリクス`EventsDropped`だけです。 DLQに入るのはイベント本体ではなく、`errorCode`と`failedMessages[].eventId`を持つJSONの記録です。そのため元のキューへ戻すリドライブはできず、バスの保持期間内のイベントを、時刻とイベントIDで絞った一時的なサブスクライバーで再生して取り直します。配信ロールにはキューへの`sqs:SendMessage`に加えて、DLQへの`sqs:SendMessage`も要ります。この権限が無いとDLQへ失敗記録を書き込めませんが、`OnFailureDestinationFailed`メトリクスで書き込み失敗を検知できます。 ``` aws eventsv2 create-subscriber \ --name order-created-to-queue \ --event-bus-arn arn:aws:events:ap-northeast-1:111122223333:event-busv2/orders/EXAMPLE1234567890abcdef \ --filter-configuration '{"Filters":[{"Scope":"DATA","Pattern":"{\"detail-type\":[\"OrderCreated\"]}"}]}' \ --invoke-configuration '{"TargetArn":"arn:aws:sqs:ap-northeast-1:111122223333:order-queue","RoleArn":"arn:aws:iam::111122223333:role/EventBusDeliveryRole"}' \ --retry-policy '{"MaxRetryAttempts":185,"MaxEventAgeInSeconds":86400}' \ --on-failure-configuration '{"Arn":"arn:aws:sqs:ap-northeast-1:111122223333:order-queue-dlq"}' ``` この例は`PutEvents`で発行したイベントを前提にしています。実行前にバス・キュー・DLQ・配信ロールを用意し、例示ARNを実際のARNに置き換えて、AWS CLIのリージョンを東京に設定します。配信ロールではEventBridgeからの引き受けを許可し、実行者にはサブスクライバー作成権限と配信ロールへの`iam:PassRole`を付与します。`PutEvents`で発行すると、フィルタが照合する`Data`は`source`・`detail-type`・`detail`を持つ従来と同じ形になり、キューに届く本文も同じ形です。`PutRawEvents`で発行したときは、送ったペイロードがそのまま本文になります。形を取り違えたフィルタはエラーにならず、何にも一致しないだけなので、作成後に一致するイベントと一致しないイベントを1件ずつ送って確かめます。新旧バスのそれ以外の違いは[EventBridgeの解説記事](/tech/details/15513/)、データ量で決まる新バスの料金は[EventBridgeの料金の解説](/tech/details/3341/)で扱っています。 ## SQSからLambdaへのイベントソースマッピング設定 SQSからLambdaへの接続は、Lambda側のESMがキューをポーリングして関数を同期的に呼び出す仕組みです。Classicのルールから入ったメッセージの本文には、イベントのJSON全体（`version`・`source`・`detail-type`・`detail`など）が文字列で入ります。関数ではまず`body`をJSONとして読み、`detail`を取り出します。 ### バッチサイズとバッチウィンドウ 1回の呼び出しに渡す件数は、標準キューで最大10,000件、FIFOキューで最大10件です（[SQSイベントソースマッピングの設定](https://docs.aws.amazon.com/lambda/latest/dg/services-sqs-configure.html)）。メッセージとメタデータの合計がLambdaの同期呼び出しペイロード上限6MBに達すると、設定した件数より少なくなります。10件を超える値を指定するときは`MaximumBatchingWindowInSeconds`を1秒以上にする必要があり、標準キューで設定できる範囲は0〜300秒（既定0秒）です。FIFOキューではバッチウィンドウを設定できません。 ### 可視性タイムアウトの推奨値と算出式 AWSの推奨は、キューの可視性タイムアウトを関数タイムアウトの6倍以上にし、バッチウィンドウを使う場合はその秒数も足すことです。関数タイムアウト30秒・バッチウィンドウ0秒なら180秒以上で、上のテンプレートの`VisibilityTimeout: 180`はこの計算です。余裕を持たせるのは、前のバッチの処理中にスロットリングされた場合でもLambdaが再試行できるようにするためです。 関数タイムアウトが可視性タイムアウトを超える設定は、ESMの作成・更新時にエラーになります。関数のタイムアウトだけを後から延ばすと次のESM更新で初めて失敗するので、2つの値は同じテンプレートで管理します。 ### 部分バッチ応答（ReportBatchItemFailures）の実装 既定では、バッチ内の1件でも処理に失敗すると、バッチ全体が可視性タイムアウト後にキューへ戻ります。成功した分まで再処理されるのを避けるには、ESMの`FunctionResponseTypes`に`ReportBatchItemFailures`を指定し、関数から失敗したメッセージのIDだけを`batchItemFailures`で返します。次の例は標準キュー向けで、本文が注文情報を含むJSONオブジェクトであることを前提に、Classicのルール経由と新バスの`PutRawEvents`経由の両方の本文を読めるようにしています。`process`は入力値を検査するだけのダミーで、実際の業務処理に置き換えます。 ``` import json def process(order): # 冪等に書く：同じ order_id が2回届いても結果が変わらない処理にする if order.get("amount", 0) < 0: raise ValueError("invalid amount") def handler(event, context): failures = [] for record in event["Records"]: try: body = json.loads(record["body"]) # PutEvents 由来はイベント全体（本体は detail）、PutRawEvents 由来は本体だけが届く order = body["detail"] if "detail-type" in body else body process(order) except Exception: failures.append({"itemIdentifier": record["messageId"]}) return {"batchItemFailures": failures} ``` 3件のうち2件目だけ`amount`が負のバッチをローカルで渡すと、戻り値は`{"batchItemFailures": [{"itemIdentifier": "m2"}]}`になり、全件成功なら空の配列が返ります。空の配列は「全件成功」の意味なので、例外を握りつぶして空を返すと失敗が消えます。FIFOキューでは最初の失敗で処理を止め、失敗分と未処理分をまとめて返して順序を保ちます。 ESMの配信は少なくとも1回で、同じメッセージが2回処理されることがあります。部分バッチ応答を入れても重複は消えないため、処理自体を冪等にしておきます。注文IDなどの業務キーで二重処理を止める方法は[冪等キーの実装解説](/tech/details/16293/)、S3から受けたCSVを分割して流す実装例は[Lambda×SQSのCSV一括インポート](/tech/details/1884/)で扱っています。 ### 最大同時実行数とプロビジョンドモードによる負荷制御 標準キューの場合、Lambdaはメッセージがあると5つの同時呼び出しから始め、1分ごとに最大300ずつ増やし、1つのESMで最大1,250まで広げます（[SQSイベントソースのスケーリング](https://docs.aws.amazon.com/lambda/latest/dg/services-sqs-scaling.html)）。下流のDB接続数に上限があるなら、`ScalingConfig.MaximumConcurrency`（2〜1,000）でESM単位の上限をかけます。この値は関数の予約同時実行数とは別の設定で、予約同時実行数を設定する場合は、その関数につながるすべてのSQSイベントソースの最大同時実行数の合計以上を確保します。他の呼び出し元がある場合は、その分の余裕も必要です。 流量の急増に立ち上がりを合わせたいときは、専用のポーラーを確保するプロビジョンドモードを使います。ポーラー1台あたり最大1MB/秒・同時10呼び出しを捌き、最小ポーラー数は2〜200（既定2）で指定します。1分あたり最大1,000ずつ同時呼び出しを増やせる一方、追加料金がかかり、最大同時実行数の設定とは併用できません。1,250を超える同時実行が要るのも、このモードを使う場面です。 ## 失敗したイベントの行き先｜ルールのDLQ・ソースキューのDLQ・関数の送信先 「DLQを設定したのに失敗が残らない」ときは、そのDLQが受け持つ失敗かを確認します。失敗は接続部分ごとに別の退避先へ行きます。 | 設定場所 | 受け持つ失敗 | キューの制約 | | ---------------- | -------------------- | --------------- | | ルールのターゲットDLQ | EventBridge→SQSの配信失敗 | 標準キューのみ・同一リージョン | | ソースキューのリドライブ | Lambdaでの処理失敗の繰り返し | ソースと同じ種別のキュー | | 関数のon-failure送信先 | ルール→Lambda直結での失敗 | SQSは標準キューのみ | EventBridge→SQS→Lambda構成で処理エラーを受けるのは、2行目のソースキューのリドライブポリシーです。関数に設定したDLQやon-failure送信先は非同期呼び出し用で、ESM経由の呼び出しには使われません。AWSはリドライブポリシーの`maxReceiveCount`を5以上にするよう推奨しており、小さすぎるとスロットリングだけでメッセージがDLQへ移ります。1行目のルールのターゲットDLQに溜まったときは、Lambdaのコードではなく、キューポリシーと暗号化キーを疑います。 ### DLQに溜まったメッセージを元のキューへ戻す手順 ソースキューのDLQに溜まったメッセージは、原因を直した後に`StartMessageMoveTask`（コンソールでは「DLQリドライブ」）で元のキューへ戻せます。移動速度は最大500件／秒まで指定でき、タスクは最大36時間実行できます。1つのキューで同時に動かせるタスクは1つだけです（[SQSのDLQリドライブ](https://docs.aws.amazon.com/AWSSimpleQueueService/latest/SQSDeveloperGuide/sqs-configure-dead-letter-queue-redrive.html)）。 ``` aws sqs start-message-move-task \ --source-arn arn:aws:sqs:ap-northeast-1:123456789012:OrderDLQ \ --max-number-of-messages-per-second 50 ``` `--destination-arn`を省略すると、元のソースキューへ戻ります。一気に戻すと関数が再びスロットリングされるので、最大同時実行数の範囲で捌ける速度に絞ります。ルールのターゲットDLQに入ったイベントはこのリドライブの対象外です。中身を読み出して元のキューへ送り直す処理を別に用意します。PutEventsでイベントバスへ再投入する方法もありますが、一致するほかのルールにも再配信されるため、再送範囲と重複処理を確かめてから行います。 ## キューにイベントが届かないときの切り分けと監視 届かないときは、上流の接続部分から順にメトリクスで潰します。 ### ルール・ターゲット・キューの順で確かめるメトリクス 1. ルールの`TriggeredRules`にデータが無ければ、イベントがパターンに一致していない。イベントの送り先のバスと、`source`・`detail-type`の綴りを確かめる。 2. `TriggeredRules`があり`FailedInvocations`も出ていれば、配信で失敗している。原因の多くはキューポリシーの不足かKMSのキーポリシーで、ターゲットDLQの`ERROR_CODE`属性で特定できる。 3. どちらも正常なのにLambdaが動かないなら、キュー側の`NumberOfMessagesSent`で着信を確かめ、ESMの状態（無効化されていないか）と関数の`Throttles`を見る。 ルールの一致とログの調べ方は[EventBridgeのログの調べ方](/tech/details/18449/)で詳しく扱っています。新バスのサブスクライバーは指標の名前空間が`AWS/EventsV2`に変わり、`FilterEvaluated`→`FilterMatched`→`EventsDelivered`の順に、どこで件数が途切れたかを見ます。 ### 常時アラームを掛けるメトリクス - EventBridge側：`FailedInvocations`と`InvocationsFailedToBeSentToDlq`。後者が出たらDLQ自体のポリシーを疑う。 - SQS側：ソースキューの`ApproximateAgeOfOldestMessage`と、2つのDLQの`ApproximateNumberOfMessagesVisible`。 - Lambda側：関数の`Errors`と`Throttles`。部分バッチ応答で例外を捕捉する場合、失敗は`Errors`に出ないので、失敗件数を独自メトリクスで記録し、messageIdと例外内容もログへ残す。 DLQに1件でも入ったら、通常経路で配信または処理を完了できなかったイベントがあるため、原因調査と再処理の対象にします。最古メッセージの滞留時間には注意点があり、標準キューで`maxReceiveCount`が3を超えると、3回以上受信された未削除のメッセージはキューの末尾へ回され、指標はその次のメッセージの年齢を示します（[SQSのデッドレターキュー](https://docs.aws.amazon.com/AWSSimpleQueueService/latest/SQSDeveloperGuide/sqs-dead-letter-queues.html)）。失敗を繰り返すメッセージがあっても滞留時間が伸びないことがあるので、DLQの件数と組み合わせて見ます。リクエストが3つのサービスをどう流れたかを追うなら、[AWS X-Rayの使い方](/tech/details/6812/)で扱うトレースを併用します。 ## SQSをソースにするEventBridge Pipesの使いどころ EventBridge Pipesは、SQSなどのソースからメッセージを取り出し、フィルタ・加工を経て1つのターゲットへ渡すサービスです。SQSの先がLambda以外（Step Functions、別のイベントバス、API送信先など）のときに、つなぐためだけのLambdaを書かずに済むのが利点です。 SQSソースのPipesのAPI設定範囲はバッチサイズ1〜10,000件、バッチウィンドウ0〜300秒ですが、実際のバッチサイズはターゲットの対応上限にも制限されます。加工先やターゲットがバッチ非対応なら、ソース側でもバッチ処理を有効にできません。フィルタに一致しなかったメッセージは、キューから自動で削除されます。東京リージョンの料金はフィルタ通過後のリクエスト100万件あたり0.50米ドルで、ペイロード64KBごとに1リクエストと数えます（[AWS Price List APIの東京の価格表](https://pricing.us-east-1.amazonaws.com/offers/v1.0/aws/AWSEvents/current/ap-northeast-1/index.json)、2026年9月24日版）。除外したメッセージも消えるので、ほかの処理が読むメッセージを混ぜず、パイプ専用のキューを使います。 SQSの先がLambdaだけならPipesは挟みません。料金が増えるだけで、ESMの部分バッチ応答や最大同時実行数に当たる制御は増えないからです。複数の処理を順に呼ぶなら[AWS Step Functionsの解説](/tech/details/15429/)で扱うステートマシンを、Pipesの実装例は[EventBridge Pipesの使い方](/tech/details/18422/)を参照してください。 ## S3イベント通知とEventBridge経由のS3イベントの違い S3のオブジェクト作成をSQSで受けるとき、S3のイベント通知で直接SQSへ送る方法と、EventBridge経由で送る方法があります。 | 観点 | S3イベント通知（直接） | EventBridge経由 | | ------- | ----------------- | ----------------- | | 配信先 | SNS・SQS・Lambda | ルールの全ターゲット | | フィルタ | キー名のprefix／suffix | イベントJSONの任意フィールド | | FIFOキュー | 非対応 | ターゲットとして指定可 | | 有効化 | 通知設定ごとに送信先を指定 | バケット単位でオン（反映に約5分） | 直接通知では、同じイベント種別に対して通知対象が重複するフィルタ設定は使えません。ただし、プレフィックスが重なってもサフィックスが重ならなければ設定できます。絞り込みもキー名の前方・後方一致に限られます。同じイベントを複数のキューへ配信したり、キー名以外の条件で振り分けたりするならEventBridge経由、1つのキューに送るだけなら直接通知の方が設定が少なく済みます。EventBridge経由のS3イベントは取り込みが課金対象になる点も、[EventBridgeの料金の解説](/tech/details/3341/)で確かめてから選びます。 EventBridgeとSQSを含むサーバーレス構成の設計や、既存システムからの移行を相談したい場合は、[AWS・Google Cloud・Azureのインフラ構築支援](/service/system/aws/)で対応しています。 ## よくある質問 ### EventBridgeとSQSの違いは何ですか？ EventBridgeはイベントの内容に応じて複数の送り先へ振り分けるルーター、SQSはメッセージを溜めて受け手のペースで取り出させるキューです。役割が違うため、この記事の構成のように振り分けをEventBridge、流量の調整をSQSに任せて組み合わせます。SNSを含めた使い分けは[SQS・SNS・SESの違い](/tech/details/9310/)で整理しています。 ### SQSの可視性タイムアウトとは何ですか？ 受信されたメッセージを、ほかの受け手から一時的に見えなくしておく時間です。この間に処理と削除が終わらないとメッセージは再び見えるようになり、別の呼び出しで重複処理されます。Lambdaと組み合わせる場合は、関数タイムアウトの6倍以上（＋バッチウィンドウ）が推奨値です。 ### EventBridgeからSQSのFIFOキューへ送れますか？ 送れます。ターゲットにMessageGroupIdを指定し、キュー側でコンテンツベース重複排除を有効にします。MessageGroupIdは固定値でなくJSONパスで指定でき、顧客IDなどでグループを分ければ並列に処理できます。ルールのターゲットDLQにはFIFOキューを使えないので、標準キューを別に用意します。 ### Lambda関数にDLQを設定したのに失敗したSQSメッセージが入らないのはなぜですか？ 関数に設定するDLQは非同期呼び出し用で、SQSのイベントソースマッピング経由の呼び出しには使われないためです。処理に失敗したメッセージを退避させるには、ソースキューのリドライブポリシーでDLQと`maxReceiveCount`を設定します。 ### EventBridgeで送れるイベントの最大サイズはいくつですか？ Classicのバスへの`PutEvents`は、1リクエスト最大10件・合計1,048,576バイト未満で、1件だけなら1イベントで最大1MBまで使えます。SQSのメッセージ最大サイズも1MiB（1,048,576バイト）です。料金はどちらも64KB単位で数えるため、大きなデータはS3に置いてキーだけを送る方が安く済みます。 ## 関連記事 - [Amazon SQSとは？FIFOキューと標準キューの違い・重複排除・可視性タイムアウトとDLQの設計【2026年10月】](/tech/details/17241/) - [Amazon EventBridgeとは？仕組み・料金とCLI・Pythonでの実装手順、新Custom Event Busとの違いを解説【2026年版】](/tech/details/15513/) - [EventBridge ログの調べ方：ルールが発火しない原因をメトリクス・バスログ・DLQで特定する](/tech/details/18449/) - [AWS Lambdaとは？仕組み・料金体系とコールドスタート対策・採用判断を実装者目線で解説](/tech/details/15407/) - [イベント駆動アーキテクチャとは？仕組み・実装パターンと採用判断を実装者目線で解説](/tech/details/13226/) --- 出典: [EventBridgeからSQS・Lambdaへつなぐ設定｜キューポリシー・FIFO・部分バッチ応答とDLQ【2026年10月】]()（株式会社一創）