2.1.3. AWS Serverless Application Model (SAM)

First Principle: AWS Serverless Application Model (SAM) simplifies the definition and deployment of serverless applications by providing a concise syntax for common serverless resources.

SAM defines this entire architecture in a single template file — API Gateway, Lambda functions, DynamoDB table, and S3 bucket with their permissions and event mappings.

AWS Serverless Application Model (SAM) is an open-source framework that extends AWS CloudFormation to provide a simplified way of defining serverless applications. It offers a shorthand syntax for declaring serverless resources like Lambda functions, API Gateway APIs, and DynamoDB tables.

• Simplified Syntax: Express common serverless resources with fewer lines of code than raw CloudFormation.
• SAM CLI: Provides local testing capabilities (sam local invoke, sam local start-api), dependency bundling, and deployment commands (sam deploy).
• CLI workflow: sam validate checks the template; sam build installs dependencies and compiles code into .aws-sam/build; sam local invoke runs one function once with an event, while sam local start-api runs a local HTTP server that emulates API Gateway; sam local generate-event (or the Lambda console's test-event templates) produces sample payloads such as an API Gateway proxy event; sam deploy --guided packages, uploads and deploys the first time and saves your answers to samconfig.toml. To ship a change, run sam deploy again — CloudFormation computes a change set and updates the existing stack.
• CloudFormation Transformation: SAM templates are transformed by AWS into standard CloudFormation templates before deployment, leveraging CloudFormation's robust deployment capabilities.
• SAM template anatomy: the Transform: AWS::Serverless-2016-10-31 line is what makes CloudFormation expand AWS::Serverless::* types — without it they are unrecognized. AWS::Serverless::Function expands into the function, its execution role and its event sources; CodeUri points to the code and Handler names the entry point. A Globals section sets shared function properties (memory, timeout, runtime, environment) once for every function. Everything else — SQS queues, S3 buckets, raw CloudFormation types — goes in Resources alongside the serverless types.
• Developer-Centric: Designed to accelerate the developer experience for serverless applications.
• Drift Detection: A SAM application deploys as a CloudFormation stack, so if someone changes its resources outside CloudFormation (e.g., edits a security group in the console), drift detection reports the differences. Then update the stack or template to bring them back in sync rather than deleting and recreating the stack.

CloudFormation & CDK essentials (SAM is built on CloudFormation):

• Why IaC: Templates give repeatable, version-controlled, reviewable provisioning. The same template builds dev, staging and prod, with environment differences passed in as Parameters (for example, a parameter file per environment or sam deploy --config-env), not hardcoded or copied per environment. Teams often pair this with a Git branch per environment (see 2.3.1).
• CloudFormation template sections: Resources and their settings live in Resources; a DynamoDB table's capacity, for example, is in that resource's Properties. Parameters are deploy-time inputs, Mappings are static lookup tables and Outputs return values.
• Intrinsic functions: !Ref returns a resource's default identifier (for a DynamoDB table, its name). !GetAtt Table.Arn returns a named attribute such as the ARN.
• Secrets: Mark a password parameter NoEcho: true so it is masked in console and API output. Better still, use a dynamic reference to Secrets Manager ({{resolve:secretsmanager:...}}). Never put secrets in Mappings, parameter defaults or UserData.
• Updates: Create a change set to preview exactly what an update will add, modify, replace or remove, then execute it. If an update fails, CloudFormation rolls back to the last stable state by default (see 3.3.2).
• AWS CDK: Define infrastructure in TypeScript, JavaScript, Python, Java, C# or Go. The code is built from constructs, components that represent one or more AWS resources and their configuration. cdk synth synthesizes the CloudFormation template, and cdk deploy synthesizes and deploys it.
• Project layout: Keep template.yaml at the project root, function code in its own folder (for example src/, referenced by CodeUri) and tests in tests/, so tests never ship in the deployment package.

Scenario: You're building a new serverless application with several Lambda functions and an API Gateway endpoint. You want a simplified way to define these resources and deploy your application, avoiding verbose CloudFormation syntax. You also need to test your Lambda functions locally.

⚠️ Exam Trap: SAM is a superset of CloudFormation — any resource you can declare in a CloudFormation template can also be declared in a SAM template, and the Transform line tells CloudFormation to expand the SAM shorthand. SAM simplifies serverless resources but uses CloudFormation for deployment. sam deploy runs aws cloudformation deploy under the hood.