どうも、拓田です。
今さらなんだけど、CloudformationとSAMがよくわからんかったので、調べました。
SAMってなんとなくCFnでサーバレスコンポーネントの記述を簡単にする、くらいの認識しかなかったので、改めてまとめた感じです。
最近はTerraformがベターですが、改めてCFn + SAMを理解出来たらTerraformのメリットも見えてきそうだったので、本記事で復習用にまとめておきます。
📌 TL;DR
- AWS SAMはサーバーレスアプリ向けに CloudFormationを抽象化・簡略化 したフレームワーク
- CloudFormationでもLambdaは作れるが、記述が煩雑になりがち
- SAMの最大のメリットは テンプレートの簡潔さ と ローカル実行による開発体験の向上
🤔 CloudFormationだけではダメだったのか？
結論から言うと、SAMなしのCloudFormationだと記述量が膨大になるため、SAMを使うことになります。
Lambda関数 ＋ API Gateway というシンプルな構成でも、CloudFormationで書くと以下をすべて明示的に定義しなければなりません。
- IAMロール
- APIのステージ
- デプロイメント
- パーミッション
これが積み重なると、あっという間に 100〜200行規模 になってしまいます😇
SAMを使うとこれを 数十行 で書けます。
AWS::Serverless::Function のような抽象化されたリソースタイプが、付随するリソースを自動生成してくれるからです。
🔍 AWS SAMとは
AWS SAM（Serverless Application Model）は、AWSが提供するサーバーレスアプリケーション向けのオープンソースフレームワークです。
CloudFormationの拡張として機能し、Lambda・API Gateway・DynamoDBといったサーバーレスリソースをシンプルな構文で定義できます。内部的にはCloudFormationに変換されるため、既存のCloudFormationリソースとも併用可能です。
主な構成要素はこの3つです。
| 要素 | 内容 |
|---|---|
| SAMテンプレート | サーバーレス構成をYAMLで定義するファイル |
| SAM CLI | ビルド・デプロイ・ローカル実行を行うコマンドラインツール |
| SAMリソースタイプ |
AWS::Serverless::Function など、CFnを抽象化した独自リソース |
🛠️ SAMを使うには？
SAMテンプレートのYAMLの先頭に以下を書くだけです。
Transform: AWS::Serverless-2016-10-31
これを書くことで、CloudFormationに「このテンプレートはSAM構文を使っている」と伝えられます。デプロイ時にSAMのリソースタイプが通常のCloudFormationリソースに自動変換されます。
ただし実際の開発では、sam init でプロジェクトを初期化すると自動生成されたテンプレートにこの記述が含まれているため、手書きする機会はほぼありません。
🚀 SAMのローカル実行が便利
SAMには sam local invoke というコマンドがあり、PCのDocker上でLambda関数を擬似的に実行 できます。
✅ SAMなし（つらい）
コードを書く
↓
AWSにデプロイ（数分かかる）
↓
AWS上で実行して動作確認
↓
バグがあれば修正してまたデプロイ…（無限ループ）
✅ SAMあり（快適）
コードを書く
↓
sam local invoke でPC上でそのまま実行
↓
即座に結果確認・デバッグ
AWS上のデプロイ待ちのストレスがなくなるだけで、かなり変わります。
⚠️ ローカル実行の限界と注意点
SAMのローカル実行はDockerコンテナで実現していますが、本番のLambdaはFirecrackerのマイクロVMで動作しています。
DockerとFirecrackerはどちらも軽量な実行環境ですが、カーネルやネットワークスタック・セキュリティモデルの細部が異なります。
そのため、SAMのローカル環境はあくまで 「近似した再現」 であって、完全な同一環境のテストではありません。
具体的に差異が出やすいポイントはこちら。
| 項目 | 内容 |
|---|---|
| タイムアウト挙動 | ローカルのコンテナは本番のタイムアウト制約と完全一致しない |
| IAMロール | ローカルでは再現されない |
| コールドスタート | FirecrackerとDockerの初期化特性が異なる |
| 他サービス連携 | DynamoDB・S3などとの結合はローカルで再現不可 |
「ローカルで動いたのに本番で動かない」は起こりうる話なので要注意です。
📋 実践的なテスト戦略
上記の限界を踏まえ、現場での定石は 2段構えのテスト戦略 です。
| フェーズ | 環境 | 目的 |
|---|---|---|
| 開発中 | ローカル（SAM） | ロジック確認・高速イテレーション |
| リリース前 | AWS上 | 結合テスト・性能検証・最終確認 |
ローカルとAWSの役割を明確に分けて使うのがポイントです。
ローカルで高速に試して、AWS上のサービスを利用した結合試験や最終確認をAWS上で行うイメージです。
📝 まとめ
| 観点 | 内容 |
|---|---|
| SAMとは | CloudFormationをサーバーレス向けに抽象化したフレームワーク |
| 登場背景 | CFnでもLambdaは書けるが記述が煩雑なため |
| 主なメリット | テンプレートの簡潔さ・ローカル実行による開発体験向上 |
| ローカル実行の仕組み | DockerでLambda実行環境を再現 |
| ローカル実行の限界 | 本番はFirecrackerのマイクロVM。完全一致ではない |
| 推奨テスト戦略 | ローカルで高速イテレーション→AWS上で最終確認 |