AWS SAMとは？CloudFormationとの違い・CLIの使い方をわかりやすく解説

AWS SAM（読み方は「サム」、AWS Serverless Application Model）は、Lambda・API Gateway・DynamoDB といったサーバーレスの構成を、CloudFormation より短いテンプレートで定義し、専用の CLI でビルドからローカルテスト・デプロイまで一気通貫で回すためのオープンソースフレームワークです。この記事では、CloudFormation との違い、sam init から sam deploy までの一連のコマンド、そして CDK や Serverless Framework との選び分けまでを、実際のテンプレートとコマンド例で整理します。

まとめ：AWS SAMは「短いYAML＋専用CLI」でサーバーレスを回す仕組み

• AWS SAM は CloudFormation の拡張（Transform マクロ）で、AWS::Serverless::Function などの短縮記法により同じ構成を数分の一の記述量で書ける。
• SAM CLI は sam init（雛形生成）→ sam build（依存関係の解決）→ sam local invoke（ローカル実行）→ sam deploy --guided（デプロイ）が基本の流れ。開発中は sam sync で変更を数秒でクラウドに反映できる。
• SAM 自体は無料。課金されるのは Lambda・API Gateway・S3 など動かした AWS リソースの従量料金だけ。
• 宣言的な YAML で AWS 特化なら SAM、汎用プログラミング言語でロジックを書きたいなら AWS CDK、マルチクラウドや豊富なプラグインが要るなら Serverless Framework、と用途で選び分ける。

AWS SAMとは：サーバーレス構成を簡潔に書くフレームワーク

AWS SAM は、サーバーレスアプリケーションを「Infrastructure as Code（コードによるインフラ管理）」で定義するための、AWS 公式のオープンソースフレームワークです。実体はテンプレート仕様とSAM CLIの2つで構成されます。テンプレートに「どんな Lambda 関数と API を作るか」を宣言し、CLI がビルド・テスト・デプロイを担当します。

読み方と正式名称、CloudFormationとの関係

SAM は「サム」と読み、正式名称は AWS Serverless Application Model です。テンプレートの先頭には必ず次の1行を書きます。

Transform: AWS::Serverless-2016-10-31

この Transform 宣言により、SAM テンプレートはデプロイ時に CloudFormation のマクロとして展開され、通常の CloudFormation テンプレートへ変換されてからスタックが作られます。つまり SAM は CloudFormation を置き換えるものではなく、その上に載る「サーバーレス向けの短縮記法」です。CloudFormation そのものの役割は AWS CloudFormationとは？テンプレートの書き方から使い方までわかりやすく解説 で説明しています。

SAMを使うメリットと料金

メリットは大きく3つです。第一に記述量の削減で、素の CloudFormation なら Lambda 関数1つに IAM ロール・ログ設定など数十行を要する構成が、SAM では十数行で済みます。第二にローカルテストで、デプロイ前に手元の Docker 上で Lambda を実行・デバッグできます。第三にデプロイの自動化で、S3 へのアーティファクト転送やスタック更新を sam deploy 一発で処理します。

料金は、SAM のフレームワーク自体は無料です。課金対象は Lambda の実行回数・実行時間、API Gateway のリクエスト数、S3・DynamoDB といった実際に稼働させた AWS リソースの従量料金だけで、SAM を使うこと自体に追加費用は発生しません。

SAMテンプレートの書き方とCloudFormationとの違い

SAM テンプレートは template.yaml という YAML ファイルに書きます。最小構成は、変換宣言・Lambda 関数リソース・ハンドラーやランタイムの指定だけです。

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

Resources:
  HelloWorldFunction:
    Type: AWS::Serverless::Function
    Properties:
      CodeUri: hello_world/
      Handler: app.lambda_handler
      Runtime: python3.13
      Events:
        HelloApi:
          Type: Api
          Properties:
            Path: /hello
            Method: get

主要なSAMリソースタイプ

SAM が用意する専用リソースタイプ（AWS::Serverless::*）を使うと、関連リソースがまとめて生成されます。代表的なものは次の通りです。

たとえば AWS::Serverless::Function を1つ書くだけで、CloudFormation では別々に定義する Lambda 関数本体・IAM 実行ロール・CloudWatch Logs のロググループが自動生成されます。これが「記述量が減る」の中身です。

CloudFormationとの違いは「短縮記法」と「ローカルテスト」

SAM と CloudFormation は対立する技術ではなく、SAM が CloudFormation の機能を絞って拡張した関係です。違いを実務目線で整理すると次のようになります。

逆に言えば、VPC やネットワーク主体の大規模インフラ全体を組むなら CloudFormation（や後述の CDK）が適し、Lambda 中心の構成なら SAM が速い、という住み分けになります。

SAM Connectorsでリソース間の権限を自動設計する

サーバーレス開発で手間取りやすいのが「Lambda から DynamoDB に書き込む」といったリソース間の IAM 権限の記述です。SAM では 2022 年に追加された AWS::Serverless::Connector を使うと、権限ポリシーを手書きせずに済みます。

  WriteConnector:
    Type: AWS::Serverless::Connector
    Properties:
      Source:
        Id: HelloWorldFunction
      Destination:
        Id: MyTable
      Permissions:
        - Write

