AWS SAM & the Serverless Framework

Once you have more than one Lambda function and an API Gateway in front of it, clicking everything together in the AWS Management Console stops scaling. You forget which settings you changed, you cannot recreate the same setup in a second account, and nobody can review the change before it ships. This is where Infrastructure as Code (IaC — describing your cloud resources in text files instead of clicking buttons) comes in. This page compares the two most popular serverless IaC tools — AWS SAM (the Serverless Application Model) and the Serverless Framework — and shows you how to define, test, and deploy a function with each.

Why IaC beats clicking in the Console

When you build a serverless app by hand in the Console, the result is unreproducible and ungoverned. There is no record of what you clicked, so the only “source of truth” is the live account itself. If someone deletes a resource, or you need an identical staging environment, you are stuck recreating it from memory.

IaC fixes this. Your whole stack — functions, routes, IAM roles, queues, tables — lives in a text file you commit to Git. That gives you:

• Repeatability — deploy the same file into dev, staging, and prod and get identical results.
• Review and history — changes go through pull requests; git blame tells you who changed what and why.
• Safe deletes — tear the whole stack down with one command, with nothing left dangling to keep billing you.

Gotcha: A function someone wired up by hand in the Console is invisible to your IaC. If you later deploy a stack that “owns” the same name, you can get conflicts or silent drift. Pick IaC from day one and never mix the two for the same resource.

SAM vs Serverless Framework vs CDK — when to use which

Tool	Language	Cloud	Best for
AWS SAM	YAML (CloudFormation superset)	AWS only	AWS-native teams who want first-class local testing and tight CloudFormation integration
Serverless Framework	YAML + huge plugin ecosystem	Multi-cloud (AWS, Azure, GCP)	Teams wanting plugins (custom domains, secrets, monitoring) or possible multi-cloud
AWS CDK	TypeScript, Python, Java, Go	AWS only	Teams who prefer real programming languages, loops, and abstractions over YAML

All three compile down to AWS CloudFormation (AWS’s native IaC engine) under the hood when targeting AWS. SAM is the most AWS-official; the Serverless Framework is the most portable; CDK gives you real code instead of YAML.

Option A — AWS SAM

SAM is a thin extension on top of CloudFormation. You write a template.yaml using shortened resource types like AWS::Serverless::Function, and SAM expands them into full CloudFormation for you. Its standout feature is sam local, which runs your function on your laptop inside a Docker container that mimics the Lambda runtime.

When to use it: you are all-in on AWS, you want local testing, and you like that it is the AWS-maintained tool.

A minimal template.yaml for an HTTP API plus a function:

AWSTemplateFormatVersion: "2010-09-09"
Transform: AWS::Serverless-2016-10-31

Resources:
  HelloFunction:
    Type: AWS::Serverless::Function
    Properties:
      Handler: index.handler
      Runtime: nodejs22.x
      Architectures: [arm64]
      CodeUri: ./src
      Events:
        HelloApi:
          Type: HttpApi
          Properties:
            Path: /hello
            Method: GET

Install the SAM CLI, then build and deploy:

sam build
sam deploy --guided

--guided asks for a stack name and region the first time and saves your answers to samconfig.toml for next time.

Output:

CloudFormation outputs from deployed stack
-------------------------------------------------
Key                 HelloApiUrl
Value               https://a1b2c3d4e5.execute-api.us-east-1.amazonaws.com/hello

Successfully created/updated stack - hello-sam in us-east-1

Testing locally with sam local

sam local invoke runs your handler in a Docker container shaped like Lambda, so you can iterate without deploying:

sam local invoke HelloFunction --event events/get.json

Output:

Invoking index.handler (nodejs22.x)
START RequestId: 8f3c1a2b-... Version: $LATEST
END RequestId: 8f3c1a2b-...
{"statusCode":200,"body":"{\"message\":\"Hello, world!\"}"}

You can even run the whole API locally with sam local start-api, which serves it at http://127.0.0.1:3000.

Important gotcha: sam local mimics Lambda but is not identical to the cloud. Your laptop’s CPU, memory limits, network access, IAM permissions, and cold-start behavior all differ. Local testing is great for fast iteration, but always test the deployed stack before you trust it. A function that passes locally can still fail in the cloud on permissions or timeouts.

Option B — the Serverless Framework

The Serverless Framework predates SAM and is multi-cloud with a large plugin ecosystem (community add-ons for custom domains, secrets, warming, and more). On AWS it also compiles to CloudFormation, but its config is a single serverless.yml.

When to use it: you want plugins SAM lacks, you might target more than one cloud, or your team already knows it. When NOT to: if you are purely AWS and want the most official, plugin-free path, SAM (or CDK) is simpler.

A serverless.yml equivalent of the SAM example above:

service: hello-service

provider:
  name: aws
  runtime: nodejs22.x
  architecture: arm64
  region: us-east-1

functions:
  hello:
    handler: src/index.handler
    events:
      - httpApi:
          path: /hello
          method: get

Deploy with one command:

serverless deploy

Output:

Deploying hello-service to stage dev (us-east-1)

endpoint: GET - https://a1b2c3d4e5.execute-api.us-east-1.amazonaws.com/hello
functions:
  hello: hello-service-dev-hello

Stack Outputs:
  HttpApiUrl: https://a1b2c3d4e5.execute-api.us-east-1.amazonaws.com

You invoke a deployed function with serverless invoke -f hello, or emulate it offline with the popular serverless-offline plugin.

Cost note

Both tools are free open-source CLIs — you pay only for the AWS resources they create (Lambda invocations, API Gateway requests, CloudFormation is free). The Serverless Framework offers an optional paid dashboard, but the CLI deploy itself costs nothing. There is no IaC “tax”: deploying via SAM costs exactly the same as clicking the same resources by hand.

Best practices

• Adopt IaC from the first function — never mix hand-clicked Console resources with IaC-managed ones for the same stack.
• Commit template.yaml / serverless.yml to Git and require pull-request review for infra changes.
• Use sam local (or serverless-offline) for fast iteration, but always validate against a real deployed stage before trusting it.
• Deploy the same template into separate dev, staging, and prod stacks rather than reusing one environment.
• Let the tool create least-privilege IAM roles per function instead of attaching one broad shared role.
• Choose SAM or CDK if you are AWS-only; pick the Serverless Framework when you need its plugins or multi-cloud reach.
• Tear down throwaway stacks with sam delete or serverless remove so leftover resources stop billing you.

Related Topics

• What is serverless?
• Building a serverless API
• Create a Lambda function
• Lambda handlers & runtimes
• When to go serverless