Choosing the right tool for your serverless journey.

What tools are available if I want to start building my own serverless applications? We will go over some of the most popular frameworks and tools available for the developer who wants to get started with AWS Lambda.

There are a lot of tools out there to use when building software that are powered by AWS Lambda. These tools aim to ease the process of coding, configuring and deploying the Lambdas themselves but also the surrounding AWS infrastructure. We will discuss the following alternatives:

  • AWS Cloud development kit (CDK)
  • Serverless Framework
  • AWS Serverless Application Model (SAM)
  • Terraform

About AWS CloudFormation

AWS CloudFormation is a service within AWS that lets you group resources (usually AWS resources) into stacks that you can deploy and continuously update. These CloudFormation templates are written in JSON or YAML and manually typing those can be very tedious. Especially when your stack grows to a lot of resources that reference each other in multiple ways. What lots of these frameworks and tools do is to provide an abstraction layer in front of CloudFormation so that the developer can more rapidly create and focus on the business value of the service they are building.

AWS Cloud development kit (CDK)

The AWS CDK went into general availability in the summer of 2019 and has been getting a lot of traction lately. It is an open source framework that lets you create your infrastructure as code instead of CloudFormation. You then generate CloudFormation templates from your code by running the command cdk synthesize.

You can choose from Python, TypeScript, JavaScript, .NET and Java to describe your resources instead of having to do it in pure CloudFormation. This gives you benefits such as code completion and being able to assign resources to variables, which helps you when a resource needs referencing to another one. Another great benefit is that it has helper functions in place to help with common developer use cases. For example setting up a NodeJs Lambda function or constructing ARNs.

The CDK code in the screeenshot will be synthesized to CloudFormation at build time. This example creates a Lambda function, a DynamoDB table and an API Gateway. The example also shows referencing between the resources: for example giving the Lambda function rights to read from the table.

Serverless Framework

This one has been around since 2015 and was called JAWS before quickly changing to its current name. As the very descriptive name says, it’s a framework for building serverless applications! The framework is easy to get started with and setting up an API with a few Lambdas require very little configuration for the developer as the framework takes care of the underlying CloudFormation template.

Because of its specific focus in serverless applications, the framework is not as broad as the CDK and that comes with pros and cons. You will get a lot of help if you are setting up Lambdas or events that trigger those Lambdas, but setting up the surrounding infrastructure such as queues, tables, kinesis streams and cognito user pools will often require you to write pure CloudFormation. At TIQQE, some of us like to create and deploy this surrounding infrastructure with the CDK, while developing the Lambdas  and the API gateway in Serverless Framework.

Serverless Framework is open source and multi-cloud. It’s also extendable with a wide range of plugins created by the community.

Shows the central configuration file in a Serverless Framework service: serverless.yml. When deployed, a Lambda function “myFirstLambda” is created and an API Gateway will be set up with a method to invoke the Lambda at the path /hello.

AWS Serverless Application Model (SAM)

AWS SAM is another framework similar to Serverless Framework that it let’s the developer write less code when building serverless applications. Unlike Serverless Framework, SAM is specific to AWS and its main configuration file template.yml is written with CloudFormation. So if you have previous experience with AWS and CloudFormation you will likely find it easy to get started with SAM. A neat feature in SAM is that it has support to deploy APIs using swagger out of the box. 

Template.yml in a AWS SAM project. Deploying this template will produce the same result as the Serverless Framework example above.


This multi-cloud tool for infrastructure as code is worth a mention! It has been around since 2014 and is written in Go. For AWS it uses the aws-sdk to manage resources instead of CloudFormation, which gives the benefit of not having a resource limit of 200 that AWS impose for CloudFormation templates.

How do I choose which one to pick?

It comes down to some characteristics of your application, and a fair bit of personal preference! 

  • Are you building a service with an API endpoint and you have little or no previous experience in AWS or serverless architecture? We recommend you to check out Serverless Framework.
  • Are you not a fan of writing CloudFormation and your architecture needs a lot of infrastructure? Check out AWS CDK.
  • Are you familiar with CloudFormation and want to get started with serverless applications? AWS SAM could be the perfect match! 

There are countless forum posts and articles debating whether to go with AWS SAM or Serverless Framework. The frameworks are very similar and many times it comes down to personal taste. At TIQQE we have lots of experience working with Serverless Framework and some of us would debate that you get the job done in less lines of code with Serverless Framework. With that said, SAM does not have to worry about being generic for multiple clouds and that can be an edge if you are working only with AWS. SAM also defaults to giving Lambda functions least privilege access rights (AWS best practice), while Serverless Frameworks share a role between all Lambdas.

Terraform can be a good match if you are creating infrastructure as code across multiple clouds. While Terraform is capable of doing many things, it is not specialised in serverless technologies and you will have to write a lot of code to achieve the same results as the other frameworks described in this post. Not having a 200 resource limit is nice but should not be a problem that often if you are designing your systems in terms of microservices.

Do you have any comments or questions about this article? Please reach out!