SAA API Gateway 設計パターン4選｜REST API・HTTP API・WebSocket・非同期統合の選択基準
AWS SAA-C03 で問われる API Gateway の選択・設計を完全整理。REST API（フル機能）vs HTTP API（低コスト低レイテンシ）vs WebSocket API（双方向リアルタイム）の違い、Lambda 同期統合 vs SQS 非同期統合の4パターンを、試験頻出シナリオと要件キーワードから即断できる粒度で解説。
「API Gateway の問題は、まず API タイプを選べ」 — SAA-C03 で API Gateway が絡む問題の正解は、ほぼ「どの API タイプを使うか」と「バックエンドを同期で呼ぶか非同期で呼ぶか」で決まる。REST API・HTTP API・WebSocket API の3タイプそれぞれの用途と制約を整理し、さらに SQS への非同期統合を加えた4パターンを押さえれば、試験のシナリオ問題を即断できる。本記事では、要件キーワードから正解パターンへの逆引きができる粒度で解説する。
※ 本記事はアフィリエイト広告（Amazon アソシエイト等）を含みます
📑 目次
- 結論：API Gateway 設計パターン4選
- API タイプ選択の判断軸
- パターン1：REST API + Lambda 同期統合
- パターン2：HTTP API — 低コスト・低レイテンシ
- パターン3：WebSocket API — 双方向リアルタイム通信
- パターン4：REST API + SQS 非同期統合
- REST API vs HTTP API 詳細比較
- セキュリティと認証の選択
- スロットリング・キャッシュ・モニタリング
- 要件キーワード早見表
- 頻出ひっかけパターンと正しい打ち手
- 次のアクション チェックリスト
- 関連記事
- 関連サイト
1. 結論：API Gateway 設計パターン4選
SAA-C03 の API Gateway 問題は、「何を接続したいか」と「同期か非同期か」の2軸で4パターンに集約できる。
| パターン | 主な技術 | 典型的なシナリオ | 試験での見分け方 |
|---|---|---|---|
| 1. REST API + Lambda | API GW REST API → Lambda | フル機能が必要なサーバーレス API（認証・変換・使用量プラン） | 「API キー」「使用量プラン」「リクエスト変換（マッピングテンプレート）」「既存エンタープライズ API」 |
| 2. HTTP API | API GW HTTP API → Lambda / HTTP | シンプルで低コスト・低レイテンシの API | 「コスト削減」「最小レイテンシ」「JWT 認証」「Lambda プロキシ統合のみ」 |
| 3. WebSocket API | API GW WebSocket → Lambda | チャット・通知・リアルタイムダッシュボード | 「双方向通信」「コネクション維持」「プッシュ通知」「チャットアプリ」 |
| 4. REST API + SQS | API GW REST API → SQS → Lambda/Worker | バーストリクエストの受付・非同期処理 | 「バースト耐性」「受付即レスポンス」「バックエンドが遅い」「Lambda タイムアウト回避」 |
最初に「リアルタイム双方向が必要か（→ WebSocket）」「非同期が必要か（→ SQS 統合）」「フル機能が必要か（→ REST API）」「低コスト重視か（→ HTTP API）」の順に確認するのが正答への最短ルートだ。
2. API タイプ選択の判断軸
2軸の判断フロー
API Gateway 選択フローチャート：
Step1: 通信モデルは？
├── 双方向・永続接続が必要 → WebSocket API（パターン3）
└── リクエスト／レスポンス型 → Step2 へ
Step2: バックエンド呼び出しモデルは？
├── 非同期（受付だけして即レスポンス） → REST API + SQS（パターン4）
└── 同期（Lambda を直接呼び出す） → Step3 へ
Step3: 必要な機能セットは？
├── API キー・使用量プラン・変換・ → REST API + Lambda（パターン1）
│ WAF 直接アタッチ・VPC Link など
└── JWT/OIDC 認証・最小レイテンシ・ → HTTP API（パターン2）
シンプルなプロキシのみで OK| 判断軸 | 問い | 答えの分岐 |
|---|---|---|
| 通信モデル | 単方向 vs 双方向 | 双方向 → WebSocket、単方向 → REST/HTTP |
| 処理モデル | 同期 vs 非同期 | 非同期デカップリング → SQS、即時 → Lambda |
| 機能要件 | フル機能 vs シンプル | 変換・API キー → REST API、JWT・低コスト → HTTP API |
| コスト感度 | フル機能 vs コスト最適化 | REST API は HTTP API の約 3.5 倍のコスト |
3. パターン1：REST API + Lambda 同期統合
概要
API Gateway の全機能を使いながら Lambda をバックエンドに接続する、最も汎用的なサーバーレス API パターン。リクエスト・レスポンスの変換（マッピングテンプレート）、API キーと使用量プラン、カナリアデプロイ、VPC リンク（プライベート統合）、WAF の直接アタッチなど、エンタープライズ向けの機能が揃う。
REST API + Lambda 同期統合：
クライアント
│ HTTPS
▼
API Gateway（REST API）
├── リクエスト変換（マッピングテンプレート）
├── 認証（IAM / Cognito / Lambda オーソライザー）
├── スロットリング（アカウント・ステージ・メソッド単位）
├── キャッシュ（TTL 秒〜時間、0.5〜237GB）
│ 同期呼び出し（最大タイムアウト 29 秒）
▼
Lambda 関数
│
▼
バックエンド（DynamoDB / RDS / SNS 等）REST API の主要機能
| 機能 | 概要 | SAA での典型シナリオ |
|---|---|---|
| API キー + 使用量プラン | サードパーティへの API 公開時にクォータ・スロットリングを設定 | 「API の使いすぎを制限したい」「従量課金 API を提供したい」 |
| マッピングテンプレート | VTL でリクエスト・レスポンスを変換 | 「レガシーバックエンドの応答形式を変換したい」 |
| カナリアリリース | ステージにカナリアスプリットを設定（例：新バージョン 10%） | 「新デプロイのリスクを最小化したい」 |
| VPC リンク | プライベートサブネットの ALB/NLB と統合 | 「インターネット非公開の内部 API を API GW 経由で公開したい」 |
| WAF 直接アタッチ | ステージに WAF ウェブ ACL をアタッチ | 「SQL インジェクション・XSS・IP 制限を API レベルで適用したい」 |
| Lambda オーソライザー | カスタム認証ロジック（JWT・OAuth トークン検証） | 「独自の認証基盤を持ちたい」「Cognito 以外の IdP を使う」 |
REST API 統合タイプ
- Lambda プロキシ統合：リクエスト全体を Lambda に渡し、Lambda がレスポンスを組み立てる（最もシンプル）
- Lambda 非プロキシ統合（カスタム統合）：マッピングテンプレートで変換してから Lambda に渡す（柔軟だが複雑）
- AWS サービス統合：SQS・SNS・Step Functions・DynamoDB などを Lambda を介さずに直接呼び出す
- HTTP 統合：既存の HTTP/HTTPS エンドポイントへプロキシ
試験での要件キーワード
- 「API キーと使用量プランで API の利用を制御したい」→ REST API
- 「リクエストボディを変換してバックエンドに渡したい（マッピングテンプレート）」→ REST API
- 「ステージレベルのキャッシュで DB クエリを削減したい」→ REST API（TTL 設定付きキャッシュ）
- 「Lambda をまったく介さず SQS に直接メッセージを送信したい」→ REST API の AWS サービス統合
4. パターン2：HTTP API — 低コスト・低レイテンシ
概要
REST API の機能を絞り込み、コストと低レイテンシを最優先したシンプルな API パターン。REST API と比較してコストが最大 71% 削減、レイテンシも低い。Lambda プロキシ統合と HTTP プロキシ統合に特化し、JWT/OIDC ベースの認証を標準サポートする。
HTTP API 構成：
クライアント
│ HTTPS
▼
API Gateway（HTTP API）
├── JWT 認証（Cognito / 外部 IdP）
├── CORS 設定（自動）
├── スロットリング（ステージ・ルート単位）
│ 最小オーバーヘッドで呼び出し
▼
Lambda / HTTP バックエンドHTTP API でできること・できないこと
| 評価項目 | REST API | HTTP API |
|---|---|---|
| コスト（百万リクエスト当たり） | $3.50（東京リージョン） | $1.00（東京リージョン） |
| レイテンシ | 標準 | REST API より低い |
| API キー・使用量プラン | ✅ 対応 | ❌ 非対応 |
| マッピングテンプレート（VTL） | ✅ 対応 | ❌ 非対応 |
| JWT/OIDC 認証 | Lambda オーソライザーで対応 | ✅ ネイティブ対応（簡単設定） |
| IAM 認証 | ✅ 対応 | ✅ 対応 |
| Lambda オーソライザー | ✅ 対応 | ✅ 対応 |
| WAF 直接アタッチ | ✅ 対応 | ❌ 非対応（CloudFront 経由なら可） |
| ステージキャッシュ | ✅ 対応 | ❌ 非対応 |
| カナリアリリース | ✅ 対応 | ❌ 非対応 |
| VPC リンク | ✅ 対応 | ✅ 対応（HTTP API 専用 VPC リンク） |
| AWS サービス直接統合 | ✅ 対応（SQS・DynamoDB 等） | ❌ 非対応 |
試験での要件キーワード
- 「API のコストを削減したい・シンプルな Lambda プロキシで十分」→ HTTP API
- 「JWT トークンで認証したい（Cognito User Pools や外部 IdP）」→ HTTP API（JWT オーソライザー）
- 「CORS の設定を自動化したい」→ HTTP API
- 「API キーや使用量プランが必要」→ HTTP API は不可、REST API を使う
5. パターン3：WebSocket API — 双方向リアルタイム通信
概要
クライアントとサーバーが永続的な WebSocket 接続を維持し、双方向にメッセージを送受信するパターン。REST / HTTP API がリクエストごとに接続を確立するのに対し、WebSocket API はコネクションを維持し続ける。チャット・リアルタイムダッシュボード・通知・オンラインゲームスコアなど、サーバー側からクライアントへ「プッシュ」が必要なシナリオに使う。
WebSocket API 構成：
クライアント A ──── WebSocket 接続 ────▶ API Gateway（WebSocket API）
クライアント B ──── WebSocket 接続 ─────────────────────────────│
│
ルートキー（$connect / $disconnect / $default / カスタム） │
▼
$connect ──▶ Lambda（接続 ID を DynamoDB に保存）
$disconnect ──▶ Lambda（DynamoDB から接続 ID を削除）
メッセージ ──▶ Lambda（DynamoDB から接続 ID を取得 → 全クライアントへ POST 送信）
│
▼
API GW Management API（POST @connections/{connectionId}）
│
▼
クライアント A・B へのプッシュ配信WebSocket API のルートキー
| ルートキー | トリガータイミング | 典型的な処理 |
|---|---|---|
| $connect | クライアントが WebSocket 接続を確立したとき | 接続 ID を DynamoDB に保存・認証 |
| $disconnect | クライアントが接続を切断したとき | DynamoDB から接続 ID を削除 |
| $default | いずれのルートにも一致しないメッセージ | メッセージのブロードキャスト |
| カスタムルート | メッセージ内の特定フィールドで分岐（例：action: "chat"） | チャットメッセージの処理 |
試験での要件キーワード
- 「チャットアプリで複数クライアントにリアルタイム配信したい」→ WebSocket API
- 「株価・センサーデータをサーバーからクライアントへリアルタイムプッシュしたい」→ WebSocket API
- 「HTTP API で定期ポーリングしているが、サーバーコストが高い」→ WebSocket API に置き換え
- 「ゲームの対戦状態をリアルタイム同期したい」→ WebSocket API
6. パターン4：REST API + SQS 非同期統合
概要
API Gateway から Lambda を介さずに SQS へ直接メッセージを送り、バックエンド処理を非同期に分離するパターン。Lambda の最大タイムアウト（15分）や API Gateway の最大タイムアウト（29秒）を超える処理、バーストリクエストの受付、バックエンド障害の影響遮断などに使う。フロントエンドは「受け付けました（202 Accepted）」とすぐに返信できる。
REST API + SQS 非同期統合：
クライアント
│ POST /orders（HTTP リクエスト）
▼
API Gateway（REST API）
│ AWS サービス統合（Lambda なし）
▼
SQS キュー
│ Lambda イベントソースマッピング
▼
Lambda（非同期処理）
│
▼
バックエンド（DynamoDB / RDS / 外部 API 等）
※ API GW → SQS の部分は Lambda タイムアウトに縛られない
※ クライアントは「202 Accepted」を受け取ってすぐに次の処理へ進める非同期統合の主要ユースケース
| ユースケース | なぜ SQS が必要か | パターン4 の効果 |
|---|---|---|
| 画像・動画処理 | エンコードに数分〜数十分かかる | API GW タイムアウト（29秒）を回避できる |
| EC サイトの注文受付 | DB 書き込み・在庫確認・決済が直列になると遅い | 受付だけ即返信、処理をキューで順次実行 |
| バーストリクエスト | Lambda 同時実行数の上限に引っかかる | SQS がバッファしてスムーズに処理 |
| バックエンド障害時の耐性 | バックエンド障害でリクエストを取りこぼしたくない | SQS に溜めてバックエンド復旧後に再処理 |
| コスト最適化 | Lambda をリアルタイムで呼び続けるとコストが高い | SQS でバッチ処理にまとめることでコスト削減 |
REST API → SQS 統合の設定ポイント
設定例：POST /orders → SQS SendMessage
統合タイプ ： AWS サービス
AWS サービス ： SQS
HTTP メソッド ： POST
アクション ： SendMessage
実行ロール ： API GW が SQS にメッセージ送信できる IAM ロール
マッピングテンプレート：
{
"QueueUrl": "<SQS_QUEUE_URL>",
"MessageBody": "$input.body"
}
レスポンス ： 202 Accepted（MessageId を含む）試験での要件キーワード
- 「Lambda のタイムアウトを超えるバックエンド処理がある」→ SQS 非同期統合
- 「バーストリクエストを受け付けて順番に処理したい」→ SQS 非同期統合
- 「バックエンド障害時にリクエストを取りこぼしたくない」→ SQS 非同期統合
- 「API GW から Lambda を介さず直接 SQS に送りたい（Lambda コールドスタートも回避）」→ REST API の AWS サービス統合
7. REST API vs HTTP API 詳細比較
SAA でよく問われる「コストと機能のトレードオフ」をさらに詳しく整理する。
コスト比較（東京リージョン）
| 項目 | REST API | HTTP API |
|---|---|---|
| 百万リクエスト当たり | $3.50 | $1.00 |
| キャッシュ（0.5GB/時間） | 別途課金 | 非対応 |
| データ転送 | 同一（AWS 標準） | 同一（AWS 標準） |
エンドポイントタイプ（REST API のみ）
REST API には3種類のエンドポイントタイプがある（HTTP API は Regional のみ）：
| タイプ | 説明 | SAA でのシナリオ |
|---|---|---|
| Edge-Optimized | CloudFront のエッジから配信（デフォルト） | グローバルクライアントへの低レイテンシ配信 |
| Regional | デプロイリージョンから直接配信 | クライアントと同じリージョン内で使う場合 |
| Private | VPC 内のみに公開（Internet GW 不要） | 社内 API・プライベートマイクロサービス間通信 |
8. セキュリティと認証の選択
認証・認可の4方式
| 認証方式 | 適合 API タイプ | 典型的なシナリオ |
|---|---|---|
| IAM 認証（AWS_IAM） | REST API・HTTP API | AWS サービス間・AWS SDK を使うクライアント |
| Cognito ユーザープール | REST API（オーソライザー経由）・HTTP API（JWT） | エンドユーザーのサインイン・サインアップ管理 |
| Lambda オーソライザー | REST API・HTTP API | 独自トークン・社内 IdP・OAuth 2.0 カスタム検証 |
| API キー | REST API のみ | サードパーティ開発者への API 公開・使用量制限 |
WAF との統合
WAF 統合パターン：
パターン A（REST API への直接アタッチ）：
クライアント → WAF WebACL → API Gateway REST API
パターン B（HTTP API には CloudFront 経由）：
クライアント → CloudFront + WAF WebACL → HTTP API
※ REST API には WAF を直接アタッチできる。
※ HTTP API には WAF を直接アタッチできないため CloudFront を前段に置く。9. スロットリング・キャッシュ・モニタリング
スロットリング（リクエスト数制限）
| スロットリングレベル | 対象 | 設定単位 |
|---|---|---|
| アカウントレベル | AWS アカウント全体 | デフォルト 10,000 RPS・バースト 5,000 |
| ステージレベル | 特定の API ステージ全体 | ステージ設定で上書き |
| メソッドレベル | 特定の HTTP メソッド | メソッドスロットリングで細かく制御 |
| 使用量プラン | API キーごと | 1日・1週・1月の制限を設定 |
キャッシュ（REST API のみ）
REST API ステージキャッシュ：
クライアント ──▶ API GW ──▶ キャッシュヒット → キャッシュから返す（Lambda 非呼び出し）
└── キャッシュミス → Lambda を呼び出して結果をキャッシュに保存
└── TTL 秒後にキャッシュ失効- キャッシュ容量：0.5GB〜237GB
- TTL：デフォルト 300 秒（0〜3600 秒）
- クライアントから
Cache-Control: max-age=0ヘッダーで無効化可能（無効化権限の IAM 制御あり）
モニタリング
- CloudWatch メトリクス：
Count（リクエスト数）/Latency（レイテンシ）/4XXError・5XXError/CacheHitCount・CacheMissCount - X-Ray：Lambda との連携でエンドツーエンドトレーシング
- CloudWatch Logs：アクセスログ（カスタム形式）・実行ログ（詳細デバッグ）
10. 要件キーワード早見表
| 要件キーワード | 選ぶパターン | 根拠 |
|---|---|---|
| 「双方向リアルタイム通信・チャット・プッシュ通知」 | WebSocket API | REST/HTTP は単方向 |
| 「バーストリクエストをキューで吸収・非同期処理」 | REST API + SQS | 受付と処理のデカップリング |
| 「API キー・使用量プランで利用制限」 | REST API | HTTP API は API キー非対応 |
| 「マッピングテンプレート・リクエスト変換」 | REST API | HTTP API は VTL 非対応 |
| 「コスト削減・シンプルな Lambda プロキシ」 | HTTP API | 最大 71% 安い |
| 「JWT/OIDC 認証を手軽に設定したい」 | HTTP API | JWT オーソライザーがネイティブ |
| 「WAF を API GW に直接アタッチしたい」 | REST API | HTTP API は直接アタッチ不可 |
| 「ステージキャッシュで DB クエリを減らしたい」 | REST API | HTTP API はキャッシュ非対応 |
| 「プライベート VPC 内のみ公開したい」 | REST API Private エンドポイント | HTTP API は Regional のみ |
| 「Lambda コールドスタートを回避して SQS に送りたい」 | REST API + SQS 直接統合 | Lambda を介さない統合 |
11. 頻出ひっかけパターンと正しい打ち手
ひっかけ1：「HTTP API でも API キーが使える」（誤）
「コスト削減のために HTTP API を使い、API キーでアクセスを制限したい」
正しい打ち手：REST API を選ぶ。HTTP API は API キーと使用量プランに非対応。コスト削減より機能要件が優先される。
ひっかけ2：「Lambda オーソライザーがあれば HTTP API で JWT 検証できる」（部分的に正しいが非効率）
「HTTP API で Lambda オーソライザーを書いて JWT を手動検証したい」
正しい打ち手：HTTP API の JWT オーソライザー（ネイティブ）を使う。Lambda を書かなくても JWT/OIDC をコンソール設定だけで検証できる。Lambda オーソライザーは独自トークン・独自ロジックが必要なときだけ書く。
ひっかけ3：「WebSocket でもリクエスト数が増えたらポーリングに切り替えるべき」（誤）
「WebSocket はサーバー側の接続維持コストが高いから、ユーザーが増えたらポーリングに戻すべきだ」
正しい打ち手：WebSocket API はフルマネージドで接続管理をスケールアウトできる。EC2 でゼロから WebSocket サーバーを建てる話とは異なり、API GW の WebSocket API は接続数に応じて自動スケールする。
ひっかけ4：「API GW → SQS は Lambda 経由でないと設定できない」（誤）
「API GW から SQS にメッセージを送るには Lambda を仲介させる必要がある」
正しい打ち手：REST API の AWS サービス統合で Lambda なしに直接 SQS SendMessage を呼べる。ただし HTTP API では不可なので REST API が前提。
ひっかけ5：「Edge-Optimized エンドポイントは HTTP API にもある」（誤）
「HTTP API でも Edge-Optimized エンドポイントを選んでグローバル配信できる」
正しい打ち手：HTTP API は Regional エンドポイントのみ。グローバル配信したい場合は CloudFront を前段に置く。
12. 次のアクション チェックリスト
13. 関連記事
- SAA Lambda/サーバーレス設計パターン
- SAA SQS/SNS/EventBridge 設計パターン
- SAA VPC 設計パターン10選
- SAA ネットワークセキュリティ設計パターン4選
- Amazon API Gateway 完全ガイド
- Amazon SQS 完全ガイド
- AWS Lambda 完全ガイド