Cargando...
Cargando...
Define, build, test, and deploy serverless apps faster with CloudFormation superpowers
AWS Serverless Application Model (SAM) is an open-source framework that extends AWS CloudFormation to simplify the definition, testing, and deployment of serverless applications. It provides shorthand syntax to express Lambda functions, API Gateway APIs, DynamoDB tables, and event source mappings — transforming them into full CloudFormation resources at deploy time. The SAM CLI adds local testing, debugging, and CI/CD pipeline capabilities, making it the end-to-end developer toolkit for serverless on AWS.
Accelerate serverless application development by abstracting CloudFormation complexity into concise SAM-specific resource types, while enabling local invocation, unit testing, and pipeline-driven deployments.
Use When
Avoid When
AWS::Serverless::Function
Shorthand for Lambda function + IAM execution role + event source mappings; supports all Lambda triggers via Events property
AWS::Serverless::Api
Creates API Gateway REST API with optional Swagger/OpenAPI definition; use AWS::Serverless::HttpApi for HTTP API (v2)
AWS::Serverless::HttpApi
Creates API Gateway HTTP API (v2) — lower latency and cost than REST API; supports JWT authorizers natively
AWS::Serverless::SimpleTable
Creates DynamoDB table with single-attribute primary key; use native AWS::DynamoDB::Table for GSIs, LSIs, or complex key schemas
AWS::Serverless::LayerVersion
Creates Lambda Layer version; supports ContentUri pointing to local path or S3; critical for sharing dependencies
AWS::Serverless::Application
Embeds a nested application from SAR (Serverless Application Repository) or a nested SAM template — key pattern for modularization
AWS::Serverless::StateMachine
Creates Step Functions state machine with SAM shorthand — supports inline definition or external ASL file
AWS::Serverless::Connector
Automatically generates least-privilege IAM policies between SAM resources — reduces boilerplate IAM policy writing
sam local invoke
Runs Lambda function locally in a Docker container matching the Lambda execution environment; supports event JSON input and Lambda Layers
sam local start-api
Starts a local HTTP server that simulates API Gateway, routing requests to local Lambda containers
sam local start-lambda
Starts a local Lambda endpoint that AWS SDKs can invoke — enables integration testing of services that call Lambda
sam local generate-event
Generates sample event payloads for supported AWS services (S3, SNS, SQS, API GW, etc.) for use with sam local invoke
sam build --use-container
Builds dependencies inside a Docker container matching the Lambda runtime — critical for native/compiled dependencies (e.g., psycopg2, numpy with C extensions)
sam deploy --guided
Interactive first-time deployment wizard that saves configuration to samconfig.toml for subsequent deployments
sam pipeline init
Generates CI/CD pipeline configuration for CodePipeline, GitHub Actions, GitLab CI, Jenkins, and Bitbucket
sam sync (SAM Accelerate)
Rapid development sync that bypasses CloudFormation for Lambda/API GW updates — NOT for production use
Globals Section
Define common properties (Timeout, MemorySize, Runtime, Environment Variables) once and apply to all functions — reduces duplication
Policy Templates
Pre-built IAM policy templates (e.g., S3ReadPolicy, DynamoDBCrudPolicy) that accept resource ARNs — faster than writing raw IAM JSON
Canary/Linear Deployments (CodeDeploy integration)
DeploymentPreference property enables Canary10Percent5Minutes, Linear10PercentEvery1Minute, etc. — automatically creates CodeDeploy application and deployment group
SAR (Serverless Application Repository) Publishing
SAM apps can be published to SAR for sharing publicly or within an AWS Organization
Function definition with automatic IAM role generation
high freqAWS::Serverless::Function automatically creates a Lambda execution role with AWSLambdaBasicExecutionRole; additional permissions added via Policies property using SAM Policy Templates or inline IAM. This is the core SAM-Lambda integration pattern.
REST API and HTTP API event source integration
high freqDefining an Api or HttpApi event in a SAM function automatically creates the API Gateway resource, method, integration, and Lambda permission. AWS::Serverless::Api allows shared API definition across multiple functions with a single Swagger/OpenAPI document.
SAM Transform — SAM as a CloudFormation macro
high freqSAM templates are CloudFormation templates with Transform: AWS::Serverless-2016-10-31. CloudFormation invokes the SAM transform macro to expand SAM shorthand into native CF resources before stack creation. This means all CloudFormation features (Parameters, Conditions, Outputs, Mappings, Fn::ImportValue) work natively in SAM templates.
Deployment artifact storage and S3 event triggers
high freqSAM uses S3 to store packaged Lambda deployment artifacts (sam package / sam deploy). Separately, S3 bucket notifications can be defined as event sources in AWS::Serverless::Function Events to trigger Lambda on object creation/deletion.
Serverless CI/CD pipeline with sam pipeline init
high freqsam pipeline init generates a CodePipeline definition with stages for source (CodeCommit/GitHub), build (CodeBuild running sam build), and deploy (CloudFormation change set + execute). CodeBuild buildspec.yml runs sam build and sam deploy --no-confirm-changeset for automated deployments.
Gradual Lambda deployment with traffic shifting
high freqAdding DeploymentPreference to AWS::Serverless::Function automatically creates a CodeDeploy application, deployment group, and CloudWatch alarms. Supports Canary (e.g., Canary10Percent5Minutes), Linear (e.g., Linear10PercentEvery1Minute), and AllAtOnce strategies. PreTraffic and PostTraffic hooks run Lambda functions before/after traffic shift.
Auditing SAM deployments and Lambda invocations
high freqCloudTrail records all SAM-initiated API calls (CloudFormation CreateStack, Lambda UpdateFunctionCode, etc.) for compliance auditing. SAM deployments are fully traceable through CloudTrail as CloudFormation and Lambda API events.
Shared dependency management via SAM LayerVersion
high freqAWS::Serverless::LayerVersion defines a layer with dependencies. Multiple functions reference the layer ARN in their Layers property. sam local invoke respects layer definitions for local testing. This is the correct pattern for sharing libraries — NOT synchronous Lambda-to-Lambda calls or runtime S3 downloads.
SimpleTable for rapid prototyping, native table for production
high freqAWS::Serverless::SimpleTable creates a DynamoDB table with a single hash key and on-demand billing — ideal for prototyping. Production workloads requiring GSIs, LSIs, streams, or complex key schemas must use native AWS::DynamoDB::Table within the same SAM template.
Orchestrated serverless workflows with StateMachine resource
high freqAWS::Serverless::StateMachine defines Step Functions state machines inline or via external ASL files. SAM auto-generates IAM roles for the state machine to invoke Lambda functions, publish to SNS, etc. — reducing IAM boilerplate for workflow orchestration.
The Transform declaration (Transform: AWS::Serverless-2016-10-31) is MANDATORY in every SAM template. Without it, CloudFormation does not recognize SAM resource types and the deployment fails with an 'Unknown resource type' error.
sam build --use-container is not just for exotic runtimes — it is the recommended practice for ANY function with native/compiled dependencies (numpy, psycopg2, Pillow) because it builds inside the exact Lambda execution environment Docker image, preventing 'wrong architecture' runtime errors.
sam local invoke fully supports Lambda Layers — SAM downloads and mounts layer content locally so your local test environment matches production. This is tested on DVA-C02 as candidates incorrectly believe layers are cloud-only.
DeploymentPreference in AWS::Serverless::Function integrates with CodeDeploy automatically — you do NOT need to define a CodeDeploy application or deployment group separately. SAM creates all required CodeDeploy resources as part of the CloudFormation stack.
SAM Policy Templates (e.g., S3ReadPolicy, DynamoDBCrudPolicy, SQSPollerPolicy) are SAM-specific shorthand that expand to proper IAM policies — they are NOT IAM managed policies and do NOT exist as standalone IAM entities in your account.
Transform: AWS::Serverless-2016-10-31 is MANDATORY — missing it causes CloudFormation to reject all SAM resource types with 'Unknown resource type' errors
Lambda Layers (AWS::Serverless::LayerVersion) are the correct pattern for sharing code/dependencies — NOT synchronous Lambda-to-Lambda calls, NOT runtime S3 downloads. sam local invoke supports layers for local testing.
sam build --use-container is a general best practice for compiled/native dependencies (not just exotic runtimes) — it builds inside the actual Lambda runtime Docker image, preventing platform-specific binary failures
The Globals section in a SAM template sets default properties for ALL functions, APIs, and tables. Individual resource definitions can override globals, but globals cannot be set per-resource-type — they apply template-wide for their resource category.
sam deploy creates or updates a CloudFormation stack using a change set by default. The --no-confirm-changeset flag skips manual approval — use this in CI/CD pipelines but never in production manual deployments where human review of changes is required.
AWS::Serverless::Application embeds nested SAM applications — either from the Serverless Application Repository (SAR) using ApplicationId or from a local/S3 SAM template using TemplateURL. This is the correct modularization pattern when your stack approaches the 500-resource CloudFormation limit.
sam local generate-event creates mock event payloads for S3, SNS, SQS, DynamoDB Streams, API Gateway, Kinesis, etc. Use these with sam local invoke -e event.json for repeatable local testing without needing live AWS services.
For cross-stack Lambda Layer sharing, Fn::ImportValue (cross-stack reference) works but creates a hard dependency between stacks — if the layer stack is updated, all consuming stacks are affected. Consider SAR publishing for truly reusable layers across teams or accounts.
Common Mistake
Synchronous Lambda-to-Lambda invocation is a good way to share common code/dependencies between functions — one function calls another that acts as a 'library function'
Correct
Lambda Layers (defined via AWS::Serverless::LayerVersion) are the correct mechanism for sharing code and dependencies. Synchronous Lambda-to-Lambda invocation adds latency, doubles cost (both functions bill simultaneously), creates tight coupling, and is an anti-pattern for dependency sharing.
This is the #1 misconception in SAM/Lambda exam questions. Remember: Layers = shared CODE/LIBRARIES. Synchronous invocation = orchestrating BUSINESS LOGIC between separate services. They solve completely different problems. If a question mentions sharing a database client library or utility module, the answer is Lambda Layers, never synchronous invocation.
Common Mistake
sam build --use-container is only necessary for unusual runtimes or exotic languages — standard Python/Node.js functions don't need it
Correct
sam build --use-container is a general best practice for any function with compiled/native dependencies (C extensions, platform-specific binaries). Python packages like numpy, pandas, psycopg2, and Pillow contain platform-specific compiled code — building on a Mac or Windows without --use-container produces binaries that crash in the Linux-based Lambda environment.
Exam questions describe a scenario where a function works locally but fails in Lambda with an 'invalid ELF header' or 'cannot import module' error — the correct fix is sam build --use-container. The distractor answers often include 'increase Lambda memory' or 'change runtime version', which are wrong.
Common Mistake
Runtime S3 downloads (fetching a shared library from S3 at Lambda cold start) are a viable, cost-effective alternative to Lambda Layers for sharing dependencies
Correct
Runtime S3 downloads add cold-start latency, incur S3 GET request costs on every cold start, require IAM permissions for S3 access in the function, and don't benefit from Lambda's layer caching. Lambda Layers are pre-mounted before function initialization, adding zero runtime latency and no per-invocation cost.
This misconception appears in questions about optimizing Lambda performance and cost. The correct answer is always Lambda Layers for static shared dependencies. S3 downloads are appropriate only for truly dynamic content that changes per-invocation (e.g., user-uploaded ML models).
Common Mistake
Fn::ImportValue (cross-stack references) is always the best pattern for sharing Lambda Layer ARNs across multiple SAM stacks
Correct
Fn::ImportValue creates a hard dependency — you cannot delete or update the exporting stack's Output while any stack imports it. For Lambda Layers, better alternatives include: (1) SSM Parameter Store to store and retrieve Layer ARNs dynamically, (2) SAR (Serverless Application Repository) for organization-wide layer sharing, or (3) a dedicated 'shared infrastructure' stack where the coupling is intentional and managed.
Exam questions present a scenario where a team can't update their layer stack because other stacks import it — the solution is SSM Parameter Store for the ARN or SAR publishing. Fn::ImportValue is not always wrong, but it's not 'always the best' as many candidates assume.
Common Mistake
SAM is a separate AWS service with its own console, API endpoints, and service quotas independent of CloudFormation
Correct
SAM is a CloudFormation transform macro — it has no independent service, console, or API. SAM templates are processed by the CloudFormation service using the AWS::Transform macro mechanism. The SAM CLI is a local developer tool; all deployments ultimately create/update CloudFormation stacks. All limits are inherited from CloudFormation, Lambda, API Gateway, etc.
Understanding that SAM IS CloudFormation (with a transform) is critical for questions about permissions, limits, troubleshooting, and rollback behavior. If a SAM deployment fails, you debug it in the CloudFormation console — not a 'SAM console' that doesn't exist.
Common Mistake
sam local invoke and sam local start-api make live calls to AWS services (DynamoDB, S3, SQS) during local testing
Correct
sam local invoke/start-api runs your Lambda function code locally in a Docker container but does NOT mock downstream AWS services. If your function code calls DynamoDB.getItem(), it will actually call the real AWS DynamoDB service (using your local AWS credentials). Use AWS SAM with LocalStack, AWS SAM local + DynamoDB Local, or moto (Python) to mock downstream services.
This causes real AWS charges and data mutations during 'local' testing if developers aren't careful. Exam questions may ask how to test a Lambda function locally WITHOUT making real AWS API calls — the answer involves DynamoDB Local or mocking frameworks, not just sam local invoke alone.
SAM = Shorthand, Accelerate, Macro — SAM provides Shorthand syntax, Accelerates development with local testing, and works as a CloudFormation Macro transform
TRANSFORM or FAIL: No 'Transform: AWS::Serverless-2016-10-31' = CloudFormation rejects all SAM resource types. Think of it as SAM's 'password' to activate the magic.
LAYERS not CALLERS: Share code with Lambda Layers, not by calling other Lambda functions. 'Layers for libraries, invocations for logic.'
USE-CONTAINER = USE-PRODUCTION-ENV: sam build --use-container builds in the same Docker image Lambda uses — what you build is what runs. No surprises in prod.
DeploymentPreference = Free CodeDeploy: SAM's DeploymentPreference property creates the entire CodeDeploy setup automatically. You write 3 lines of YAML, SAM creates 10+ CloudFormation resources.
CertAI Tutor · DVA-C02, DEA-C01, DOP-C02 · 2026-02-21
In the Same Category
Comparisons
Guides & Patterns