Deploy Serverless Applications to AWS Lambda Using AWS SAM

To begin implementing and coding a serverless application that you want to deploy to AWS Lambda, you must first add the appropriate AWS Lambda (SAM) technology templates in the Develop phase of your feature. This enables you to set up the technology stack, create the source code repository, and begin implementing Lambda function logic before moving on to deployment configuration. To add the technology templates, do the following:

1. In the Develop phase of your product feature, click + New Technologies. If you haven't created a branch template yet, you'll be prompted to do so before adding a technology. To create a branch template as per your branching strategy, click Configure Branch Template. See Create Branch Template.

   If you choose to do it later, click Proceed.

2. On the Add Technologies screen, on the Serverless tab, in the AWS Lambda SAM Templates section, choose your desired runtime templates. Currently, the following templates are available:

   • .NET 8

   • Golang

   • Java 21 – Gradle

   • Java 21 – Maven

   • Node.js 22

   • Node.js 22 with Typescript

   • Python 3.13

   • Python 3.12

   • Ruby 3.4

   These templates help you bootstrap application development quickly. Select the required technology templates and click Add.

   

3. Provide the required details:

   • Title
     Enter a logical name for the Lambda technology.

   • Repository Name
     Specify the name of the source code repository to be created for this technology.

   • Organization
     This field is auto-selected. The organization shown here is configured by your administrator. You cannot modify this value while adding the technology.

   • Visibility
     Select the repository visibility based on your organization’s governance policy.

   If you want to use an existing repository instead of creating a new one:

   1. Turn on the Use Existing Repository toggle.

   2. Provide a technology title.

   3. Select the required repository from the list of repositories available in your configured source code repository tool.

   This allows you to associate an existing codebase with the Lambda technology for further development and deployment.

   

   Note:

   • Create a new repository when you are starting development for a new Lambda function or serverless capability and want Calibo Accelerate to initialize a repository using a supported technology template.
   • Use an existing repository when you already have a Lambda codebase or SAM-based project in your source control system and want to bring it under Calibo Accelerate for deployment, CI/CD automation, and lifecycle management.

   

   

   Note:

   The Publish as Library option is not applicable to AWS Lambda technologies. Lambda functions represent deployable serverless applications and cannot be published or reused as shared library components within the platform.

4. Click Save.

After Calibo Accelerate creates or links the repository for the selected AWS Lambda (SAM) technology template, you can begin implementing your Lambda function in the src/ directory and add tests under tests/ as required.

Review and update the provided SAM template to configure function settings, permissions, and event sources.

The provided templates support both ZIP-based and container image–based deployments. You need to select the Lambda package type while configuring the technology deployment details.

Commit and push your changes to the branch you plan to deploy from. Once the source code is ready, proceed to the Deploy phase.

To deploy a serverless application to AWS Lambda, you must first enable Serverless deployment mode at the deployment stage level of your feature.

1. From the Calibo Accelerate home page, click Products in the left navigation pane.

2. Select your desired product and open the product feature for which you want to deploy an AWS Lambda function.

3. In the feature workflow, select the Deploy phase.

4. On the Deployment Workflow screen, locate the deployment stage you want to configure (for example, Dev).

5. On the selected stage tile, click the ellipsis (...) and then click Edit Details.

6. In the Edit Stage side drawer, configure the following:

   1. Deployment Mode
      From the Deployment Mode list, select Serverless.

   2. Cloud Accounts
      Select the AWS cloud accounts where you want to deploy the Lambda functions.

      These cloud accounts are preconfigured by your administrator as part of the initial Calibo Accelerate platform setup. The list displays only the AWS accounts that have already been onboarded and approved for use within your tenant.

      If the AWS account you want to use is not available in the list, contact your Calibo Accelerate administrator to have the required cloud account configured or enabled.

   3. Continuous Integration Tool
      Select GitHub Actions as the CI/CD tool for this stage.

   4. Container Image Scanning Tool (Optional)
      If your Lambda function uses Image-based packaging, you can select Snyk to enable container image vulnerability scanning during CI.

   5. Code Analysis Tool (Optional)
      Select the code analysis tool (for example SonarQube) to be used in the CI/CD pipeline for this stage.

   6. Click Save to apply the stage configuration.

   

   Note:

   The Enable Continuous Integration toggle is not applicable for the Serverless deployment mode.

