Skip to main content
In this lesson we cover the AWS Serverless Application Model (SAM) — a developer-focused toolkit that streamlines building, testing, packaging, and deploying serverless applications on AWS. Think of SAM as a blueprint system: instead of describing every low-level infrastructure detail (every brick, pipe, and nail), you write a higher-level template that defines Lambda functions, APIs, and event sources. That template drives automated packaging and deployment, producing a working serverless application. Key benefits
  • Simplified template syntax (an extension of AWS CloudFormation) for serverless resources.
  • A focused CLI (sam) for scaffolding, building, local testing, packaging, and deploying serverless apps.
  • Reduced boilerplate via high-level resource types like AWS::Serverless::Function.
SAM template essentials A SAM template is YAML (or JSON) that begins with the CloudFormation transform declaration:
Common SAM resource types you will use:
  • AWS::Serverless::Function — Lambda function with optional events (API, S3, SNS, etc.).
  • AWS::Serverless::Api — Serverless REST API powered by API Gateway.
  • AWS::Serverless::SimpleTable — A simplified DynamoDB table definition.
  • Outputs typically expose useful values such as API endpoints or Lambda ARNs.
A slide titled "SAM Template" showing a dotted container with blocks for a Lambda function (Name, Runtime, Handler, Code Location), an API Gateway (Type, Path), and an Output (URL). An orange AWS-style document icon appears to the left of the template.
SAM vs CloudFormation
  • SAM is a CloudFormation transform: SAM templates are syntactic sugar that compile into standard CloudFormation templates.
  • Use SAM when you want serverless-focused resources with less YAML/JSON boilerplate; CloudFormation remains the underlying engine for deployment and lifecycle management.
Common SAM CLI commands Example CLI workflow
Packaging and deployment flow (end-to-end)
  1. Author a SAM template declaring your functions, APIs, permissions, and outputs.
  2. Build and package application code and dependencies. sam package or sam deploy uploads artifacts (Lambda code, layers) to an S3 bucket and updates the template to reference those S3 objects.
  3. The transformed template is processed by CloudFormation (SAM is a transform) to create or update stacks and provision the declared resources.
  4. After deployment, outputs (for example, API Gateway endpoints) are available and can be surfaced via the template Outputs section.
A diagram titled "Serverless Application Model" showing a SAM template (YAML) and an application uploaded to an S3 bucket, which then flows into CloudFormation for deployment.
SAM speeds serverless development by providing higher-level resource types and an integrated CLI while delegating actual deployment and lifecycle to CloudFormation. Use sam local with Docker for fast iteration and sam deploy (or sam package + sam deploy) to publish artifacts to S3 and provision resources via CloudFormation.
Best practices and tips
  • Start with sam init to scaffold idiomatic project layouts and supported runtime templates.
  • Use sam local and Docker to iterate quickly and catch runtime issues before deploying.
  • Keep Lambda deployment packages small; use Lambda Layers for shared dependencies.
  • Use Outputs in the template to expose useful endpoints and ARNs after deployment.
  • Use sam validate as part of CI to catch template issues early.
Summary
  • AWS SAM is a developer-focused extension of CloudFormation that simplifies authoring serverless applications using high-level resource types.
  • The SAM CLI streamlines the application lifecycle: initialization (sam init), build (sam build), local testing (sam local), packaging (sam package), and deployment (sam deploy).
  • Under the hood, SAM compiles to CloudFormation and uses S3 for artifact storage; CloudFormation executes the actual provisioning. For more details, consult AWS SAM and CloudFormation documentation.

Watch Video