AWSコンソールだけでメモアプリAPIを構築する手順【Lambda＋API Gateway＋DynamoDB / SAMとの比較付き】

はじめに

この記事は、SAM版ハンズオン記事の比較版です。

SAM版ではコマンド数本でインフラが完成しましたが、「その裏で何が起きているのか？」「SAMを使わない場合はどれだけ手間がかかるのか？」 を実感してもらうために、全く同じメモアプリAPIをAWSコンソールのみで手作業で構築する手順を詳細に解説します。

この記事を読むとわかること：

• AWS各サービス（DynamoDB・IAM・Lambda・API Gateway）を個別に設定する流れ
• SAMが裏側で自動処理していること（IAMロール・API Gatewayルーティング・権限付与など）
• SAMとコンソール手動操作、それぞれの使いどころ

SAM vs コンソール：どれだけ違うか

まず差分を数字で確認します。

「それでもコンソール操作を知っておく価値はあるか？」という問いに対して、答えは Yes です。

コンソール操作が特に有効な場面：

• 障害調査 — 実際にどのリソースがどう設定されているか目視確認する
• SAMのデバッグ — SAMでデプロイしたリソースをコンソールで確認・修正する
• 初学習 — 各サービスの設定項目を理解するための最初の一歩

Amazon検索[本 AWS 開発]

構築するもの

SAM版と全く同じ構成・機能のAPIを構築します。

インターネット
  ↓ HTTPS
API Gateway（Prod ステージ）
  ↓ Lambdaプロキシ統合
Lambda（MemoFunction / Python 3.12）
  ↓ boto3
DynamoDB（memo-api-dynamodb-stack-Memos テーブル）

全体の作業順序

SAMは依存関係を自動解決しますが、コンソールでは依存する順番通りに作成する必要があります。

① DynamoDB テーブル作成
      ↓（テーブル名が必要）
② IAM ロール作成（Lambda実行用）
      ↓（ロールARNが必要）
③ Lambda 関数作成（zipアップロード・環境変数設定）
      ↓（関数ARNが必要）
④ API Gateway 作成・リソース・メソッド設定・デプロイ
      ↓
⑤ Lambda に API Gateway からの実行許可を確認・付与

この順序を守らないと、設定画面で参照先リソースが見つからずエラーになります。

① DynamoDB テーブル作成

AWSコンソール → DynamoDB → テーブル → 「テーブルの作成」

設定値

「テーブルの作成」ボタンをクリック。作成完了まで数十秒待ちます。

▶ 控えておく情報：

• テーブル名: memo-api-dynamodb-stack-Memos

キャパシティーモードはオンデマンドを選ぶ理由：
デフォルトの「プロビジョンド」はあらかじめ読み書き容量を指定して課金されます。学習目的ではアクセスがない時間も課金されてしまうため、アクセスがあった分だけ課金される「オンデマンド」を選択します。SAMの BillingMode: PAY_PER_REQUEST に相当します。

② IAM ロール作成（Lambda実行用）

AWSコンソール → IAM → ロール → 「ロールを作成」

SAMでは DynamoDBCrudPolicy を1行書くだけで自動生成されていたIAMロールを、ここでは手動で作成します。

2-1. 信頼ポリシーの設定

「次へ」をクリックします。

2-2. 許可ポリシーのアタッチ（CloudWatch Logs 用）

検索ボックスに AWSLambdaBasicExecutionRole と入力してチェックを入れます。

→ 「次へ」

2-3. ロール名を設定して作成

「ロールを作成」をクリックします。

2-4. DynamoDB CRUD 権限をインラインポリシーで追加

作成したロール memo-api-lambda-role を開き → 「許可を追加」→「インラインポリシーを作成」→「JSON」タブ を選択して以下を貼り付けます：

{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Effect": "Allow",
      "Action": [
        "dynamodb:GetItem",
        "dynamodb:PutItem",
        "dynamodb:UpdateItem",
        "dynamodb:DeleteItem",
        "dynamodb:Scan",
        "dynamodb:Query"
      ],
      "Resource": "arn:aws:dynamodb:ap-northeast-1:*:table/memo-api-dynamodb-stack-Memos"
    }
  ]
}

ポリシー名（例: DynamoDBCrudPolicy-Memos）を入力して「ポリシーの作成」をクリックします。

▶ 控えておく情報：

