🍽️ AWS SAM

レストラン経営で理解する超入門ガイド

🏪 お店の設計図 → 📋 材料の準備 → 🍽️ レストラン開店

AWS SAMを、身近なレストラン経営で例えて分かりやすく説明します!

🤔 まず、AWS SAMって何?

📝 簡単に言うと...

サーバーレスアプリケーション 設計図一枚 で作って、 自動でAWS上にお店を開店 してくれる魔法のツールです

🍽️ レストラン経営の例

お店を開くために 必要なのは...


👨‍🍳 料理人 (注文が来たら料理)
🙋‍♀️ ウェイター (お客さんの注文受付)
🏪 食材倉庫 (材料やレシピ保存)
📋 設計図 (お店全体の計画書)

☁️ AWS SAMの世界

アプリを作るために 必要なのは...


Lambda (リクエストが来たら処理)
🚪 API Gateway (ユーザーからの要求受付)
💾 DynamoDB (データやファイル保存)
📄 SAMテンプレート (アプリ全体の設計書)

🏪 4つの重要な要素をレストランで理解

🙋‍♀️

API Gateway
= ウェイター

お客さんの注文を受け付ける 窓口です。
お客さんが「パスタください!」と言うと、
厨房の 適切な料理人(Lambda) に注文を伝えます。

役割: HTTPリクエストの受付
特徴: 認証、ログ、レート制限も担当
👨‍🍳

Lambda Function
= 料理人

注文が来た時だけ動く プロの料理人です。
普段はお休み中で、注文が入ると瞬時に起きて
美味しい料理(処理結果) を作ります。

特徴: サーバーレス + 使った分だけ課金
言語: Python, Node.js, Java など
🏪

DynamoDB
= 食材倉庫

レシピや食材を保存 する倉庫です。
料理人がいつでも必要な材料を
高速で取り出せる よう整理されています。

役割: NoSQLデータベース
特徴: 高速 + 自動スケーリング
📋

SAMテンプレート
= お店の設計図

レストラン全体の計画書 です。
「どんな料理人を何人雇うか」
「倉庫はどのくらいの大きさか」を YAML形式 で記述。

形式: YAML/JSON
機能: インフラをコードで管理

🗺️ レストランの注文の流れを図で見てみよう

😊

お客さん

ユーザー

「パスタください!」
(HTTPリクエスト)
🙋‍♀️

ウェイター

API Gateway

注文を受けて
厨房に伝達
👨‍🍳

料理人

Lambda Function

注文を受けて
料理を調理
⬇️

必要に応じて食材を取りに行く

🏪

食材倉庫

DynamoDB

レシピや材料を
高速で提供

🍝 完成した料理(レスポンス)がお客さんに届けられます!

お客さん → ウェイター → 料理人 → (必要に応じて倉庫) → 料理完成 → お客さん

📋 SAMテンプレートって何?

📐 SAMテンプレート = レストランの設計図書

お店を開くときに必要な「設計図」と「材料リスト」を一枚の紙にまとめたようなものです

🏪 レストランの設計図

📋 設計図に書くこと:


  • 👨‍🍳 料理人を3名雇う
  • 🙋‍♀️ ウェイターを2名雇う
  • 🏪 倉庫は50平米で準備
  • 🍝 メニューはイタリアン
  • ⏰ 営業時間は11:00-22:00

📄 SAMテンプレート

📄 YAMLファイルに書くこと:


  • ⚡ Lambda関数を3個作成
  • 🚪 API Gatewayで窓口設置
  • 💾 DynamoDBテーブル準備
  • 🔐 IAMロールで権限設定
  • 🌍 環境変数の設定
# SAMテンプレートの例(レストランアプリ) AWSTemplateFormatVersion: ' 2010-09-09 ' Transform: AWS::Serverless-2016-10-31 # レストランの設定 Globals: Function: Runtime: python3.9 Environment: Variables: RESTAURANT_NAME : "Delicious Pasta" Resources: # ウェイター(API Gateway) RestaurantAPI : Type: AWS::Serverless::Api Properties: StageName: prod # 料理人(Lambda Function) OrderFunction : Type: AWS::Serverless::Function Properties: CodeUri: src/order/ Handler: app.lambda_handler Events: OrderAPI: Type: Api Properties: Path: /order Method: post # 食材倉庫(DynamoDB) MenuTable : Type: AWS::Serverless::SimpleTable Properties: PrimaryKey: Name: menu_id Type: String

💡 設計図の魔法

📋 たった一つのファイルで:

  • 🏗️ 全てのインフラを自動構築
  • 🔗 各サービス間の連携も自動設定
  • 🔐 セキュリティ設定も自動で適用
  • 📊 ログ・モニタリングも自動構成
  • 🌍 本番環境とテスト環境を簡単に作り分け

🚀 レストラン開店の手順(SAMデプロイ)

1

設計図を書く(template.yaml)

SAMテンプレートを作成
→ お店の設計図を書く(何人雇うか、倉庫の大きさなど)
→ 必要なサービスとその設定をYAMLで記述

2

料理のレシピを準備(コード作成)

Lambda関数のコードを作成
→ 料理人が作る料理のレシピを書く
→ Python、Node.js、Javaなどで処理ロジックを実装

3

材料をまとめる(sam build)

アプリケーションをビルド
→ レシピと材料を一つの配達ボックスにまとめる
→ 依存関係の解決とパッケージング

$ sam build
4

開店準備(sam deploy)

AWS上にデプロイ
→ 実際にレストランを開店させる
→ CloudFormationが全てのリソースを自動作成

$ sam deploy --guided
5

開店完了!🎉

アプリケーション稼働開始
→ お客さんがお店に来れるようになった!
→ API Gateway経由でアプリにアクセス可能

