2026年8月13日

AWS CLB でセッションアフィニティ（スティッキーセッション）を設定する方法

ネットワーク・接続

AWS の Classic Load Balancer（CLB）では、HTTP/HTTPS リスナーに Cookie ベースのスティッキーセッション・ポリシーを付けることで、同じ利用者のリクエストを同じ EC2 インスタンスに送り続けられます。この記事では、2種類のポリシーの違い、AWS CLI での設定手順、HTTPS リスナーで起きやすい設定の上書き事故、効いているかの確認方法、そして WordPress でそもそも固定が必要かどうかの判断までを説明します。

始める前に：CLB の位置づけ

CLB は AWS のロードバランサーの中で前世代にあたるサービスで、AWS は新しい構成には Application Load Balancer（ALB）や Network Load Balancer（NLB）を勧めています。既存の CLB を当面使い続ける場合にこの記事の手順が役立ちますが、新規構築なら ALB のターゲットグループでスティッキーセッションを設定する方法を検討してください。CLB の提供状況や移行支援の内容は変わることがあるため、AWS の公式ドキュメントで最新情報を確認してください（2026年10月現在）。

また、スティッキーセッションが使えるのは HTTP/HTTPS リスナーだけです。TCP/SSL リスナーではロードバランサーが HTTP の Cookie を扱えないため、この機能は使えません。

2種類のスティッキーセッション・ポリシー

CLB には次の2つの方式があります。

期間ベース（ロードバランサー生成 Cookie）

ロードバランサー自身が AWSELB という名前の Cookie を発行し、その Cookie を持つリクエストを同じインスタンスに送ります。有効期間（秒）を指定でき、指定しない場合はブラウザのセッションの間だけ有効です。アプリケーション側の変更が不要なので、まず試すならこちらです。

アプリケーション制御（アプリケーション生成 Cookie）

アプリケーションが発行する Cookie の名前を指定し、その Cookie が存在する間だけ固定します。アプリがログアウト時に Cookie を消せば、固定も解除されます。ロードバランサーは指定した名前の Cookie を目印に独自の Cookie を発行する仕組みで、アプリの Cookie が無くなると振り分けは通常に戻ります。

どちらの方式でも、固定先のインスタンスがヘルスチェックで異常と判定されると、リクエストは正常なインスタンスへ送られ、そのインスタンスに固定し直されます。

AWS CLI で設定する手順

ここでは、ロードバランサー名を my-clb、HTTPS リスナーのポートを 443 として説明します。作業前に現在の設定を控えておき、可能ならステージング用の CLB で試してから本番に適用してください。

1. 現在のリスナーとポリシーを確認する

aws elb describe-load-balancers \
  --load-balancer-names my-clb \
  --query 'LoadBalancerDescriptions[0].ListenerDescriptions'

各リスナーの PolicyNames に、すでに割り当てられているポリシー名が表示されます。HTTPS リスナーでは、ここに SSL ネゴシエーションのポリシー（暗号スイートや TLS バージョンを決めるもの）が入っているはずです。この名前を控えておくことが次の手順で重要になります。

2. ポリシーを作成する

期間ベースの場合は、有効期間を秒で指定します。次の例は1時間（3600秒）です。

aws elb create-lb-cookie-stickiness-policy \
  --load-balancer-name my-clb \
  --policy-name sticky-1h \
  --cookie-expiration-period 3600

アプリケーション制御の場合は、アプリが発行する Cookie 名を指定します。

aws elb create-app-cookie-stickiness-policy \
  --load-balancer-name my-clb \
  --policy-name sticky-app \
  --cookie-name your-app-cookie

3. リスナーにポリシーを割り当てる

ここが最もつまずきやすい手順です。set-load-balancer-policies-of-listener は、リスナーに付いているポリシーを指定したもので「置き換える」動作をします。スティッキーセッションのポリシー名だけを指定すると、HTTPS リスナーから SSL ネゴシエーションのポリシーが外れてしまいます。手順1で控えた名前を一緒に指定してください。