• ロール ARN（例: arn:aws:iam::123456789012:role/memo-api-lambda-role）

SAMとの差分： SAMの DynamoDBCrudPolicy は必要な6つのDynamoDBアクションとCloudWatch Logs権限を1行で自動付与します。コンソールでは「管理ポリシーのアタッチ」と「インラインポリシーの作成」の2手順が必要です。

③ Lambda 関数作成

3-1. Lambdaコードをzipファイルに圧縮する（ローカル作業）

src/app.py と src/requirements.txt を zip 圧縮します。

Windowsエクスプローラーでの操作：

1. src/ フォルダを開く
2. app.py と requirements.txt を両方選択
3. 右クリック → 「ZIPファイルに圧縮」
4. lambda.zip という名前で保存

【注意】フォルダごとではなくファイルを直接zipする

src/ フォルダ自体を右クリックしてzipすると、中身のパスが src/app.py になります。LambdaはCodeUri直下に app.py があることを期待するため、フォルダの中身のファイルを選択してからzipしてください。フォルダごと圧縮するとパスが変わって Handler: app.lambda_handler が見つからずエラーになります。

コードの内容はSAM版ハンズオン記事のStep 3を参照してください。

3-2. Lambda 関数の作成

AWSコンソール → Lambda → 関数 → 「関数の作成」

「関数の作成」をクリックします。

3-3. コードのアップロード

関数ページ → 「コードソース」セクション → 「アップロード元」→「.zip ファイル」→ lambda.zip を選択 → 「保存」

3-4. 環境変数の設定

「設定」タブ → 「環境変数」→「編集」→「環境変数を追加」

「保存」をクリックします。

SAMとの差分： SAMでは template.yaml の Environment.Variables.TABLE_NAME: !Ref MemosTable が自動でテーブル名を解決して設定します。コンソールでは①で作成したテーブル名を手動でコピーして貼り付ける必要があります。

3-5. タイムアウトの設定

「設定」タブ → 「一般設定」→「編集」

「保存」をクリックします。

▶ 控えておく情報：

• 関数 ARN（例: arn:aws:lambda:ap-northeast-1:123456789012:function:MemoFunction）

④ API Gateway 作成・設定・デプロイ

ここが最も手順が多いセクションです。5エンドポイント × 複数設定 = 大量のクリック作業になります。SAMが Events: セクションの数行で自動処理していた部分を全て手動で設定します。

4-1. REST API の作成

AWSコンソール → API Gateway → 「APIを作成」

「APIを作成」をクリックします。

4-2. リソース /memos の作成

「リソース」→「リソースを作成」

「リソースを作成」をクリックします。

4-3. POST /memos メソッドの作成

/memos リソースを選択 →「メソッドを作成」

「メソッドを作成」をクリックします。

「Lambda プロキシ統合」をオンにする理由：
オンにすると、HTTPリクエスト全体（メソッド・パス・ボディ・ヘッダー）がそのままLambdaの event に渡されます。オフにすると、マッピングテンプレートを別途設定する必要があり手順が大幅に増えます。SAMはデフォルトでプロキシ統合を使用します。

4-4. GET /memos メソッドの作成

/memos リソースを選択 →「メソッドを作成」

「メソッドを作成」をクリックします。

4-5. リソース /memos/{id} の作成

/memos リソースを選択 →「リソースを作成」

「リソースを作成」をクリックします。

{id} は波括弧ごと入力する
{id} と入力することで API Gateway がパスパラメータとして認識し、Lambda の event['pathParameters']['id'] で受け取れるようになります。

4-6. GET /memos/{id} メソッドの作成

/memos/{id} リソースを選択 →「メソッドを作成」

「メソッドを作成」をクリックします。

4-7. PUT /memos/{id} メソッドの作成

/memos/{id} リソースを選択 →「メソッドを作成」

「メソッドを作成」をクリックします。

4-8. DELETE /memos/{id} メソッドの作成

/memos/{id} リソースを選択 →「メソッドを作成」

「メソッドを作成」をクリックします。

4-9. API のデプロイ

「APIをデプロイ」ボタンをクリックします。

「デプロイ」をクリックします。

ステージ画面の「呼び出し URL」に表示されるURLを控えておきます：

https://xxxxxxxxxx.execute-api.ap-northeast-1.amazonaws.com/Prod

▶ 控えておく情報：

• 呼び出し URL（テストで使います）

