AWS ソリューションアーキテクト – アソシエイト学習サイト CP 学習サイトへ戻る

Amazon API Gateway

Amazon API Gateway は、アプリやブラウザから呼び出される API（Application Programming Interface: プログラム同士の窓口）の「入口」をフルマネージドで用意するサービスです。SAA では、Lambda と組み合わせたサーバーレス構成、認可、スロットリング、キャッシュの選び方がよく問われます。

ひとことで言うと: API Gateway は「バックエンドの前に立つ受付窓口」です。

たとえるなら、ビルの受付です。来訪者の身元を確認し（認可）、混雑時は入場を制限し（スロットリング）、よくある質問にはその場で答え（キャッシュ）、それ以外を担当部署（Lambda や EC2）へ取り次ぎます。

このページで押さえる論点

API Gateway の役割と統合先

Web アプリやスマホアプリは、HTTPS で API を呼び出してデータを取得・更新します。API Gateway はこの API の入口をマネージドで提供し、受け取ったリクエストを後ろのシステム（バックエンド）へ渡します。バックエンドへ渡す設定を統合と呼び、主な統合先は次のとおりです。

SAA の試験ガイドでは「API の作成と管理（Amazon API Gateway、REST API など）」「サーバーレステクノロジーとパターン」が疎結合アーキテクチャの知識として挙がっています。API Gateway はリクエスト数に応じて自動でスケールし、使った分だけ支払うため、アクセス数の変動が大きい API をサーバー管理なしで公開したい要件に向きます。

再生型アニメ図解

リクエストが API Gateway を通る流れ

利用者 API Gateway ① 認可 ② 流量制限 ③ キャッシュ Lambda ✓ 200 応答 ✓ 呼ばない ✕ 429 応答 ✕ 401/403

※簡略化しています: 実際の処理順序や、リクエストの検証・変換、ログ出力などは省略しています。キャッシュは REST API だけの機能です（「3 種類の API」参照）。

REST API・HTTP API・WebSocket API

API Gateway で作れる API には 3 種類あります。試験では「要件に必要な機能がどの種類にあるか」で選ばせる問題が出ます。

種類特徴選ぶ場面
REST API機能が最も多い。API キー・使用量プラン、AWS WAF、API キャッシュ、リクエスト検証、リソースポリシー、エッジ最適化・プライベートエンドポイント、Canary リリース、X-Ray トレースに対応クライアントごとの利用制限、WAF での保護、キャッシュ、VPC 内だけで使う API が必要
HTTP API機能を絞った分、低コスト・低レイテンシー。JWT オーソライザー、自動デプロイに対応Lambda や HTTP バックエンドへの単純な中継で足り、コストを下げたい
WebSocket API接続を張ったままにして、クライアントとサーバーの双方向でメッセージを送れるチャット、リアルタイムの通知、対戦ゲーム、ダッシュボードの即時更新

REST API と HTTP API はどちらも「リクエストが来たら応答を返す」方式です。サーバー側から任意のタイミングでクライアントへ知らせたいときは WebSocket API を選びます。

比較・選択フローチャート

質問に答えて API の種類を選ぶ

