クラウド時代にプロキシサーバーは必要なのか

はじめに

オンプレからクラウド環境へ移管する際になんとなくそのままプロキシサーバーも移管したのですが、ALBを利用できるクラウドでプロキシサーバーは必要なのか、はっきり分かっていなかったため、調べてみました。

前提

今回はバックエンドとして採用する機会が多いFastAPIを想定し「ユーザー → ALB → FastAPI」というよくある構成で、ALB と FastAPI の間に nginx を挟む意味はあるのかという前提を持とうと思います。

対象構成: ユーザー → ALB → FastAPI（uvicorn）
ALB も nginx も L7（HTTP/HTTPS）で動くリバースプロキシ
比較対象は「AWSとGoogle Cloud における ALB」と「VM/コンテナ上の nginx」

AWS: ALB と nginx の機能比較

機能	AWS ALB	nginx	備考
HTTPS 終端	○	○	ALB は HTTPS リスナーで暗号化/復号をオフロード
負荷分散	○	○	ALB は AZ をまたぐ分散・ターゲットグループ管理込み
ヘルスチェック	○	○	ALB はターゲットグループ単位
パスベースルーティング	○	○	ALB はワイルドカード（*？）に加え正規表現に対応
正規表現での振り分け	○（制約あり）	○	ALB は lookahead / lookbehind / 後方参照など非対応
URL リライト（パス書き換え転送）	○（2025年10月〜）	○	ALB の rule transforms。パスとクエリのみ、ルールあたり1つ
Host ヘッダー書き換え	○（2025年10月〜）	○	同上 rule transforms
ヘッダー変更	△（2024年11月〜）	○	ALB は TLS 系ヘッダーのリネーム、レスポンスヘッダー挿入（HSTS/CORS/CSP）、Server ヘッダー削除まで。任意のリクエストヘッダーの自由な書き換えは不可
メソッド制限	○	○	ALB は http-request-method 条件 + fixed-response で実現（完全一致のみ）
静的ファイル配信	△	○	CloudFront と S3が推奨構成。 ALB + S3 interface VPC エンドポイント（PrivateLink）の構成で可能ではあるが制約多め
レスポンス圧縮（gzip/brotli）	✕	○	ALB に圧縮機能はない。アプリ側か nginx/CloudFront で行う
slow client バッファリング	△	○	nginx はproxy_buffering等で明示制御可能
レート制限・キャッシュ・Lua 拡張	✕（WAF 等の別サービス）	○

AWS ALB は 2024〜2025 年のアップデートで大きく変更

2024年11月
- ヘッダー変更機能
  - TLS/mTLS 系ヘッダーのリネーム、HSTS・CORS 等のレスポンスヘッダー挿入、Server ヘッダーの無効化が可能
2025年10月
URL / Host ヘッダーリライト + 正規表現ルーティング
- host-header・http-header・path-pattern 条件で正規表現マッチが使えるようになり、rule transforms で正規表現＋置換によるパス・クエリの書き換え転送が可能

AWS 自身がこのリリースを「追加のプロキシレイヤーを不要にし、アーキテクチャを簡素化する」ものと位置づけている。[参考]

ただし ALB の正規表現には機能制限がある（lookahead、lookbehind、後方参照、アトミックグループ、再帰などは使えない）。

また構造上の上限として、ルールはリスナーあたりデフォルト100（引き上げ可）、条件値はルールあたり5（固定）、ワイルドカードはルールあたり6（固定） というクォータがある。

Google Cloud: 外部 ALB と nginx の機能比較

Google Cloud のグローバル外部アプリケーションロードバランサで同じ比較をすると、「LB スイートに最初から統合されている」機能が多い。

機能	Google Cloud 外部 ALB	備考
HTTPS 終端	○	Google マネージド証明書含む
パス/正規表現ルーティング	○	pathRules はワイルドカード、routeRules は prefixMatch / fullPathMatch / regexMatch（RE2 構文） / headerMatches / queryParameterMatches
URL リライト	○（以前からネイティブ）	urlRewrite（pathPrefixRewrite / hostRewrite / pathTemplateRewrite）。
ヘッダー変更	○	カスタムリクエスト/レスポンスヘッダー client_region や tls_ja3_fingerprint など 30 以上の変数展開に対応（上限 8KB / 16 ヘッダー）
メソッドでのルーティング	✕	matchRules に HTTP メソッド条件はない。メソッド制限をエッジでやるなら Cloud Armor のカスタムルール（CEL の request.method）を併用
静的ファイル配信	○（backend bucket）	Cloud Storage バケットをLB の直接バックエンドにできる。 URL マップで動的（backend service）と静的（backend bucket）をパスで振り分け可能。別途CDNを構える必要がない
レスポンス圧縮	○（Cloud CDN 統合）	LB に統合された Cloud CDN の dynamic compression（gzip / Brotli、圧縮可能コンテンツで 60〜80% 削減）
ルール上限	十分大きい	host rules / path matchers: URL マップあたり 1000、path rules: matcher あたり 1000 など。ALB の「ルール100」より桁が大きい

