Bucket causes error for Lambda Trigger - Invalid Argument

I am happy to try to help here. I have pretty good experience using S3 Event Notification with Lambda Functions. Maybe I can ask you a few questions: It sounds like you are saying that you have one S3 Bucket yet when the Put Event happens, you want more than one Lambda Function to handle that event. Is that correct? If so, are you specifying Prefix or Suffix in the Create Event Notification wizard in the S3 Bucket so that one Lambda Function is triggered for one type of file, such as .jpg, and another Lambda Function is triggered for another type of file, such as .txt?

Here's something to understand: When you choose to set up Event Notification in S3 there is a finite list of events like Put, Post, Copy, Multipart upload completed, etc. The rule is that each event can only have one Destination. If you go through the Create Event Notification wizard in the S3 Bucket to tie an event to a Lambda Function, any given event can only be configured for a single Destination. For example, you cannot configure the Put event in a single bucket to notify more than one Lambda Function nor can you configure the Put event to notify both a Lambda Function and an SNS Topic.

If you are specifying Prefix and/or Suffix when setting up these event notifications you might be able to configure the same S3 Event to trigger different Lambda Functions although I have not tried that yet.

Now, if you really do need multiple Lambda Functions to be run any time an object is created in that single S3 Bucket, you will have better luck using EventBridge. I can help with that, too, if you need.

TheSpunicorn

Root Cause Analysis:

• The S3 manual lists the error plausible root causes as follows. Link
• PutBucketNotification API action explains the following: 1, 2

• *The PUT notification is an atomic operation. For example, suppose your notification configuration includes SNS topic, SQS queue, and Lambda function configurations. When you send a PUT request with this configuration, Amazon S3 sends test messages to your SNS topic. If the message fails, the entire PUT action will fail, and Amazon S3 will not add the configuration to your bucket. *

1. Scenario 1 - new Event:

Repro steps:

      * Add an Event to the S3 bucket with a target or either SNS or SQS where each topic/queue has an IAM Resource Policy that BLOCKS the bucket from accessing it.
      * Expected Result: 
      * The Bucket fails to send a test message to the SNS/SQS topic/queue thus failing with the error Error: Invalid Argument, you can confirm this via CloudTrail logs for the Bucket using the Resource name field.
      * Actual Result:
      * Same as expected

2. Scenario 2 - modified Event/Trigger or adding event/Trigger to a bucket previously configured with Events:

Precondition:

      * An S3 bucket with existing Event Notifications pointing to either SNS, SQS or Lambda function 

Repro steps:

     * After successfully configuring the S3 bucket with an Event that CAN ACCESS the SNS Topic/SQS queue and passes the test, MODIFY the Access Policy of said SNS Topic/SQS queue to DENY access from the bucket to it, either implicitly by allowing another bucket under the Resources list or   explicitly by adding a Deny effect.
     * Add/Modify a Lambda trigger.
     * Expected Result: The Trigger is added/Modified
     * Actual Result: The error documented in the link above is thrown by the API: 

An error occurred when creating the trigger: Unable to validate the following destination configurations (Service: Amazon S3; Status Code: 400; Error Code: InvalidArgument

Analysis conclusion:

1. Because the S3 PutBucketNotification CHECKS every Event currently existing in the bucket for accessibility once the Resource Policy of the SNS Topic/SQS queue is modified to DENY the bucket from accessing it this accessibility test from the bucket FAILS, throwing the error listed under Actual Result above.
2. The mistake is human and one of mismanagement of the resources integrated with the S3 bucket through its Event Notification interface.
3. Unfortunately the AWS back-end logic is designed to perform this test on EVERY S3 bucket Notification Target every time a new Event is added to the bucket(confirmed through CloudTrail logs on which you can see a json list object with EVERY SINGLE Event Notification configured in the bucket being re-submitted instead of the event you've been working on).
4. Because of the fact that S3 checks for every event target every time a new event is added/modified this propitiates a failure and creates the illusion that something is wrong with the Bucket Event notification the user is actively modifying/adding(Lambda) when in reality is ANOTHER event in the bucket that's the problem
5. In our Test cases the SNS Topic or SQS queue are breaking the AWS S3 Event accessibility test.