Constant ID on Bucket Notification Configuration Prevents Parallel Deployments

[jamiepedwards]

Describe the bug When attempting to do parallel deployments of the WAF (e.g. if deploying a new version alongside the existing one to allow a smooth transition), it errors out on the ConfigureAppAccessLogBucket resource with the error message "Failed to create resource. An error occurred (InvalidArgument) when calling the PutBucketNotificationConfiguration operation: Same ID used for multiple configurations. IDs must be unique."

To Reproduce Deploy the v2.3.3 version to an account, then deploy the v3.0.0 version, using the same AppAccessLogBucket value for both, and with both having the same ActivateScannersProbesProtectionParam value

Expected behavior The stack deploys successfully

Please complete the following information about the solution:

• [ ] Version: v3.0.0 and v2.3.3
• [ ] Region: us-east-1
• [ ] Was the solution modified from the version published on this repository?: No
• [ ] If the answer to the previous question was yes, are the changes available on GitHub?
• [ ] Have you checked your service quotas for the sevices this solution uses?: Yes
• [ ] Were there any errors in the CloudWatch Logs?: No

Additional context The issue is due to the fact that the "Id" property of the bucket notification (Lines 139 and 148 in custom-resource.py) is set to a constant value. Since bucket notification configuration IDs must be unique, this causes the custom resource lambda to error out when trying to create the bucket notification configuration. Suggest changing this value to be dynamic - either a unique ID or based off of the name of the stack.

[aijunpeng]

Thanks for reporting the issue. Please provide the values for the input parameters for both cloudformation stacks. However, the recommended upgrade path for the solution is to delete the old stack and deploy the new stack with new s3 bucket.

[jamiepedwards]

Here's the parameters for each stack: v3.0.0: Key	Value	Resolved Value
ActivateAWSManagedRulesParam	yes	-
ActivateBadBotProtectionParam	yes	-
ActivateCrossSiteScriptingProtectionParam	yes	-
ActivateHttpFloodProtectionParam	yes - AWS WAF rate based rule	-
ActivateReputationListsProtectionParam	yes	-
ActivateScannersProbesProtectionParam	yes - AWS Lambda log parser	-
ActivateSqlInjectionProtectionParam	yes	-
AppAccessLogBucket	cgna-618833736385-alblogs-bucket	-
EndpointType	ALB	-
ErrorThreshold	50	-
KeepDataInOriginalS3Location	No	-
RequestThreshold	100	-
WAFBlockPeriod	240	-

v2.3.3 Key	Value	Resolved Value
ActivateBadBotProtectionParam	yes	-
ActivateCrossSiteScriptingProtectionParam	yes	-
ActivateHttpFloodProtectionParam	yes - AWS WAF rate based rule	-
ActivateReputationListsProtectionParam	yes	-
ActivateScannersProbesProtectionParam	yes - AWS Lambda log parser	-
ActivateSqlInjectionProtectionParam	yes	-
AppAccessLogBucket	cgna-618833736385-alblogs	-
EndpointType	ALB	-
ErrorThreshold	50	-
KeepDataInOriginalS3Location	No	-
RequestThreshold	2000	-
WAFBlockPeriod	240	-

I was able to work around the issue by changing the AppAccessLogBucket. The two primary factors involved in reproducing the bug are having the EndpointType parameter set to "ALB" and the AppAccessLogBucket being identical on both stacks.

When I reviewed the guide (https://s3.amazonaws.com/solutions-reference/aws-waf-security-automations/latest/aws-waf-security-automations.pdf), it advocated a blue/green approach for solution update, which would require parallel deployment, I'm not seeing anything mentioning deleting the stack and rebuilding it - not to mention the fact that this would be enormously complicated and risky in a large environment with many ALBs relying on that stack.

Having parallel stacks would greatly simplify the transition process, allowing one to opportunistically shift workloads over to the new WAF instead of having to coordinate a knife-edge cutover.

[aijunpeng]

Thanks for your prompt response. You can deploy new stack using new s3 AppAccessLogBucket in parallel with the old stack if you don't change endpoint type. We added the issue to our backlog for further evaluation and it will be addressed in a future release as needed.

[CovertLeopard]

I ran into this exact problem today. Changing the bucket name did indeed allow us to work around the issue.

[SanthoshBachu11]

Changing the s3 bucket name will work Note: Don't create s3 bucket in s3 console just give the new bucket name in the field AppAccessLogBucket: Your new bucket name

[aijunpeng]

Closing this old issue due to inactivity