本文へスキップ
BecomeCoder

AWS SAP（ソリューションアーキテクト プロフェッショナル）コース　·　第5章　新規ソリューションの設計①：コンピューティングと疎結合　·　レッスン28

スケーラブルなAPIとエッジ ― API Gateway / CloudFront / Global Accelerator

導入

利用者に近い場所でリクエストを受け止め、賢く裁いてからバックエンドに届ける。この「エッジでの制御」を担う3つのサービスは、名前が似た役割に見えて実は担当領域が違います。SAPでは、この使い分けを問う問題が頻出します。

説明

flowchart LR
    U["利用者"] --> CF["CloudFront<br/>静的コンテンツのキャッシュ配信"]
    U --> GA["Global Accelerator<br/>最適経路への振り分け"]
    CF --> APIGW["API Gateway<br/>APIの受付・認証・スロットリング"]
    GA --> APIGW
    APIGW --> BE["バックエンド<br/>（Lambda/ECS/EC2）"]
サービス担当領域得意なこと
API GatewayAPIの「入口」そのもの認証（IAM/Cognito/Lambda Authorizer）、スロットリング、リクエスト変換、Lambda統合
CloudFrontコンテンツ配信のキャッシュ層静的アセット・APIレスポンスのエッジキャッシュ、DDoS緩和、TLS終端
AWS Global Acceleratorネットワーク層の経路最適化AnycastIPで最寄りのAWSエッジへ誘導、TCP/UDP含む非HTTPプロトコルにも対応、高速フェイルオーバー

3つとも「利用者に近いところで裁く」点は共通ですが、CloudFrontはキャッシュできるコンテンツの配信が主目的、Global Acceleratorはキャッシュできないリアルタイム通信の経路最適化が主目的という違いがあります。API Gatewayはそもそも配信網ではなく、APIリクエストの受付窓口（認証・流量制御・変換）です。

  • 「静的コンテンツ＋動的APIの両方を高速配信したい」→ CloudFront
  • 「オンラインゲーム・VoIPなどTCP/UDPで低レイテンシーが必須」→ Global Accelerator
  • 「APIキーごとにリクエスト数を制限したい」「Lambdaと統合したAPIを素早く公開したい」→ API Gateway

具体例

グローバル展開するサービスの3つのニーズを、3サービスに割り当てます。担当領域が違うので、実は併用されます。

  • モバイルアプリのバックエンドAPIを、認証と流量制限つきで公開したい → API Gateway … 「無料プランは1秒10回まで」といったAPIキーごとのスロットリング、Cognito認証、Lambda統合が最初から備わる。
  • 画像やJS/CSSなど静的アセットを世界中に高速配信したい → CloudFront … キャッシュ可能なコンテンツをエッジから配信。API Gatewayの前段に置いてAPIレスポンスをキャッシュすることも。
  • オンライン対戦の低遅延通信（UDP）を最適経路で届けたい → Global Accelerator … キャッシュできない動的通信を、AnycastIPで最寄りのAWSエッジへ誘導。固定IPと高速フェイルオーバーも。

最大の判断軸は「キャッシュできるか」。動画・画像・静的サイトはCloudFront、キャッシュが効かないゲーム・VoIPはGlobal Accelerator、APIの受付窓口はAPI Gateway。「利用者の近くで裁く」点は共通でも、担当が違うと押さえます。

読んでみよう

「CloudFrontとGlobal Acceleratorのどちらを使うべきか」という設問は、キャッシュ可能かどうかが最大の判断軸です。動画配信・画像配信・静的サイトはCloudFront、リアルタイム性が命でキャッシュが効かないゲームサーバーやIP固定が必要な通信はGlobal Accelerator、と対応づけて覚えておきましょう。

次のレッスンへ →