Deployment - Serverless Architectures with AWS Lambda


Performing a deployment in Lambda is as simple as uploading a new function code package, publishing a new version, and updating your aliases. However, these steps should only be pieces of your deployment process with Lambda. Each deployment process is application-specific. To design a deployment process that avoids negatively disrupting your users or application behavior, you need to understand the relationship between each Lambda function and its event sources and dependencies. Things to consider are:

  • Parallel version invocations – Updating an alias to point to a new version of a Lambda function happens asynchronously on the service side. There will be a short period of time that existing function containers containing the previous source code package will continue to be invoked alongside the new function version the alias has been updated to. It’s important that your application continues to operate as expected during this process. An artifact of this might be that any stack dependencies being decommissioned after a deployment (for example, database tables, a message queue, etc.) not be decommissioned until after you’ve observed all invocations targeting the new function version.

  • Deployment schedule – Performing a Lambda function deployment during a peak traffic time could result in more cold start times than desired. You should always perform your function deployments during a low traffic period to minimize the immediate impact of the new/cold function containers being provisioned in the Lambda environment.

  • Rollback – Lambda provides details about Lambda function versions (for example, created time, incrementing numbers, etc.). However, it doesn’t logically track how your application lifecycle has been using those versions. If you need to roll back your Lambda function code, it’s important for your processes to roll back to the function version that was previously deployed.