オンプレのApache構成

典型的な大規模システムのApache構成は以下のようになっている。

httpd.conf（典型的な構成要素）
# SSL
LoadModule ssl_module modules/mod_ssl.so
SSLEngine On
SSLCertificateFile /etc/ssl/certs/server.crt

# 圧縮
LoadModule deflate_module modules/mod_deflate.so
AddOutputFilterByType DEFLATE text/html text/css application/javascript

# URLリライト
LoadModule rewrite_module modules/mod_rewrite.so
RewriteEngine On
RewriteRule ^/old-path(.*)$ /new-path$1 [R=301,L]

# 静的コンテンツ
DocumentRoot /var/www/html
Alias /static/ /var/www/static/

# IP制限
<Location /admin>
  Require ip 192.168.1.0/24
</Location>

# Tomcat連携
LoadModule jk_module modules/mod_jk.so
JkMount /app/* tomcat-worker

Apacheの機能を分解する

AWSに移行するときに重要なのは「Apacheを1つのサービスに置き換える」のではなく、Apacheが担っていた各機能を適切なAWSサービスに分散させるという発想だ。

Apache機能（モジュール）AWS対応サービス備考
mod_ssl（SSL終端）CloudFront / ALB + ACMPART 01参照
mod_rewrite（URL書き換え・リダイレクト）ALBリスナールール / CloudFront Functions複雑なルールはLambda@Edge
静的ファイル配信（DocumentRoot）S3 + CloudFrontAPサーバーの負荷ゼロ化
mod_deflate（gzip圧縮）CloudFront（自動）設定不要で有効化される
IP制限（Require ip）WAF IPセット / Security GroupWAFはL7、SGはL4
レート制限（mod_ratelimit）WAF レートベースルール5分あたりのリクエスト数で制限
Basic認証（.htpasswd）Cognito / Lambda@EdgeIAM認証も選択肢
VirtualHost（複数ドメイン）ALBホストベースルーティング1つのALBで複数ドメイン対応
アクセスログALBアクセスログ → S3S3から Athena / OpenSearch へ連携可
mod_jk（Tomcat連携）不要（ALBがコンテナに直接転送）PART 03参照

静的コンテンツ配信の切り出し

オンプレでは画像・CSS・JSファイルをApacheのDocumentRootに置いてTomcatと同じサーバーから配信することが多い。AWSではこれをS3 + CloudFrontに完全に分離できる。

静的コンテンツ分離の構成
【オンプレ】
クライアント → Apache（静的 + 動的を一緒に処理）
                └── 静的: DocumentRoot /var/www/html
                └── 動的: mod_jk → Tomcat

【AWS】
クライアント
    ├── 静的リクエスト（/static/*, *.css, *.js）
    │       → CloudFront → S3
    │         （Apacheもサーバーも不要）
    │
    └── 動的リクエスト（/api/*, /app/*）
            → CloudFront → ALB → ECS

💡 静的分離のメリット

APサーバー（ECS）は動的リクエストだけを処理すればよくなり、オートスケールの判断がシンプルになる。S3 + CloudFrontのキャッシュにより、APサーバーへの到達リクエスト数自体が大幅に減る。

URLルーティング（mod_rewrite → ALBルール）

mod_rewriteで実装していたURLのリダイレクト・書き換えは、ALBのリスナールールで実現できる。

mod_rewriteのパターンALBリスナールール
RewriteRule ^/old(.*)$ /new$1 [R=301] 条件: パスが /old/* に一致 → アクション: リダイレクト (301) → /new/#{path}
パスプレフィックスによる振り分け 条件: パスが /api/* → ターゲットグループA
条件: パスが /app/* → ターゲットグループB
VirtualHost によるホスト別振り分け 条件: ホストヘッダが api.example.com → ターゲットグループA

⚠️ 複雑なRewriteルールはCloudFront Functionsへ

ALBリスナールールでは正規表現が使えず、条件もパス・ホスト・HTTP メソッド・ヘッダー・クエリ文字列に限られる。複雑なURL書き換えが必要な場合はCloudFront Functions（軽量JavaScript）またはLambda@Edge（Node.js/Python）に実装する。

アクセス制御（IP制限・レート制限）

ApacheのRequire ipやmod_ratelimitに相当するアクセス制御は、WAFで実現する。

WAFルールの構成例
WAF WebACL
├── IPセットルール（IP制限）
│     許可IPリスト: 203.0.113.0/24, 10.0.0.0/8
│     アクション: 一致しないリクエストをブロック
│
├── レートベースルール（レート制限）
│     閾値: 同一IPから5分間で2000リクエスト
│     アクション: 超過したIPをブロック（5分間）
│
├── AWS マネージドルール（SQLインジェクション等）
│     AWSManagedRulesCommonRuleSet
│     AWSManagedRulesSQLiRuleSet
│
└── カスタムルール（ヘッダー検査等）
      条件: X-Forwarded-For が特定のレンジ外
      アクション: ブロック

Nginxサイドカーを置くべきケース

多くの場合、ALB + WAF + CloudFrontの組み合わせでApacheの機能はカバーできる。ただし、以下のケースではECSコンテナ内にNginxサイドカーを置くことを検討する。

ケース判断
リクエストボディの大きなアップロード（数十MB）のバッファリングNginxサイドカー検討
コンテナ単位の独立したアクセスログ管理Nginxサイドカー検討
レスポンスのマイクロキャッシュ（数秒単位）Nginxサイドカー検討
単純なパスルーティング・ヘルスチェックのみALBで十分・Nginx不要
IP制限・レート制限WAFで十分・Nginx不要

対比表

Apache機能オンプレAWS
URL書き換えmod_rewrite（httpd.conf）ALBリスナールール / CloudFront Functions
静的コンテンツApache DocumentRootS3 + CloudFront
gzip圧縮mod_deflateCloudFront（自動）
IP制限Require ip / .htaccessWAF IPセット
レート制限mod_ratelimitWAF レートベースルール
複数ドメイン対応VirtualHostALBホストベースルーティング
アクセスログ/var/log/httpd/access_logALBアクセスログ → S3

ハマりポイント

⚠️ ALBリスナールールの優先度に注意

ALBは複数のリスナールールを優先度順に評価する。デフォルトルール（全リクエストを転送）を誤った位置に置くと、特定パスのルーティングが機能しない。優先度の数値が小さいほど先に評価される。

✅ 次の記事では…

PART 03 では Apache の mod_jk / AJP という「最も大きな変化」に焦点を当てる。AWSではAJPが完全に不要になり、セッション管理の設計も根本的に変わる。