AWS LambdaのS3トリガー設定で「Configuration is ambiguously defined」エラーが発生するパターン

AWS LambdaのS3トリガー設定で「Configuration is ambiguously defined」エラーが発生するパターン

2025.11.19

はじめに

AWS Lambda と Amazon S3 を連携させる際、S3 バケットのイベント通知(Event Notification)を使って Lambda 関数をトリガーできます。

ところが、通知設定を複数追加しようとした時、次のようなエラーが出ることがあります。

Configuration is ambiguously defined

cm-hirai-screenshot 2025-11-18 9.08.42

このエラーは、通知設定の「イベントタイプ」と「プレフィックス/サフィックス(Filter)」の組み合わせが既存設定と重複するかあいまいになる場合に発生します。

AWS 公式ドキュメントには、Filter を使う通知設定では「overlapping prefixes(重なり合うプレフィックス)」「overlapping suffixes(重なり合うサフィックス)」「prefix と suffix の組み合わせの重複」が同じイベントタイプであってはならないという記載があります。

https://docs.aws.amazon.com/AmazonS3/latest/userguide/notification-how-to-filtering.html?utm_source=openai

実際にAWSコンソールでS3イベント通知を設定する際、以下の注意書きが表示されます。

Lambda 関数をトリガーするイベントを選択してください。オプションで、プレフィックスやサフィックスを設定できます。

※ 注意:同じオブジェクトに一致する可能性のある重複したプレフィックス/サフィックスの組み合わせは設定できません。

cm-hirai-screenshot 2025-11-18 9.03.27

本記事では、どのような設定がエラーになるのか、どのような組み合わせなら問題ないのかを、実際の例を交えて解説します。

S3イベント通知の重複設定に関する制約

S3イベント通知では、同一のイベント条件(プレフィックス/サフィックス、イベントタイプ)に対して、複数のLambda関数をトリガーすることができません。

これは、同じオブジェクトに対する通知先が曖昧になることを防ぐための制約です。

この制約は S3 に特有 のものです。

例えば、Amazon DynamoDB Streams の場合には、S3の「通知設定(event notification)」でのフィルター(プレフィックス/サフィックス)や「Configuration is ambiguously defined」エラーのような重複禁止ルールは、公式ドキュメントには記載されていません。

通知設定の重複(重なり)に関する制約

S3 の通知設定で Filter を使う場合、同じイベントタイプに対して次のような重複またはあいまいな組み合わせは無効です。これらは保存できず、「Configuration is ambiguously defined」エラーを引き起こします。

  • 重なり合うプレフィックス(例:「images/」と「images/thumbnails/」)
  • 重なり合うサフィックス(例:「.json」と「on」など、末尾で重なりうるもの)
  • prefix と suffix の組み合わせが重なる場合(例:あるルールで prefix+suffix、他のルールでサフィックスのみなど)

ただし、以下の条件であれば重複が許されます:

  • イベントタイプが異なる設定同士
  • 同じイベントタイプでも、プレフィックス同士が重なっていても、サフィックスが重ならない組み合わせ
  • またはサフィックス同士が重なっていても、プレフィックスが重ならない組み合わせ

https://docs.aws.amazon.com/AmazonS3/latest/userguide/notification-how-to-filtering.html?utm_source=openai

エラーになる設定の具体例

次のような組み合わせはエラーになります。

パターン1:同じイベントタイプ + 同じプレフィックスのみ

設定1: プレフィックス「images/」 + イベントタイプ s3:ObjectCreated:Put → Lambda A  
設定2: プレフィックス「images/」 + イベントタイプ s3:ObjectCreated:Put → Lambda B

images/photo.jpg をアップロードすると、両方の設定に一致するためエラーになります。

パターン2:同じイベントタイプ + フィルタなし(プレフィックスもサフィックスもなし)

設定1: フィルタなし + イベントタイプ s3:ObjectCreated:Put → Lambda A  
設定2: フィルタなし + イベントタイプ s3:ObjectCreated:Put → Lambda B

PUT イベントが両方の通知に該当するため、どちらを呼ぶか不明瞭になってエラーになります。

パターン3:同じイベントタイプ + プレフィックスとサフィックスの重複可能性

設定1: プレフィックス「data/」 + イベントタイプ s3:ObjectCreated:Put → Lambda A  
設定2: サフィックス「.json」  + イベントタイプ s3:ObjectCreated:Put → Lambda B

一見問題なさそうに見えますが、ファイル data/test.json がアップロードされた場合、両設定に一致するため重複と判断されます。

パターン4:ワイルドカードを含むイベントタイプ・重複条件