After enabling the Serverless mode, configure AWS SAM settings at the deployment stage level.

1. On the Deployment tab within the stage, click the Serverless tab.

2. In the AWS Lambda section, all the AWS accounts you selected in the stage configuration are displayed. In your desired AWS account card, in the upper right corner, click Configure AWS SAM Settings for Lambda Deployment.

   

3. In the Configure AWS SAM Settings for Lambda Deployment side drawer, configure the following:

   Field	Description
   SAM Execution Role (Optional)	Specify the IAM role assumed by the CI/CD pipeline to build and deploy AWS Lambda functions using AWS SAM. This role must have permissions for CloudFormation and S3 operations required for deployment.
   S3 Bucket (Optional)	Provide the S3 bucket name where AWS SAM will upload Lambda deployment artifacts or packaged templates before deployment. Ensure the bucket exists in the selected AWS account and region.
   S3 Folder Path (Optional)	Enter the folder path within the specified S3 bucket where build artifacts for this deployment will be stored. If the specified path does not exist, it will be created automatically.

   

   Note:

   The settings configured in this section act as default values for all Lambda technologies added to that stage. These values can be overridden at the individual technology level in the deployment details configuration. This allows different Lambda technologies within the same stage to use distinct IAM roles or artifact storage locations, based on security or operational requirements.

   

   Click Configure to save the settings. A confirmation message indicates successful configuration.

1. In a deployment stage, on the Serverless tab, in the AWS Lambda section, click Add Technologies.