aws elb set-load-balancer-policies-of-listener \
  --load-balancer-name my-clb \
  --load-balancer-port 443 \
  --policy-names your-ssl-negotiation-policy sticky-1h

HTTP（80番）のリスナーにも固定を効かせたい場合は、同じ要領で 80 番に対しても割り当てます。設定後にもう一度 describe-load-balancers を実行し、PolicyNames に両方の名前が入っていることを確認します。

マネジメントコンソールからも、ロードバランサーのリスナー設定画面でスティッキーセッションを編集できます。画面の構成や項目名は変わることがあるため、表示に合わせて「期間ベース」か「アプリケーション制御」かを選んでください。

効いているかを確認する

Cookie の発行を見る

curl -sI https://example.com/ | grep -i set-cookie

期間ベースなら AWSELB の Cookie が返ってくるはずです。

どのインスタンスが応答したかを見る

各 EC2 インスタンスの Web サーバーに、ホスト名を返すレスポンスヘッダーを一時的に追加すると、固定が効いているかを判別できます。Nginx の例です。

# 検証が終わったら削除する
add_header X-Backend-Host $hostname always;

Cookie を保存しながら何度かリクエストし、X-Backend-Host が変わらなければ固定されています。

for i in 1 2 3 4 5; do
  curl -s -o /dev/null -D - -b cookies.txt -c cookies.txt https://example.com/ \
    | grep -i x-backend-host
done

内部のホスト名を外部に見せ続けるのは望ましくないため、確認が済んだらヘッダーは外します。

WordPress でスティッキーセッションは必要か

WordPress のログイン状態は、wordpress_logged_in_ などの Cookie と、データベースに保存されたセッショントークンで管理されています。つまり、次の条件がそろっていれば、どのインスタンスにリクエストが届いてもログインは維持され、スティッキーセッションは必須ではありません。

全インスタンスの wp-config.php で AUTH_KEY などの認証キーとソルトが同じ
全インスタンスが同じデータベースを参照している
wp-content/uploads が共有ストレージや S3 などで共有されている
オブジェクトキャッシュを使う場合、Redis や Memcached をインスタンス間で共有している

WooCommerce のカート情報も、標準ではデータベースのセッションテーブルに保存されます。「ランダムにログアウトされる」「アップロードした画像が表示されたりされなかったりする」という症状は、固定で隠すより、上の条件のどれが欠けているかを確認するほうが根本的な解決になります。

一方で、PHP の標準セッション（$_SESSION）をファイルに保存するプラグインや、ローカルディスクに一時ファイルを書く処理を使っている場合は、固定が当面の対処として有効です。

固定することの副作用

インスタンスごとの負荷が偏りやすく、スケールアウトしても既存の利用者は古いインスタンスに留まる
インスタンスを入れ替える際、固定されていた利用者の状態（ローカルに置いたデータ）は失われる
AWSELB などの Cookie が付くことで、CDN やページキャッシュの設定によってはキャッシュが効きにくくなる。CloudFront などで Cookie をオリジンに転送する設定にしている場合は、キャッシュキーに含めていないか確認する

有効期間を長くしすぎると偏りが続くので、必要な処理の長さに合わせて短めに設定するのが無難です。

まとめ

CLB のスティッキーセッションは HTTP/HTTPS リスナーでのみ使え、期間ベースとアプリケーション制御の2方式がある
set-load-balancer-policies-of-listener はポリシーを置き換えるため、HTTPS リスナーでは SSL ネゴシエーションのポリシーも一緒に指定する
設定後は describe-load-balancers と、応答インスタンスを示す一時ヘッダーで動作を確認する
WordPress は認証キー・DB・アップロード・オブジェクトキャッシュを共有すれば、固定なしで動かせることが多い
CLB は前世代のサービスなので、新規構成や移行時は ALB での設定を検討する