--- title: "AWS SAMとは？CloudFormationとの違い・SAM CLIの使い方を実例で解説" url: "https://www.issoh.co.jp/tech/details/3823/" published: 2024-10-11 updated: 2026-10-28 categories: ["AWS"] publisher: "株式会社一創" --- # AWS SAMとは？CloudFormationとの違い・SAM CLIの使い方を実例で解説 AWS SAM（読み方は「サム」、正式名称は AWS Serverless Application Model）は、Lambda や API Gateway を使うサーバーレス構成を短い YAML で書き、SAM CLI でビルド・ローカル実行・デプロイまで回すための AWS 公式のオープンソースフレームワークです。この記事では、SAM テンプレートが CloudFormation の何に展開されるのかを実際に変換した結果で示し、SAM CLI 1.170.0 でのインストールから `sam init`・`sam build`・`sam local`・`sam deploy`・`sam sync` までの手順、CDK・Terraform との選び分けを整理します。 ## まとめ：AWS SAMはCloudFormationの短縮記法とSAM CLIの組み合わせ - SAM テンプレートは先頭の `Transform: AWS::Serverless-2016-10-31` により、デプロイ時に通常の CloudFormation テンプレートへ変換される。Hello World の雛形は、Lambda 関数・IAM ロール・API Gateway の3リソース・Lambda の呼び出し許可の計6リソースに展開される。 - CloudFormation との違いは、サーバーレス向けの短縮記法と、Docker か Finch の上で Lambda を手元で動かせる SAM CLI の2点。VPC やネットワークが主役の構成は CloudFormation（または CDK）で書く。 - SAM CLI の基本の流れは `sam init` → `sam build` → `sam local invoke` → `sam deploy --guided`。`sam sync` は CloudFormation を通さずにコードを書き換えるので開発用スタックだけに使う。 - SAM の利用自体に追加料金はなく、課金されるのは作成した Lambda・API Gateway・S3 などのリソースだけ。 - AWS だけで Lambda 中心なら SAM、条件分岐やループで構成を組み立てるなら CDK、AWS 以外も同じ道具で管理するなら Terraform を選ぶ。 ## AWS SAMの仕組み：テンプレート仕様とSAM CLI AWS SAM は、`template.yaml` に書く**テンプレート仕様**と、それをビルド・テスト・デプロイする**SAM CLI**の2つでできています。テンプレートの変換処理は GitHub の [aws/serverless-application-model](https://github.com/aws/serverless-application-model)、CLI は [aws/aws-sam-cli](https://github.com/aws/aws-sam-cli/releases/tag/v1.170.0) で公開されており、2026年10月28日時点の CLI の最新版は 2026年10月22日に出た 1.170.0 です。 ### 読み方・正式名称とライセンス SAM は「サム」と読み、Serverless Application Model の頭文字です。変換処理のリポジトリは Apache License 2.0（no-charge, royalty-free）で提供されています。 ### AWS SAMの利用料金と作成リソースの課金 AWS の [AWS SAM FAQ](https://aws.amazon.com/serverless/sam/faqs/) は「AWS SAM の利用に追加料金はかからない」と明記しています。請求に載るのは SAM で作った Lambda・API Gateway・デプロイ用 S3 などの利用料で、手作業で作った場合と同じ金額です。Lambda 側の単価と付帯課金は [AWS Lambdaの料金を東京リージョンの実額で計算する：付帯課金の内訳と単価を下げる手順](/tech/details/17740/) で試算しています。 ## AWS SAMとCloudFormationの違い SAM テンプレートは CloudFormation のマクロ（Transform）として展開され、CloudFormation のスタックとしてデプロイされます。違いは「何を書かずに済むか」と「デプロイ前に手元で動かせるか」の2点です。CloudFormation そのものの書き方は [AWS CloudFormationとは？テンプレートの書き方・スタック操作と更新で消える設定の防ぎ方](/tech/details/2927/) で解説しています。 ### TransformによるHello Worldの展開結果：6リソースの内訳 SAM CLI 1.170.0 の `sam init` で作った Hello World の雛形（コメントを含み、空行を除いて37行）を、SAM の変換ライブラリ samtranslator 1.115.0 で CloudFormation に変換すると、次の6リソースに展開されました（コードの置き場所だけ S3 の URI に置き換えて変換）。 | 展開後の論理ID | CloudFormationのリソースタイプ | | ------------------------------------------ | --------------------------- | | HelloWorldFunction | AWS::Lambda::Function | | HelloWorldFunctionRole | AWS::IAM::Role | | ServerlessRestApi | AWS::ApiGateway::RestApi | | ServerlessRestApiDeployment＋ハッシュ | AWS::ApiGateway::Deployment | | ServerlessRestApiProdStage | AWS::ApiGateway::Stage | | HelloWorldFunctionHelloWorldPermissionProd | AWS::Lambda::Permission | 変換後の YAML は、今回の出力形式で空行を除いて103行です。SAM 側では関数1つと `Events` に API イベント1つを定義しており、API Gateway 本体・デプロイ・`Prod` ステージ・API から Lambda を呼ぶ許可は SAM が補っています。テンプレートの `Outputs` で `ServerlessRestApi` や `HelloWorldFunctionRole` を参照できるのは、この暗黙のリソースに決まった論理IDが付くためです。 注意したいのは、**ロググループは生成されない**点です。[AWS::Serverless::Function の生成リソース一覧](https://docs.aws.amazon.com/serverless-application-model/latest/developerguide/sam-specification-generated-resources-function.html)にあるのは Lambda 関数本体と、`Role` を省略したときの IAM ロールで、`AutoPublishAlias` を付けると `AWS::Lambda::Version` と `AWS::Lambda::Alias` が加わります。ログは Lambda が初回実行時に作るロググループに出るため、保持期間を決めたいなら `AWS::Logs::LogGroup` を自分で書く必要があります。保持期間とコストの考え方は [AWS Lambdaのログ運用ガイド｜CloudWatch Logsの見方・JSON構造化・S3出力とコスト削減](/tech/details/4031/) にまとめています。 ### CloudFormationとSAMの比較表 | 観点 | CloudFormation | AWS SAM | | --------------------- | ------------------------- | -------------------------------- | | 書ける範囲 | AWSリソース全般 | CloudFormationの全リソース＋Serverless型 | | Lambda＋REST API（今回の例） | 6リソースを個別に記述 | 関数1つとEvents | | IAM権限 | 管理ポリシーの参照・個別定義 | Connectorやポリシーテンプレート | | ローカル実行 | なし | sam local（Docker/Finch） | | デプロイ | aws cloudformation deploy | sam deploy（S3への転送込み） | | 実体 | スタック | 変換後に同じスタック | ### CloudFormationを直接書くべき場面 VPC・RDS・ECS が主役で Lambda が脇役の構成では、SAM の短縮記法はほとんど効かず、Transform の一段を挟むぶん変換後を読む手間が増えるだけです。この場合は CloudFormation を直接書きます。SAM テンプレートには `AWS::EC2::VPC` などの通常リソースも混ぜられるので、Lambda が中心で一部に VPC がある程度なら SAM にまとめて構いません。 ## SAMテンプレートの書き方 テンプレートは `template.yaml` に書きます。`sam init` が生成する Hello World の中身（コメントと `Outputs` を省略）は次のとおりです。 ``` AWSTemplateFormatVersion: '2010-09-09' Transform: AWS::Serverless-2016-10-31 Globals: Function: Timeout: 3 Resources: HelloWorldFunction: Type: AWS::Serverless::Function Properties: CodeUri: hello_world/ Handler: app.lambda_handler Runtime: python3.13 Architectures: - x86_64 Events: HelloWorld: Type: Api Properties: Path: /hello Method: get ``` `Globals` に書いた値（ここではタイムアウト3秒）は、テンプレート内のすべての関数に既定値として効きます。`Runtime` に指定する Python は、[Lambda のランタイム一覧](https://docs.aws.amazon.com/lambda/latest/dg/lambda-runtimes.html)で python3.13 と python3.14 の非推奨予定日がともに 2029年6月30日、python3.12 は 2028年10月31日です。新規に作るなら python3.13 か python3.14 を選びます。 ### 主要なSAMリソースタイプと展開先 専用リソースタイプを書くと、関連するリソースがまとめて生成されます。samtranslator 1.115.0 で最小構成を変換したときの展開先は次のとおりです。 | SAMのリソースタイプ | 展開される主なリソース | | ----------------------------- | ------------------------------------- | | AWS::Serverless::Function | Lambda::Function＋IAM::Role | | （AutoPublishAlias指定時） | ＋Lambda::Version・Lambda::Alias | | AWS::Serverless::Api | ApiGateway::RestApi・Deployment・Stage | | AWS::Serverless::HttpApi | ApiGatewayV2::Api・Stage | | AWS::Serverless::SimpleTable | DynamoDB::Table | | AWS::Serverless::StateMachine | StepFunctions::StateMachine＋IAM::Role | | AWS::Serverless::LayerVersion | Lambda::LayerVersion | | AWS::Serverless::Connector | IAM::ManagedPolicy など | ### SAM Connectorsで関数からテーブルへの権限を宣言する Lambda から DynamoDB に書き込む権限を IAM ポリシーで手書きする代わりに、[AWS::Serverless::Connector](https://docs.aws.amazon.com/serverless-application-model/latest/developerguide/sam-resource-connector.html) で「どこから・どこへ・読むか書くか」だけを宣言できます。 ``` WriteConnector: Type: AWS::Serverless::Connector Properties: Source: Id: HelloWorldFunction Destination: Id: MyTable Permissions: - Write ``` この断片は `Resources` の直下に追加し、同じ階層に `MyTable`（`Type: AWS::Serverless::SimpleTable`）も定義します。この構成を変換すると、`AWS::IAM::ManagedPolicy` が1つ生成され、許可されるアクションは `dynamodb:PutItem`・`UpdateItem`・`DeleteItem`・`BatchWriteItem` と PartiQL の Insert・Update・Delete の7つでした。`Write` には削除系も含まれるので、削除させたくない関数には Connector ではなく個別のポリシーを書きます。接続できる組み合わせはソースと宛先の型ごとに[対応表](https://docs.aws.amazon.com/serverless-application-model/latest/developerguide/reference-sam-connector.html)で決まっています。 ## SAM CLIのインストール ### OS別のインストーラー SAM CLI は [公式のインストール手順](https://docs.aws.amazon.com/serverless-application-model/latest/developerguide/install-sam-cli.html)にある OS 別のインストーラーで入れます。 | OS | 配布物 | | -------------------- | ----------------------------- | | macOS（Intel） | aws-sam-cli-macos-x86\_64.pkg | | macOS（Apple シリコン） | aws-sam-cli-macos-arm64.pkg | | Windows | 64bit の MSI | | Linux（x86\_64／arm64） | zip＋同梱の install | Linux（x86\_64）では次のように展開してインストールし、最後にバージョンを確かめます。 ``` curl -LO https://github.com/aws/aws-sam-cli/releases/latest/download/aws-sam-cli-linux-x86_64.zip unzip aws-sam-cli-linux-x86_64.zip -d sam-installation sudo ./sam-installation/install sam --version ``` Homebrew の `aws/tap/aws-sam-cli` は 2023年9月で AWS による保守が終わり、以後はコミュニティ管理です。Homebrew や pip で入れた SAM CLI を公式インストーラーに切り替えるときは、先に古いほうをアンインストールします。`sam init` がテンプレートを GitHub から取得するため Git も必要です。 ### ローカル実行に必要なDockerまたはFinch コンテナランタイムが要るのは、`sam local` でのローカル実行、`sam build --use-container`、コンテナイメージ形式（`PackageType: Image`）の関数のビルドの3つです。この記事のように関数を ZIP 形式（既定）で作る構成なら、`sam build`・`sam deploy`・`sam sync` はコンテナなしで実行できます。SAM CLI 1.145.0（2025年10月）から、Docker の代わりに AWS の OSS コンテナツール [Finch](https://docs.aws.amazon.com/serverless-application-model/latest/developerguide/install-finch.html) も使えるようになりました。管理者設定で指定が無ければ Docker を先に探し、見つからなければ Finch を使います（1.170.0 のソース `container_client_factory.py` の判定順）。 ## SAM CLIの使い方：init→build→local→deploy 以下の手順では、SAM CLI と Git に加え、通常のビルド用に Python 3.13 と pip、ローカル実行用に起動済みの Docker または Finch を用意します。デプロイ前には AWS 認証情報と、対象リソースを作成・更新できる IAM 権限も設定してください。SAM CLI 1.170.0 で Hello World（python3.13）を作り、手元で動かしてデプロイするまでの流れです。順序は AWS 公式の [Hello World チュートリアル](https://docs.aws.amazon.com/serverless-application-model/latest/developerguide/serverless-getting-started-hello-world.html)と同じです。 ### sam initでプロジェクトの雛形を作る 対話形式の `sam init` でも作れますが、条件を引数で渡すと質問なしで生成できます。 ``` sam init --no-interactive --name sam-app --runtime python3.13 \ --dependency-manager pip --app-template hello-world ``` 生成されるのは `template.yaml`・`samconfig.toml`・関数本体の `hello_world/app.py` と `requirements.txt`・テスト用イベント `events/event.json`・単体テストと結合テストの雛形です。`samconfig.toml` には最初から `sam validate` で lint を有効にする設定、`sam deploy` で変更セットを確認してから反映する設定（`confirm_changeset = true`）、デプロイ用 S3 バケットを自動で用意する設定（`resolve_s3 = true`）が入っています。 ### sam buildで依存関係をまとめる ``` cd sam-app sam build ``` `requirements.txt` の依存パッケージを取り込んだ成果物が `.aws-sam/build` に出力されます。手元の Python のバージョンが `Runtime` と違う、またはネイティブ拡張を含むパッケージを使う場合は、`sam build --use-container` で Lambda の実行環境に合わせた SAM のビルド用コンテナ内でビルドします。コンテナイメージ形式の関数は 1.156.0（2026年3月）から `--use-buildkit` で BuildKit ビルドが使え、Docker の buildx プラグインか Finch が必要です。 テンプレートの書き方の誤りは `sam validate --lint` で確認できます。中身は cfn-lint による検査で、雛形のままなら「is a valid SAM Template」と返ります。検査ルールの調整は [cfn-lintとは？CloudFormationテンプレート検証の導入・設定・CI組み込み【v1.57対応】](/tech/details/10676/) で扱っています。 ### sam localでLambdaとAPIを手元で動かす ``` sam local invoke HelloWorldFunction --event events/event.json sam local start-api ``` `sam local invoke` は関数を1回だけ実行します。Hello World では `public.ecr.aws/lambda/python:3.13` 系のイメージで関数が起動し、`{"statusCode": 200, "body": "{\"message\": \"hello world\"}"}` が返りました。初回は必要なコンテナイメージの取得が発生します。取得時間は回線速度やキャッシュの状態によって変わります。`sam local start-api` は API Gateway を模したサーバーを `http://127.0.0.1:3000` で起動するので、`curl http://127.0.0.1:3000/hello` でリクエストを送れます。S3 や SQS などのイベントの JSON は `sam local generate-event` で作れます。 1.150.0（2025年12月）からは durable functions に対応し、`sam local execution`（ローカル実行の状態・履歴の確認と停止）と `sam local callback`（待機中の実行へのコールバック送信）が加わりました。DynamoDB や S3 まで手元で再現したい場合は SAM の範囲外なので、[LocalStackとは？AWSをローカルで動かす手順と有料化後の料金・判断基準](/tech/details/17634/) のようなエミュレーターを組み合わせます。 ### sam deployでAWSへデプロイする ``` sam deploy --guided ``` 初回は `--guided` を付けると、スタック名・リージョン・IAM ロール作成の許可・変更セットの確認有無を対話で決め、答えを `samconfig.toml` に保存します。2回目以降は `sam deploy` だけで済みます。内部では成果物を S3 に上げて CloudFormation の変更セットを作り、確認を有効にした場合は承認後にスタックを更新します。ロールバックは既定で有効ですが、対話設定で無効にした場合は失敗しても自動では戻りません。API の URL は `Outputs` の `HelloWorldApi` に表示されます。DynamoDB まで含めて REST API を作る例は [AWS サーバーレス ハンズオン｜Lambda・DynamoDB・API GatewayでREST APIを作る手順【2026年版】](/tech/details/2818/) にあります。 ### sam syncで開発スタックへ変更を同期する ``` sam sync --stack-name sam-app-dev --watch ``` `sam sync --watch` はファイルの変更を監視し、コードの変更は Lambda などのサービス API で直接書き換え、インフラの変更は CloudFormation で反映します。`--code` を付けるとコードだけを同期します。速い代わりに、[公式ドキュメント](https://docs.aws.amazon.com/serverless-application-model/latest/developerguide/using-sam-cli-sync.html)と CLI の確認メッセージが「CloudFormation スタックにドリフトが生じる」「開発用スタックにだけ使う」と明記しています。本番には `sam deploy` か CI/CD パイプラインを使い、`sam sync` の対象は本番と別名の開発スタックに限ります。 監視から外すファイルは `--watch-exclude` で指定します。ソースフォルダーの中で直接ビルドする `--build-in-source` が使えるのは、1.170.0 のヘルプでは nodejs16.x〜nodejs22.x・Makefile・esbuild です。この記事の Python＋pip の標準ビルドは対象外ですが、Python でも Makefile ビルドを指定した場合は利用できます。 ### sam logsでログを取得し、sam deleteでスタックを削除する ``` sam logs --stack-name sam-app --tail sam delete --stack-name sam-app # sam sync の例で開発スタックも作成した場合 sam delete --stack-name sam-app-dev ``` `sam logs` はスタック内の Lambda の CloudWatch Logs を取得し、`--tail` で流し続けます。検証が終わったら `sam delete` でスタックと、`sam deploy` が S3 に置いた成果物をまとめて削除します。ただし、Lambda が自動作成したロググループはスタック管理外なので残ります。不要な検証ログは別途削除するか、保持期間を設定してください。CI/CD に移すときは `sam pipeline init` が GitHub Actions などのパイプライン設定ファイルを生成します。 ## AWS SAM・CDK・Serverless Framework・Terraformの選び分け | ツール | 書き方 | 対象 | ツールの料金 | | ----------------------- | ------------------ | ------- | ------- | | AWS SAM | YAML（宣言的） | AWSのみ | 無料 | | AWS CDK | TypeScript・Python等 | AWSのみ | 無料 | | Serverless Framework v4 | YAML＋プラグイン | AWS中心 | 条件付きで有料 | | Terraform | HCL | マルチクラウド | CLIは無料 | **Lambda と API を素直に並べるだけなら SAM を選びます。**変換後も CloudFormation のスタックなので、変更セットでそのまま追えます。環境ごとに関数の数が変わる、同じ構成をループで量産するといった「ロジックで構成を組み立てる」要件が出たら CDK に移ります。CDK のプロジェクトでも、SAM CLI のローカルテスト機能を組み合わせて使えることが [What is AWS SAM?](https://docs.aws.amazon.com/serverless-application-model/latest/developerguide/what-is-sam.html) に書かれています。 SAM が向かないのは、AWS 以外のクラウドや SaaS の設定も同じ道具で管理したいときで、この場合は Terraform にします。Serverless Framework は v4 から、無料で使える組織の条件が年商だけでなく組織の種類でも決まるため、採用前に規約を確認してください（詳細は [Serverless Frameworkとは？v4の料金・使い方・Python対応と無料の代替oslsまで【2026年10月】](/tech/details/8464/)）。サーバーレスで組むか自体を迷っている段階なら、構成パターンから比べる [サーバーレスアーキテクチャとは？構成パターン・AWS実装・採用判断を実装者目線で解説](/tech/details/13125/) が先です。IaC の選定から本番構築までまとめて進めるなら、[AWS・Google Cloud・Azureのインフラ構築支援](/service/system/aws/)で構成の検討から相談できます。 ## よくある質問 ### AWS SAMの読み方は？ 「サム」と読みます。AWS Serverless Application Model の略です。 ### AWS SAMの利用に料金はかかりますか？ SAM 自体に追加料金はありません。課金されるのは、SAM で作成した Lambda・API Gateway・S3 などのリソースの利用料だけです。 ### DockerがなくてもAWS SAMは使えますか？ 関数を ZIP 形式（既定）で作る構成なら使えます。`sam build`（`--use-container` なし）・`sam deploy`・`sam sync` は Docker 無しで動きます。関数のローカル実行、`sam build --use-container`、コンテナイメージ形式の関数のビルドには、Docker か Finch が必要です。 ### sam syncを本番環境で使ってもよいですか？ 使いません。`sam sync` は CloudFormation を通さずに Lambda などを更新するのでスタックにドリフトが生じ、AWS も開発用スタック専用としています。本番は `sam deploy` か CI/CD で反映します。 ### AWS SAMとCloudFormationはどちらを使えばよいですか？ Lambda・API Gateway・DynamoDB が中心なら SAM、VPC や RDS などサーバーレス以外が主役なら CloudFormation です。SAM テンプレートには通常の CloudFormation リソースも書けるので、両方が混ざる構成は SAM にまとめられます。 ## 関連記事 - [AWS CloudFormationとは？テンプレートの書き方・スタック操作と更新で消える設定の防ぎ方](/tech/details/2927/) - [AWS サーバーレス ハンズオン｜Lambda・DynamoDB・API GatewayでREST APIを作る手順【2026年版】](/tech/details/2818/) - [サーバーレスアーキテクチャとは？構成パターン・AWS実装・採用判断を実装者目線で解説](/tech/details/13125/) - [Serverless Frameworkとは？v4の料金・使い方・Python対応と無料の代替oslsまで【2026年10月】](/tech/details/8464/) - [cfn-lintとは？CloudFormationテンプレート検証の導入・設定・CI組み込み【v1.57対応】](/tech/details/10676/) --- 出典: [AWS SAMとは？CloudFormationとの違い・SAM CLIの使い方を実例で解説]()（株式会社一創）