Tech

ロードバランサの背後にリバースプロキシを使うべきかどうか

最終更新：2026.04.27

Tech AWS

AWSを利用していると必ず耳にする、「ALB(Application Load Balancer: L7)」, 「NLB(Network Load Balancer: L4)」、誰もが耳にしたことのあるサービスの1つだと思います。

しかし、具体的にどのようなメリットがあるのか、あるいはNginxのようなリバースプロキシとどう使い分けるべきか、曖昧な方も多いのではないでしょうか。

本記事は、その曖昧さをなくし、わかりやすくまとめられたらと思います。

ロードバランサの基本役割

ロードバランサとは、その名の通り負荷を均等にしてくれる装置あるいはソフトウェアです。

もう少し解像度を上げてみます。

大量のアクセスがあるWebサイトやアプリケーションの負荷を分散させ、1台のサーバーにかかる負荷を軽減するための装置です。

例えば、あるWebサイトを見るときはみなさんはWebブラウザを通じてそのWebサイトがあるWebサーバーにアクセスし、見たいサイトを画面に表示しています。

このWebサイトに対して多くの人がアクセスした場合、1台のサーバーでは処理しきれなくなります。

そこでサーバーの台数を複数台にしてあげれば、1ヶ所に負荷が集中することなく分散されるというわけです。

ただ、1回のリクエストに対して複数のWebサーバーが反応してしまうと逆に混乱しますよね。

そこで登場するのが、「ロードバランサー」です。

クライアントと複数台のWebサーバーの間に入ることで、「このページはサーバーAがして」「これはサーバーB」のように処理の振り分けをしてくれるようになります。

かつ、ダウンしたサーバーには振り分けないといった死活監視的な機能も担っています。

冒頭に出ていたL4, L7を軽く話します。

L4, L7はネットワークのレイヤーのことをさしており、OSI参照モデルのトランスポート層（L4）とアプリケーション層（L7）のことを示しています。

詳しくは以下を見てみてください。

OSI参照モデル(おーえすあいさんしょうもでる)とは？ 意味や使い方 – コトバンク

L4は、「誰から（IPアドレス）」「どの窓口に（ポート番号）」来たかという情報だけを見て機械的に振り分けます。

TCP/UDPストリームを扱うため、HTTPヘッダの解析やリライトはできません。

そして、L7はURL、HTTPヘッダー、Cookie、画像かテキストをみて振り分けを行なっています。

ヘッダ書き換えやキャッシュ、リライトといった高度な制御が可能で、リバースプロキシ的な機能と重なる部分が多いです。

続いて、プロキシの役割や機能をみていきます。

プロキシについて整理する

フォワードプロキシとは

リバースプロキシの説明に入る前に、フォワードプロキシと混合しないようにフォワードプロキシについても話します。

一般的に、「プロキシ」だけだったらフォワードプロキシのこと言ってるんだなと思ってください。フォワードプロキシは、「クライアント（中から外へ）」の代わりに立ってくれる代理人みたいなイメージでOKです。

フォワードプロキシの機能としては、以下のようなものが挙げられます。

  • セキュリティ強化
    • 自分のIPアドレスを隠してアクセスを行うため
  • アクセスログの取得
  • フィルタリング
    • 特定のサイトへのアクセスを禁止する

リバースプロキシとは

リバースプロキシとは、クライアント (ブラウザなど) からのリクエストを受け取り、内部のアプリケーションサーバや他のWebサーバ へ転送して、その結果をクライアントに返す仕組みです。

リバースプロキシのメリットとしては以下が挙げられます。

  • 負荷分散
  • セキュリティ強化
  • SSLの終端
  • キャッシュ

ここで勘の良い方なら気づいたかもしれないですが、AWSではこの機能をALBが提供してくれています。

ALBの強み

ALBは、L7での負荷分散を提供してくれるフルマネージド型ロードバランサーです。

例えば以下のことをマネージドしてくれます。

パスベース・ホストベースのルーティング

ALBはURLのパスやホスト名を見てリクエストの転送先を変えることができます。

