AWS introduced the Serverless Application Model (SAM) to ease the building of serverless applications on AWS. Essentially, it is an extension of AWS CloudFormation, and consists of two major components: SAM template specifications and SAM CLI.
In this blog, we’re going to share five tips to get the most out of AWS SAM templates. So, without further ado, let’s dive right in.
In this article
AWS SAM Tip #1: Reuse Common Patterns using Nested Applications
As serverless architectures grow, common patterns get reimplemented across teams, and projects. This can really hurt development velocity and lead to wasted effort. To avoid that, AWS has come up with nested applications in AWS SAM and the AWS Serverless Application Repository (SAR) to make these patterns shareable publicly and privately.
Related content: Read our guide to Lambda architecture
Nested applications are based on a concept in AWS CloudFormation called nested stacks. Serverless applications are deployed as stacks that contain one or more other serverless application stacks.
Let’s take an example. If we want to build an API made up of AWS Lambda and Amazon API Gateway, we can use AWS Serverless Application Model to create Lambda functions, configure API Gateway, then deploy and manage them both. Now, we want to secure this API. API Gateway offers several methods for doing this. Let’s say we want to implement basic HTTP Basic Auth. So, instead of creating this functionality from scratch, we can search for it in SAR.
We can review the AWS SAM template, license, and permissions provided. If it meets our requirements, we simply copy the SAM Template of it and put it in our application SAM template under the “Resources” tag.
These applications will have a type: AWS::Serverless::Application
Now, we can check the output of this application and refer to that in the main API Authorizer, as below:
With this simple piece of code, we can reuse any existing code resided in SAR.
AWS SAM Tip #2: Minimize Code Using Globals
Serverless architecture is all about breaking large applications into smaller functions. So, if we end up having 10-20 Lambda functions for our application and we configure that in SAM template, we will notice so many Functions definition under “Resources” tag.
In AWS SAM templates, Globals is where you can define properties common to all the Serverless Functions and APIs. Here is a typical example:
AWS SAM Tip #3: Enable a feature using SAM Parameter and Mappings
Let’s suppose we want to enable a feature in our application based on the flag value set in an environment variable. It can get complicated if we want to do it based on the deployment environment, such as testing/production.
For example, I have a feature “Download PDF” which I want to enable only in the test environment for now and don’t want to publish to Prod until the feature is approved. So, the flow will be that an environment value (testing/prod) will be passed as a parameter. There should be a collection object like Map which should hold the status value (on/off) for each environment. Now, logic has to be introduced to retrieve the status dynamically and set in environment variable so that the application can behave accordingly.
Using SAM Parameters and Mapping tags, this can be done very easily. See the below SAM template on how it is implemented.
Here !FindInMap will search DocumentEnvironment parameter value (testing/staging/prod) in DownloadPDFFeature Map and retrieve “status” field value and set it with “Download_Feature1” variable.
AWS SAM Tip #4: Safe Deployment using AutoPublishAlias and DeploymentPreference
AWS Lambda has a Versioning and Alias feature which helps facilitate the incremental deployment of Functions. When an enhancement happens on a function, it can be published with a bumped-up version and an Alias can point to a version that we want to expose to our end users. Below is an example:
In SAM, we can bump up this version by just using one property – AutoPublishAlias
Behind the scenes, AWS Serverless Application Model detects changes to the function code, publishes an updated version, and creates an alias pointing to the updated function.
Apart from this, DeploymentPreference property will help to enable the canary and linear deployment strategy which ensures that if there is any problem with the newer version of the function, it can be rolled back. For example, in the above code, it is going to redirect only 10% of the traffic to the new version for 10 minutes and then keep increasing by 10% every 10 minutes. So, we can monitor the new version and rollback if any issues found.
Related content: read about deploying serverless apps with the AWS CDK
AWS SAM Tip #5: Enable Security using Policy Templates
For any Lambda Function, the most important thing is to define what execution it can do and who can invoke it. That’s where we define the security around it. SAM has a concept called Policy Templates. Using these templates, just two lines of code correspond to a complete IAM policy that will be keyed in.
In the above example, we have used the DynamoDBCrudPolicy template which corresponds to the below IAM policy.
Using this feature we are able to reduce the complexity of the security configuration and standardize the security of Lambda Function.
Summary
As you can see, AWS SAM is an essential tool for reducing the complexity of building serverless applications. Of course, there are numerous other powerful features available in SAM, but we will be parking those for another day. Until then, get in touch on Twitter with your tips and suggestions for using AWS SAM like a pro.