2. Add the Lambda technologies from the list.

   

   This opens the side drawer to configure deployment details and parameters for the selected Lambda technology. Configure the following details:

   1. Basic Deployment Details

   Field	Description
   Source Code Branch	Select the Git branch that contains the Lambda source code and AWS SAM templates to be used for deployment. The selected branch is used by both CI and CD workflows.
   AWS Region	Select the AWS region where you want to deploy the Lambda function and associated resources (CloudFormation stack, S3 artifacts, ECR images if applicable).
   Runner Labels	Specify the GitHub Actions runner labels to be used for executing CI and CD workflows. By default, ubuntu-latest is selected. Use custom labels if your organization uses self-hosted runners. What are runners in GitHub Actions? In GitHub Actions, a runner is a server that executes the jobs defined in your workflow. Each runner listens for available jobs, runs them when triggered, and reports the results back to GitHub. There are two main types of runners: GitHub-hosted runners – Managed by GitHub, automatically updated, and preconfigured with popular tools and languages. Self-hosted runners – Managed by you, allowing custom hardware, software, and network configurations. What are runner labels? Runner labels are tags or identifiers assigned to self-hosted runners to categorize them based on their characteristics, capabilities, or intended use. When you specify runner labels in your deployment configuration, the job will be assigned only to runners that match all the specified labels. Specify all intended runner labels Specify one or more runner labels to ensure that the GitHub Actions workflow is assigned to an appropriate runner. The workflow job is assigned to a runner whose label set matches all specified labels. If no matching runner is available, the job remains in a pending state until one becomes available. Tip: Maintain a documented list of available runner labels in your project so developers know which labels to use.

   2. Deployment Roles & Access

   Field	Description
   SAM Execution Role	Select the IAM role assumed by the GitHub Actions workflow to run sam build and sam deploy commands. This role must have permissions to deploy Lambda functions, manage CloudFormation stacks, and access required AWS services. This role orchestrates the deployment and invokes CloudFormation to create or update the stack.
   CloudFormation Stack Name	Specify the name of the CloudFormation stack that will be created or updated during deployment. Each deployment stage should typically use a unique stack name. Calibo Accelerate verifies the availability of the specified name in the selected AWS account. A stack name must start with a letter and contain only letters, numbers, and hyphens.
   CloudFormation Assume Role (Optional)	Specify an IAM role that CloudFormation should assume while executing stack operations. Use this when separating deployment orchestration permissions from infrastructure provisioning permissions. The CloudFormation Assume Role must trust the CloudFormation service (cloudformation.amazonaws.com) in its trust policy. In addition, the role used by the deployment workflow (for example, the SAM Execution Role assumed by GitHub Actions) must have iam:PassRole permission on the CloudFormation Assume Role to allow CloudFormation to assume it during stack operations.

   3. Lambda Configuration Details

   These fields define how your Lambda function is packaged and where build artifacts are stored.

   Field	Description
   Lambda Package Type	Select the packaging type for the Lambda function: Zip or Image. The available options depend on how your SAM template is structured.
   SAM CloudFormation Template Path	Path to the AWS SAM template file in the selected branch (for example, template.yaml or template-image.yaml). This template is used to extract parameters and drive the deployment.
   ECR Repository	This field is available if your Lambda Package Type is Image. In the ECR Repository field, select the Amazon ECR repository that contains the Lambda container image to be deployed. Ensure that the selected repository contains a valid Lambda-compatible container image and that the configured IAM role has the required permissions to pull images from the repository.
   S3 Bucket	Select the S3 bucket used to store Lambda build artifacts during ZIP-based deployments. The bucket must already exist and be accessible by the selected execution role.
   S3 Folder Path (Optional)	Specify the folder path within the selected S3 bucket where artifacts are uploaded (for example, artifacts/dev). This helps organize artifacts by environment or stage.
   Snyk Configuration	The section is visible only when Snyk is selected as the Container Image Scanning Tool in the stage configuration. By specifying the appropriate Snyk project and severity level, you can enforce security gates that cause the CI pipeline to fail when vulnerabilities exceed the allowed risk threshold, preventing insecure container images from being promoted further in the delivery workflow. Use the following settings to create a Snyk project from within Calibo Accelerate and define the vulnerability severity thresholds that act as security gates for the CI pipeline. Project: Provide a unique name for the Snyk project that will be created for this technology. Calibo Accelerate creates a separate Snyk project with this name to independently manage and track scan results for this technology in your Snyk dashboard. If the project name already exists, or if the configured Snyk API token is invalid or expired, project creation fails and an appropriate validation or authentication error is displayed. In this case, contact your Calibo Accelerate administrator for assistance. Severity: Select the vulnerability severity level from the drop-down that will trigger CI pipeline failure: Critical: The pipeline fails only when critical vulnerabilities are detected. High: The pipeline fails when high and/or critical vulnerabilities are detected. Medium: The pipeline fails when medium, high, and/or critical vulnerabilities are detected. Low: The pipeline fails when any vulnerabilities, including low-severity issues, are detected. None: Bypasses severity checks and allows the pipeline to continue regardless of detected vulnerabilities. Use this option when you want to collect information regarding vulnerabilities without blocking the deployment process.

   

   Note:

   • S3 Bucket and Folder Path are required only for ZIP-based Lambda deployments.

   • For Image-based deployments, artifacts are built as container images and pushed to Amazon ECR.

   4. Pipeline Triggers

   Pipeline triggers control when GitHub Actions workflows are executed for Continuous Integration (CI) and Continuous Deployment (CD).

   CI Trigger

   The CI trigger determines when the CI workflow runs to build, test, and package the Lambda application.

   • Manual (Default and Mandatory)
     

     • Always added automatically.

     • Required by Calibo Accelerate to allow you to manually trigger the workflow from the platform if automated triggers are unavailable or fail.

     • Ensures that you can always deploy on demand, even if no code changes occur.

   • Additional Triggers
     Click + New Trigger to add triggers such as:

     • After Push

       • Triggers the workflow automatically whenever a commit is pushed to the selected branch.

       • Ideal for continuous delivery pipelines in lower environments.

     • Cron Schedule – You can define one or more time-based schedules to run the workflow automatically at specific times. Useful for nightly builds, weekly refreshes, or maintenance deployments.

       In each schedule, you can specify the following:

       1. Time Zone: Select the desired time zone for the CI trigger schedule.

       2. Frequency : Select the Every Day or Every Week option as required.

       3. Time: Define when to trigger the pipeline (in hours and minutes). You can define multiple schedules as well.

   CD Trigger

   The CD trigger determines when the deployment workflow runs to deploy the Lambda function using AWS SAM. Depending on your chosen trigger type, deployments can run automatically after CI, on a fixed schedule, or on demand.

   • Manual (Default)
     Allows you to explicitly control when deployments are executed.

   • Additional Triggers
     Click + New Trigger to add triggers such as:

     • After CI – Runs deployment automatically after a successful CI run.

     • Cron Schedule
       Runs deployment automatically at predefined intervals (for example, daily or weekly). Builds may occur more frequently, but deployments happen only on the set schedule.

       In each schedule, you can specify the following:

       • Time Zone: Select the desired time zone for the CD trigger schedule.

       • Frequency : Select the Every Day or Every Week option as required.

       • Time: Define when to trigger the pipeline (in hours and minutes). You can define multiple schedules as well.

   You can remove the configured triggers by using the Delete (trash) icon.

