Issues with this solution (and the blog post)

[Shogan]

I have recently been trying to deploy this stack and solution to a newly setup org with control tower configured, but ran into various issues with this solution. Here is a list of problems:

1. This solution is not really scalable. If a new account is provisioned using the Account Factory, then the stack needs to be re-deployed and updated to add the new Account ID (if wishing to exclude it in AWS Config).
2. The list of AWS Resource Types is not scalable either. CloudFormation limits the size of data going into stack input fields to 4096 bytes. If I supply a large list of AWS Resource Types to exclude, I very quickly hit this limit.
3. The stack by default fails to deploy. The CopyZips function fails on trying to copy the lambda source files from the marketplace-sa-resources S3 bucket. I'm assuming the key in this bucket that is referenced either no longer exists, or is not publicly accessible? I had to work around this by bundling the lambda python functions with the cfnresponse.py module into zip files, uploaded to my own, private S3 bucket, and then updated the template to reference these new locations.

Is there a way to simply disable AWS Config altogether for Control Tower, or alternatively update AWS Config manually in newly provisioned accounts to pause config collection but not cause any issues with the Control Tower stacks and drift?

[be-aws-architect]

This solution is not really scalable. If a new account is provisioned using the Account Factory, then the stack needs to be re-deployed and updated to add the new Account ID (if wishing to exclude it in AWS Config).

This has nothing to do with scalability, its way more logical to automatically include an account than excluding it.

The list of AWS Resource Types is not scalable either. CloudFormation limits the size of data going into stack input fields to 4096 bytes. If I supply a large list of AWS Resource Types to exclude, I very quickly hit this limit. However, to hit that, you need to put in like 100 resources. At that point, you're probably better off putting default recording to daily by default..

This is indeed annoying, but not a limitation of this product, but of Cloudformation itself. Easily fixed with multiple parameters and joining them together.

The stack by default fails to deploy. The CopyZips function fails on trying to copy the lambda source files from the marketplace-sa-resources S3 bucket. I'm assuming the key in this bucket that is referenced either no longer exists, or is not publicly accessible? I had to work around this by bundling the lambda python functions with the cfnresponse.py module into zip files, uploaded to my own, private S3 bucket, and then updated the template to reference these new locations.

Not sure what happened here, but this works for me without issues.