[discussion] bundled code can potentially be too big for Lambda function.

Nobody has claimed this yet.

Right now, `magic-cfn-resources` has users create the `handler` for the Lambda function in the repository they are working in. Therefore, because the handler is in the repository, the code for the Lambda function is bundled with the repository, and the entirety of the repository is part of the bundled code referenced in the Lambda function. This can lead to the Lambda function that creates the magic resource to fail to create because it has a requirement of `Unzipped size must be smaller than 262144000 bytes`.

The actual resources to make a `magic-cfn-resource` is not anywhere near the limit, but the current set up makes it so it's possible code from the repository a magic-cfn-resource is used in can breach the size limit. Therefore, one idea is to bundle the code for magic-cfn-resources and place it on S3. Them, refer to where the code is when creating a magic-cfn-resource.

However, the issue is how do we access the magic-cfn-resource if we are using multiple AWS accounts? The goal of creating magic-cfn-resources was so all the resources necessary to create a magic-cfn-resource lived really close to the repository that uses it. By creating a designated location for magic-cfn-resource code as mentioned in the solution above, it defeats the original intent.

@jakepruitt, @rclark, and I are still discussing how to move forward. Will leave this ticket open for discussion.

No files, tests, or entry points are named. Start by reviewing the current repository-local handler bundling and the Lambda size constraint, then resolve the multi-account deployment approach; done means the team has an agreed design that avoids unrelated repository code while preserving the intended proximity to the consuming repository.

Written by the indexing model from the issue text.