AWS Serverless Application Model (SAM)

AWS Serverless Application Model (SAM) is an open-source framework for building serverless applications. It extends AWS CloudFormation with simplified syntax specifically for serverless resources. SAM allows you to define serverless components—such as Lambda functions, API Gateway APIs, and DynamoDB tables—using a compact, high-level syntax. Under the hood, SAM transforms your template into a standard CloudFormation template that creates all the necessary resources.

Before SAM, deploying a serverless application required writing verbose CloudFormation templates with many lines of boilerplate code. For example, a simple Lambda function behind API Gateway needed explicit definitions for:

SAM reduces this to a few lines. It also provides a CLI (sam) for local testing, packaging, and deployment, which CloudFormation alone lacks.

SAM operates in two phases: transformation and deployment.

Phase 1: Transformation When you run sam deploy or aws cloudformation deploy with a SAM template, CloudFormation invokes a macro called AWS::Serverless-2016-10-31. This macro processes your template and expands each SAM resource into the underlying CloudFormation resources. For example, AWS::Serverless::Function expands to: - AWS::Lambda::Function - AWS::IAM::Role - AWS::Lambda::Permission (if event sources are defined) - Potentially other resources depending on the event source (e.g., AWS::ApiGateway::RestApi for HttpApi events)

The transformation happens server-side in CloudFormation. The resulting template is then used to create or update the stack.

Phase 2: Deployment The transformed CloudFormation template is deployed as a standard CloudFormation stack. All SAM resources become actual AWS resources. The SAM CLI (sam deploy) automates this process, including packaging artifacts (zipping Lambda code, uploading to S3) and handling IAM capabilities.

SAM defines several resource types that start with AWS::Serverless:::

- AWS::Serverless::Function: Defines a Lambda function. Key properties: - CodeUri: Path to the function code (local or S3). - Handler: Function handler (e.g., index.handler). - Runtime: e.g., python3.9, nodejs18.x. - Events: Event sources that trigger the function (e.g., API Gateway, S3, SNS, DynamoDB Streams). - Policies: IAM policies attached to the function's role. Can be managed policy ARNs or inline policies. - Environment: Environment variables. - AutoPublishAlias: Enables traffic shifting for canary deployments. - DeploymentPreference: Controls canary deployment behavior (e.g., Linear10PercentEvery1Minute).

- AWS::Serverless::Api: Defines an API Gateway REST API. Key properties: - StageName: e.g., Prod. - DefinitionBody or DefinitionUri: OpenAPI specification. - Cors: CORS configuration. - Auth: Authorization settings (e.g., Cognito, IAM, Lambda authorizer). - EndpointConfiguration: e.g., REGIONAL, EDGE, PRIVATE.

A SAM template is a CloudFormation template with a Transform declaration:

AWSTemplateFormatVersion: '2010-09-09'
Transform: AWS::Serverless-2016-10-31
Description: My SAM application

Globals:
  Function:
    Timeout: 10
    MemorySize: 128

Resources:
  MyFunction:
    Type: AWS::Serverless::Function
    Properties:
      CodeUri: src/
      Handler: index.handler
      Runtime: nodejs18.x
      Events:
        HelloWorld:
          Type: Api
          Properties:
            Path: /hello
            Method: get

The Globals section allows setting shared properties for all functions, APIs, etc. in the template. This reduces duplication.

The SAM CLI (sam) provides several commands crucial for the exam:

- `sam init`: Initializes a new SAM project from a template (e.g., sam init --runtime python3.9). - `sam build`: Builds your application by installing dependencies and packaging code. It looks for a requirements.txt (Python) or package.json (Node.js) and runs the appropriate build commands. It also copies source files to a .aws-sam build directory. - `sam package`: Packages your application by uploading artifacts to S3 and producing a packaged template. Equivalent to aws cloudformation package. - `sam deploy`: Deploys the application. Common options: - --guided: Interactive mode that prompts for parameters. - --stack-name: CloudFormation stack name. - --s3-bucket: S3 bucket for artifacts. - --capabilities CAPABILITY_IAM: Required because SAM creates IAM roles. - --no-fail-on-empty-changeset: Prevents failure when no changes are made. - `sam local invoke`: Invokes a Lambda function locally using a Docker container that mimics the Lambda runtime. - `sam local start-api`: Starts a local HTTP server that emulates API Gateway and invokes Lambda functions. - `sam logs`: Fetches logs from CloudWatch Logs for a function. - `sam sync`: (Newer) Syncs local changes to the cloud for rapid development. - `sam validate`: Validates your SAM template against the SAM specification. - `sam delete`: Deletes the stack and associated artifacts.