ソース・宛先・権限（Read / Write）を宣言するだけで、SAM が必要最小限の IAM ポリシーを組み立てて付与します。手書きの過剰な権限付与を避けられるため、最小権限の原則を保ちやすくなります。

AWS SAM CLIの使い方：init→build→local→deploy

SAM CLI をインストールした後の基本フローは、sam --version でバージョンを確認してから、初期化・ビルド・ローカルテスト・デプロイの順に進めます。

sam init：プロジェクトの雛形を作る

sam init を実行すると対話形式でテンプレートを選べ、ランタイムやサンプルアプリを指定すると template.yaml とアプリのフォルダ構成が生成されます。

sam init

クイックスタートの「Hello World Example」を選ぶと、Lambda 関数・API Gateway・テストコードを含む最小構成が一式そろい、そのままビルドまで進められます。

sam build：依存関係を解決してビルドする

sam build は、requirements.txt などの依存ライブラリを取り込み、デプロイ可能な成果物を .aws-sam/build 配下に作成します。

sam build

Docker を使ってLambdaのランタイムをローカルでビルドするモードもあるためAWS 側の環境差でハマりにくいのが利点です。

sam local：ローカルでLambdaとAPIを実行する

デプロイ前に手元で動作確認できるのが SAM の強みです。単発の関数呼び出しには sam local invoke、API Gateway を模したローカルサーバーの起動には sam local start-api を使います。

sam local invoke "HelloWorldFunction"
sam local start-api

後者は http://127.0.0.1:3000/ でエンドポイントを立ち上げるので、ブラウザや curl から実際のリクエストを投げてレスポンスを確認できます。ローカル実行には Docker が必要です。

sam deploy：ガイド付きでデプロイする

初回は sam deploy --guided を使うと、スタック名・リージョン・確認プロンプトの有無などを対話で決められ、その内容は samconfig.toml に保存されます。2回目以降は sam deploy だけで同じ設定を再利用できます。

sam deploy --guided

デプロイは内部的に CloudFormation スタックの作成・更新として実行されるため、失敗時は自動ロールバックが働き、中途半端な状態が残りにくい設計です。

sam sync：変更を数秒でクラウドに反映する

開発中に毎回フルデプロイを待つのは非効率です。sam sync --watch を使うと、ソースの変更を検知して差分だけを高速に同期でき、コード変更なら CloudFormation を経由せず Lambda を直接更新するため反映が数秒で済みます。

sam sync --watch

不要なファイルの監視を外す --watch-exclude や、ソースフォルダ内で直接ビルドしてビルド時間を短縮する --build-in-source（Node.js の esbuild ビルドなどが対象）といったオプションも用意されています。ただし sam sync は開発環境向けで、本番へは sam deploy を使うのが原則です。

SAMと他のサーバーレス開発ツールの比較と選び分け

サーバーレスの IaC ツールは SAM だけではありません。よく比較される AWS CDK と Serverless Framework との違いを、実際の選定基準として整理します。

AWS CDK は TypeScript や Python などのコードでインフラを書くため、条件分岐やループでリソースを動的に生成したい場合に向きます。一方、Lambda と API を素直に宣言したいだけなら、YAML で完結する SAM のほうが学習コストは低く、レビューもしやすくなります。

Serverless Framework はマルチクラウド対応とプラグインの豊富さが強みですが、v4 から一定規模以上の企業には有料化されました（料金体系の詳細は Serverless Frameworkとは？v4の料金・使い方・無料の代替まで【2026年最新】 を参照）。AWS だけを使い、追加費用をかけたくないなら SAM を選ぶべきです。逆に、複数クラウドをまたぐ・特定プラグインに依存するといった要件があるなら SAM は適さず、Serverless Framework や CDK を検討します。

よくある質問

AWS SAMの読み方は？

「サム」と読みます。AWS Serverless Application Model の略で、公式ドキュメントでも AWS SAM と表記されます。

AWS SAMとCloudFormationの違いは？

SAM は CloudFormation の拡張で、サーバーレス構成に特化した短縮記法とローカルテスト機能を追加したものです。SAM テンプレートはデプロイ時に CloudFormation テンプレートへ変換されて実行されます。

AWS SAMの利用に料金はかかりますか？

SAM 自体は無料です。課金されるのは Lambda・API Gateway・S3 など、実際に稼働させた AWS リソースの従量料金だけです。

ローカルでLambdaをテストするには？

sam local invoke で単発実行、sam local start-api で API Gateway を模したローカルサーバーを起動できます。いずれも Docker が必要です。

Lambda関数の性能や監視はどうする？

コールドスタートの短縮には Lambda SnapStartの概要とその基本的な特徴とは が有効です。デプロイ後の稼働監視は AWS Lambda関数のモニタリングに必要な基礎知識と概要 で、CloudWatch を使った指標の見方を解説しています。

関連記事

• AWS CloudFormationとは？テンプレートの書き方から使い方までわかりやすく解説
• Serverless Frameworkとは？v4の料金・使い方・無料の代替まで【2026年最新】
• Lambda SnapStartの概要とその基本的な特徴とは
• AWS Lambda関数のモニタリングに必要な基礎知識と概要