{
  "content": "# SAM vs CloudFormation: What It Is and When to Use It\n\n## Definition\n\n[AWS CloudFormation](/terms/cloudformation) is a foundational Infrastructure as Code (IaC) service that allows you to model, provision, and manage almost any AWS resource using declarative YAML or JSON templates. The AWS Serverless Application Model (SAM) is an open-source framework and an extension of CloudFormation, specifically designed to simplify and accelerate the development of serverless applications by providing a shorthand syntax for common serverless resources.\n\n## How It Works\n\n### AWS CloudFormation\n\nCloudFormation works by interpreting a template file you provide. This template defines a collection of related AWS resources, known as a **stack**. When you create or update a stack, CloudFormation communicates with the respective AWS service APIs to provision and configure the resources exactly as you've described.\n\n- **Templates**: These are YAML or JSON files that act as a blueprint for your infrastructure.\n- **Stacks**: A stack is the single unit of management for the collection of resources defined in a template. You can create, update, and delete stacks as a whole.\n- **Change Sets**: Before applying updates to a stack, you can generate a change set. This provides a preview of the changes CloudFormation will make, such as which resources will be created, modified, or deleted, allowing for safer updates.\n- **Drift Detection**: CloudFormation can detect when a stack's actual configuration has "drifted" from the configuration defined in its template, helping you identify manual changes that may have occurred outside of IaC.\n\n### AWS Serverless Application Model (SAM)\n\nSAM builds directly on top of CloudFormation. A SAM template is a CloudFormation template with a special `Transform` declaration (`AWS::Serverless-2016-10-31`) that enables its unique, simplified syntax for serverless resources.\n\nThe workflow involves the **SAM CLI**, a command-line tool that is central to the SAM experience:\n\n1.  **Define**: You write a `template.yaml` file using SAM's shorthand syntax (e.g., `AWS::Serverless::Function`, `AWS::Serverless::Api`).\n2.  **Build**: You run the `sam build` command. The SAM CLI packages your application code and dependencies.\n3.  **Transform & Deploy**: You run the `sam deploy` command. The SAM CLI first transforms the SAM template into a standard, more verbose CloudFormation template. It then packages your application, uploads the artifacts to an [Amazon S3](/terms/s3) bucket, and initiates a CloudFormation stack deployment with the generated template.\n\nThe SAM CLI also provides powerful tools for local development, allowing you to invoke [AWS Lambda](/terms/lambda) functions, run a local [Amazon API Gateway](/terms/api-gateway), and generate test events without deploying to the cloud.\n\n## Key Features and Limits\n\n| Feature | AWS CloudFormation | [AWS SAM](/terms/sam) (Serverless Application Model) |\n| :--- | :--- | :--- |\n| **Primary Focus** | General-purpose Infrastructure as Code for all AWS resources. | Specialized framework for serverless applications (Lambda, API Gateway, DynamoDB). |\n| **Syntax** | Verbose and explicit. Requires detailed definition for all resource properties (e.g., [IAM Role](/terms/iam-role)s, Lambda event source mappings). | Concise shorthand syntax for serverless resources. Automatically creates required IAM roles and policies based on simple definitions. |\n| **Resource Support** | Supports nearly all AWS services and resources. | Natively supports a specific set of serverless resources (e.g., `AWS::Serverless::Function`, `AWS::Serverless::Api`, `AWS::Serverless::SimpleTable`). Can include *any* standard CloudFormation resource within the same template. |\n| **Tooling** | Managed via AWS Management Console, AWS CLI (`aws cloudformation ...`), or SDKs. | Managed via the **SAM CLI** (`sam ...`), which provides commands like `init`, `build`, `deploy`, `local invoke`, and `local start-api`. |\n| **Local Development** | No native local testing capabilities. Requires deployment to an AWS environment for testing. | Extensive local testing and debugging features via the SAM CLI and Docker, allowing you to run Lambda functions and APIs on your local machine. |\n| **Deployment** | Multi-step process: package code, upload to S3, create/update stack via console or CLI. | Streamlined `sam deploy` command handles packaging, uploading, and deploying in a single, guided process. |\n\n### Service Limits\n\nSince SAM transforms into CloudFormation, it inherits most of CloudFormation's service quotas. As of 2026, key limits include:\n\n*   **Resources per Stack**: 500 (increased from 200).\n*   **Parameters per Template**: 200 (increased from 60).\n*   **Mappings per Template**: 200 (increased from 100).\n*   **Outputs per Template**: 200 (increased from 60).\n*   **Template Size (from S3)**: 1 MB (increased from 450 KB).\n*   **Stacks per Region**: 2000 (by default, can be increased).\n\n## Common Use Cases\n\n**Choose AWS CloudFormation when:**\n\n*   **Provisioning Foundational Infrastructure**: Defining core components like VPCs, subnets, security groups, IAM roles, and networking configurations.\n*   **Managing Complex, Non-Serverless Applications**: Deploying traditional applications on [Amazon EC2](/terms/ec2), containerized workloads with [Amazon ECS](/terms/ecs)/EKS, or relational databases with [Amazon RDS](/terms/rds).\n*   **Enforcing Organizational Standards**: Creating standardized, reusable templates for common infrastructure patterns that can be shared across teams using StackSets or AWS Service Catalog.\n*   **Managing Third-Party Resources**: Using the CloudFormation Registry to provision and manage non-AWS resources alongside native ones.\n\n**Choose AWS SAM when:**\n\n*   **Building Serverless Applications**: Rapidly developing applications centered around AWS Lambda, Amazon API Gateway, and [Amazon DynamoDB](/terms/dynamodb).\n*   **Prioritizing Local Development and Testing**: Your workflow benefits significantly from the ability to invoke, test, and debug Lambda functions and APIs locally before deploying.\n*   **Streamlining CI/CD for Serverless**: Integrating with tools like [AWS CodePipeline](/terms/codepipeline) to automate the build and deployment of serverless applications.\n*   **Extending Existing CloudFormation Stacks**: Adding serverless components or microservices to an existing infrastructure that is already managed by CloudFormation.\n\n## Pricing Model\n\nBoth AWS CloudFormation and the AWS SAM framework are free to use. You only pay for the AWS resources (e.g., Lambda function invocations, API Gateway requests, DynamoDB table capacity) that you create and manage using them.\n\nThere are a few exceptions where CloudFormation itself may incur minor charges:\n*   **Third-Party Resource Providers**: When using the CloudFormation Registry to manage non-AWS resources, you are charged a small fee per handler operation (CREATE, UPDATE, DELETE, etc.).\n*   **AWS CloudFormation Hooks**: Custom hooks that invoke AWS services like Lambda for pre-provisioning validation can incur costs.\n\nThere is a free tier for these operations, which includes 1,000 handler operations per month. Always use the [AWS Pricing Calculator](https://calculator.aws/) to estimate the cost of the underlying resources your templates will provision.\n\n## Pros and Cons\n\n| | AWS CloudFormation | AWS SAM |\n| :--- | :--- | :--- |\n| **Pros** | **Comprehensive**: Supports the widest range of AWS services. <br> **Mature & Foundational**: The core IaC engine for AWS. <br> **Powerful Features**: Includes drift detection, change sets, and StackSets for multi-account deployments. <br> **Explicit Control**: Provides granular control over every resource property. | **Concise Syntax**: Drastically reduces the amount of code needed for serverless resources. <br> **Developer-Friendly Tooling**: The SAM CLI provides a superior local development, testing, and debugging experience. <br> **Built on CloudFormation**: Inherits the reliability and deployment capabilities of the underlying engine. <br> **Best Practices Built-in**: Simplifies security by generating scoped IAM policies automatically. |\n| **Cons** | **Verbose**: Can require hundreds of lines of YAML/JSON for even simple serverless applications. <br> **Steeper Learning Curve**: The sheer number of resource types and properties can be overwhelming. <br> **No Local Testing**: Lacks a native feedback loop for local development. | **Serverless-Focused**: While it can include any CloudFormation resource, its primary benefits are for serverless patterns. <br> **Abstraction Layer**: Can hide important CloudFormation details, which might be a drawback for complex configurations. <br> **Requires SAM CLI**: Adds another tool dependency to your development workflow. |\n\n## Comparison with Alternatives\n\n*   **[AWS CDK](/terms/cdk) (Cloud Development Kit)**: The CDK allows you to define infrastructure using familiar programming languages like TypeScript, Python, and Java. This offers more power and abstraction than SAM's declarative YAML. During synthesis (`cdk synth`), a CDK app generates a standard CloudFormation template. Choose CDK for complex logic, creating reusable high-level components (Constructs), and if your team prefers imperative programming over declarative templates.\n\n*   **Terraform by HashiCorp**: Terraform is a popular open-source, cloud-agnostic IaC tool. The key difference is that CloudFormation is an AWS-native service that manages state automatically within AWS, while Terraform is a third-party tool that manages its own state file, which you are responsible for securing and managing (often in an S3 bucket). Terraform is often chosen for multi-cloud or hybrid-cloud environments.\n\n## Exam Relevance\n\nBoth CloudFormation and SAM are critical topics for several AWS certifications, particularly those focused on development and DevOps.\n\n*   **AWS Certified Developer - Associate (DVA-C02)**: Expects deep knowledge of SAM, including the SAM CLI for building, testing, and deploying serverless applications. CloudFormation fundamentals are also essential for deploying application infrastructure.\n\n*   **AWS Certified DevOps Engineer - Professional (DOP-C02)**: This exam heavily tests your ability to automate infrastructure provisioning and management. A thorough understanding of CloudFormation features like StackSets, change sets, and drift detection is required. You must also know how to implement CI/CD pipelines for both serverless (SAM) and traditional applications.\n\n*   **AWS Certified Solutions Architect - Associate & Professional**: Both architect exams require a strong understanding of CloudFormation as the primary method for implementing Infrastructure as Code on AWS.\n\n## Frequently Asked Questions\n\n### Q: Can I use standard CloudFormation resources in a SAM template?\n\nA: Yes. A SAM template is a superset of a CloudFormation template. You can include any standard `AWS::*` resource type alongside the simplified `AWS::Serverless::*` types in the same template file. This allows you to manage both your serverless components and other resources like VPCs or RDS databases in a single stack.\n\n### Q: Is SAM a replacement for CloudFormation?\n\nA: No, SAM is not a replacement. It is an extension or a transformation layer built on top of CloudFormation. The `sam deploy` command ultimately converts your concise SAM syntax into a standard CloudFormation template and uses the CloudFormation service to provision the resources.\n\n### Q: Do I need to learn CloudFormation before learning SAM?\n\nA: While you can start with SAM directly for simple serverless projects, having a foundational understanding of CloudFormation is highly recommended. Because SAM transforms into CloudFormation, you will need to understand the underlying CloudFormation resources and properties to debug deployment issues, customize configurations beyond what SAM's shorthand provides, or integrate non-serverless resources.\n\n---\n*This article reflects AWS features and pricing as of 2026. AWS services evolve rapidly — always verify against the [official AWS documentation](https://docs.aws.amazon.com/) before making production decisions.*",
  "contentPlain": "# SAM vs CloudFormation: What It Is and When to Use It\n\n## Definition\n\nAWS CloudFormation is a foundational Infrastructure as Code (IaC) service that allows you to model, provision, and manage almost any AWS resource using declarative YAML or JSON templates. The AWS Serverless Application Model (SAM) is an open-source framework and an extension of CloudFormation, specifically designed to simplify and accelerate the development of serverless applications by providing a shorthand syntax for common serverless resources.\n\n## How It Works\n\n### AWS CloudFormation\n\nCloudFormation works by interpreting a template file you provide. This template defines a collection of related AWS resources, known as a **stack**. When you create or update a stack, CloudFormation communicates with the respective AWS service APIs to provision and configure the resources exactly as you've described.\n\n- **Templates**: These are YAML or JSON files that act as a blueprint for your infrastructure.\n- **Stacks**: A stack is the single unit of management for the collection of resources defined in a template. You can create, update, and delete stacks as a whole.\n- **Change Sets**: Before applying updates to a stack, you can generate a change set. This provides a preview of the changes CloudFormation will make, such as which resources will be created, modified, or deleted, allowing for safer updates.\n- **Drift Detection**: CloudFormation can detect when a stack's actual configuration has \"drifted\" from the configuration defined in its template, helping you identify manual changes that may have occurred outside of IaC.\n\n### AWS Serverless Application Model (SAM)\n\nSAM builds directly on top of CloudFormation. A SAM template is a CloudFormation template with a special `Transform` declaration (`AWS::Serverless-2016-10-31`) that enables its unique, simplified syntax for serverless resources.\n\nThe workflow involves the **SAM CLI**, a command-line tool that is central to the SAM experience:\n\n1.  **Define**: You write a `template.yaml` file using SAM's shorthand syntax (e.g., `AWS::Serverless::Function`, `AWS::Serverless::Api`).\n2.  **Build**: You run the `sam build` command. The SAM CLI packages your application code and dependencies.\n3.  **Transform & Deploy**: You run the `sam deploy` command. The SAM CLI first transforms the SAM template into a standard, more verbose CloudFormation template. It then packages your application, uploads the artifacts to an Amazon S3 bucket, and initiates a CloudFormation stack deployment with the generated template.\n\nThe SAM CLI also provides powerful tools for local development, allowing you to invoke AWS Lambda functions, run a local Amazon API Gateway, and generate test events without deploying to the cloud.\n\n## Key Features and Limits\n\n| Feature | AWS CloudFormation | AWS SAM (Serverless Application Model) |\n| :--- | :--- | :--- |\n| **Primary Focus** | General-purpose Infrastructure as Code for all AWS resources. | Specialized framework for serverless applications (Lambda, API Gateway, DynamoDB). |\n| **Syntax** | Verbose and explicit. Requires detailed definition for all resource properties (e.g., IAM Roles, Lambda event source mappings). | Concise shorthand syntax for serverless resources. Automatically creates required IAM roles and policies based on simple definitions. |\n| **Resource Support** | Supports nearly all AWS services and resources. | Natively supports a specific set of serverless resources (e.g., `AWS::Serverless::Function`, `AWS::Serverless::Api`, `AWS::Serverless::SimpleTable`). Can include *any* standard CloudFormation resource within the same template. |\n| **Tooling** | Managed via AWS Management Console, AWS CLI (`aws cloudformation ...`), or SDKs. | Managed via the **SAM CLI** (`sam ...`), which provides commands like `init`, `build`, `deploy`, `local invoke`, and `local start-api`. |\n| **Local Development** | No native local testing capabilities. Requires deployment to an AWS environment for testing. | Extensive local testing and debugging features via the SAM CLI and Docker, allowing you to run Lambda functions and APIs on your local machine. |\n| **Deployment** | Multi-step process: package code, upload to S3, create/update stack via console or CLI. | Streamlined `sam deploy` command handles packaging, uploading, and deploying in a single, guided process. |\n\n### Service Limits\n\nSince SAM transforms into CloudFormation, it inherits most of CloudFormation's service quotas. As of 2026, key limits include:\n\n*   **Resources per Stack**: 500 (increased from 200).\n*   **Parameters per Template**: 200 (increased from 60).\n*   **Mappings per Template**: 200 (increased from 100).\n*   **Outputs per Template**: 200 (increased from 60).\n*   **Template Size (from S3)**: 1 MB (increased from 450 KB).\n*   **Stacks per Region**: 2000 (by default, can be increased).\n\n## Common Use Cases\n\n**Choose AWS CloudFormation when:**\n\n*   **Provisioning Foundational Infrastructure**: Defining core components like VPCs, subnets, security groups, IAM roles, and networking configurations.\n*   **Managing Complex, Non-Serverless Applications**: Deploying traditional applications on Amazon EC2, containerized workloads with Amazon ECS/EKS, or relational databases with Amazon RDS.\n*   **Enforcing Organizational Standards**: Creating standardized, reusable templates for common infrastructure patterns that can be shared across teams using StackSets or AWS Service Catalog.\n*   **Managing Third-Party Resources**: Using the CloudFormation Registry to provision and manage non-AWS resources alongside native ones.\n\n**Choose AWS SAM when:**\n\n*   **Building Serverless Applications**: Rapidly developing applications centered around AWS Lambda, Amazon API Gateway, and Amazon DynamoDB.\n*   **Prioritizing Local Development and Testing**: Your workflow benefits significantly from the ability to invoke, test, and debug Lambda functions and APIs locally before deploying.\n*   **Streamlining CI/CD for Serverless**: Integrating with tools like AWS CodePipeline to automate the build and deployment of serverless applications.\n*   **Extending Existing CloudFormation Stacks**: Adding serverless components or microservices to an existing infrastructure that is already managed by CloudFormation.\n\n## Pricing Model\n\nBoth AWS CloudFormation and the AWS SAM framework are free to use. You only pay for the AWS resources (e.g., Lambda function invocations, API Gateway requests, DynamoDB table capacity) that you create and manage using them.\n\nThere are a few exceptions where CloudFormation itself may incur minor charges:\n*   **Third-Party Resource Providers**: When using the CloudFormation Registry to manage non-AWS resources, you are charged a small fee per handler operation (CREATE, UPDATE, DELETE, etc.).\n*   **AWS CloudFormation Hooks**: Custom hooks that invoke AWS services like Lambda for pre-provisioning validation can incur costs.\n\nThere is a free tier for these operations, which includes 1,000 handler operations per month. Always use the [AWS Pricing Calculator](https://calculator.aws/) to estimate the cost of the underlying resources your templates will provision.\n\n## Pros and Cons\n\n| | AWS CloudFormation | AWS SAM |\n| :--- | :--- | :--- |\n| **Pros** | **Comprehensive**: Supports the widest range of AWS services. <br> **Mature & Foundational**: The core IaC engine for AWS. <br> **Powerful Features**: Includes drift detection, change sets, and StackSets for multi-account deployments. <br> **Explicit Control**: Provides granular control over every resource property. | **Concise Syntax**: Drastically reduces the amount of code needed for serverless resources. <br> **Developer-Friendly Tooling**: The SAM CLI provides a superior local development, testing, and debugging experience. <br> **Built on CloudFormation**: Inherits the reliability and deployment capabilities of the underlying engine. <br> **Best Practices Built-in**: Simplifies security by generating scoped IAM policies automatically. |\n| **Cons** | **Verbose**: Can require hundreds of lines of YAML/JSON for even simple serverless applications. <br> **Steeper Learning Curve**: The sheer number of resource types and properties can be overwhelming. <br> **No Local Testing**: Lacks a native feedback loop for local development. | **Serverless-Focused**: While it can include any CloudFormation resource, its primary benefits are for serverless patterns. <br> **Abstraction Layer**: Can hide important CloudFormation details, which might be a drawback for complex configurations. <br> **Requires SAM CLI**: Adds another tool dependency to your development workflow. |\n\n## Comparison with Alternatives\n\n*   **AWS CDK (Cloud Development Kit)**: The CDK allows you to define infrastructure using familiar programming languages like TypeScript, Python, and Java. This offers more power and abstraction than SAM's declarative YAML. During synthesis (`cdk synth`), a CDK app generates a standard CloudFormation template. Choose CDK for complex logic, creating reusable high-level components (Constructs), and if your team prefers imperative programming over declarative templates.\n\n*   **Terraform by HashiCorp**: Terraform is a popular open-source, cloud-agnostic IaC tool. The key difference is that CloudFormation is an AWS-native service that manages state automatically within AWS, while Terraform is a third-party tool that manages its own state file, which you are responsible for securing and managing (often in an S3 bucket). Terraform is often chosen for multi-cloud or hybrid-cloud environments.\n\n## Exam Relevance\n\nBoth CloudFormation and SAM are critical topics for several AWS certifications, particularly those focused on development and DevOps.\n\n*   **AWS Certified Developer - Associate (DVA-C02)**: Expects deep knowledge of SAM, including the SAM CLI for building, testing, and deploying serverless applications. CloudFormation fundamentals are also essential for deploying application infrastructure.\n\n*   **AWS Certified DevOps Engineer - Professional (DOP-C02)**: This exam heavily tests your ability to automate infrastructure provisioning and management. A thorough understanding of CloudFormation features like StackSets, change sets, and drift detection is required. You must also know how to implement CI/CD pipelines for both serverless (SAM) and traditional applications.\n\n*   **AWS Certified Solutions Architect - Associate & Professional**: Both architect exams require a strong understanding of CloudFormation as the primary method for implementing Infrastructure as Code on AWS.\n\n## Frequently Asked Questions\n\n### Q: Can I use standard CloudFormation resources in a SAM template?\n\nA: Yes. A SAM template is a superset of a CloudFormation template. You can include any standard `AWS::*` resource type alongside the simplified `AWS::Serverless::*` types in the same template file. This allows you to manage both your serverless components and other resources like VPCs or RDS databases in a single stack.\n\n### Q: Is SAM a replacement for CloudFormation?\n\nA: No, SAM is not a replacement. It is an extension or a transformation layer built on top of CloudFormation. The `sam deploy` command ultimately converts your concise SAM syntax into a standard CloudFormation template and uses the CloudFormation service to provision the resources.\n\n### Q: Do I need to learn CloudFormation before learning SAM?\n\nA: While you can start with SAM directly for simple serverless projects, having a foundational understanding of CloudFormation is highly recommended. Because SAM transforms into CloudFormation, you will need to understand the underlying CloudFormation resources and properties to debug deployment issues, customize configurations beyond what SAM's shorthand provides, or integrate non-serverless resources.\n\n---\n*This article reflects AWS features and pricing as of 2026. AWS services evolve rapidly — always verify against the [official AWS documentation](https://docs.aws.amazon.com/) before making production decisions.*",
  "faq": [
    {
      "question": "Can I use standard CloudFormation resources in a SAM template?",
      "answer": "Yes. A SAM template is a superset of a CloudFormation template. You can include any standard `AWS::*` resource type alongside the simplified `AWS::Serverless::*` types in the same template file. This allows you to manage both your serverless components and other resources like VPCs or RDS databases in a single stack."
    },
    {
      "question": "Is SAM a replacement for CloudFormation?",
      "answer": "No, SAM is not a replacement. It is an extension or a transformation layer built on top of CloudFormation. The `sam deploy` command ultimately converts your concise SAM syntax into a standard CloudFormation template and uses the CloudFormation service to provision the resources."
    },
    {
      "question": "Do I need to learn CloudFormation before learning SAM?",
      "answer": "While you can start with SAM directly for simple serverless projects, having a foundational understanding of CloudFormation is highly recommended. Because SAM transforms into CloudFormation, you will need to understand the underlying CloudFormation resources and properties to debug deployment issues, customize configurations beyond what SAM's shorthand provides, or integrate non-serverless resources."
    }
  ]
}