How to Deploy Your Lambda Functions with CloudFormation

AWS Lambda is a powerful tool for developing serverless applications and on-demand workflows. However, this power comes at a cost in terms of flexibility and ease of deployment, as the manual deployment process that AWS Lambda recommends can be error-prone and hard to scale. 

CloudFormation revolutionizes this process, replacing copied zip files with dependable and repeatable template-based deployment schemes. With CloudFormation, your Lambda functions will be easier to maintain, easier for your developers to understand, and easier to scale as your application grows.

Reviewing AWS Lambda Deployments

AWS Lambda function deployments are based around file handling—namely, by zipping your code into an archive and uploading the file to AWS. At its core, all AWS Lambda functions follow this pattern:

  • Create a zip file.
  • Upload to an S3 bucket.
  • Set the function to active.

This takes place whether you’re manually deploying the code, have outsourced your deployments to a tool, or are following any protocol in-between.

Once the file is received, AWS unzips your code into the appropriate folder structure, making it available to run when the Lambda container is spun up. This approach is a key point to remember as we discuss Lambda deployments and also exposes one of the first holes in the manual deployment process—AWS Lambda functions have an unstated structure that you need to follow. 

Simply put, you do not want to right-click on a file and create an archive; otherwise, you’ll encounter an error when you try to run your deployed Lambda code. The following screenshots illustrate this issue:

Figure 1: Do not zip the folder using this method

If you examine the zip files produced by the above method, you’ll find that their root level consists of your code folder:

Figure 2: This zip file will not be parsable by AWS Lambda

The issue this introduces is specifically related to how AWS Lambda deploys the code—namely, it simply unzips the provided code archive to an executable folder, then routes invocation requests to the application code found in that folder. When you provide a zip archive with a folder at the root level, instead of the application code itself, AWS Lambda has no idea what to do and throws errors. So, make sure that you zip the folder contents themselves, as follows:

Figure 3: Zipped at the appropriate level, the function code should be the root of the archive

When you do this, your code is put at the root level of the zip folder. This allows AWS Lambda to easily deploy your published code:

Figure 4: The code file is present at the root of the zip archive

IOD recruits tech experts from around the world to create compelling content for our clients’ tech blogs. Contact us to learn how we can help you with your content marketing challenges.

Each Lambda function exists independently, meaning that you cannot easily share resources between Lambda functions—shared libraries, source data files, and all other information sources that need to be included with the zip archive you upload. This additional fragility and duplication can be resolved with Lambda layers. Lambda layers provide you with a common base for your functions, letting you easily deploy shared libraries without the duplication that would be required when using only the base container.

While you can set up a scriptable and maintainable deployment process, once the project size grows, the brittleness of the above steps will quickly become apparent. AWS CloudFormation solves this very complex problem by categorizing infrastructure as code; this lets your developers and development operations teams create, deploy, and tear down resources with simple configuration-file modifications. These configuration files are human-readable and can be modified in any text configuration, programming language, or UI tools that you desire. 

Furthermore, CloudFormation lets you centralize the deployment of your infrastructure, creating a build process for your serverless functions that is both repeatable and predictable.

Improving Lambda Deployments with CloudFormation

Moving from the error-prone manual process of Lambda deployment to the superpowered CloudFormation model is a straightforward process of translating your function’s infrastructure needs into the appropriate CloudFormation template language. CloudFormation lets you then consolidate the disparate resource deployments for your application into a small set of configuration files, allowing your infrastructure to be maintained alongside your application code.

All in all, CloudFormation makes deploying AWS Lambda functions incredibly simple.

Start by creating the template file that will define your resources. This will be your working folder for your code. Next, create your function in the appropriate file for your desired Lambda runtime. Finally, create an S3 bucket and provide its address to your Lambda function; once you’ve done this, you can deploy functions simply by copying your zip file to the correct S3 bucket.

CloudFormation will be the tool that ties together all the resources your function requires. In CloudFormation, you will define the function, the function’s IAM role, the function’s code repository in S3, and execution policies to ensure that your function can do everything it needs to do within the AWS ecosystem. CloudFormation further gathers these resources together, centralizing all of your infrastructure definitions in a single template file that lives alongside your code.

Running Through a Sample Deployment

In this section, we’ll run through a quick example of creating a CloudFormation-driven deployment process for an AWS Lambda function. Start with the following Node.JS code to create a simple Lambda function using the nodejs12.x runtime:

