AWS SAM vs CloudFormation: Cost, Features, and Which to Choose

Most “SAM vs CloudFormation” comparisons start from a false premise, that you are choosing between two rival tools. You are not. AWS SAM is built on CloudFormation, deploys through CloudFormation, and produces a CloudFormation stack every time you run it. The real question is narrower and more useful: for the serverless parts of your infrastructure, is SAM's extra layer worth adopting, and what does the answer mean for how much you build, how fast you ship, and what you pay?

This guide answers that properly. It explains exactly how AWS SAM relates to AWS CloudFormation, compares them on scope, syntax, tooling, and cost in US dollars, works through a realistic serverless example, and ends with a decision framework. It also covers the part most comparisons skip: how each one shapes the AWS bill of the resources it deploys.

Key Takeaways

• SAM runs on CloudFormation: a SAM template is a CloudFormation template with a Transform declaration, and every SAM deploy produces a CloudFormation stack.
• SAM's value is shorthand and tooling: one AWS::Serverless::Function replaces dozens of lines of raw CloudFormation, and the SAM CLI adds local invocation, API emulation, and fast sync deployment.
• Both are free to use; you pay for the resources deployed. CloudFormation charges about $0.0009 per operation only for third-party registry resource types beyond a free allowance.
• SAM's convenience can create cost through defaults, especially CloudWatch Logs retention set to never expire; explicit settings in the template prevent it.
• Use SAM for serverless stacks, CloudFormation for everything else, and combine them freely in one template.

How SAM and CloudFormation Relate

CloudFormation is the engine. You describe resources, VPCs, IAM roles, EC2 instances, Lambda functions, databases, in a declarative YAML or JSON template, and CloudFormation creates, updates, and deletes them as a unit called a stack, tracking state and handling dependencies and rollbacks. It can define nearly every AWS resource type and is the substrate that other AWS tooling, including the CDK, compiles down to.

SAM is a layer on that engine, delivered as a CloudFormation transform, which is a macro that CloudFormation runs on your template before deploying it. Adding the line Transform: AWS::Serverless-2016-10-31 to a CloudFormation template turns it into a SAM template and unlocks a handful of serverless resource types: AWS::Serverless::Function, Api, HttpApi, SimpleTable, StateMachine, and, as of 2026, CapacityProvider. When you deploy, CloudFormation expands each of these into the standard resources it represents. A five-line Serverless::Function becomes a Lambda function, an execution role with appropriate policies, event source mappings, often an API Gateway route, and typically a log group. The SAM developer guide documents the expansion; the practical upshot is that SAM is specialized CloudFormation that knows a great deal about Lambda.

The second half of SAM is the SAM CLI, a separate open-source tool that builds function code and dependencies, invokes functions and emulates API Gateway locally, packages artifacts to S3, deploys through CloudFormation, and, with sam sync, pushes code changes to the cloud in seconds without a full stack update. None of this exists in CloudFormation itself, and for many teams the CLI rather than the template shorthand is the reason to adopt SAM.

Side-by-Side Comparison

What Each One Costs

Neither tool has a price tag of its own for ordinary use. CloudFormation is free for managing AWS resource types, and its only charge, listed on the official CloudFormation pricing page, is for third-party and private registry resource types: roughly $0.0009 per handler operation after 1,000 free operations a month, which is negligible for almost everyone. SAM inherits those rules because it deploys through CloudFormation, and the SAM CLI is free and open source. The cost of either is the cost of what they deploy.

For a serverless stack, that means Lambda invocations and duration, API Gateway requests, DynamoDB reads and writes, and, easily forgotten, CloudWatch Logs ingestion and storage. The Lambda pricing page lists the compute side; the pattern for controlling it is the same as for any AWS service and is covered in our AWS cost optimization guide. Where SAM and CloudFormation differ on cost is not in their own fees but in how each shapes the deployed footprint, which the next section covers.

The Cost Angle Most Comparisons Skip

SAM's convenience is also its cost risk. When one line expands into five resources, you inherit the defaults of resources you did not explicitly write. Three matter for the bill.