設定1: フィルタなし + イベントタイプ s3:ObjectCreated:Put → Lambda A  
設定2: フィルタなし + イベントタイプ s3:ObjectCreated:*   → Lambda B

s3:ObjectCreated:*s3:ObjectCreated:Put を含むため、重複する設定となります。

https://docs.aws.amazon.com/AmazonS3/latest/userguide/notification-how-to-event-types-and-destinations.html?utm_source=openai#supported-notification-event-types

パターン5:ネストしているプレフィックス(プレフィックス同士に包含関係がある)

設定1: プレフィックス「images/」 + イベントタイプ s3:ObjectCreated:Put → Lambda A  
設定2: プレフィックス「images/thumbnails/」 + イベントタイプ s3:ObjectCreated:Put → Lambda B

images/thumbnails/は、images/のサブディレクトリにあたるため、同一イベントタイプでは重複と見なされます。

設定可能なパターン(重複しない設定例)

次のような組み合わせは問題なく設定できます。

パターンA:同じプレフィックスでもイベントタイプが異なる

設定1: プレフィックス「images/」 + イベントタイプ s3:ObjectCreated:Put → Lambda A  
設定2: プレフィックス「images/」 + イベントタイプ s3:ObjectRemoved:*   → Lambda B

イベントタイプが異なるため、同じファイルでも処理が曖昧になることはありません。

オブジェクトの作成時と削除時で通知先が異なり、どちらか一方だけが発火します。

動作例

  • images/photo.jpg をアップロード → Lambda A のみ起動
  • images/photo.jpg を削除 → Lambda B のみ起動

なお、S3バケット画面から、トリガー設定一覧が確認できます。

cm-hirai-screenshot 2025-11-18 9.14.40

パターンB:異なるプレフィックス(重なっていない) + 同じイベントタイプ

設定1: プレフィックス「images/」 + イベントタイプ s3:ObjectCreated:Put → Lambda A  
設定2: プレフィックス「logs/」 + イベントタイプ s3:ObjectCreated:Put → Lambda B

それぞれ対象のオブジェクトの範囲が明確に区別されます。

プレフィックスが異なるため、同じファイルが両方の条件に一致することはありません。

動作例

  • images/photo.jpg をアップロード → Lambda A のみ起動
  • logs/report.pdf をアップロード → Lambda B のみ起動

パターンC:異なるサフィックス + 同じイベントタイプ

設定1: サフィックス「.jpg」 + イベントタイプ s3:ObjectCreated:Put → Lambda A  
設定2: サフィックス「.png」 + イベントタイプ s3:ObjectCreated:Put → Lambda B

サフィックスが互いに重なっていないため、それぞれ異なるファイル拡張子を対象として正しく分けられます。

動作例

  • photo.jpg をアップロード → Lambda A のみ起動
  • logo.png をアップロード → Lambda B のみ起動

パターンD:同じプレフィックス内でサフィックスのみを使い分ける

設定1: プレフィックス「images/」 + サフィックス「.jpg」 + イベントタイプ s3:ObjectCreated:Put → Lambda A  
設定2: プレフィックス「images/」 + サフィックス「.png」 + イベントタイプ s3:ObjectCreated:Put → Lambda B

プレフィックスは同じですが、サフィックスが異なり重なり合わず、設定として有効です。

回避策

どうしても同じイベントタイプ + 重複するプレフィックス/サフィックスの条件で複数処理を行いたい場合、次のような方法があります。

方法1:SNS や SQS を使ったファンアウト

S3イベント → SNS トピック → Lambda A  
                         → Lambda B  
                         → Lambda C

S3 の通知先を Amazon SNS(または SQS)にすると、そこから複数の Lambda に分岐できます。

方法2:親 Lambda を経由して呼び出す

S3イベント → 親の Lambda → Lambda A  
                        → Lambda B

単一の Lambda をトリガーして、そこから invoke() を使って他の Lambda を呼び出す構成です。

方法3:EventBridgeを利用する

S3バケットのAmazon EventBridge通知を有効化し、EventBridge ルールから複数のLambdaに送る構成です。

以下の設定方法は、記事が参考になります。

https://dev.classmethod.jp/articles/lambda-trigger-eventbridge-s3/

最後に

Amazon S3 の通知設定で「Configuration is ambiguously defined」エラーが発生する主な原因は、同じイベントタイプ重なり合うプレフィックス/サフィックスを持つルールを複数定義してしまうことです。

Filterを使う通知設定においてプレフィックス/サフィックスの重複が禁止されており、これは同じオブジェクトに対して複数の通知先が曖昧になることを防ぐための制約です。

同じ条件で複数処理が必要な場合は、紹介した回避方法を検討してください。

この記事をシェアする

FacebookHatena blogX

関連記事