作りたい API の要件を思い浮かべて「はい / いいえ」で答えてください。答えた経路が上から順に表示されます。

    ※簡略化しています: 代表的な判断基準だけを分岐にしています。リクエスト検証、Canary リリース、X-Ray トレースなど、REST API だけにあるほかの機能は上の表で確認してください。

    エンドポイントタイプ

    REST API では、API の入口をどこに置くかを 3 つから選びます。

    タイプ仕組み選ぶ場面
    エッジ最適化世界中の CloudFront のエッジロケーションを経由してリクエストを受ける世界各地に利用者がいる公開 API
    リージョン特定のリージョンで直接受ける同じリージョンの利用者やサーバーから呼ばれる API。自前の CloudFront ディストリビューションと組み合わせたい
    プライベートVPC のインターフェイス VPC エンドポイント経由でのみアクセスできるインターネットに公開せず、VPC 内（または VPN・Direct Connect の先）からだけ使う社内 API

    プライベート API では、どの VPC・VPC エンドポイントからの呼び出しを許すかをリソースポリシーで指定します。VPC エンドポイントの詳細は「VPC の接続」ページで扱っています。

    認可とセキュリティ

    API を「誰が呼び出してよいか」を決める仕組み（認可）は、呼び出し元の種類で選びます。

    方式仕組み向いている呼び出し元
    IAM 認可リクエストに IAM の認証情報で署名（署名バージョン 4）し、IAM ポリシーで許可を判断AWS 内のサービスや、IAM ロールを持つアプリ
    Amazon Cognito ユーザープール オーソライザーCognito でサインインした利用者のトークンを検証（REST API）一般の利用者がサインインして使う Web・モバイルアプリ
    JWT オーソライザーCognito などが発行した JWT（JSON Web Token）を検証（HTTP API）HTTP API を OIDC・OAuth 2.0 の ID 基盤で保護する
    Lambda オーソライザー自作の Lambda 関数でトークンやヘッダーを検証し、許可・拒否を返す独自の認証方式や外部の ID 基盤を使いたい
    リソースポリシーAPI 側に付ける JSON ポリシーで、呼び出し元の AWS アカウント・IP アドレス範囲・VPC を制限（REST API）特定の IP や VPC、別アカウントからだけ許可したい

    SQL インジェクションやクロスサイトスクリプティングなど、Web アプリへの一般的な攻撃を防ぐには、REST API の前段に AWS WAF を関連付けます。API キーは利用状況を識別するためのもので、認可の仕組みとしては使わないよう AWS は案内しています。API キーは「誰がどれだけ使ったか」の把握と使用量プランに使い、アクセス制御は上の表の方式で行います。

    CloudFront やほかのドメインのブラウザアプリから呼び出す場合は、CORS（Cross-Origin Resource Sharing: 別ドメインからの呼び出しをブラウザに許可する仕組み）を API で有効にする必要があります。

    スロットリング・使用量プラン・キャッシュ

    スロットリング（流量制限）

    API Gateway は、リクエストが多すぎるときに受け付けを制限して、バックエンドを守ります。これをスロットリングと呼び、制限を超えたリクエストには 429 Too Many Requests を返します。制限はトークンバケットという方式で、「毎秒のリクエスト数（レート）」と「一時的に受け止められる量（バースト）」の 2 つの値で決まります。

    試験ガイドのコスト最適化分野には「適切なスロットリング戦略を選択する」が挙がっています。後段のデータベースが一定以上の負荷に耐えられないとき、API Gateway でスロットリングをかけるか、SQS を挟んで平準化する（「SQS と SNS」参照）のが定番の答えです。

    API キャッシュ（REST API）

    ステージでキャッシュを有効にすると、同じリクエストへの応答を一定時間保存し、バックエンドを呼ばずに返します。レイテンシーが下がり、Lambda や DB の負荷とコストも下がります。キャッシュの有効期間（TTL）は既定 300 秒、0〜3,600 秒の範囲で設定できます。キャッシュは容量に応じた時間単位の料金がかかる点も覚えておきます。

    上限値と、長い処理・大きなデータの扱い方

    項目値（REST API）試験での使いどころ
    統合のタイムアウト50 ミリ秒〜29 秒。リージョン・プライベート API は引き上げ申請可能、エッジ最適化 API は不可長い処理は同期で待たせず、非同期（SQS や Step Functions に渡して結果は後で取得）にする
    ペイロードサイズ10 MB（引き上げ不可）大きなファイルは API Gateway を通さず、S3 の署名付き URL で直接アップロードさせる
    アカウントのスロットリング毎秒 10,000 リクエスト、バースト 5,000（ほとんどのリージョン。引き上げ可能）超えると 429。急増が予想されるなら事前に引き上げ申請
    キャッシュの TTL既定 300 秒、最大 3,600 秒変化の少ないデータの応答を速くし、バックエンドの負荷を下げる
    キャッシュできる応答サイズ1 MB大きな応答はキャッシュされない

    「動画ファイルを API 経由でアップロードすると失敗する」なら、10 MB の上限が原因です。「処理に数分かかる API がタイムアウトする」なら、29 秒の統合タイムアウトが原因です。どちらも API Gateway の設定を変えるより、構成を変える（S3 への直接アップロード、非同期処理）のが正解になりやすい問題です。

    問題文のキーワード → 選ぶべき答え

    問題文の言い回し選ぶべき答えと理由
    「サーバーを管理せずに REST API を公開」「アクセス数の変動が大きい」API Gateway + Lambda。自動でスケールし、使った分だけの料金
    「顧客ごとに API の利用回数を制限したい」「API を有料で提供」API キー + 使用量プラン（REST API）
    「API に SQL インジェクション対策をしたい」REST API に AWS WAF を関連付け。HTTP API は WAF 非対応
    「同じ内容の問い合わせが多く、バックエンドの負荷を下げたい」API キャッシュ（REST API、TTL 既定 300 秒）
    「チャット」「サーバーからクライアントへリアルタイムに通知」WebSocket API
    「最小のコストで Lambda の前に API を置きたい」「JWT で認可」HTTP API
    「VPC の中からだけ呼び出せる API」プライベート API（インターフェイス VPC エンドポイント + リソースポリシー）
    「世界中の利用者に低レイテンシーで API を提供」エッジ最適化エンドポイント
    「Cognito でサインインした利用者だけに API を使わせたい」Cognito ユーザープール オーソライザー
    「独自のトークン形式で認証したい」Lambda オーソライザー
    「急なアクセス増で 429 エラーが返る」スロットリングの上限に達している。上限の引き上げ、キャッシュ、クライアント側の指数バックオフ再試行
    「大きなファイルのアップロードが失敗する」ペイロード上限 10 MB。S3 の署名付き URL で直接アップロード

    引っかけポイント

    まとめ: SAA 試験で押さえるポイント

    確認問題

    参考リンク

    AWS 公式ドキュメント（外部サイトが開きます）。本文の数値はこれらで確認しています。