3. Click Next to proceed. In the Parameters Configuration section, you can add or update parameters required for your Lambda function.

   Configure Lambda Parameters (AWS SAM)

   Calibo Accelerate reads the latest version of the SAM template from the selected branch and displays all parameters defined under the Parameters: section in the template.yaml file. The Parameter Name column corresponds directly to the parameter names defined in template.yaml.

   1. For each parameter displayed, enter the value you want to use for this deployment. These values are applied as runtime overrides when the Lambda function is deployed.

      For example:

      • FunctionName → payment-authorization-processor-dev

      • LambdaExecutionRoleArn → ARN of an existing IAM execution role

      

      In the upper right corner on the Parameters Configuration screen, the following change indicators are displayed:

      • New – Parameters newly added to the SAM template since the last configuration

      • Deleted – Parameters removed from the SAM template

      

      These indicators help you track changes made directly in the template.yaml file stored in the GitHub repository:

      • If you add a parameter in template.yaml, it appears as New in the UI.

      • If you remove a parameter from template.yaml, it appears as Deleted in the UI.

      • If there are no changes, the indicators show 0 New and 0 Deleted.

      

      Note:

      When adding or updating CloudFormation parameters in the template.yaml file, ensure proper YAML indentation and alignment. Incorrect formatting may prevent the parameters from synchronizing correctly with the Calibo UI.

   2. Leave parameters blank if the SAM template defines a default value or if the parameter is optional.

      If you keep one or more parameters blank and proceed, a confirmation message is displayed.

      

      This message indicates that any parameters left blank will be passed to the deployment as blank values. You can choose to continue with blank values or go back and provide the required inputs before proceeding.

   3. After you specify the parameter values, click Add to proceed.

      The technology is added for deployment to your selected cloud account.

      

1. Missing YAML Workflow Files Are Identified

As soon as you add a Lambda technology for deployment, Calibo Accelerate automatically detects the required GitHub Actions workflow files needed to enable the CI/CD pipeline. The platform displays a prompt asking you to review and commit these files to the linked GitHub repository. Click Create Pipeline to generate and commit the workflow files to the selected branch, ensuring that the CI/CD pipeline for the technology is properly set up and ready for execution.

2. Review Pipeline Files

On the Create CI/CD Pipeline screen, the following required pipeline files are listed:

• Continuous Integration (ci-dev.yaml) – Handles building the application, running unit tests, performing static code analysis (SonarQube), scanning container images, and preparing artifacts.

• Continuous Deployment (deploy-serverless-dev.yaml) – Handles serverless application deployments, supporting deploy, promote, rollback, and destroy actions, along with optional functional testing and artifact promotion.

Click each file’s expand icon to preview its full YAML content.

3. Commit the Workflow Files to GitHub Repository

Once you have reviewed the CI/CD workflow files (for both Continuous Integration and Continuous Deployment), you must commit them to your GitHub repository so that they can be executed by GitHub Actions. Committing these files will place them under the .github/workflows/ directory in your repository, making them available for the platform to trigger pipeline runs.

• Commit Message: A short, clear summary of the change you are committing. For example: Add CI/CD workflows for Dev stage.

