Deploy lambdas with single Cloudformation template

Question

TLDR: Is there a way to -- using a single Cloudformation template -- deploy a lambda function with code in S3 or ECR?

Say I have two Lambda functions.

• Function A has code in an S3 bucket and relies on a Lambda Layer
• Function B is a containerized function with the image in an ECR instance

Here's my deployment setup for the two functions:

function-a/
  s3-bucket.template       // CFN Stack template for S3 bucket
  lambda-function.template // CFN Stack template for lambda function
  deploy.sh                // Script that creates S3 bucket template,
                              builds/uploads code,
                              and creates lambda function stack
function-b/
  ecr.template             // CFN Stack template for ECR instance
  lambda-function.template // CFN Stack template for lambda function
  deploy.sh                // Script that creates ECR,
                              builds/uploads docker image,
                              and creates lambda function stack

Results: 4 Cloudformation stacks, 1 S3 bucket, 1 ECR, 2 Lambda functions

I find this amount of configuration setup for these two functions needlessly complex. I understand that buckets and registries need to exist. But I don't want to explicitly define/deploy/manage them using extra build steps.

What else I looked at: I checked AWS SAM -- but SAM also doesn't absolve me from managing the code deployment myself. I used AWS CDK which actually abstracts this away. But for certain reasons I don't want to use CDK here atm. I do not want to use the Serverless framework.

I'm disappointed that most of the examples from the documentation of Cloudformation and SAM just end up creating buckets and registries manually. This doesn't seem like a scalable way to handle it for many environments. This isn't Infrastructure-as-Code.

Is there a simpler way?

Answer 1

The S3 bucket and ECR would be reused for future functionality. So I think of it as two shared resources (S3 code bucket and ECR) and then two new resources (the new Lambda functions).

Most likely you'll have a stack of shared items, things are used by everything but don't structurally change that much. Then another stack of application functions, which will likely change more often. Separating these two different types of things is a good idea.