tech・4分で読める
Apache / Nginx は必要？用途と使い分けまとめ
Apache と Nginx の役割は「Webサーバ」だけではない。静的配信、リバースプロキシ、TLS終端、負荷分散、キャッシュなど“境界”の責務として整理し、いつ必要でいつ不要かを判断できるようにまとめます。
#apache#nginx#webserver#infra
Apache / Nginx とは
どちらも一般に Webサーバ と呼ばれますが、現代の実務ではそれ以上に **「アプリの手前に置く“境界（edge）”の部品」**として使われます。
- Apache: 歴史が長く、柔軟（モジュール豊富）。特に
.htaccess文化や運用知見が多い - Nginx: 高速なリバースプロキシ/静的配信が得意で、設定がシンプル寄り
（補足）今は Caddy、クラウドの ALB / Cloud Load Balancing、Kubernetes の Ingress なども同じ領域の役割を担います。
そもそも「必要性」はどこから来る？
Apache/Nginxが必要になるのは、アプリの前段で **次のような“非アプリの仕事”**をさせたいときです。
静的ファイル配信
- 画像/CSS/JS/HTML を高速に返す
Cache-Control等のヘッダ制御- （場合によっては）gzip/brotli 圧縮
リバースプロキシ（アプリの前に立つ）
- アプリサーバ（Node/Go/Rails等）へ転送する
- パスで振り分け（
/apiはA、/adminはB など） - 0-downtime の入れ替え（Blue/Green や段階的切替の足場）
TLS終端（HTTPS化）
- 証明書管理、HTTP→HTTPSリダイレクト
- HSTSなどのセキュリティヘッダ
負荷分散（ロードバランス）
- 複数台のアプリサーバへ分散
- ヘルスチェックやフェイルオーバ
レート制限 / WAF 的な入口制御（簡易）
- 同一IPからの過剰アクセス抑制
- Botっぽいアクセスの遮断（簡易）
キャッシュ（簡易CDNみたいなもの）
- 近い場所で返してアプリ/DB負荷を減らす（ただし設計を誤ると事故の元）
AWSでは何に置き換えられる？
AWSでは、Apache/Nginx が担っていた「入口の責務」を CloudFront / ALB / API Gateway / WAF などのマネージドサービスに分解して置き換えるのが典型です。
ALB と NLB の使い分け（どっちを使う？）
AWSのロードバランサは大きく ALB（Application Load Balancer） と NLB（Network Load Balancer） があり、レイヤが違います。
- ALB（L7）: HTTP/HTTPS を理解して、パス/ホストベースで振り分けたり、HTTP固有の機能（リダイレクト等）を使いたいとき
- NLB（L4）: TCP/UDP/TLS レベルで高速に捌きたい、または HTTP 以外（独自プロトコル等）を扱いたいとき
| 観点 | ALB | NLB |
|---|---|---|
| レイヤ | L7（HTTP/HTTPS） | L4（TCP/UDP/TLS） |
| 代表的ユースケース | Web/API、マイクロサービスの入口 | 高スループットTCP、gRPC以外の独自プロトコル、DBプロキシなど |
| ルーティング | パス/ホストでのルールが得意 | ポート/接続単位（HTTPのパスは見ない） |
| 入口の機能 | リダイレクト、ヘッダ、WAF連携など“Webっぽい”機能 | 低レイヤでシンプル、高速 |
| IP要件 | 通常は抽象化される（固定IPを前提にしない） | **固定IP（EIP）**を持たせたい要件で選ばれやすい |
ざっくり判断
- Webサイト/APIの入口（
/api振り分け、HTTP→HTTPS、ホスト/パスルールを使いたい）→ ALB - HTTP以外もまとめて捌きたい / 低レイヤで高性能に捌きたい / 固定IP要件 → NLB
- その上で、グローバルにキャッシュさせたい/静的配信したいなら前段に CloudFront を置く
もっと具体的な用途の使い分け（例）
| こういう要件・用途 | どっち？ | 理由（決め手） |
|---|---|---|
1ドメインで複数サービスをパスで分岐（/api /admin） | ALB | L7でパス/ホストルーティングができる |
| HTTP→HTTPSリダイレクトを入口でやりたい | ALB | リスナールールで実装しやすい |
| WAFで防御したい（ルールベースでブロックしたい） | ALB（or CloudFront） | AWS WAFを付けられる（NLBは不可） |
| OIDC/Cognito等で入口認証をしたい | ALB | ALBの認証機能を使える |
| WebSocketを使うWebアプリ/API | ALB | HTTPの入口として扱える（設計がシンプル） |
| gRPCをHTTPとして扱いたい（観測/ルーティングも含めL7で） | ALB | gRPCをL7として扱える（ルール/観測/運用が揃う） |
| TCPの独自プロトコル（ゲームサーバ等） | NLB | L4（TCP）で捌ける |
| UDPが必要（例: 一部リアルタイム通信） | NLB | UDP対応は基本NLB |
| 固定IPが必要（取引先のIP許可、オンプレFW許可など） | NLB | EIPで固定しやすい |
| クライアントの送信元IPをそのままアプリで見たい | NLB | L4で送信元IPを保持しやすい（ALBは通常X-Forwarded-For経由） |
| PrivateLink で他VPC/他社へ“プライベート公開”したい | NLB | PrivateLink（Endpoint Service）はNLBが定番 |
よくある構成例（入口の置き換え方）
- Web（静的あり）:
CloudFront → ALB → ECS/EKS/EC2 - HTTP API（サーバレス）:
CloudFront → API Gateway → Lambda - TCPサービス:
NLB → ECS/EKS/EC2
※ 現実は「ALBかNLBか」単体より、CloudFront（キャッシュ/ヘッダ/グローバル配信）を前段に置くかがセットで効いてきます。
| やりたいこと | AWSでの置き換え先（代表例） |
|---|---|
| 静的ファイル配信（画像/CSS/JS/HTML） | S3 + CloudFront |
Cache-Control 等のヘッダ制御 | CloudFront Response Headers Policy（付与/上書き）＋ S3オブジェクトのメタデータ（Cache-Control） |
| gzip/brotli 圧縮 | CloudFront の圧縮（自動圧縮） |
| リバースプロキシ（アプリへ転送） | ALB / CloudFront →（オリジンに）ALB / CloudFront → API Gateway |
パスで振り分け（/api と /admin など） | ALB Listener Rules（パスベース） / CloudFront Behaviors（パスごとにオリジン切替） / API Gateway ルート |
| 0-downtime の入れ替え（Blue/Green 等） | ECS + CodeDeploy（Blue/Green） / ALB の Target Group 切替 / Lambda alias weighted / Route 53 weighted |
| TLS終端（HTTPS）/ 証明書管理 | ACM +（CloudFront / ALB / API Gateway） |
| HTTP→HTTPS リダイレクト | ALB リスナールール / CloudFront Functions（軽量）/ Lambda@Edge |
| HSTS等セキュリティヘッダ | CloudFront Response Headers Policy（HSTS含む） |
| 負荷分散（ロードバランス） | ALB（HTTP）/ NLB（TCP） / Route 53 / Global Accelerator |
| ヘルスチェック/フェイルオーバ | ALB/NLB のヘルスチェック + Auto Scaling / Route 53 health check + failover |
| レート制限 / WAF 的な入口制御 | AWS WAF（CloudFront/ALB/API Gatewayに付与） / API Gateway throttling / AWS Shield（DDoS） |
| キャッシュ（簡易CDN） | CloudFront キャッシュ / （APIなら）API Gateway cache / （アプリ内なら）ElastiCache（Redis） |
よくある置き換えパターンは次の通りです。
- 静的サイト/アセット中心:
CloudFront ← S3 - Web + API:
CloudFront（静的はS3 / APIはALB or API Gateway） - コンテナ/EC2アプリ:
ALB ← ECS/EKS/EC2（必要なら前段にCloudFront）
ポイントは「Apache/Nginx が不要になる」ではなく、入口の責務を“どこに持たせるか”が AWS 側に移るということです。
Apache と Nginx の使い分け（超ざっくり）
| 観点 | Apache | Nginx |
|---|---|---|
| 得意領域 | “機能の幅”と互換性 | リバースプロキシ/静的配信の軽さ |
| 設定文化 | .htaccess など分散設定が多い | 集中設定が基本 |
| 運用感 | 長年の知見・レガシー案件に強い | モダン構成の「入口」に置かれやすい |
結論だけ言うと、新規で「アプリの前段に置く」用途なら Nginx が選ばれやすいです。 一方で **既存資産（設定、運用、アプリ互換）**があるなら Apache を選ぶ合理性は十分あります。
「Webサーバが要る/要らない」はどう判断する？
要ることが多いケース
- 自前サーバ/VMで運用していて、入口の責務（TLS/振り分け/静的）をまとめたい
- アプリがそのままだと危ない・弱い（直公開したくない、タイムアウトや同時接続の制御が必要）
- 複数アプリを1ドメインにぶら下げたい（パスでのルーティング）
- 段階的リリース（切り替えやすい入口が欲しい）
不要になりやすいケース（代替がある）
- Vercel/Netlify/Cloudflare Pages などのホスティング（入口がマネージド）
- クラウドLB + CDN（ALB/Cloud LB + CloudFront 等で責務を吸収）
- サーバレス/関数（API Gateway などが入口を担当）
- Kubernetes の Ingress（Ingress Controller が入口の役割を持つ）
ここでのポイントは「Apache/Nginxが不要」ではなく、“入口の責務”はどこかが必ず持つということです。 自分で持つか、マネージドに任せるかの違いです。
よくある構成パターン（現代版）
パターンA: Nginx → アプリ（最小）
- Nginx: TLS終端 /
/apiをアプリへ / 静的配信 - アプリ: ビジネスロジック
小規模〜中規模で分かりやすいです。
パターンB: CDN →（クラウドLB）→ アプリ
- CDN: 静的・キャッシュ
- LB: TLS終端 / ルーティング / ヘルスチェック
- アプリ: 水平スケール
この場合、Apache/Nginxを自前で置く必要が薄くなることが多いです。
パターンC: Kubernetes Ingress → Service → Pod
Ingress Controller（Nginx/Traefik等）が 入口の責務を担います。 「Nginxを使っている」けど「Nginxサーバを自前で立てている」とは別物、という認識が重要です。
よくある誤解
- 「Nginx/Apache = アプリサーバ」ではない アプリは Node/Java/Go 等の “アプリサーバ” が動かし、Nginx/Apacheは前段で補助することが多いです。
- 「不要」=「入口の責務が消える」ではない マネージドに移るだけです（CDN/LB/Ingress/API Gateway等）。
まとめ（判断の最短ルール）
- 入口でやりたいことがある（TLS、静的、振り分け、制御、キャッシュ）→ 何かしらの “入口” が必要
- その入口を 自分で持つなら: Nginx/Apache（またはCaddy等）
- マネージドに任せるなら: CDN/LB/Ingress/ホスティングの機能で代替可能