EC2 で動かしている WordPress の前に Application Load Balancer（ALB）を置くと、HTTPS の終端をまとめられ、サーバーを複数台に増やしても入口は1つのまま運用できます。この記事では、ターゲットグループ・ALB・リスナーを作る順番、ヘルスチェックの決め方、そして WordPress を ALB の背後に置いたときに起きやすい「リダイレクトループ」「アクセス元IPがALBになる」問題の直し方までを説明します。
この記事は AWS マネジメントコンソールの構成（2026年10月現在）をもとに説明していますが、画面の項目名は更新で変わることがあります。名前が違っていても、各手順の「目的」を手がかりに読み替えてください。本番の変更前には、EC2 の AMI やスナップショット、データベースのバックアップを取っておくことをおすすめします。
ALBの構成要素と作る順番
ALB は次の4つの部品の組み合わせで動きます。
- ロードバランサー本体: インターネットからの入口。2つ以上のアベイラビリティーゾーン（AZ）のサブネットを指定する必要があります。
- リスナー: 「どのポート・プロトコルで受けるか」と「受けた通信をどう扱うか（転送・リダイレクトなど）」の定義です。通常は HTTP:80 と HTTPS:443 の2つを作ります。
- ターゲットグループ: 転送先の EC2 インスタンスの集まりと、ヘルスチェックの設定を持ちます。
- セキュリティグループ: ALB 用と EC2 用を分けて作ります。
作る順番は「セキュリティグループ → ターゲットグループ → ALB 本体とリスナー → DNS」です。ターゲットグループを先に用意しておくと、ALB 作成時のリスナー設定で転送先をそのまま選べます。
手順1：セキュリティグループを2つ用意する
ALB 用のセキュリティグループは、インターネットからの 80/443 を受け付けます。EC2 用のセキュリティグループは、インバウンドの HTTP（80）の送信元を「ALB 用セキュリティグループ」に限定します。IP アドレス範囲ではなくセキュリティグループ ID を送信元に指定するのがポイントで、ALB の内部 IP が変わっても設定を直す必要がありません。
こうしておくと、EC2 に直接アクセスされる経路がなくなり、後述する X-Forwarded-Proto ヘッダーを信用してよい前提が成り立ちます。SSH 用の 22 番は、管理用の固定 IP からだけに絞るか、Session Manager を使って閉じておくと安全です。
手順2：ターゲットグループを作る
ターゲットの種類は「インスタンス」、プロトコルは HTTP、ポートは 80 を選びます。HTTPS の暗号化は ALB で終端し、ALB から EC2 までは VPC 内の HTTP で通す構成がもっとも一般的です。
AWS CLI で作る場合の例です。ID や名前は自分の環境に合わせて置き換えてください。
# ターゲットグループの作成（ヘルスチェックは専用ファイルに向ける）
aws elbv2 create-target-group \
--name wp-tg \
--protocol HTTP \
--port 80 \
--vpc-id vpc-0123456789abcdef0 \
--target-type instance \
--health-check-path /healthcheck.html \
--matcher HttpCode=200
# EC2 インスタンスを登録
aws elbv2 register-targets \
--target-group-arn arn:aws:elasticloadbalancing:ap-northeast-1:123456789012:targetgroup/wp-tg/0123456789abcdef \
--targets Id=i-0aaaaaaaaaaaaaaaa Id=i-0bbbbbbbbbbbbbbbbヘルスチェックのパスで失敗しやすい理由
ヘルスチェックをサイトのトップ（/）に向けると、WordPress が 301 を返してターゲットが「unhealthy」になることがよくあります。WordPress は「サイトアドレス」と違うホスト名やプロトコルで来たリクエストを正規の URL へリダイレクトするためです。ALB のヘルスチェックはホスト名として EC2 の IP を使うので、この動きに引っかかります。
対策は2つあります。1つは、ドキュメントルートに healthcheck.html のような静的ファイルを置き、そこへ向けて 200 を期待する方法です。もう1つは成功コードを 200-399 のように広げる方法ですが、こちらは「リダイレクトしか返せない壊れた状態」も正常と判定してしまいます。まずは静的ファイル方式で始めるのが分かりやすいでしょう。
PHP でデータベース接続まで確認するヘルスチェックも作れますが、DB が止まると全台が同時に unhealthy になります。ALB は全ターゲットが unhealthy になると全台へ振り分ける動き（フェイルオープン）をするとされていますが、監視の判断は複雑になります。何を「正常」と見なすかを決めてから選んでください。
手順3：ALB本体とリスナーを作る
スキームは「インターネット向け」、サブネットは異なる AZ のパブリックサブネットを2つ以上選び、手順1の ALB 用セキュリティグループを付けます。
HTTPS リスナーには AWS Certificate Manager（ACM）の証明書を指定します。ACM の証明書は ALB と同じリージョン で発行したものしか選べない点に注意してください（CloudFront 用の us-east-1 の証明書とは別に必要です）。
# ALB の作成（サブネットは異なる AZ を2つ以上）
aws elbv2 create-load-balancer \
--name wp-alb \
--type application \
--subnets subnet-0aaaaaaaaaaaaaaaa subnet-0bbbbbbbbbbbbbbbb \
--security-groups sg-0alb000000000000
# HTTPS:443 → ターゲットグループへ転送
aws elbv2 create-listener \
--load-balancer-arn arn:aws:elasticloadbalancing:ap-northeast-1:123456789012:loadbalancer/app/wp-alb/0123456789abcdef \
--protocol HTTPS --port 443 \
--certificates CertificateArn=arn:aws:acm:ap-northeast-1:123456789012:certificate/your-certificate-id \
--default-actions Type=forward,TargetGroupArn=arn:aws:elasticloadbalancing:ap-northeast-1:123456789012:targetgroup/wp-tg/0123456789abcdef
# HTTP:80 → HTTPS へ 301 リダイレクト
aws elbv2 create-listener \
--load-balancer-arn arn:aws:elasticloadbalancing:ap-northeast-1:123456789012:loadbalancer/app/wp-alb/0123456789abcdef \
--protocol HTTP --port 80 \
--default-actions 'Type=redirect,RedirectConfig={Protocol=HTTPS,Port=443,StatusCode=HTTP_301}'HTTP から HTTPS へのリダイレクトを ALB で行えば、EC2 側の Apache や Nginx でリダイレクトを書く必要はありません。両方に書くと、後述のループの原因になります。セキュリティポリシー（TLS のバージョンや暗号スイートの組み合わせ）は指定しなければ既定のものが使われます。古い端末への対応が必要な場合を除き、既定か、より新しいポリシーを選ぶのが無難です。
手順4：WordPress側の設定を直す
ALB の背後に置いた直後に多いのが、「管理画面に入ろうとするとリダイレクトが止まらない」「CSS が読み込まれない（混在コンテンツ）」という症状です。原因は、ALB と EC2 の間が HTTP なので、WordPress が「自分は HTTP で呼ばれている」と判断してしまうことです。
ALB は元の通信が HTTPS だったことを X-Forwarded-Proto ヘッダーで伝えます。これを wp-config.php で読み取り、WordPress に HTTPS だと認識させます。/* That's all, stop editing! */ の行より上に追記してください。
// ALB で HTTPS を終端している場合のみ。EC2 が ALB 以外から直接アクセスされない構成が前提
if ( isset( $_SERVER['HTTP_X_FORWARDED_PROTO'] ) && 'https' === $_SERVER['HTTP_X_FORWARDED_PROTO'] ) {
$_SERVER['HTTPS'] = 'on';
}このヘッダーは誰でも付けて送れるため、EC2 に直接届く経路が残っていると偽装に使われます。手順1でセキュリティグループを絞っておくのはこのためです。あわせて、「設定 → 一般」の WordPress アドレスとサイトアドレスが https:// から始まる独自ドメインになっているかも確認してください。ALB の DNS 名（〜.elb.amazonaws.com）でアクセスすると、WordPress は独自ドメインへリダイレクトするのが正常な動きです。
アクセス元IPがALBのアドレスになる問題
ALB 経由では、EC2 から見た接続元はすべて ALB の内部 IP になります。アクセスログ、コメントの IP、ログイン試行の制限を行うセキュリティ系プラグインがこの影響を受けます。実際のクライアント IP は X-Forwarded-For ヘッダーに入っているので、Web サーバー側で信頼するプロキシの範囲を指定して置き換えます。
# Apache（mod_remoteip を有効化したうえで）。範囲は自分の VPC の CIDR に合わせる
RemoteIPHeader X-Forwarded-For
RemoteIPInternalProxy 10.0.0.0/16# Nginx（ngx_http_realip_module）
set_real_ip_from 10.0.0.0/16;
real_ip_header X-Forwarded-For;信頼する範囲を広く取りすぎると、ヘッダーを偽装した IP をそのまま記録してしまいます。VPC の CIDR に限定してください。
複数台構成にするときに決めておくこと
ALB を入れる目的が「EC2 を複数台にすること」なら、WordPress 側でサーバー間の差をなくしておく必要があります。
- アップロードファイル: 1台目に上げた画像が2台目に無い、という状態になります。Amazon EFS で
wp-content/uploadsを共有するか、メディアを S3 へ逃がすプラグインを使って、どのサーバーからも同じファイルが見えるようにします。 - wp-config.php の認証キーとソルト: 全台で同じ値にします。WordPress のログイン状態は Cookie で管理されるため、キーが揃っていればスティッキーセッション（同じ利用者を同じサーバーへ送り続ける設定）は通常不要です。
- プラグインやテーマの更新: 管理画面からの更新は1台にしか反映されません。AMI から台数を増やす運用か、デプロイの仕組みで全台に配る運用に切り替えます。
- データベース: 各 EC2 にローカルの MySQL を置くのではなく、Amazon RDS などの共通 DB に接続します。
動作確認の方法
設定が終わったら、次の順で確認します。
- ターゲットグループの「ターゲット」でヘルスステータスが healthy になっているか。CLI では
aws elbv2 describe-target-health --target-group-arn <ARN>で理由コードも確認できます。 - ALB の DNS 名に対して
curl -I http://<ALBのDNS名>/を実行し、HTTPS への 301 が返るか。 - Route 53 で独自ドメインを ALB へのエイリアスレコードに向けたあと、ブラウザで表示・ログイン・画像アップロードを試す。
- Web サーバーのアクセスログに、ALB の IP ではなく実際のクライアント IP が記録されているか。
unhealthy のままなら、EC2 のセキュリティグループが ALB からの 80 番を許可しているか、ヘルスチェックのパスにファイルが存在するか、Web サーバーが起動しているかを順に確認すると原因にたどり着きやすくなります。
まとめ
- ALB は「セキュリティグループ → ターゲットグループ → ALB とリスナー → DNS」の順に作ると迷いにくい。
- EC2 への 80 番は ALB のセキュリティグループからだけ許可する。これが
X-Forwarded-Protoを信用する前提になる。 - ヘルスチェックは静的ファイルに向け、WordPress のリダイレクトで unhealthy になるのを避ける。
- HTTP→HTTPS のリダイレクトは ALB 側に一本化し、
wp-config.phpで HTTPS 判定を補う。 - 複数台にするなら、アップロードファイルの共有・認証キーの統一・更新の配り方を先に決めておく。