AWS Serverless Application Model (SAM)

解決する課題

サーバーレスアプリは Lambda 関数だけでなく、API Gateway・DynamoDB テーブル・イベントソース・IAM ロールなど多数のリソースの組み合わせで成り立ちます。これを素の CloudFormation で書くと、1 つの API つき Lambda を定義するだけでも記述が長くなりがちでした。SAM なら：

• サーバーレス向けの 短い専用記法で、関数や API をまとめて宣言できる
• ロールやイベント連携など定型的な配線を自動生成し、記述量を大幅に減らせる
• ローカルでの実行・テストから本番デプロイまでを 1 つのツールチェーンで回せる

SAM は単独のマネージドサービスというより、CloudFormation の上に乗る オープンソースのフレームワーク兼 CLI です。インフラをコードで宣言する点は他クラウドの IaC（例: Azure では Bicep、汎用では Terraform）に近く、その中でもサーバーレスに特化している点が特徴です。

主要概念と用語

• SAM テンプレート: Transform: AWS::Serverless-2016-10-31 を宣言した YAML / JSON。CloudFormation テンプレートの上位互換
• Transform マクロ: デプロイ時に SAM の短い記法を通常の CloudFormation リソースへ展開する仕組み
• AWS::Serverless::Function: Lambda 関数を簡潔に定義するリソース型。イベントソースや権限もまとめて書ける
• AWS::Serverless::Api: API Gateway を定義するリソース型。関数の Events から暗黙的に生成されることも多い
• Events（イベントソース）: Api・S3・SQS・DynamoDB・Schedule など、関数を起動するトリガーの宣言
• Policies / Policy Templates: 関数の実行ロールに与える権限。よくあるパターンはテンプレート名で簡潔に指定できる
• SAM CLI: ビルド・ローカル実行・デプロイを行うコマンドラインツール（sam build / sam local / sam deploy）

仕様・制限・クォータ

• テンプレート冒頭の Transform 宣言が必須で、これがないと SAM の短い記法は展開されない
• SAM の機能の多くは最終的に CloudFormation のスタックとして適用されるため、スタックやリソースに関する CloudFormation 側の上限がそのまま効く
• sam local でのローカル実行には Docker が必要で、Lambda 実行環境を模したコンテナで関数を動かす
• ローカル実行はあくまで近似であり、IAM 権限の評価やサービス間連携など本番環境とは挙動が異なる部分がある
• デプロイ成果物はアーティファクト用の S3 バケット（コンテナイメージなら ECR） を経由する

内部の仕組み

横にスクロール

SAM の中心は Transform という CloudFormation マクロです。sam deploy を実行すると、CLI はまずローカルでビルドした成果物をアップロードし、SAM テンプレートを CloudFormation に渡します。CloudFormation 側で Transform が適用されると、AWS::Serverless::Function のような短い記法が、Lambda 関数・実行ロール・API Gateway・パーミッションといった複数の通常リソースへ展開されます。

• 関数の Events に Api を書くと、対応する API Gateway とメソッド・統合・呼び出し許可が自動生成される
• Policies に権限を書くと、それを反映した IAM ロールが生成される
• 展開後は通常の CloudFormation スタックとして扱われるため、変更セット（Change Set）やドリフト検出などの仕組みがそのまま使える

sam build はソースと依存関係をビルドして配置し、sam local invoke / sam local start-api は Docker 上で Lambda 実行環境を再現してローカルテストを可能にします。つまり、開発時はローカルの近似環境、デプロイ時は CloudFormation という二段構えになっています。

設計パターン / ベストプラクティス

• サーバーレス中心の構成では SAM テンプレートを単一の真実の源とし、関数・API・テーブルをまとめて管理する
• 実行ロールは ポリシーテンプレートや最小権限の記述で絞り、ワイルドカードの広い権限を避ける
• 設定値は Parameters とステージごとのパラメータファイルで切り替え、テンプレート本体は環境非依存に保つ
• 本番反映前に Change Set を確認してから適用し、想定外の差分を防ぐ
• 段階的リリースが必要なら AWS::Serverless::Function の DeploymentPreference（CodeDeploy 連携によるカナリア / 線形デプロイ）を活用する
• ローカルテストはあくまで近似と割り切り、統合テストはデプロイ済みの実環境でも行う

運用・監視

• 関数のログは CloudWatch Logs、分散トレースは AWS X-Ray で確認する（テンプレートでトレース有効化を宣言できる）
• デプロイは CloudFormation スタックとして履歴が残るため、スタックイベントで失敗箇所を追跡できる
• 失敗時は ロールバックが効く。リソース作成エラーの原因（権限・命名・依存）はスタックイベントで切り分ける
• CI/CD では sam build と sam deploy をパイプラインに組み込み、SAM Pipelines で雛形を生成して CodePipeline などと連携する
• ローカルで sam local start-api を使えば、デプロイせずに API の動作確認やデバッグができる

コスト

• SAM フレームワーク自体に追加料金はかからない（オープンソースのツール）。課金されるのは展開された Lambda・API Gateway・DynamoDB などの実リソースの利用分
• デプロイ成果物を置く S3 / ECR の保管・転送にはそれぞれの料金が発生する
• サーバーレス構成はアイドル時の固定費が小さく、使った分への課金になりやすいため、過剰なプロビジョニングを避けやすい
• 段階デプロイで CodeDeploy を併用する場合は、その関連リソースのコストも考慮する

セキュリティ

• 関数の実行ロールは 最小権限で定義し、ポリシーテンプレートを使うときも付与範囲を確認する
• 機密値はテンプレートに直書きせず、Secrets Manager / SSM Parameter Store から参照する
• API には認証・認可（IAM 認可・Cognito・Lambda オーソライザーなど）を設定し、公開範囲を絞る
• テンプレートとパラメータはバージョン管理し、本番反映は Change Set とレビューを通す
• デプロイに使う CI/CD 実行ロールも最小権限にし、広すぎる管理者権限を避ける

関連サービス・比較

サーバーレス向け IaC として、より汎用的な AWS CDK とよく比較されます。SAM は宣言的な YAML 記法でサーバーレスに特化し、CDK は一般のプログラミング言語でより広い構成を組み立てられます。

ハンズオン / CLI例

# 新規プロジェクトの雛形を対話で作成
sam init

# 関数と依存関係をビルド（必要に応じてコンテナ内でビルド）
sam build

# ローカルで API を起動して動作確認（Docker が必要）
sam local start-api

# ガイド付きでデプロイ（初回は設定が保存される）
sam deploy --guided