We chose AWS CDK over Serverless Framework as it provides stronger support for code re-use and modular software development, better IaC testing capabilities and tooling.

Comparison of CloudFormation (+ SAM) vs. Serverless Framework vs. AWS CDK: CloudFormation, with SAM (Serverless Application Model) syntax

:plus: Extensive documentation
:plus: Not too verbose for common scenarios
:minus: For anything non-standard, we are forced to use the verbose CloudFormation syntax

Serverless Framework

:plus: Less verbose than CloudFormation for common scenarios
:plus: Plugins make certain operations much simpler (e.g. serverless-domain-manager + serverless-certificate-creator)
:minus: For anything non-standard, we are forced to use CloudFormation syntax
:minus: Creating variations of the same set of resources with different parameters is not simple (as opposed to CDK constructs)
:minus: More generally, there is no support for code re-use (beyond including YAML chunks)
:minus: As it uses specific DSL that is being translated into CloudFormation (CF) DSL one has to reason in two modes when looking at the resulting CF stacks, interpretation of default values for some configuration properties (e.g. logging for API Gateway, etc.) can be surprising
:minus: There’s no way to preview the generated CF template for validation purposes
:plus: :minus: Controls Lambda code bundling with a purpose of making it user-friendly, but inevitably introduces constraints, which show up when you have many lambda functions

AWS CDK

:plus: Concise syntax
:plus: When constructs exist, really easy to use
:plus: The object model that is used in CDK is very close to CF DSL, the low-level Cfn-* are 1to1 wrappers of the CF ones
:plus: The use of Typescript (and other languages) enables type-checking, autocompletion and unit testing. Due to the fact that it is a plain-old Typescript code re-use (npm modules + packages) is possible and is highly encouraged (and can be done once for multiple platforms via aws/jsii )
:plus: There is substantial documentation now:
:plus: The existing set of constructs (see documentation mentioned above) plus our cdk-constructs library are sufficient to implement a system of virtually any complexity
:minus: Due to the fact that for CDK a programming language is supposed to be used, if a developer is inclined to use an imperative style of programming (rather than declarative or functional) the constructs are highly likely to be written in imperative style. With YAML imperative style is practically impossible. However, the constructs allow the interface to remain highly declarative thus hiding the imperative nature of implementation even in the worst case scenario.
:minus: There is no self-evident migration path from the stacks deployed using serverless to the stacks deployed using CDK. Thus making it practically impossible to migrate existing infrastructure to CDK.

Dmytro Yurchenko