• Description (Optional): Additional context for your team, especially if the commit involves multiple steps or dependencies. Useful for complex changes or when multiple stakeholders are reviewing the commit. For example: Added GitHub Actions YAML files for Dev environment build, test, and deployment automation for Phoenix Payment Authorization Processor.

• Branch Selection: You can choose where to commit the workflow files in the GitHub repository.

  • Commit directly to the default branch (<branch name>): The workflows become active immediately in your repository. Choose this option for urgent changes or when you are confident the workflows are ready for production use.

  • Create a new branch for this commit: Commits the files to a separate branch, allowing review and testing before merging into the default branch. This is useful for collaborative environments where changes need to be peer-reviewed.

  After filling in the fields, click Commit to save the workflow files.

  

  These files will then be available in your repository’s .github/workflows/ folder, and GitHub Actions will start using them according to the triggers defined in the YAML files.

4. Run the CI Pipeline

1. On the technology card, click the ellipsis (...).

2. Click Run CI Pipeline.

   

3. In the CloudFormation Parameters for Lambda Deployment side drawer, review the CloudFormation parameter values that will be passed to the AWS SAM build/package workflow (these values are sourced from your Parameters Configuration step).

4. If required, override parameter values directly in the dialog. These overrides apply to this CI execution.

5. Click Run CI Pipeline to trigger the GitHub Actions CI workflow for this technology. The workflow builds and packages the Lambda application using the selected template and the reviewed parameter overrides.

   

6. After the CI pipeline starts, the CI status changes to CI pipeline in progress.

7. Click Refresh in the top right to update the status.

8. After the pipeline completes, the CI status changes to CI pipeline success.

9. To check real-time progress of your CI pipeline,

   Go to the CI/CD Pipeline tab.

   In the Continuous Integration (CI) pipeline for the Lambda technology being deployed, review each step:

   1. Set Up Job – Starts the GitHub Actions job on the runner and prepares the execution context (job workspace, environment variables, permissions, and required runner setup).

   2. Pull Snyk / Snyk Docker – Pulls the Snyk scanner image when Snyk is enabled for the stage and the Lambda package type is set to Image. This step performs vulnerability scanning on the container image as part of the CI workflow.

      This step is not applicable for ZIP-based Lambda deployments.

   3. Checkout Code – Checks out the Lambda source code and AWS SAM template from the configured Git branch in the source code repository.

   4. Initialization – Performs initial setup tasks such as preparing directories, validating configuration files, and setting up environment variables required for subsequent steps.

   5. Unit Tests – Executes automated unit tests defined for the Lambda application to validate function logic before packaging. The CI run fails if tests fail.

   6. SonarQube Scan – Runs static code analysis using SonarQube when it is enabled for the stage. Code quality results are captured and enforced as per configured quality gates.

   7. Configure AWS Credentials - Configures AWS authentication for the pipeline run using the selected cloud account and execution role. This enables the pipeline to interact with AWS services securely.

   8. Set Up SAM- Installs and configures the AWS SAM CLI in the runner environment, preparing the pipeline for SAM-based build and packaging operations.

   9. SAM Build -Builds the Lambda application using AWS SAM. This step compiles dependencies and prepares the application artifacts based on the selected packaging type (ZIP or Image).

   10. SAM Package - Packages the built artifacts:

       • For zip-based deployments, artifacts are uploaded to the configured S3 bucket.

       • For image-based deployments, container images are prepared for publishing to Amazon ECR.

   11. Build Container Image – Creates a Docker image of the application from the repository (typically using the Dockerfile and build context) and tags the image for downstream scanning and publishing.

   12. Create Change Set- Generates a CloudFormation change set based on the SAM template and the parameter values provided for the CI run. This allows review of proposed changes before deployment.

   13. Snyk Installation – Installs the Snyk CLI in the pipeline.

   14. Snyk Monitor – Publishes the project snapshot to Snyk so vulnerabilities can be tracked over time in the Snyk dashboard (baseline tracking and ongoing monitoring).

   15. Container Image Scan – Scans the built container image for vulnerabilities based on the configured severity gate. The CI pipeline fails when detected vulnerabilities exceed the selected threshold.

   16. Publish Container Image – Pushes the built (and approved) container image to the configured container registry, so it can be pulled during deployment.

   17. Push to Collector – Sends CI execution metadata, stage results, and relevant logs to Calibo Accelerate for traceability, audit history, and pipeline visualization.

   18. Post Configure AWS Credentials - Cleans up or resets AWS credentials and execution context after deployment-related operations are completed.

   19. Post Checkout Code - Performs workspace cleanup after CI execution (removes checked-out files, temp artifacts, cached data created during the run).

   20. Complete Job- Finalizes the CI workflow run and marks the execution status (Success/Failure) in the CI/CD Pipelines view in Calibo Accelerate.

