Today, AWS has three frameworks to build infrastructure logic and runtime logic for applications based on Amazon API Gateway and AWS Lambda. These are the AWS Cloud Development Kit (AWS CDK), AWS Serverless Application Model (AWS SAM), and AWS Chalice. In this blog post, I will describe tradeoffs between some combinations of them.

To begin with, AWS recently announced the general availability of SAM CLI (v1.0.0). SAM CLI allows to locally invoke Lambda functions generated by CDK. CloudFormation and SAM section in CDK FAQ provides a general guideline for choosing between CDK and CloudFormation/SAM. In a gist, it says the following: “If you prefer defining your serverless infrastructure in concise declarative templates, SAM is the better fit. If you want to define your AWS infrastructure in a familiar programming language, we encourage you to try out AWS CDK.”. I would like to further expand on that and add Chalice into the mix.

If you’d like to generate SAM resources using CDK (might be useful for working with generated SAM template in an IDE and AWS Toolkit, for example), there is an aws-sam module in CDK. This is an easy way to combine CDK and SAM for new code. As for existing CloudFormation templates generated by SAM, you can include them in a broader CDK application using the cloudformation-include module (it’s currently experimental, some features are still being worked on). That would be all my thoughts about interoperability between CDK and SAM as of today :).

Chalice takes a different approach to application modeling. Unlike SAM, where I would say infrastructure logic encapsulates runtime logic (the Lambda function code for example), Chalice generates infrastructure logic based on runtime logic (using @route annotations) and its configuration file format. With SAM, you can express anything CloudFormation can express about API Gateway, Lambda, and additional AWS resources. Chalice framework can also generate a SAM template, but its flexibility is tightly coupled to whatever Chalice configuration can support at the time. See AWS CloudFormation Support in Chalice documentation for more details. For example, only recently Chalice added support for custom domain names.

I outlined an approach for combining CDK and Chalice in the Deploying AWS Chalice application using AWS Cloud Development Kit blog post. That should allow you to enjoy both worlds - use a familiar microframework programming model (Chalice is very similar to Flask in this regard) and also write the infrastructure logic using CDK, all in Python. To achieve this, I developed an open-source library called cdk-chalice, that automates the generation of Chalice configuration file and respective SAM template from CDK code. It is possible to reference resources generated as part of the Chalice SAM template in the broader CDK application, in addition to passing values from CDK to Chalice configuration. Today it requires knowing resource names and using CDK lookup functions for CloudFormation to reference these resources. There is an open issue in the cdk-chalice repository to consider using the aforementioned cloudformation-include module once it’s stable. The module can help to make the resources generated by Chalice available as native CDK objects.

As a closing thought, another thing to consider regarding SAM is that it doesn’t provide a runtime level framework. Serverless Framework, Chalice, and others have a lot of developer boilerplate done for you - blueprints, CORS modeling, HTTP requests parsing, logging, and in-app authorization integration. Using CDK to define some of the aforementioned configuration (e.g. CORS) balances things a bit as compared to relying on frameworks for this, but still less straightforward in my personal opinion. That’s why I often debate between the two when thinking about a recommendation for one or the other.

Hope the above provided a good summary of current options and trade-offs involved, to help you decide in either direction :).