cloudformation-coverage-roadmap
cloudformation-coverage-roadmap copied to clipboard
AWS::S3::BucketNotification
- Title -> AWS::S3::BucketNotification
- Scope of request -> Allow bucket notifications to be managed separate from the bucket resource itself, resolving a longstanding circular reference problem
- Expected behavior -> I should be able to create auto-named buckets with notifications that invoke Lambda/SNS/SQS
- Links to existing API doc -> see below
- Category tag -> Compute, Storage
- Additional context:
The problem:
- Image thumbnailing is serverless 101. It involves setting up bucket notifications to invoke a Lambda function on file upload to a bucket (then generate the thumbnails and write them back to the bucket).
- A best practice for CloudFormation is to let CloudFormation name your resources wherever possible, and only deal with logical ids, not physical resource ids.
- These two things cannot currently be accomplished simultaneously. There needs to be a Lambda permission or SNS/SQS topic/queue policy, which needs to reference the bucket name, but the permission is checked for at notification configuration creation, before the bucket name could be provided to the permission resource.
Fundamentally, this is because there is not a separation between the the creation of a bucket (and its name) and the settings on that bucket. There are at least three separate places on AWS that say 🤷 to customers and tell them to manually create a bucket name in two separate places, which is brittle both in terms of multiple deployments of the template and in terms of updating that bucket name in the future.
This could instead be solved with a separate BucketNotification resource. The bucket resource would be created first, the name !Ref'd to the relevant places, and then the BucketNotification resource would install the notification configuration onto the bucket.
Would this help solve this SAM issue? https://github.com/awslabs/serverless-application-model/issues/138
Yes, it's exactly that same problem.
AWS folks, any chance this will move onto the board soon?
We're keeping an eye on the +1s on this, but we're trying to prioritize coverage items first.
This took us by surprise today. Seems to make Policy Templates unusable.. Please Fix! We don't like letting workaround hacks live in our production environments.
+1 on this. This has hit us more than once and feel this should be prioritized. It is not possible to achieve what i consider "THE" base use-case for bucket notifications: "read file that was just added to bucket", without resolving to cumbersome workarounds.
A couple of useful links:
Existing Custom Resource which implements this functionality: https://aws.amazon.com/premiumsupport/knowledge-center/cloudformation-s3-notification-lambda/
CDK issue which is blocked by this issue: aws/aws-cdk#4323
+1
+1
+1
+1
+1
+1
Still implementing workarounds like this, https://aws.amazon.com/blogs/mt/resolving-circular-dependency-in-provisioning-of-amazon-s3-buckets-with-aws-lambda-event-notifications/
Plus-one for all of Ben's original points.
+1
+1
+1
Yes! +1
+1
@purnesh @yeDor @IanShoe @kz974 @jamescarignan
- Please vote on this issue by adding a 👍 reaction to the original issue to help the community and maintainers prioritize this request
- Please do not leave "+1" or "me too" comments, they generate extra noise for issue followers and do not help prioritize the request
+1
+1
👍
:+1:
https://github.com/aws/aws-cdk/pull/11773 PR tries to resolve this for AWS CDK.
+1
+1
+1
@pam81 @frank-io @gdelia @itharavi @mrosenlund @KlemenKozelj
If you react with the 👍 button to the original issue, (the first comment, click on the smiley face if you're the first reacting), your votes can be used to sort issues and determine priorities.
A comment will send a notification to everyone (participants and watchers), but cannot be easily counted as a vote for an issue. Thus It's generally better to vote than to comment with "+1". To keep up to date, you can also add yourself as a watcher.
How was this issue resolved? I don't see any updates in the CloudFormation documentation relevant to it, and it still warns against the circular dependency: https://docs.aws.amazon.com/AWSCloudFormation/latest/UserGuide/aws-properties-s3-bucket-notificationconfig.html
+1