Skip to content

SYSTEM Cited by 1 source

AWS SAM (Serverless Application Model)

What it is

AWS Serverless Application Model (SAM) is AWS's open-source framework for defining + deploying serverless applications. A SAM template is a superset of CloudFormation — same YAML/JSON dialect, plus the AWS::Serverless::* transform that expands shorthand resource types (AWS::Serverless::Function → Lambda function + execution role + event source wiring) into CloudFormation primitives. SAM is to serverless applications what systems/aws-cdk is to general AWS infrastructure — both synthesise to CloudFormation, with SAM specialised for the Lambda-centric shape.

Role in this wiki — local emulation for agentic development

SAM's load-bearing feature for this wiki is the SAM CLI's local emulation surface, named by the AWS Architecture Blog as the canonical AI-agent feedback-loop entry point for serverless apps:

"Serverless applications built with AWS Lambda and Amazon API Gateway can be emulated locally using the AWS Serverless Application Model (AWS SAM). With the sam local start-api command, an AI agent can invoke Lambda functions through a locally emulated API Gateway, observe responses immediately, and iterate in seconds rather than minutes." (Source: sources/2026-03-26-aws-architecting-for-agentic-ai-development-on-aws)

This places SAM in the patterns/local-emulation-first tier — the cheapest tier that can falsify an AI-generated change to a Lambda handler. Iteration time collapses from "minutes to hours per change" (deploy to real Lambda + wait for pipeline + wait for logs) to "seconds per change" (local invocation against a Docker-based Lambda runtime + local API Gateway mock).

SAM CLI local-emulation surfaces

The AWS post names sam local start-api specifically; the broader CLI also offers:

  • sam local invoke <Function> — single-function invocation with event payload (tests a handler in isolation).
  • sam local start-api — locally-emulated API Gateway over Lambda functions; agent or browser hits http://localhost:3000/... and gets the real Lambda code path.
  • sam local start-lambda — local Lambda service endpoint the AWS SDK can target for testing service-to-service invocation paths.
  • sam build — build the deployment artefact (Python deps installed, Java jars assembled, container images built).
  • sam deploy — deploy via CloudFormation.
  • sam sync — incremental code updates against a deployed stack, faster than full redeploy (useful for the tier above local emulation).

Relation to concepts/agentic-development

Agentic development depends on feedback-loop speed, and feedback speed for serverless apps is gated by how long it takes to validate a Lambda change. SAM's local emulation compresses that validation from the deploy-and-wait tier to the subprocess tier. The AWS blog's escalating tier ladder for agentic feedback:

Tier Tool Latency
1. Local emulation (Lambda + API Gateway) SAM sam local start-api seconds
1. Local container run docker run same image seconds
1. Local DynamoDB systems/dynamodb-local seconds
1. Local Glue Glue Docker images seconds
2. Hybrid cloud (no emulator) patterns/hybrid-cloud-testing via CloudFormation/CDK small stacks minutes
3. Preview environment (full app) patterns/ephemeral-preview-environments IaC stacks minutes

SAM sits at tier 1 — the default path the agent should try first.

Caveats

  • Emulator drift. sam local runs Lambda handlers in a Docker-based Lambda Runtime Interface Emulator; API Gateway is re-implemented client-side. Behaviour is close but not identical to production — throttling, timeout, cold-start, IAM evaluation, authoriser composition all differ. The AWS post doesn't discuss this drift; real projects eventually need hybrid tests + smoke tests against deployed envs to catch what the emulator silently passes.
  • Cold-start profile is not reproduced. Local invocation hot-loads the handler and skips the init-phase costs that dominate production tail latency.
  • IAM evaluation is not simulated. Missing iam:PassRole or cross-service permissions only surface in deployed envs, which is why the AWS post mandates smoke tests "to surface configuration or permission issues that only appear at runtime."

Seen in

Last updated · 200 distilled / 1,178 read