⑤ Lambda に API Gateway からの実行許可を確認・付与

API GatewayがLambdaを呼び出す権限を確認します。

Lambda プロキシ統合でメソッドを作成した際に「Lambda関数に権限を追加しますか？」という確認ダイアログが表示されて「OK」をクリックした場合は、この手順は自動で完了しています。

もし 403 Forbidden エラーが出た場合は、以下の手順で手動付与します：

Lambda → 対象関数 → 「設定」タブ → 「リソースベースのポリシーステートメント」→「追加」

テスト（CMDでの動作確認）

テスト手順はSAM版と同じです。コンソールで取得した呼び出し URLを使って実行します。

set API_URL=https://xxxxxxxxxx.execute-api.ap-northeast-1.amazonaws.com/Prod

POST /memos — メモを作成する

curl -s -X POST "%API_URL%/memos" -H "Content-Type: application/json" -d "{\"title\":\"初めてのメモ\",\"content\":\"DynamoDBに保存されます\"}"

レスポンス例：

{
  "memoId": "6150433b-4834-4cfe-81f5-266d3dad9e57",
  "title": "初めてのメモ",
  "content": "DynamoDBに保存されます",
  "createdAt": "2026-02-20T10:00:00.000000+00:00",
  "updatedAt": "2026-02-20T10:00:00.000000+00:00"
}

GET /memos — メモ一覧を取得する

curl -s "%API_URL%/memos"

GET /memos/{id} — メモ1件を取得する

curl -s "%API_URL%/memos/6150433b-4834-4cfe-81f5-266d3dad9e57"

PUT /memos/{id} — メモを更新する

curl -s -X PUT "%API_URL%/memos/6150433b-4834-4cfe-81f5-266d3dad9e57" -H "Content-Type: application/json" -d "{\"title\":\"更新後タイトル\",\"content\":\"内容も更新しました\"}"

DELETE /memos/{id} — メモを削除する

curl -s -X DELETE "%API_URL%/memos/6150433b-4834-4cfe-81f5-266d3dad9e57"

CMDでのテストの詳細な注意点（変数未設定によるCloudFront 400エラーなど）はSAM版ハンズオン記事のStep 9を参照してください。

⑥ リソースの削除（コンソール）

削除する順番が重要です（依存関係の逆順）。 SAMなら sam delete 1コマンドで完了するところを、4サービスを個別に手動削除します。

1. API Gateway を削除する

API Gateway → MemoApi を選択 → 「削除」→ 確認テキストを入力 → 「削除」

2. Lambda を削除する

Lambda → 関数 → MemoFunction を選択 → 「アクション」→「削除」→ 確認テキストを入力 → 「削除」

3. IAM ロールを削除する

IAM → ロール → memo-api-lambda-role を選択 → 「削除」→ ロール名を入力 → 「削除」

4. DynamoDB テーブルを削除する

DynamoDB → テーブル → memo-api-dynamodb-stack-Memos → 「削除」→ テーブル名を入力して確認 → 「削除」

SAMとの差分： SAMの sam delete は CloudFormation スタックを削除することで、S3・Lambda・API Gateway・DynamoDB・IAMロールを一括で削除します。コンソールでは依存関係の逆順に4サービスを個別に削除する必要があります。

まとめ

今回の手順で確認したこと

コンソール操作を通じて、SAMが裏側で自動処理している内容が明確になりました：

コンソール操作で学べたこと

• IAMロールの構造 — 信頼ポリシー（誰がロールを使えるか）とアクセス許可ポリシー（何ができるか）の2層構造
• API Gatewayの仕組み — リソース（パス）とメソッド（HTTPメソッド）を組み合わせてエンドポイントを定義する
• Lambdaプロキシ統合 — リクエスト全体をeventとしてLambdaに渡す仕組み
• リソース間の依存関係 — 作成順序・削除順序が決まっている理由

どちらを使うべきか

関連記事

• SAM版ハンズオン — VS Codeで全自動デプロイ

AWS初心者ハンズオン - Lambda＋API Gateway＋DynamoDBでメモアプリAPIを作ろう【Windows対応】

はじめに「AWSのサーバーレスを試してみたい」「Lambda・API Gateway・DynamoDBを組み合わせて何か作ってみたい」と思っていませんか？この記事では、AWS SAM（Serverless Application Model...

caymezon.com

2026.02.20

Amazon検索[本 AWS 開発]