5. Deploy the Technology

After the CI pipeline completes successfully, you can deploy the Lambda application.

1. On the Lambda technology card, click the ellipsis (...).

2. Click Deploy.

   

3. The Deploy side drawer lists the Lambda technology selected for deployment.

   

   1. Review the Changeset

      Click View Changeset to see the CloudFormation changes that will be applied.

      The changeset shows which AWS resources will be added, updated, or replaced (such as the Lambda function, IAM roles, or API Gateway resources).

      

      Review this carefully to understand the deployment impact and ensure no unintended infrastructure changes will occur.

   2. Review the Parameters

      Click View Parameters to view the exact CloudFormation parameter values that will be used.

      These values come from the Parameters Configuration step and any overrides provided during the CI run.

      

      Verify environment-specific settings such as function name, memory, timeout, concurrency, execution role, log level, and so on.

   3. If you need to add, remove, or modify CloudFormation parameters (for example, introduce a new parameter or change its definition), update the template.yaml file in the source code repository and commit the changes.

      After committing the update, return to Calibo Accelerate and run the CI pipeline again. The updated parameters will be reloaded and available for review and override in the Parameters Configuration step.

      If you only need to change parameter values (not their definitions), you can update the values directly in Calibo during the CI run or before deployment—no template change is required.

   4. Click Deploy. CD status changes to Pipeline build is in progress.

4. Click Refresh in the top right to update the status. When the deployment is complete, CD status changes to Deployed.

   

6. View Deployment Details and Validate a Deployed Lambda Function

After a Lambda technology is successfully deployed, you can review deployment configuration, monitor execution, test the function, and analyze logs and metrics directly from Calibo Accelerate.

Click View Details on the Lambda technology card to check the following:

You can track the real-time status of your Lambda deployment from the CI/CD Pipelines tab.

You can review the following stages of the CD pipeline:

1. Set Up Job
   Initializes the GitHub Actions runner environment and prepares the execution context for deployment.

2. Checkout Code
   Pulls the latest source code and SAM template from the configured GitHub repository.

3. Initialization
   Sets required environment variables and prepares runtime configuration for SAM execution.

4. Configure AWS Credentials
   Authenticates to AWS using the configured OIDC role or IAM credentials. Ensures the workflow has required permissions to create or update CloudFormation stacks.

5. Set Up SAM
   Installs and configures the AWS SAM CLI on the runner environment.

6. SAM Deploy
   Executes the SAM deployment command. This step:

   • Builds the application (if required)

   • Packages artifacts (ZIP or image)

   • Creates or updates the CloudFormation stack

   • Applies infrastructure changes

7. Push to Collector
   Sends deployment metadata and status information back to Calibo Accelerate for tracking and audit purposes.

8. Post Checkout Code
   Performs post-deployment cleanup of the runner workspace.

9. Complete Job
   Marks the deployment workflow as complete and updates the status in Calibo Accelerate.

To investigate any particular pipeline stage, click that stage in the pipeline timeline. You are redirected to the corresponding GitHub Actions workflow run. You can review the console logs, SAM build output, CloudFormation changeset details, and any error messages directly in GitHub Actions.

To remove a Lambda deployment:

1. Click the ellipsis (…) on the technology card.

2. Select Uninstall.

   

3. Confirm the action.

   

This removes:

• Lambda deployment configuration

• Associated CI/CD pipelines

• CloudFormation stack (as applicable)