APIゲートウェイ・ロードバランサー・リバースプロキシの違いとは？クラウド設計でよく混同される3コンポーネントを整理する実践ガイド

オンプレ環境でNginxやHAProxyを使っていたエンジニアがクラウド設計に取り組むと、必ず迷う場面がある。「Application GatewayとAPI ManagementとLoad Balancerのどれを選ぶべきか」「ALBだけで十分か、API Gatewayも必要か」という問いだ。

この3コンポーネント──リバースプロキシ・ロードバランサー・APIゲートウェイ──はいずれも「リクエストを受け取って転送する」という外見上の動作が共通しているため混同されやすい。だが担う責務と動作レイヤーは明確に異なる。

本記事では、オンプレ経験者が直感的に理解できるよう3つの違いを構造から整理し、AWS・Azureでの実装対応と実務での使い分け判断基準を解説する。

まず「動作レイヤー」で整理する

3コンポーネントの違いは、どのOSIレイヤーで何を見て転送を決めるかで大きく分類できる。

L4ロードバランサーはTCPレベルで動作し、HTTPの中身を解釈しない。宛先IPとポートだけで転送先を決める。L7ロードバランサー（リバースプロキシ）はHTTPを理解し、URLパスやホスト名でバックエンドを振り分けられる。

APIゲートウェイはL7の延長線上にあるが、「振り分け」にとどまらず、認証・認可・レート制限・ログ収集・プロトコル変換などAPI管理に特化した機能を提供する点が本質的に異なる。

リバースプロキシとは何か

リバースプロキシはクライアントとバックエンドサーバーの間に立ち、クライアントからのリクエストを代理受信してバックエンドに転送するコンポーネントだ。オンプレ環境ではNginxやApache（mod_proxy）がこの役割を担うことが多かった。

主な役割はこれだ。
・SSL終端（TLSオフロード）: クライアントとの暗号化通信を終端し、バックエンドへはHTTPで転送してバックエンドの処理負荷を下げる
・キャッシュ: 静的コンテンツやAPIレスポンスをキャッシュして応答速度を改善する
・URLルーティング: パスやホスト名によって複数のバックエンドに振り分ける
・圧縮: レスポンスをgzip圧縮してクライアントへ返す
・ヘッダー操作: X-Forwarded-For等のヘッダーを付与・変換する

リバースプロキシとL7ロードバランサーはほぼ同義に使われることが多いが、「複数バックエンドへの均等分散」に特化した文脈ではロードバランサーと呼ばれる。

ロードバランサーとは何か

ロードバランサーは複数のバックエンドサーバーにトラフィックを分散させて可用性とスループットを高めるコンポーネントだ。L4とL7の2種類がある。

1. L4ロードバランサー（トランスポート層）

IPアドレスとTCP/UDPポートだけを見て転送先を決める。HTTPの中身は解釈しない。超低レイテンシが必要な場面や非HTTP/HTTPS（SMTP、FTP、カスタムTCPプロトコル）の分散に向いている。

AWSではNetwork Load Balancer（NLB）がL4動作に相当する。AzureではAzure Load BalancerがL4対応だ。

2. L7ロードバランサー（アプリケーション層）

HTTPリクエストのURL・ホスト名・Cookieなどを解釈して転送先を決める。コンテンツベースルーティング（パスで転送先を切り替える）やホストベースルーティングが可能で、WebアプリケーションのほとんどはL7を使う。

AWSではApplication Load Balancer（ALB）がL7対応の主力だ。ALBとNLBの詳細比較・使い分けについては別記事で詳しく解説している。

AzureではAzure Application GatewayがL7ロードバランサー兼リバースプロキシの役割を担い、WAFオプションも統合できる。Azure Load Balancer vs Application Gatewayの違いも参考にしてほしい。

# AWS ALBのパスベースルーティング確認（AWS CLI）
# /api/* → API用ターゲットグループ
# /static/* → 静的コンテンツ用ターゲットグループ
aws elbv2 describe-rules \
  --listener-arn arn:aws:elasticloadbalancing:ap-northeast-1:ACCOUNT_ID:listener/app/my-alb/xxx/yyy \
  --query 'Rules[*].{Priority:Priority,Conditions:Conditions,Actions:Actions}'

APIゲートウェイとは何か

APIゲートウェイはリバースプロキシやL7ロードバランサーと同じL7で動作するが、本質的な違いは「API管理機能の集約」にある。

リバースプロキシが「URLを見てどこに転送するか」を担うのに対し、APIゲートウェイは「誰が・何を・どのくらいの頻度でリクエストできるかを制御した上で転送する」という責務を持つ。

APIゲートウェイが提供する主な機能はこれだ。
・認証・認可: APIキー検証、JWT/OAuth2トークン検証、IAM認証など
・レート制限（スロットリング）: 1秒あたり・1分あたりのリクエスト数を制限して過負荷を防ぐ
・リクエスト/レスポンス変換: クライアントが送るJSONをバックエンドが期待するXMLに変換するなど
・バージョニング: /v1/usersと/v2/usersを別バックエンドにルーティングするAPIバージョン管理
・ログ・モニタリング: APIごとのリクエスト数・レイテンシ・エラー率を収集する
・プロトコル変換: HTTPSからgRPCに変換するなど、クライアントとバックエンドのプロトコルを橋渡しする
・カナリアデプロイ: 新バージョンのAPIに一部トラフィックを流してA/Bテストする