• Log retention. A SAM function typically gets a CloudWatch log group whose retention defaults to never expire. Logs accumulate indefinitely at about $0.03 per GB stored, and a chatty function can build a meaningful storage line over a year. Set RetentionInDays explicitly, in the Globals section if you want it everywhere.
• Memory and timeout. SAM makes it easy to set a generous memory size once in Globals and forget it. Lambda bills by GB-second, so a function at 1,024 MB that needs 256 costs four times what it should per invocation. Right-size per function using the utilization Lambda reports.
• API throttling. A Serverless::Api or HttpApi deploys with default throttling that may be far above your real traffic. Explicit limits protect against runaway invocation cost from a bug or a bad actor.

Raw CloudFormation has the same defaults but forces you to write each resource, so you are more likely to notice them. That is not an argument against SAM; it is an argument for treating the template as the place cost is decided, which is the principle behind shifting cost left into code review that we describe in our guide to infrastructure as code. A SAM template with explicit retention, memory, and throttling is both shorter and cheaper to run than the equivalent raw CloudFormation with defaults left alone.

A Worked Example: The Same API Two Ways

Consider a small HTTP API: three Lambda functions behind an HTTP API, writing to a DynamoDB table, with IAM roles and log groups. In raw CloudFormation, that is typically 250 to 350 lines: each function, its role and policy, each route and integration, the table, and each log group written out. The same stack in SAM is often 60 to 90 lines, because each AWS::Serverless::Function declares its handler, runtime, and an Events block, and SAM generates the role, permissions, route, and integration. Both deploy to identical resources and identical monthly cost, roughly a few dollars at low traffic, since Lambda and HTTP API bill per use and the DynamoDB table can sit in on-demand mode.

The difference is developer time and iteration speed. The SAM version can be invoked locally, tested against an emulated API, and pushed to the cloud in seconds with sam sync during development, where the CloudFormation version requires a full stack update each time. For a team shipping serverless features daily, that difference in cycle time is the real cost saving, and it dwarfs the negligible fees of either tool.

Where Plain CloudFormation Is the Better Choice

SAM's shorthand only helps where serverless resources dominate. For a stack that is mostly a VPC, subnets, security groups, EC2 instances, RDS, and load balancers, SAM adds a transform and a CLI you will not use, and plain CloudFormation is cleaner. It is also the better choice when a team standardizes on one tool for everything and wants no layer to debug through, since a SAM deployment error surfaces as a CloudFormation error on an expanded resource you did not write. And organizations that have chosen the AWS CDK or Terraform for their infrastructure will usually find SAM's CLI useful for local Lambda testing but SAM's template layer redundant.

How to Choose

• Choose SAM when the stack is built on Lambda, API Gateway, DynamoDB, or Step Functions, you want local invocation and fast iteration, and shorter templates matter to your team.
• Choose plain CloudFormation when the stack is mostly non-serverless infrastructure, you want one tool with no transform layer, or your team already knows CloudFormation deeply.
• Use both when a stack has a serverless application layer and supporting infrastructure, which is most real applications. Write the functions and APIs as SAM resources and the rest as standard CloudFormation in the same template.
• Consider the alternatives when you want real programming languages (AWS CDK), or multi-cloud portability (Terraform or OpenTofu), both of which are covered in our guide to

multi-cloud deployment tools. SAM's CLI works alongside either for local Lambda testing.

The Bottom Line

SAM versus CloudFormation is not a contest, because SAM is CloudFormation with a serverless dialect and a better developer workflow attached. Neither costs anything to use; both cost whatever they deploy. Reach for SAM when Lambda is at the center of what you are building, because its shorthand and its CLI genuinely shorten templates and development cycles. Reach for plain CloudFormation when it is not, and combine them whenever a stack has both. Then treat the template, in either dialect, as the place where cost is set: explicit log retention, right-sized memory, and sensible throttling written into the code cost nothing to add and are the difference between a serverless bill that stays small and one that quietly grows. Watching that bill by function and by team afterward is the job of Opslyft's cost visibility, and the practices around it are in our guide to DevOps practices.