AWS SAM & Elastic Beanstalk
Two higher-level deployment abstractions that trade some CloudFormation/CDK flexibility for a much faster path to a running application — SAM for serverless, Beanstalk for traditional web apps.
Want a visual for this topic?
Generate a diagram tailored to AWS SAM & Elastic Beanstalk — the AI picks whichever visual (architecture, flowchart, ER diagram, etc.) best fits this specific AWS concept.
Sign in to generate a visual →🎓 Learning objectives
- •Explain what SAM adds on top of raw CloudFormation for serverless applications
- •Explain what Elastic Beanstalk automates on your behalf for a traditional web application
- •Describe the tradeoff both services make between simplicity and infrastructure control
- •Identify when to reach for SAM/Beanstalk versus CloudFormation/CDK directly
What is it?
AWS SAM (Serverless Application Model) is an open-source extension of CloudFormation with a simplified, purpose-built shorthand syntax for serverless resources — a few lines of AWS::Serverless::Function expand into the full Lambda function, IAM role, and event-source-mapping resources CloudFormation would otherwise require spelled out explicitly. The SAM CLI adds local testing (sam local invoke, sam local start-api) and a streamlined sam build && sam deploy workflow. Elastic Beanstalk is a fully managed application deployment service for traditional (non-serverless) applications: given your application code (or a Docker image) and a platform choice, it automatically provisions and wires EC2 instances, an Auto Scaling group, an Elastic Load Balancer, and CloudWatch monitoring, and manages rolling deployments and health-based rollback — while still exposing the underlying EC2/ASG/ELB resources for direct customization if needed.
Why it exists
SAM exists because early serverless CloudFormation templates were extremely verbose — a single Lambda function with an API Gateway trigger required many lines of explicit resource definitions and wiring that were nearly identical across almost every serverless project. SAM's shorthand collapses that boilerplate into a few lines while still compiling to standard CloudFormation, so it doesn't sacrifice CloudFormation's state management and rollback guarantees. Elastic Beanstalk exists from an earlier AWS era (2011, well before ECS or Lambda existed) to answer the single most common early-cloud question — 'I just have some code, how do I get it running reliably at scale on AWS' — without requiring the team to learn EC2/ASG/ELB configuration from scratch.
Problem it solves
SAM solves serverless CloudFormation's boilerplate problem and the lack of a fast local test loop. Elastic Beanstalk solves the 'how do I go from application code to a production-grade, auto-scaled, load-balanced, monitored deployment' problem without requiring the team to design that infrastructure from scratch in CloudFormation, CDK, or Terraform.
Intuition
Both trade some of CloudFormation/CDK's full control for speed — SAM specifically for the serverless resource shape, Beanstalk specifically for the 'give me code, get me a running load-balanced fleet' shape. Neither replaces CloudFormation entirely: SAM literally compiles down to CloudFormation, and Beanstalk manages a CloudFormation stack under the hood that you can still inspect and, cautiously, modify.
Analogy
CloudFormation/CDK are like buying raw building materials and a detailed architectural blueprint — full control, but you assemble everything. SAM is a pre-fabricated kit specifically for one kind of structure (serverless functions and APIs) — much faster to assemble, less flexible if you want something the kit wasn't designed for. Elastic Beanstalk is closer to a fully pre-built modular home — hand over your furniture (application code) and choose a floor plan (platform), and the rest (foundation, wiring, plumbing) is handled for you.
Technical explanation
SAM's transform is registered as a CloudFormation macro (Transform: AWS::Serverless-2016-10-31) — when you run sam deploy, the SAM CLI packages your code to S3, then calls CloudFormation's own CreateChangeSet/ExecuteChangeSet APIs with the transform applied, meaning the actual deployed artifact is standard CloudFormation and shows up identically in the CloudFormation console. sam local invoke pulls a Docker image (amazon/aws-sam-cli-emulation-image-*) matching your function's actual Lambda runtime and architecture, so local execution closely mirrors the real Lambda environment, including cold-start-like initialization behavior. Elastic Beanstalk's health-based rollback works by having its per-instance agent report application and system health metrics back to the Beanstalk service, which compares against configured thresholds and can automatically abort and roll back an in-progress deployment if enough instances report 'Severe' health during the rollout.
Architecture
SAM's CLI performs a template transform step (AWS::Serverless-2016-10-31 transform) that expands shorthand serverless resources into their full CloudFormation equivalents before deployment, then hands off to CloudFormation's standard stack-creation/update engine — SAM adds no separate runtime component, it's purely a build-time convenience layer. Elastic Beanstalk maintains its own management layer (the 'Beanstalk environment') that internally creates and manages a CloudFormation stack containing an Auto Scaling group, launch template, load balancer, and supporting resources (security groups, CloudWatch alarms for health-based scaling/rollback) — Beanstalk's own agent runs on each EC2 instance to report health and pull new application versions during a deployment.
Workflow
For SAM: 1) Write a template.yaml using SAM's shorthand serverless resource types. 2) Test locally with sam local invoke or sam local start-api. 3) sam build to package dependencies. 4) sam deploy --guided for a first deploy (prompts for stack name/region/parameters) or sam deploy thereafter, which transforms the SAM template into full CloudFormation and deploys it as a stack. For Beanstalk: 1) Create an application and choose a platform (Java, Node.js, Python, Docker, etc.). 2) Upload your application source bundle (or point at an S3 location/container image). 3) Beanstalk provisions the environment (EC2/ASG/ELB) and deploys your code onto it. 4) Subsequent deployments upload a new version and Beanstalk performs a rolling update, monitoring instance health and rolling back automatically on failure if configured.
Example
A team building a serverless API defines it in a ~30-line SAM template (AWS::Serverless::Api + a few AWS::Serverless::Function resources), tests it locally with sam local start-api before ever touching AWS, then deploys with sam deploy --guided. A separate team with an existing Spring Boot JAR deploys it to Elastic Beanstalk by uploading the JAR and choosing the 'Corretto' Java platform — Beanstalk provisions the EC2 instances, load balancer, and Auto Scaling group automatically, with zero CloudFormation/Terraform authored by the team.
Real-world usage
SAM is commonly the first tool teams reach for when starting a new serverless project, specifically for the local-testing workflow, before some teams eventually migrate larger serverless projects to CDK for more programmatic flexibility as they grow. Elastic Beanstalk remains popular for straightforward web application deployments (especially Java/Spring Boot and .NET applications) where a team wants production-grade auto-scaling and load balancing without adopting ECS/EKS or hand-writing CloudFormation, and is frequently the deployment target recommended in AWS's own getting-started tutorials for traditional web frameworks.
Trade-offs
SAM's shorthand syntax only covers serverless resource patterns well — a template mixing serverless functions with significant non-serverless infrastructure (a VPC, an RDS instance, a complex network topology) often ends up reaching for raw CloudFormation resources alongside the SAM shorthand anyway, at which point CDK's full programming-language expressiveness may fit better. Beanstalk's opinionated deployment model is faster to get started with than hand-rolling ECS/EKS, but offers less fine-grained control over deployment strategy, container orchestration patterns, or multi-service architectures — teams that outgrow Beanstalk's model typically migrate to ECS/EKS rather than deeply customizing Beanstalk further.
Visual explanation
Picture a spectrum from 'raw materials' to 'fully assembled.' CloudFormation/CDK sit at the raw-materials end — full control, full effort. SAM sits partway toward assembled, but only for the serverless-shaped kit. Elastic Beanstalk sits further toward assembled for the traditional-web-app shape — hand over code, get back a running, scaled environment, with the option to open the access panel (.ebextensions, underlying CloudFormation stack) if you need to reach in and adjust something.
Advantages
- —
SAM: dramatically less boilerplate for serverless resources than raw CloudFormation, plus genuinely useful local testing via Docker-based Lambda emulation
- —
SAM: still full CloudFormation under the hood, so stack rollback, drift detection, and change sets all still apply
- —
Beanstalk: fastest path from 'application code' to 'running, load-balanced, auto-scaled, monitored environment' with zero infrastructure code written
- —
Beanstalk: supports rolling, immutable, and blue/green deployment options out of the box, with automatic health-based rollback
- —
Both: no additional charge beyond the underlying resources they provision (Lambda/API Gateway for SAM, EC2/ASG/ELB for Beanstalk) — the abstraction layer itself is free
Disadvantages
- —
SAM's shorthand only covers serverless-shaped infrastructure well — mixed serverless/traditional architectures often need raw CloudFormation resources alongside it
- —
Beanstalk's opinionated model makes some advanced deployment patterns (canary analysis, service mesh, fine-grained container placement) harder to express than in ECS/EKS directly
- —
Both add an abstraction layer that can obscure exactly what CloudFormation resources are actually being created, which occasionally complicates debugging a failed deployment
- —
Beanstalk environments still incur the underlying EC2/ELB costs even when idle — it does not scale to zero the way Lambda-based SAM applications can
Common mistakes
- —
Using SAM for a project that's mostly non-serverless infrastructure, fighting the shorthand syntax instead of just using CloudFormation or CDK directly
- —
Never testing with
sam local invokebefore deploying, missing the main productivity benefit SAM offers over raw CloudFormation for Lambda development - —
Heavily customizing a Beanstalk environment via
.ebextensionsuntil it's effectively a hand-maintained CloudFormation stack anyway, at which point migrating to actual CloudFormation/CDK would be clearer - —
Leaving a Beanstalk environment running for a low-traffic or discontinued application, paying for EC2/ELB capacity nobody is using — Beanstalk environments need the same lifecycle hygiene as any other EC2-backed resource
In the AWS Console
- 1
(CLI, not console) — `sam init`
Install the SAM CLI and initialize a new project from a starter template.
SAM's own quick-start templates (e.g. 'Hello World Example') are a fast way to see the shorthand syntax and local-test workflow immediately.
- 2
Elastic Beanstalk → Create application
Create a new Elastic Beanstalk application and environment, uploading an application source bundle and choosing a platform.
Choose 'Single instance' for quick testing, or 'Load balanced, auto scaling' for anything meant to resemble production.
- 3
Elastic Beanstalk → [environment] → Upload and deploy
Deploy a new application version to an existing Beanstalk environment and watch the rolling update and health status.
🎤 Interview questions
What is AWS SAM, and how does it relate to CloudFormation? (Listen for: SAM (Serverless Application Model) is an open-source framework that extends CloudFormation with a simplified shorthand syntax specifically for serverless resources — AWS::Serverless::Function, AWS::Serverless::Api — that the SAM CLI transforms into full CloudFormation templates at deploy time; it's a thin layer over CloudFormation, not a separate deployment engine)
What does Elastic Beanstalk automate that you'd otherwise configure manually? (Listen for: given just your application code and a platform choice (Java, Node.js, Python, Docker, etc.), Beanstalk provisions and wires together EC2, an Auto Scaling group, a load balancer, and CloudWatch monitoring automatically, and handles rolling deployments/health monitoring/rollback — while still giving you access to the underlying resources if you need to customize them)
How does sam local invoke help during development? (Listen for: it runs a Lambda function locally inside a Docker container that emulates the actual Lambda execution environment, letting you test function code and debug without deploying to AWS first, dramatically shortening the serverless dev feedback loop)
When would you choose Elastic Beanstalk over ECS/EKS for deploying a containerized application? (Listen for: Beanstalk when you want the fastest path to a running, auto-scaled, load-balanced application with minimal infrastructure decisions and are comfortable with its more opinionated deployment model; ECS/EKS when you need finer-grained control over task placement, service mesh, or multi-container orchestration patterns Beanstalk doesn't expose)
Can you still customize the underlying infrastructure Beanstalk creates? (Listen for: yes, via .ebextensions configuration files in the application source, or by directly modifying resources in the underlying CloudFormation stack Beanstalk manages — though heavy customization starts eroding the 'it just works' simplicity that's the main reason to choose Beanstalk in the first place)