exports.handler = async (event) => {
        // TODO implement
        const response = {
            statusCode: 200,
            body: JSON.stringify('CloudFormation deployment
         return response;

This code is deliberately simple, allowing you to highlight the deployment process itself. Once you’ve created the function code, you can begin creating all of the items that will allow you to deploy and run the code with CloudFormation.

First, create a new file in the same directory as the function. These instructions assume that your file will be named template.yml. Once you‘ve created the empty template file, start including resources needed to get your function running. You can begin with defining an S3 bucket to hold your function code:

 AWSTemplateFormatVersion: '2010-09-09'
     Description: 'Example Lambda zip copy'
          Type: AWS::S3::Bucket

Then, create the resources needed for your function, including an IAM role and the function definition itself:

          Type: AWS::IAM::Role
                Version: '2012-10-17'
                   - Effect: Allow
                     Action: sts:AssumeRole
arn:aws:iam::aws:policy/service role/AWSLambdaBasicExecutionRole
            DependsOn: CopyZips
            Type: AWS::Lambda::Function
               Description: Example
               Handler: index.handler
               Runtime: nodejs12.x
               Role: !GetAtt 'MyFunctionRole.Arn'
               Timeout: 300
                   S3Bucket: !Ref 'LambdaZipsBucket'
                   S3Key: !Sub '${QSS3KeyPrefix}/

Once you’ve created the template file and modified it to reflect the resources above, you can deploy your functions from the command line with a single call:

aws cloudformation deploy --template-file template.yml
    --stack-name your-stack-name-here

This basic configuration will allow you to deploy your functions once they‘ve been uploaded to the S3 bucket specified in the function definition. You can now build upon this basic set of deployment functionality to automate any aspect of your stack creation. For a fully functional deployment sample, you can clone the excellent quickstart repo from AWS.

Some Tips and Additional Resources

As you work CloudFormation into your Lambda development pipeline, you’re bound to encounter headaches. Here are a few tips to help avoid unnecessary frustration from this immensely helpful AWS blog article on the topic:

  • Did you know that you can deploy in-line Lambda code? Simply include your (small) Lambda function code as lines appended after the zipfile key.
  • If you only need to release your functions to a small subset of AWS regions, you can provide a list of regional buckets to populate with your code; simply expand the resource listing when defining your source Lambda zip files.
  • With a simple name format policy and some custom code, you can create a system that allows you to upload your S3 file once, then publish it to any AWS region that supports AWS Lambda.

In addition to the AWS blog post above, my fellow IOD experts also had a few thoughts on the best ways to achieve serverless deployment zen:

Once again, the excellent Quickstart repo provided by AWS also offers a useful CloudFormation-driven tool for deploying your AWS Lambda code across multiple regions from a single bucket.

Wrapping Up

AWS Lambda deployments are brittle and prone to error out-of-the-box, requiring you to wade through numerous user interfaces and dialog flows to create your function, associated execution roles, and the resources you need to host your deployable code. 

With CloudFormation, you can convert all of this manual configuration into a single template file with the power to describe an entire application stack. CloudFormation replaces the complex and error-prone manual process of deploying Lambda functions with a repeatable, maintainable process that can be maintained alongside your code.

IOD’s expert+editor teams create the kind of content that tech marketing professionals just don’t have the expertise to create.

Learn more.

News and Resources

News round up – Razer launches new fund for VR & gaming start-ups

Welcome to DeveloperEconomics’ weekly news roundup. In this edition, Blackstorm raises $33.5m for a ‘post-app store”, Razer launches a new fund for VR and gaming start-ups and Kony releases a new survey on the challenges of wearable development. Read on for the full news rundown.

Blackstorm raises $33.5m for ‘post-app store’ platform

Blackstorm has raised $33.5 million for what it calls a “post app store” solution, letting developers share apps outside of typical store fronts. Blackstorm offers a universal IDE designed to create apps that are shared across different distribution channels, such as messaging apps and mobile browsers. The company says its goal is to power “the infrastructure to trade and distribute software to all the post app-store platforms.”

Aruba announces platform to accelerate enterprise IoT adoption

HP’s Aruba has released the Aruba Mobile First platform, which aims to build a dev eco-system around its ArubaOS operating system. Aruba says the platform, which incorporates ArubaOS 8, lets third party devs quickly improve apps or create new ones based on its wireless networking technologies. The platform also collects data from IoT and mobile devices and customises networking functions dynamically in real time.

Google issues Nougat security update

Google has released a security update for Android Nougat. The update fixed a vulnerability that could enable remote code execution on an affected device. However, Google added that it’s had no reports of active customer exploitation or abuse of the fixed issues.

Korean firms consider legal action over Apple’s API policy

A group of Korean financial tech firms are reportedly launching a complaint to state regulators against Apple’s closed API policy around NFC functions. The companies complain that Apple is blocking providers such as Samsung Card and BC Card from accessing the NFC features. A similar complaint was previously lodged by Australian banks with regulators in the country.

PerfectlySoft releases Perfect 2.0 framework for Swift 3.0

PerfectlySoft has released the latest version of its server-side development framework for Swift 3.0. Perfect 2.0 features support for additional datasources, such as Redis and Filemaker, as well as “significant” performance and scalability enhancements. The company says Swift is “evolving extremely rapidly” and its framework helps developers keep up with the changes.

AWS SDK for C++ now available for production use

Amazon has released version 1.0 of its AWS SDK for C++. The SDK has received a number of improvements following developer feedback, including an improved Transfer Manager and symmetric cryptography support. The SDK also now follows semantic versioning so devs can upgrade within the 1.x series without breaking their build.

InfluxDB version 1.0 releases

InfluxData has released version 1.0 of its InfluxDB open-source time-series database. Influx DB was written in the Go programming language and is already being used by companies to monitor network infrastructure, security, container infrastructure, solar panels, and more. InfluxData says the database has been in development for nearly three years.

Box releases updates to attract more developers

Storage platform Box has released a series of updates aimed at developers. The platform now supports annotations, watermarking and new content types. Devs using the JavaScript SDK can now benefit from HD video, 3D models, VR files and 360-degree content. Box is also releasing a UI Kit that makes it easier to integrate elements into their web apps.

MySQL 8.0.0 Milestone Release is available

MySQL have announced that their 8.0.0 milestone release is now available for download. In their blog post, the engineers have outlined the most significant changes, some of which address problems that have plagued MySQL. The source code is available at GitHub.

Razer launches $30m fund for VR, IoT and gaming start-ups

Gaming hardware company Razer has launched zVentures, a new fund for investing in start-ups focused on gaming, VR, robotics and IoT. Razer is looking to fund early-stage start-ups with investments ranging from $100,000 to $1 million. The fund is based out of San Francisco and Singapore.

Survey highlights top challenges around wearables development

Kony has released a new survey looking at the challenges around developing apps for wearables. According to the survey, wearables will be “commonplace” in the enterprise by 2020 and 78% of devs surveyed said they are working on 2 wearable apps or more. Forty percent said the lack of communication between designers, stakeholders and developers is the biggest challenge for wearable development.