Photo by Ian Stauffer on Unsplash

The Power of AWS SAM & AWS CDK together 🚀

How to use AWS SAM and AWS CDK together in serverless development to quickly push code changes to the cloud, and easily tail the live cloud logs as we test; with example code repo and visuals.


✔️ Introduction
✔️ What issues do we face currently?
✔️ What tools can we use to circumvent the issues?
✔️ Lets see this in action!
✔️ Testing!


In this article we are going to cover speeding up your AWS CDK serverless development through two key features; AWS CDK Hotswapping and tailing logs with the AWS SAM CLI.

To showcase this in action we will build out a really simple solution below for our fictitious “Lee Pirate Costume hire” company (just for fun):

Note: You can find the full code for the article here:

⚠️ Note: The code repo is a basic example to show the high level approach in practice, and is not production ready. For example, I have tried to keep all of the code in handlers (one place) to make it easier to scroll through, rather than splitting up into separate functions.

Lee’s Pirate Costume Hire — suggestion from the fantastic Daniel Mackenzie who I have the pleasure of working with!

The diagram below shows what we are building and how this works:

Fig 1: We are going to build the most basic of solutions to create and get orders

Steps are:

  1. Users can access our API to both order and get the status of their pirate costume orders. This uses Amazon API Gateway.
  2. A user can create an order using a POST on the /orders/ endpoint.
  3. We have a Lambda Function which validates and creates the order through an Express Workflow, which also publishes the event to Amazon EventBridge.
  4. The order is subsequently stored in DynamoDB via the Create Order function.
  5. A user can also check the status of their pirate costume order using a GET based on order id /orders/111 which uses a synchronous Express Workflow to get the order from DynamoDB.

👇 Before we go any further — please connect with me on LinkedIn for future blog posts and Serverless news

What issues do we face currently?

When we are developing in the serverless world we typically develop against ephemeral cloud stacks (the cloud provider, say AWS), as opposed to performing local development through tools like LocalStack.

Two key issues we face with this approach are:

a.) AWS CloudFormation taking soooooo long to deploy our stacks (sits beneath the AWS CDK), and..

b.) accessing the logs of our Lambda functions when developing/testing (say through Postman or equivalent)

Waiting for our CloudFormation stacks to deploy can be exhausting..

This is highlighted in the previous article below:

Let’s see how the AWS CDK and AWS SAM CLI can help us mitigate these issues!

What tools can we use to circumvent the issues?

So let’s cover the two key tools for this article below; hotswapping and tailing logs.

Hotswapping ♼

This will attempt to perform a faster, short-circuit deployment if possible (for example, if you only changed the code of a Lambda function in your CDK app, but nothing else in your CDK code), skipping CloudFormation, and updating the affected resources directly; this includes changes to resources in nested stacks.

If the tool detects that the change does not support hotswapping, it will fall back and perform a full CloudFormation deployment, exactly like cdk deploy does without the --hotswap flag.

Hotswapping is currently supported for the following changes:

✔️ Code asset (including Docker image and inline code) and tag changes of AWS Lambda functions.

✔️ AWS Lambda Versions and Aliases changes.

✔️ Definition changes of AWS Step Functions State Machines.

✔️ Container asset changes of AWS ECS Services.

✔️ Website asset changes of AWS S3 Bucket Deployments.

✔️ Source and Environment changes of AWS CodeBuild Projects.

✔️ VTL mapping template changes for AppSync Resolvers and Functions

Tailing logs with SAM CLI 📝

OK, so now we will look at tailing live CloudWatch logs using the SAM CLI, which allows us to test our code whilst seeing the tailed logs appear in our terminal in real time.

When your functions are a part of an AWS CloudFormation stack, you can fetch logs by using the function’s logical ID when you specify the stack name.

Lets see this in action 🚀

Let’s get the solution deployed using the following command in the root folder once we have cloned the repo:

npm run deploy

⚠️ Note: Ensure that you have the SAM CLI installed —

Now that we have the stacks deployed, let’s now open two terminal windows, running the two following commands (one in each):

Tailing the logs of our lambda function

We can tail the Lambda function CloudWatch logs from our solution using its function name, which we can find in the .\cdk-outputs.json file in our repo with the key ‘GetOrderLambdaName’ once we have deployed the solution:

Viewing our deployed Lambda function name using the cdk-outputs.json file which is auto-generated

or using the AWS Toolkit for VS Code as shown below which I personally think is more work compared to above:

Using the AWS Toolkit to view your deployed Lambda names

We can then use the value for this key in the next terminal SAM CLI call:

sam logs --name PirateCostumeStatelessStack-GetOrderLambda123456 --tail

Now let’s also do the same for the Create Order Lambda function.

We are now tailing the logs in realtime for the Lambda function in one CLI call. Neat!

Deploying the stack with hotswap

Now let’s run hotswap for our quick deployments:

npm run deploy:hot

In our package.json the NPM script deploy:hot is actually running the following command below:

cdk deploy --outputs-file ./cdk-outputs.json --all --hotswap

Once we have the two commands running, we can make a change to the Lambda function code to view the results in real time via the logs in the terminal window, through using the Postman file found here in the repo ./postman to make the calls. Let’s use this Postman file to test our solution in the next section.

Testing! 🧪

So let’s start using the postman file to do some testing to see this in action! Firstly, let’s create a new order as shown below:

Note: Ensure that you are now tailing the create order lambda which can be found in the same .\cdk-outputs.json file in the root of the repo

Example of creating a new Pirate Costume Order
Example output in the terminal window based on hitting the endpoint using Postman

We can see above that the live logs are now tailed when we hit the function via Postman. You will see that the terminal will change to show the new logs each time you perform the request! (You are now testing and seeing live logs in the cloud!)

Now let’s make a change to the Lambda code to see this reflected in the live logs.

If we change line 24 in the file ./serverless-cdk-sam/pirate-costume-orders/stateless/src/handlers/get-order/get-order.ts and hit the get order endpoint in Postman you will see that we can change the console log from *’s to !’s in seconds rather than deploying the full stack!

We can see the hotswap feature in action!

You will see that the change is deployed in approx 6.84 seconds as opposed to a full CloudFormation deployment of around 60 seconds using hotswap!

We can also see in the live tailing of the logs the change from ‘*’s to ‘!’s when we hit the endpoint:

Example showing the live tailing of logs and the super quick deployments using hotswap, and swapping the console logs from ‘*’s to ‘!’s

This shows the power of using the two features together in development!


I hope you found that useful as a way of speeding up the development of our AWS CDK apps using the CDK hotswapping feature alongside the AWS SAM CLI!

Wrapping up 👋

Please go and subscribe on my YouTube channel for similar content!

I would love to connect with you also on any of the following:

If you enjoyed the posts please follow my profile Lee James Gilmore for further posts/series, and don’t forget to connect and say Hi 👋

Please also use the ‘clap’ feature at the bottom of the post if you enjoyed it! (You can clap more than once!!)

About me

Hi, I’m Lee, an AWS Community Builder, Blogger, AWS certified cloud architect and Global Enterprise Serverless Architect (GESA) based in the UK; currently working for City Electrical Factors (UK) & City Electric Supply (US), having worked primarily in full-stack JavaScript on AWS for the past 6 years.

I consider myself a serverless advocate with a love of all things AWS, innovation, software architecture and technology.

*** The information provided are my own personal views and I accept no responsibility on the use of the information. ***

You may also be interested in the following:



Get the Medium app

A button that says 'Download on the App Store', and if clicked it will lead you to the iOS App store
A button that says 'Get it on, Google Play', and if clicked it will lead you to the Google Play store