SAM sets sensible defaults for many properties:

SAM integrates with: - CloudFormation: As the underlying deployment engine. - Lambda: For serverless compute. - API Gateway: For REST and HTTP APIs. - DynamoDB: Via SimpleTable or raw DynamoDB resources. - S3: For event sources and artifact storage. - SNS, SQS: As event sources for Lambda. - Step Functions: Via AWS::Serverless::StateMachine. - Cognito: For API authorization. - CodeDeploy: For safe Lambda deployments with traffic shifting. - CloudWatch: For logging and monitoring.

SAM provides predefined policy templates that attach common permissions to Lambda functions. Examples: - S3CrudPolicy: Read/write access to a specific S3 bucket. - DynamoDBCrudPolicy: Read/write access to a DynamoDB table. - SQSPollerPolicy: Allows polling an SQS queue. - CloudWatchPutMetricPolicy: Allows putting custom metrics.

You can reference these in the Policies property:

Policies:

- S3CrudPolicy:
      BucketName: my-bucket

SAM supports canary and linear deployments for Lambda functions using DeploymentPreference and AutoPublishAlias. This creates a CodeDeploy application that shifts traffic gradually. For example:

AutoPublishAlias: live
DeploymentPreference:
  Type: Canary10Percent5Minutes

This publishes a new version, creates an alias live, and shifts 10% of traffic to the new version for 5 minutes before moving to 100%.

While Terraform is also used for infrastructure as code, SAM is AWS-native and deeply integrated with Lambda, API Gateway, and other serverless services. SAM templates are simpler for serverless workloads, but Terraform supports multi-cloud. For the DVA-C02, SAM is the expected tool for serverless deployment.

A company builds a REST API for a mobile app using multiple Lambda functions for different endpoints (users, orders, payments). They use SAM to define each function with its own API Gateway resource. The SAM template includes an AWS::Serverless::Api for the REST API with a custom domain and Cognito authorizer. Each function is defined with Events of type Api pointing to specific paths and methods. The Globals section sets a common timeout and memory size. The team uses sam local start-api for local development, which speeds up iteration. In production, they deploy with sam deploy --guided and use DeploymentPreference for canary releases. One challenge is managing environment-specific configuration (e.g., database table names). They use CloudFormation parameters and the Parameters section in the template. A misconfiguration—like forgetting to add CAPABILITY_IAM—causes deployment failures. Also, if the CodeUri points to a local path that doesn't exist after build, the packaged template references a missing zip file, causing a stack update failure. They learned to always run sam build before sam package or sam deploy.

A financial services company processes real-time transaction data. They use SAM to define Lambda functions triggered by S3 events (new files), SNS topics, and DynamoDB Streams. The SAM template includes an AWS::Serverless::Function for each processor, with Events of type S3, SNS, and DynamoDB. They use AWS::Serverless::SimpleTable for a DynamoDB table that stores processing status. The SAM Policies property attaches S3ReadPolicy and DynamoDBCrudPolicy to the functions. They use sam build with a custom build script to compile Java code. During deployment, they use --parameter-overrides to pass environment-specific values (e.g., S3 bucket names). A common issue is that the S3 event source requires the bucket to be in the same account and region. Also, if the function code has dependencies that are not included in the build, the function fails at runtime. They use sam local invoke with test events to validate. They also use sam logs to tail CloudWatch logs during testing.

A startup builds a serverless web app with user authentication via Amazon Cognito. They use SAM to define an HTTP API (AWS::Serverless::HttpApi) with JWT authorizer. The SAM template includes a Lambda function for each API route. They use the Auth property on the API to specify the Cognito user pool. For the frontend, they host static files on S3 and CloudFront, but that part is outside SAM. During development, they use sam local start-api to test locally, but they need to mock Cognito tokens. In production, they deploy with sam deploy and use AWS::Serverless::LayerVersion for common dependencies (e.g., AWS SDK). They also use sam sync for rapid updates. A misconfiguration: if the Auth property is not set correctly, API Gateway returns 401 errors. They learned to test with actual Cognito tokens using sam local invoke with a token in the event.