先に要点
- ALB / API Gateway / CloudFront はどれも 「前段に立てる AWS サービス」 だが、役割の主軸が違う。ALB は VPC 内の L7 ロードバランサ、API Gateway は API 専用のフロントドア(認証・流量制御・スキーマ)、CloudFront は 世界配信 + 防御 + 料金最適化を兼ねた CDN。
- 排他関係ではなく、CloudFront → ALB / API Gateway → アプリ のように 重ねて使う のが標準。「どれを選ぶか」 より 「どの順番で並べるか」 を意識すると設計が決まりやすい。
- 判断軸: 配信高速化と DDoS 防御が要るか(CloudFront)」 「通常の Web アプリ・社内システム(ALB)」 `公開 API・認証/流量制御が必要(API Gateway)。Lambda メインなら API Gateway、コンテナや EC2 メインなら ALB が素直。
- 料金構造もまるで違う。ALB は 時間料金 + LCU(処理量)、API Gateway は リクエスト課金、CloudFront は 下り転送 + リクエスト課金。「小規模だが常時起動」 は ALB が高くつくこともあり、トラフィックパターンで選び方が変わる。
- 「迷ったら CloudFront を最前段に置き、その後段で ALB か API Gateway を選ぶ」 が現代の AWS の定番。小規模 Web の AWS 構成パターン とも整合する。
「AWS の構成図を書こうとしたら、ALB と API Gateway と CloudFront の役割が混ざってわからなくなった」 ── これは AWS をある程度触り始めた人ほどよくぶつかる壁です。
3つとも 「前段(フロントドア)に立つ AWS サービス」 という点では共通していますが、担当する仕事は違います。さらに 「どれか1つ選ぶ」 ではなく 「重ねて使う」 ことも多いため、「比較」 だけでなく 「組み合わせ」 を理解するのが実務的です。
この記事では、3つの役割と判断軸、典型構成、料金感を整理します。CloudFront 単体については Amazon CloudFront とは？AWS の CDN の仕組みと使いどころ と API Gateway とは？Lambda の前段で何をしているのか も併読してください。
まず役割を一言で押さえる
3者の主軸を一言で言うとこうなります。
| サービス | 主軸 | 得意分野 | 後ろに置く典型 |
|---|---|---|---|
| ALB (Application Load Balancer) | L7 ロードバランサ | VPC 内に立てた EC2 / ECS / EKS / Fargate を HTTP/HTTPS で分散。パスや Host ヘッダでルーティング | EC2、ECS、Fargate、Lambda、EKS |
| API Gateway | API のフロントドア | 認証(IAM / Cognito / Lambda Authorizer)、流量制御、リクエスト/レスポンス変換、API キー、Usage Plan、スキーマ を一括提供 | Lambda、HTTP バックエンド、VPC リンク経由の ALB |
| CloudFront | CDN + 防御 + 料金最適化 | 世界各地のエッジで キャッシュ・WAF・TLS 終端・オリジン秘匿 をまとめて担当 | S3、ALB、API Gateway、独自オリジン |
ここで重要なのは 「 後ろに置く典型」 の列。CloudFront は 「ALB や API Gateway の前にも立てる」 のが普通で、3者は 同じレイヤで競合しているわけではない と気付くと、構成図を書きやすくなります。
典型構成 — 「どの順番で並べるか」
実務でよく使う構成パターンを4つに分けます。
① CloudFront → ALB → ECS / EC2
「 通常の Web アプリ / 社内 SaaS / Laravel / Rails」 の標準構成。CloudFront でキャッシュ・TLS・WAF を担当し、ALB が VPC 内の複数 EC2 / コンテナ に分散。「まず迷ったらこれ」 という基準構成。
② CloudFront → API Gateway → Lambda
「 サーバレス API / バックエンド API / Webhook 受け口」 の典型。API Gateway が認証・流量制御を、Lambda がビジネスロジックを担当。CloudFront を前段に置くと WAF / カスタムドメイン / キャッシュ が乗る。
③ CloudFront → S3
「 静的サイト / SPA / Next.js export / ドキュメント配信」 の構成。アプリケーションロジックは不要で、ストレージから直接配信。OAC で S3 を秘匿し、CloudFront からだけ読めるようにする。S3 公開設定の事故 を防ぐ意味でも標準形。
「CloudFront を入れない選択肢もある」 のは確かですが、公開 Web では CloudFront を最前段にするのが現代の AWS 標準 と覚えておくと迷いが減ります。
判断軸 — どれをどう使い分けるか
「3つ全部を入れるべきか」 「1つで済むケースは?」 を判断するための観点を整理します。
迷ったときの一番安全な判断は次のとおりです。
迷ったら CloudFront を最前段
「 何を後ろに置くか」 は要件で変わるが、CloudFront を最前段に置くこと自体は外しにくい選択。WAF・TLS・キャッシュ・ドメインがまとめて整い、後から構成変更しても URL が変わらない。
後段は 「何が動くか」 で決まる
「 EC2 / コンテナで動く Web アプリ」 なら ALB、「Lambda で動く API」 なら API Gateway、「静的ファイル配信」 なら S3。後段は実行基盤で素直に決まる。
小規模なら省略してよい場合もある
「 検証用 / 社内のみ / API トラフィックが極小」 なら、ALB だけ・API Gateway だけ・直接 Lambda URL も選択肢。過剰な構成は運用・料金の両面で重い。
国際展開・DDoS リスクが見えたら CloudFront 必須
「 海外アクセス比率が増えた」 「B2C で誰でも触れる」 「攻撃を受けたことがある」 ようなフェーズに入ったら、後付けでもいいので CloudFront を必ず最前段に挟む。「AWS Shield Standard」 が自動で効くだけでも価値が大きい。
料金構造の違い
3者は料金の取り方も違います。「どのトラフィックパターンで安いか」 を理解すると無駄な構成を避けられます。
| サービス | 主な課金軸 | 常時アクセスが少ない場合 | 大量トラフィックの場合 |
|---|---|---|---|
| ALB | 時間料金 + LCU(処理量) | 固定費が発生(アクセス0でも月額) | LCU 料金は比較的安定 |
| API Gateway | リクエスト課金 + データ転送 | 使わない分は0円(理想的) | リクエストが伸びるとリニアに増える |
| CloudFront | 下り転送 + リクエスト + (オプション WAF/Lambda@Edge) | 無料枠 1TB / 1,000万 req まで | キャッシュヒット率次第。ヒット率高ければ S3 直接より安くなる |
小規模 API は API Gateway + Lambda が圧倒的に安い
「 月のリクエストが数千〜数万」 程度なら、ALB を常時起動させるより API Gateway + Lambda の方が大幅に安い。ALB は アクセスが無くても時間料金が発生 するため、検証用や個人開発の小規模 API には重い。
大量トラフィックの常時 API は ALB が安定
「 高頻度・長時間接続・WebSocket・gRPC」 のような構成では、ALB + ECS / EC2 のほうが料金もパフォーマンスも安定する。API Gateway は 1リクエスト単価が ALB より高い ので、桁が増えると効いてくる。
ALB vs API Gateway — 「どちらでも作れる API」 のとき
「Lambda の前に ALB を立てるか、API Gateway を立てるか」 は実務でよく聞かれる比較です。実は ALB でも Lambda をターゲットにできるため、選択肢が2つに見えます。
API Gateway を選ぶ場面
「 認証(Cognito)、API キー、Usage Plan、スキーマ検証、リクエスト/レスポンス変換、Throttling」 を仕組みとして欲しい場合。API として最初から設計されたサービス なので、機能の網羅性が高い。
ALB を選ぶ場面
「 既に ALB がある」 「常時アクセスが多くて Pay-per-request だと高くなる」 「WebSocket / gRPC を扱う」 場合。ALB は時間料金型なので、リクエスト単価は API Gateway より安い。
CloudFront を被せれば共通化できる
どちらを選んでも、前段に CloudFront を立てれば WAF / TLS / カスタムドメインは共通。「後から API Gateway → ALB に切り替える」 ような移行も、CloudFront 経由なら URL を変えずに済む。
迷ったら API Gateway から始める
「 初期構築の楽さ」 と 「小規模時の料金」 で API Gateway が有利な場面が多い。スケールしてから ALB へ」 のリプレースは比較的安全。
落とし穴と再発防止メモ
3者を組み合わせるときによくあるトラブルを整理しておきます。
CloudFront のキャッシュで API が古いまま
「 API レスポンスをキャッシュさせない設定にし忘れる」 と、認証系で他人の情報を返す事故になる。/api/* ビヘイビアはキャッシュなし を明示する。
ALB と API Gateway のタイムアウトの違い
ALB の アイドルタイムアウト(デフォルト 60 秒) と API Gateway の 統合タイムアウト(最大 29 秒) は仕様が違う。「Lambda が 30 秒以上動く」 ような処理を API Gateway 経由で実行できない罠がある。
CloudFront 経由のヘッダ転送設定
「 認証用ヘッダ (Authorization) が後段に届かない」 トラブル。CloudFront のキャッシュポリシー / オリジンリクエストポリシーで 必要なヘッダを明示的に転送する設定 が必要。
「 ALB から ECS へのセキュリティグループが閉じている」 「API Gateway → VPC リンクの設定漏れ」 など、構成図上は繋がっているのに通信が通らない パターンが多い。疎通確認は段階的に行う。
ALB vs API Gateway vs CloudFront に関するよくある質問
Q. 3つ全部入れないとダメですか?
A. 必須ではありません。「Lambda 直接呼び出し」 「ALB だけ」 「API Gateway だけ」 でも動きます。ただ 公開する Web / API では CloudFront を最前段に置く のが現代の AWS では標準です。「WAF・TLS・カスタムドメイン・キャッシュ」 を別途用意するより、CloudFront 経由でまとめる方が楽で安全。
Q. ALB と CloudFront はどう違いますか?
A. 役割のレイヤが違います。ALB は VPC 内の L7 負荷分散 でリージョン内に閉じています。CloudFront は 世界各地のエッジで配信・防御・キャッシュ を担当する CDN。「CloudFront → ALB → コンテナ」 のように 重ねて使う のが普通で、「どちらを選ぶか」 ではなく 「どちらも置く」 のが標準構成。
Q. API Gateway と CloudFront は被りませんか?
A. 役割が違うので被りません。API Gateway は API 専用の認証・流量制御・変換、CloudFront は CDN・WAF・TLS。「CloudFront → API Gateway → Lambda」 と並べると、世界配信は CloudFront、API 機能は API Gateway、ビジネスロジックは Lambda と責任が分かれて綺麗に整理できます。
Q. ALB の代わりに NLB を使うべき場面は?
A. NLB(Network Load Balancer) は L4 (TCP/UDP) ロードバランサ で、「超低レイテンシ」 「静的 IP が必要」 「非 HTTP プロトコル」 のときに選びます。「 通常の Web/API なら ALB」 が無難で、NLB は SSL 終端を自前でやりたい」 `LB を経由するが何でも通したい といった特殊な要件で選ぶイメージです。
Q. CloudFront を入れると遅くなることはありますか?
A. キャッシュ設定が甘いと遅くなることはあります。「キャッシュキーにヘッダや Cookie を入れすぎる」 と、「同じコンテンツでもキャッシュキーがバラバラ」 になりヒット率が下がります。「Lambda@Edge で重い処理を毎回走らせる」 のも遅延の元です。キャッシュヒット率 80% 以上 を最初の目標にすると、CloudFront のメリットを取り損ねません。
Q. API Gateway は REST と HTTP API のどちらを選ぶべき?
A. 新規は基本的に HTTP API がおすすめです。「料金が REST の約 1/3」 「レイテンシも低い」 「JWT 認証を組み込みで使える」。` REST API しか持ってない機能(API キー、Usage Plan、リクエスト検証、変換、WAF 連携の一部)が必要なら REST API、それ以外は HTTP API、で考えると整理しやすいです。
Q. オンプレや他クラウドのバックエンドを前段で受けられますか?
A. 3つとも受けられます。CloudFront はカスタムオリジンとして任意の HTTPS エンドポイントを指定可能、ALB の IP ターゲットタイプ でオンプレ IP を直接指定可能、API Gateway は HTTP 統合 で外部 URL を呼べます。「AWS で前段だけ立てて、後段はオンプレや他社クラウド」 という構成も現実的に組めます。
まとめ
ALB / API Gateway / CloudFront は 役割が違うので排他関係ではなく、重ねて使う のが現代の AWS の標準です。「どれを選ぶか」 より 「どの順番で並べるか」 を意識すると、構成図がスッと組み立てられるようになります。
迷ったら CloudFront を最前段、後段はアプリの実行基盤で選ぶ を基準にしてください。「EC2 / コンテナ → ALB」 「Lambda → API Gateway」 「S3 → 直接 CloudFront」 が素直な対応です。
参考リンク
- AWS: Application Load Balancer
- AWS: Amazon API Gateway
- AWS: Amazon CloudFront
- AWS Docs: API Gateway REST API vs HTTP API
- AWS Architecture Blog: Front Door patterns on AWS