【AWS】Lambdaは呼び出されるだけじゃない！SQS連携で学ぶイベントソースマッピングとイベントフィルタリング
はじめに
こんにちは、ニシグチです。AWSの資格勉強などをしていると、「SQSにデータが入ったらLambdaが起動する」という流れをよく目にすると思います。
私自身も「SQSがLambdaを呼び出している（動かしている）」と思っていました。
しかし、実務で仕様を調べる中で、「誰が誰を呼び出しているのか？」 という仕組みの根本を理解できていなかったことに気づきました。
この記事では、Lambdaの呼び出しモデルの違いを整理した上で、Lambdaが主体となって見に行く「イベントソースマッピング」と、その中で無駄な実行を抑える「イベントフィルタリング」の実践結果をまとめます。
1. Lambdaの2つの呼び出しモデル（プッシュ型 vs プル型）
公式ドキュメントを読み解くと、Lambdaの起動方法は大きく2つに分かれます。
| 分類 | 主導権（主語） | 仕組み（モデル） | 主なサービス |
|---|---|---|---|
| イベント駆動型（同期・非同期） | 相手のサービス | プッシュ型（呼び出される） | S3, API Gateway, SNS |
| イベントソースマッピング | Lambda側 | プル型（見に行く・呼び出す） | SQS, Kinesis, DynamoDB Streams |
「呼び出される」イベント駆動（プッシュ型）
S3にファイルが置かれたり、API Gatewayにリクエストが来たりした時に、相手のサービスがLambdaを1回だけ呼び出し（Invoke）に来るタイプです。
「見に行く」イベントソースマッピング（プル型）
SQSなどは「データを溜めておくだけの箱」です。SQSがLambdaを呼び出すのではなく、Lambda側の仕組み（イベントソースマッピング）がSQSへデータを見に行き（ポーリング）、溜まっていれば自分自身（関数）を呼び出すタイプです。
2. なぜこの違いが重要なのか？
「見に行っているのがLambda側（イベントソースマッピング）」だと理解すると、各種設定をどこで行うべきかの理由がすっきり繋がります。
例えば、SQSから届く特定のデータだけを処理したい場合、SQS側ではなくLambda側の「イベントソースマッピング」でフィルタリング設定を行うことになります。
3. 【実践】イベントソースマッピングでフィルタリングしてみる
今回は、SQSに届いたメッセージのうち、特定の条件（type: order）を満たす時だけLambdaが起動する設定を試します。
構成
-
SQS: 標準キュー（名前
sample-queueにしてそれ以外デフォルトで作成） - Lambda: 到着したイベントをログ出力するシンプルなコード
- トリガー設定: イベントソースマッピングにフィルタリング条件（JSON）を追加
Lambda関数は作成後、以下コードに
import json
def lambda_handler(event, context):
# SQSから届いたメッセージ（event）をログに出力するだけ
print("Received event:", json.dumps(event))
return {
'statusCode': 200,
'body': json.dumps('Hello from Lambda!')
}
コードを変更したらDeployをクリックして変更を反映します。
フィルタリング条件の追加ボタンをクリックしたらJSON形式の入力欄が表示されるので
以下を入力します。
{
"body": {
"type": ["order"]
}
}
トリガーの追加完了
IAM権限の付与【★ハマりポイント】
LambdaがSQSを見に行ってメッセージを削除できるように、Lambdaの実行ロールに AWSLambdaSQSQueueExecutionRole というAWS管理ポリシーをアタッチしておきます。
4. 検証結果：本当にLambdaは起動しないのか？
パターンA：条件に一致するメッセージを送信（type: order）
SQSに以下のメッセージを送信します。
{
"type": "order",
"item": "Apple"
}
以下のメッセージ送受信をクリック
メッセージ本文に先程のjsonをコピーしてメッセージ送信をクリック
今度はLambda側のコンソールからモニタリングタブのCloudWatch Logsを見に行きます。
【結果】
CloudWatch Logsにログが出力され、Lambdaが正しく起動されたことが確認できました！
パターンB：条件に一致しないメッセージを送信（type: cancel）
今度は条件外のメッセージをSQSに送信します。
{
"type": "cancel",
"item": "Apple"
}
先ほどと同様の画面から上記jsonを貼り付けてメッセージ送信します。
【結果】
SQSにはメッセージが送信されましたが、CloudWatch Logsには新しいログが1行も増えませんでした。
つまり、Lambdaのコードの中で if 文で判定してスキップしているのではなく、Lambdaが起動する前（イベントソースマッピング）の段階で不要なメッセージが遮断されていることが実証できました！
まとめ
- Lambdaの連携には 「呼び出される側（プッシュ型）」 と 「見に行く側（プル型）」 がある
- SQS連携は イベントソースマッピング（プル型） であり、Lambda側が主導権を持っている
- イベントフィルタリングを活用することで、Lambdaの無駄な起動（コスト）を抑え、コードもシンプルに保つことができる
資格勉強で得た点と点の知識が、実際に手を動かすことで線としてつながりました。同じように「SQSがLambdaを呼んでいる」と思っていた方の参考になれば幸いです！
おまけ
この前7/31にJAWS-UG神戸のコミュニティイベントにて初めてのLT登壇をしてきました。
【JAWS-UG 神戸 #13】夏を乗り切る！LT会
LTの内容は以前記事にしたことを喋ってきました。
神戸支部では自由な内容でのLT会を二ヶ月にみたいなので、私みたいなAWSこれから頑張ろうって方も気軽に参加出来ると思います。アウトプットの機会を探している方は是非！