例えば、example.com/api/* はAPIサーバーへ、example.com/static/* は静的ファイルサーバーへ、

といった振り分けが可能です。

また、api.example.com と app.example.com のようにサブドメイン単位での振り分けも1台のALBで対応できます。

スティッキーセッション

同一クライアントからのリクエストを、常に同じバックエンドサーバーに転送する機能です。
セッション情報をサーバー側で持つような古いアーキテクチャでは、リクエストのたびに転送先が変わるとログアウトされてしまいます。
スティッキーセッションを有効にすることで、こうした問題を回避できます。

マネージドなセキュリティ（ACM, WAF連携）

  • SSL終端
    • ACM(AWS Certificate Manager) と連携し、証明書の更新を自動化できます
  • 攻撃遮断
    • AWS WAFを統合し、SQLインジェクション等の攻撃をALBのレイヤーでブロックできます

ALB, WAF, ACMを組み合わせればリバースプロキシが従来提供していたものをカバーできます。

高可用性・スケーラビリティ

ALB自体がAWSによってマルチAZ構成で管理されており、SPOF（単一障害点）になりません。

トラフィックの増減に応じて自動でスケールするため、急激なアクセス増加にも対応できます。
EC2 Auto ScalingやECSと組み合わせると、バックエンドのスケールアウト・インをALBが自動で追従してくれるため、運用コストを大幅に削減できます。

高度なトラフィック管理

重み付きターゲットグループを使うことで、新バージョンのサーバーに対してトラフィックを少しずつ流すカナリアリリースが実現できます。

また、ヘッダーやクエリパラメータの値に応じた条件分岐もサポートしており、A/Bテストのような用途にも活用できます。

ALBだけで解決できること

これまでの話を聞いていると、「リバースプロキシ設定する必要あるの?」と感じる方もいらっしゃるのではないでしょうか。

確かに、以下の条件が揃うなら ALB + WAF + ACM で十分です。

  • アプリケーションはAWS上で完結している
  • ルーティングルールがシンプル（パス・ホストベース程度）
  • レスポンスの書き換えやボディの加工が不要
  • 静的コンテンツはS3 + CloudFrontで配信している
  • 独自の認証ロジックをプロキシ層に持たせる必要がない

スタートアップや中規模のWebサービスであれば、このスタックで大半の要件はカバーできます。 マネージドである分、運用コストも最小限に抑えられます。

しかし、次のようなケースを考えるとリバースプロキシが必要になってきます。

リバースプロキシが必要になるケース

レスポンスの書き換えが必要なとき

ALBはリクエストを「どこに転送するか」を決める装置であり、転送後のレスポンスの中身には関与しません。これはALBの設計思想上の制約であり、機能追加で解決できるものではありません。

そのため、レスポンスボディの加工が必要な場合はNginxの sub_filter を使って対応していく必要があります。

複雑なリダイレクト・書き換えルール

ALBのリスナールールは条件数に上限（ルールごとに最大5つの比較文字列）があり、正規表現も限定的です。

レガシーシステムの移行などで数十パターンのリダイレクトが必要な場合、Nginxの rewrite や map ディレクティブの方が現実的です。

ALB単体で制御が難しい場合はリバースプロキシで対応しましょう。

静的コンテンツのキャッシュをサーバー側で持ちたいとき

CloudFrontを使えば解決できるケースが多いですが、オンプレとのハイブリッド構成や、きめ細かいキャッシュ制御が必要な場合はNginxをキャッシュサーバーとして機能させることで実現できます。

プロキシ層で独自認証を挟みたいとき

ALBはCognitoやOIDCと統合した認証をサポートしていますが、社内の独自認証基盤やAPI Keyの検証ロジックを柔軟に組み込みたい場合は、OpenRestyやLuaが選ばれます。

ロードバランサの背後にリバースプロキシを持たせるかどうか

ここでタイトルにもあった通り、「ロードバランサの背後にリバースプロキシを持たせるべきかどうか」について。

これはケースバイケースで、要件次第でどちらも正しいです。

判断基準はシンプルで、「リバースプロキシが必要なケース」に該当するものがあればNginxを足す、なければALBだけで完結させることです。

最初からNginxを入れておくのは間違いではありませんが、マネージドサービスで解決できるものをわざわざ自前で運用するのはコストの無駄になります。

ALBとNginxは競合ではなく役割が違います。ALBはスケールと可用性を担い、Nginxは細かい制御を担う。両者を組み合わせることで、それぞれの強みを活かした構成が実現できると考えています。

まとめ

AWS上で完結するシンプルな構成であれば、ALB + WAF + ACMで十分です。運用コストを最小化できるこの構成を最初の選択肢にするのが現実的です。

一方で、レスポンスの加工・複雑なリダイレクト・独自認証といった要件が出てきた時点でNginxの導入を検討してください。

今回まとめた判断基準をもとに、要件に合った設計の参考になれば幸いです。

参考文献

「分かりそう」で「分からない」でも「分かった」気になれるIT用語辞典

Application Load Balancer とは?