fix(s3): enabling EventBridge on many buckets exceeds IAM policy size limit

[vishwakt]

Closes #38041.

Reason for this change

Enabling EventBridge notifications on a bucket (via the eventBridgeEnabled prop or enableEventBridgeNotification()) routes through the stack-singleton BucketNotificationsHandler custom resource. That handler's IAM role accumulates one s3:PutBucketNotification policy statement per bucket, so stacks with many EventBridge-enabled buckets exceed the 10,240 byte IAM role policy size limit at deploy time:

Maximum policy size of 10240 bytes exceeded for role <Stack>-BucketNotificationsHandler...

EventBridge enablement is a simple boolean on the bucket and, unlike Lambda/SQS/SNS notification targets, has no circular-dependency reason to go through the custom resource. It can be set directly on the bucket resource's NotificationConfiguration.EventBridgeConfiguration property.

Description of changes

Behind a new feature flag @aws-cdk/aws-s3:eventBridgeNotificationViaCfnProperty (FlagType.BugFix, recommended true, unconfiguredBehavesLike: { v2: false }):

• EventBridge notifications for buckets created in the current stack are rendered directly on the AWS::S3::Bucket resource. An EventBridge-only bucket no longer creates the custom resource or its per-bucket IAM policy.
• Buckets that also have Lambda/SQS/SNS notifications keep the custom resource, which continues to render EventBridge so its (full-overwrite) PutBucketNotification call does not drop it. This is handled for both orderings (enable EventBridge first then add a target, and vice versa).
• Imported buckets have no bucket resource to set and continue to use the custom resource.

Why a feature flag (migration safety): switching an existing stack from the custom resource to the native property in place would, in a single deployment, add the native property and delete the custom resource. CloudFormation does not guarantee the bucket update runs after the resource deletion, and the custom resource's Delete handler issues put_bucket_notification_configuration({}), which could wipe the configuration on a live bucket. Gating behind a flag means existing stacks keep the current behavior and only new stacks (or explicit opt-in) get the native property.

Describe any new or updated permissions being added

None. This change removes IAM policy statements (the per-bucket handler policy is no longer created for EventBridge-only buckets).

Description of how you validated changes

Unit tests in aws-s3/test/notification.test.ts covering:

• EventBridge-only bucket with the flag on: native property set, no custom resource, no Lambda handler.
• enableEventBridgeNotification() called after construction.
• EventBridge + a topic notification: custom resource keeps EventBridge, bucket does not duplicate it.
• Topic notification added before enabling EventBridge (reverse ordering).
• Flag off: behavior unchanged (still routes through the custom resource).
• Imported bucket: routes through the custom resource even with the flag on.

Added integ test integ.bucket-eventbridge-notification-via-property whose snapshot shows a single AWS::S3::Bucket carrying EventBridgeConfiguration and zero Custom::S3BucketNotifications resources.

Note for reviewers: I don't have deploy access, so the integ snapshot was generated via integ-runner --dry-run (synth-accurate). The template is correct (native config, no custom resource), but the live getBucketNotificationConfiguration assertion was not executed against AWS. Happy to have it deployed/verified.

Checklist

• My code adheres to the CONTRIBUTING GUIDE and DESIGN GUIDELINES

Credit to @fsojye for the report and reproduction, and to @pahud for the root-cause diagnosis on the issue.

---

By submitting this pull request, I confirm that my contribution is made under the terms of the Apache-2.0 license

[aws-cdk-automation]

(This review is outdated)

✅ Updated pull request passes all PRLinter validations. Dismissing previous PRLinter review.