AWS との構造的な違い

静的配信
- AWS は「ALB とは別に CloudFront と S3 を構成」がベスト
- Google Cloud は同一 LB の URL マップに GCS バケットを直接ぶら下げられる。
  - AWS がCloudFrontとS3 の疎結合な組み合わせを基本とするのに対し、Google Cloud は同一 LB 内で集約する設計アプローチをとっています。
前提の補足
- GCS 単体でもカスタムドメイン配信は可能だが HTTP のみ。
- 公式も “Cloud Storage doesn’t support custom domains with HTTPS on its own” と明記しており、カスタムドメイン + HTTPS には外部 ALB + backend bucket 構成が必要
この構成での HTTPS 終端は LB のフロントエンド（ターゲット HTTPS プロキシ）で行われ、Google マネージド証明書がそのまま使える。GCS 側に証明書設定は不要
前提構成（ユーザー → ALB → FastAPI）では LB が既に HTTPS 終端しているため、backend bucket をパスルールで足すだけで静的配信も HTTPS 化される
AWS 側の正確な整理
- ALB のターゲットタイプは instance / ip / lambda のみで S3 は直接指定できない。
- ただし S3 の interface VPC エンドポイント（PrivateLink）の private IP を ip ターゲットに登録すれば ALB + S3 で HTTPS 静的配信は可能。
- AWS 公式ブログが示すパターンだが、internal ALB（社内サイト）向けの想定で、バケット名を証明書ドメインと一致させる必要があり、website hosting 機能（index.html 自動解決）も使えない。
圧縮
- AWS は ALB 単体では不可（CloudFront かアプリ側）だが、Google Cloud は LB 統合の Cloud CDN でチェックボックス一つ
リライト・正規表現
- Google Cloud はネイティブ対応で、AWS は 2025年10月に追いついた。
メソッド制限
- こちらはAWSの方がシンプル、Google Cloud は Cloud Armor 併用

Google Cloud では LB スイート内で機能が完結するため、フロントに nginx を置く必要性が一層低くなります。

それでも nginx（リバースプロキシ）を挟むべきユースケース

機能表だけ見ると「ほぼ ALB で代替可能」だが、以下のケースでは nginx を追加する判断に合理性がある。

1. 静的ファイル配信を同一ノードで完結させたい

AWS の定石は CloudFront と S3 だが、「小規模なアプリで配信インフラを増やしたくない」「動的コンテンツと静的コンテンツを同一ノードで返したい」場合、nginx の root / try_files で済ませる構成は簡潔

2. レスポンス圧縮を行いたい

ALB はレスポンスを圧縮しない。FastAPI 側で GZipMiddleware を使う手もあるが、圧縮を Python プロセスの CPU で行うことになる。nginx の gzip on に逃がす、あるいは CloudFront に任せる方がアプリの負荷を下げられるように思う。

3. ALB の正規表現・ルール数の制約を超える複雑なルーティング

正規表現の機能制限に収まらない複雑な分岐は nginx を採用する。表現力に実質的な制限はないため。

4. slow client からアプリサーバーを守る必要がある（gunicorn sync worker など）

下記gunicorn 公式記載です。（参考）

Gunicornはプロキシサーバーの背後で実行することを強くお勧めします。

HTTPプロキシは数多く存在しますが、 Nginxをお勧めします。デフォルトの同期ワーカーを使用する場合は、プロキシが低速なクライアントをバッファリングするように設定する必要があります。そうしないと、Gunicornはサービス拒否攻撃に対して脆弱になります。

一方 uvicorn（FastAPI の標準的な実行環境）は非同期 I/O なので事情が異なり、マネージド環境ではこのレイヤーが不要になるとも明記されている。

ただ、puma は README で「built-in request bufferer があるため、リバースプロキシなしでデプロイできる（Standalone）」（参考）と明言しており、アプリサーバーごとに公式の見解を確認するのが良いのかもしれない。

5. オンプレとクラウドで構成を揃えたい

オンプレ・他クラウド・ローカル開発環境と同じ構成ファイル（nginx.conf）で挙動を揃えたい場合、nginx を挟むことで環境差分を最小化できる。

6. インフラとアプリケーションを分離したい

ALB のリスナールールは Terraform/CloudFormation などインフラ管理の変更フローに乗ってしまうが、 nginx.conf はアプリのリポジトリに置いてアプリのデプロイフローで変更できる。「ルーティングの変更主体は誰か」でレイヤーを分ける設計という意図での採用も正しいと思われる。

結論

「ユーザー → ALB → FastAPI」の基本構成において、ルーティング・TLS 終端・ヘッダー操作・リライトしか行わない場合にnginx を挟む必要はもうないと考えます。
nginx を挟む判断が残るのは先述のユースケースのいずれかに該当し優先するとき。
AWS・Google Cloud ともにマネージド機能が拡充されており、一般的な要件であれば Nginx なしのシンプル構成を実現できます。
「とりあえず nginx を挟む」はもう卒業するべき

クラウド時代にプロキシサーバーは必要なのか

はじめに

前提