マイクロサービスアーキテクチャでは、多数のバックエンドサービスへのAPIを一元管理する「APIゲートウェイパターン」が広く使われる。クライアントは単一のエンドポイントと通信し、内部の複雑さを隠蔽できる。

また、BFF（Backend for Frontend）パターンでは、フロントエンド種別ごとに最適化されたAPIゲートウェイを設けるアーキテクチャも用いられる。

AWS・Azureでの実装対応表

サービスメッシュはコンテナ間通信を制御するコンポーネントで、上記3つとは守備範囲が異なる。詳しくはサービスメッシュ（Istio・AWS App Mesh・Linkerd）の比較を参照してほしい。

ALBとAmazon API Gatewayの使い分け

AWSを使い始めたエンジニアが最も迷うのが「ALBだけでいいのか、API Gatewayも立てるべきか」だ。判断の目安はこうなる。

ALBだけで十分なケース:
・内部マイクロサービス間通信: 同一VPC内でコンテナ間のHTTPルーティングをするだけならALBで足りる
・Webアプリのロードバランシング: ユーザー向けWebサービスをECSやEC2に振り分けるだけの用途
・コスト優先: Amazon API GatewayはREST APIで$3.50/百万リクエスト（2026年3月時点）のリクエスト課金のため、大量トラフィックではALBのほうが費用を抑えられる

Amazon API Gatewayを追加するケース:
・外部公開APIの認証管理: Cognitoや外部IdPと連携したJWT認証をAPI単位で制御する
・スロットリングが必要: APIキーごとに1秒あたりのリクエスト数上限を設ける
・バックエンドがLambdaの場合: API Gateway + Lambdaはサーバーレスの定番構成
・APIバージョン管理: v1/v2を別Lambdaや別コンテナに振り分けてバージョン管理する

詳細なAPI設計の選択についてはREST API vs GraphQL vs gRPC の比較も参考になる。

Azure Application GatewayとAzure API Managementの関係

AzureではApplication Gateway（WAF統合も可）を前段に置き、その背後にAPI Managementを配置する多段構成がよく使われる。

インターネット → Application Gateway（WAF + SSL終端 + 負荷分散）→ Azure API Management（認証 + スロットリング + ルーティング）→ バックエンドサービス

この構成はWAFによる防御とAPI管理を分離できるため大規模なAPIプラットフォームで採用される。小規模であればAPI Managementのみか、Application Gatewayのみで代替することも多い。

判断フローで整理する

どのコンポーネントを使うかを迷ったときの判断フローはこのとおりだ。

ステップ1: 認証・スロットリング・バージョン管理などのAPI管理機能が必要か？
→ Yes → APIゲートウェイを使う（Amazon API Gateway / Azure API Management）
→ No → ステップ2へ

ステップ2: HTTPヘッダー・URL・ホスト名などL7情報でルーティングしたいか？
→ Yes → L7ロードバランサー / リバースプロキシを使う（ALB / Application Gateway）
→ No → ステップ3へ

ステップ3: 高スループット・超低レイテンシが必要か、または非HTTPプロトコルを扱うか？
→ Yes → L4ロードバランサーを使う（NLB / Azure Load Balancer）
→ No → L7ロードバランサーで十分な場合が多い

実際の本番環境では複数を組み合わせる構成が一般的だ。「NLBでTCPを受けてALBに転送し、ALBの背後にAPI Gatewayを置く」ような多段構成は過剰なケースが多く、まずは最小構成（ALBのみ、またはALB + API Gateway）から始めて実需に応じて足すのが現場のやり方だ。

よくある設計の落とし穴

1. ALBとAPI Gatewayを二重に立てて管理コストが増大する

「ALBだけで十分なのにAPI管理が必要と思いAPI Gatewayも追加した」ケースがある。API GatewayはALBより1リクエストあたりのコストが高く、大量トラフィックでは費用が膨らむ。認証・スロットリングが本当に必要かを先に確認してから追加するべきだ。

2. Application GatewayのWAFをスルーしてAPIに直接アクセスできてしまう

AzureでApplication Gateway（WAF付き）を前段に置いたのに、バックエンドAPIがパブリックIPで直接アクセス可能になっているケース。バックエンドはVNet内のプライベートエンドポイントか、Application Gatewayのサブネットからの受信のみを許可する設計にすべきだ。

3. オンプレNginxの設定をそのままリフトアンドシフトしてしまう

Nginxに認証ロジックやレート制限のカスタムルールを書き込み続けた結果、設定が複雑化したオンプレNginxをそのままクラウドに持ち込むケースがある。クラウドではAPIゲートウェイの機能を活用することで、Nginxの複雑な設定管理をなくせる場合が多い。

本記事のまとめ

3コンポーネントは「HTTPリクエストを転送する」という見た目こそ似ているが、責務のレイヤーが異なる。L4は「TCP接続をどこに届けるか」、L7は「このHTTPリクエストをどのバックエンドに送るか」、APIゲートウェイは「誰が・何を・どのくらいできるかを制御した上で転送する」という順序で上位の責務を担う。

クラウド移行時に迷ったら、まずL7ロードバランサー（ALBまたはApplication Gateway）から始め、API管理の必要性が生じた段階でAPIゲートウェイを追加するのが現実的なアプローチだ。