📋

設計図

template.yaml

📦

ビルド

sam build

🚀

デプロイ

sam deploy

🍽️

開店

稼働開始

❓ よくある質問

🤔 なぜSAMを使うの?普通のAWSじゃダメ?
💰 SAMは無料?お金はかかる?
📚 どんなアプリが作れるの?
🛠️ 設定や開発は難しい?

✨ SAMを使うメリット

超高速開発

手動設定なら数日かかる作業が、数分で完成。レストランが即座に開店!

💰

コスト最適化

使った分だけ課金。お客さんが来ない時間は料金ゼロ!

📈

自動スケーリング

お客さんが急増しても自動で料理人を増員。パンクしません

🔧

メンテナンス不要

サーバー管理やOSアップデートは全てAWSにお任せ

🌍

環境複製

同じ設計図で、テスト店舗と本店を簡単に作り分け

🔄

バージョン管理

設計図をGitで管理すれば、チーム開発も楽々

🎯 SAM vs 他の選択肢

🏗️ 従来の方法

👷‍♂️ 手動でレストラン開店:


  • 料理人を一人ずつ面接・雇用
  • ウェイターを一人ずつ面接・雇用
  • 倉庫を一つずつ契約・設営
  • 各スタッフの連携を個別に調整
  • 数週間〜数ヶ月 😰

🚀 SAM使用

📋 設計図でレストラン開店:


  • 設計図(YAML)を書く
  • sam deployコマンド実行
  • 全スタッフ自動雇用・自動連携
  • お店が自動で開店準備完了
  • 数分 🎉

📊 比較表

項目 従来手動 SAM
開発時間 数日〜数週間 数時間
複雑さ 高い 低い
エラー率 高い 低い
チーム開発 困難 簡単

🏗️ SAM vs CloudFormation どちらを選ぶ?

🍽️ レストラン専用テンプレート vs 🏗️ 万能建築マニュアル

AWS SAMとCloudFormationは、どちらもAWSインフラを作るツール。でも使いやすさと対象が全然違います!

🍽️ AWS SAM

📋 レストラン専用の簡単設計図


  • 🍽️ サーバーレス専用
  • 📝 記述量が少ない
  • 開発が早い
  • 🎯 初心者でも簡単
  • 🎨 テンプレートが豊富

「料理人3名、ウェイター2名、倉庫50㎡」
→ お任せでレストラン完成!

🏗️ CloudFormation

🏢 万能建築の詳細設計図


  • 🌍 AWS全サービス対応
  • 📚 記述量が多い
  • ⚙️ 細かい制御可能
  • 🎓 上級者向け
  • 🔧 完全カスタマイズ

「配管の位置、電気の容量、窓の寸法...」
→ 全て一から詳細設計

🔄 2つの関係性

📋

SAMテンプレート

簡単な注文書

「料理人3名
ウェイター2名
イタリアンレストラン」
⚙️

SAMが自動変換

詳細設計を生成

内部で自動的に
CloudFormation形式に変換
🏗️

CloudFormation

詳細設計図

全ての配線、配管
構造の詳細仕様書

💡 つまり...

SAMはCloudFormationの「簡単版」
内部的にはCloudFormationを使って、複雑な設定を自動生成してくれます!

📝 コード記述量の違い

CF

CloudFormationでLambda + API Gateway

約80行のコード が必要
→ IAMロール、API Gateway、Lambda、各設定を個別に記述
→ 権限設定、リソース間の連携を手動で設定

Resources: LambdaExecutionRole: Type: AWS::IAM::Role Properties: # 20行以上... MyLambdaFunction: Type: AWS::Lambda::Function Properties: # 15行以上... ApiGatewayRestApi: Type: AWS::ApiGateway::RestApi Properties: # 10行以上... # さらに多くの設定...
SAM

SAMで同じものを作成

約10行のコード で完成
→ 必要最小限の設定のみ記述
→ 権限設定、連携設定は自動で生成

Resources: OrderFunction: Type: AWS::Serverless::Function Properties: CodeUri: src/ Handler: app.lambda_handler Runtime: python3.9 Events: OrderAPI: Type: Api Properties: Path: /order Method: post

🤔 どちらを選ぶべき?判断基準

🍽️ SAMを選ぶべき場面は?
🏗️ CloudFormationを選ぶべき場面は?
🎯 結局どっちから学ぶべき?

⚖️ 最終比較表

🍽️

AWS SAM

対象: サーバーレス専用
難易度: ⭐⭐
記述量: 少ない
開発速度: 高速

🏗️

CloudFormation

対象: AWS全サービス
難易度: ⭐⭐⭐⭐⭐
記述量: 多い
開発速度: 時間がかかる

🎯

使い分け

初心者: SAMから始める
API作成: SAM
複雑インフラ: CloudFormation
迷ったら: SAM

🎯 まとめ

🍽️ AWS SAM = レストラン経営の魔法の設計図

🙋‍♀️ API Gateway = ウェイター(注文受付)

👨‍🍳 Lambda = 料理人(実際の処理)

🏪 DynamoDB = 食材倉庫(データ保存)

📋 SAMテンプレート = 設計図(YAML)


🚀 たった一つの設計図で、完全なレストラン(アプリ)が自動開店!


🎯 初心者へのアドバイス:

  • まずは公式チュートリアルで「Hello World」を作ってみる
  • 小さなAPIから始めて、徐々に機能を追加
  • エラーを恐れずに試してみる(簡単に削除・再作成可能)
  • コミュニティやドキュメントを活用する

🌟 SAMなら、誰でも簡単にプロ級のサーバーレスアプリが作れます!

Created by SSuzuki1063

AWS SAP Learning Resources