SSL 終端とスティッキーセッション
ACM 証明書を使ってロードバランサーで TLS を終端し、ステートフルなワークロードでクライアントの固定性が必要な場合はスティッキーセッションを有効にします。
「SSL 終端とスティッキーセッション」はCoddyKit上の無料AWS Solutions Architectレッスンです。 これはレッスン4/4です。 下記で完全なレッスンを無料で読むことができます。その後、ブラウザ内の組み込みコードエディタと24時間対応のAIチューターでハンズオン演習できます。 これはAWS Solutions Architect学習パスの一部であり、ウェブとCoddyKitアプリ全体で進捗が同期されます。 AWS Solutions Architectコースには全4レッスンが含まれています。
ロードバランサーでのSSL/TLS終端
SSL/TLS終端とは、ロードバランサーが受信したHTTPSトラフィックを復号し、平文のHTTPリクエストを調べて(ルーティングを決定するため)、必要に応じてバックエンドへ転送する前に再暗号化することです。ALBで終端すると、アプリケーションサーバーはロードバランサーから暗号化されていないHTTPトラフィックを受信できるため、バックエンドの設定が簡単になります。
ロードバランサーで終端すると、アプリケーションサーバー側で接続ごとにTLSハンドシェイクを行う必要がなくなり、CPU負荷を軽減できます。また、HTTPヘッダーの読み取りが必要なコンテンツベースのルーティングが可能になり、証明書管理も一元化できます。
AWS Certificate Manager(ACM)との統合
AWS Certificate Manager(ACM)は、SSL/TLS証明書を追加料金なしで発行、管理、更新します。ALBとNLBはACMと直接統合でき、HTTPSリスナーの設定でACM証明書を選択すると、ロードバランサーが接続するクライアントにその証明書を提示します。
ACM証明書は有効期限が切れる前に自動更新されるため、手動更新や、証明書の期限切れによるダウンタイムは必要ありません。パブリック証明書では、ACMはDNS検証(Route 53のCNAMEレコード)またはEメール検証によってドメインの所有権を確認します。内部利用の場合は、ACM Private CAでプライベート証明書を発行できます。
# Request a public certificate in ACM
aws acm request-certificate \
--domain-name api.example.com \
--subject-alternative-names '*.example.com' \
--validation-method DNS \
--region us-east-1
# Create an HTTPS listener using the ACM certificate
aws elbv2 create-listener \
--load-balancer-arn arn:aws:elasticloadbalancing:us-east-1:123456789:loadbalancer/app/my-alb/abc \
--protocol HTTPS \
--port 443 \
--ssl-policy ELBSecurityPolicy-TLS13-1-2-2021-06 \
--certificates CertificateArn=arn:aws:acm:us-east-1:123456789:certificate/cert-id \
--default-actions Type=forward,TargetGroupArn=arn:aws:elasticloadbalancing:us-east-1:123456789:targetgroup/my-tg/xyzServer Name Indication(SNI)
SNI(Server Name Indication)は、1つのIPアドレス(したがって1つのALBまたはNLBリスナー)で、異なるドメイン名に対して複数のTLS証明書を提供できるTLS拡張機能です。クライアントはTLS ClientHelloメッセージに接続先のホスト名を含め、ロードバランサーが適切な証明書を選択します。
ALBはSNIをネイティブにサポートしているため、1つのHTTPSリスナーに複数のACM証明書を関連付けられます。ALBは、クライアントのSNIホスト名に基づいて適切な証明書を自動的に選択します。これにより、ドメインごとに別のリスナーやロードバランサーを用意する必要がなくなり、SSLを使用した真のバーチャルホスティングが可能になります。
# Add a second certificate to an existing HTTPS listener (SNI)
aws elbv2 add-listener-certificates \
--listener-arn arn:aws:elasticloadbalancing:us-east-1:123456789:listener/app/my-alb/abc/lis456 \
--certificates CertificateArn=arn:aws:acm:us-east-1:123456789:certificate/second-cert-idSSLセキュリティポリシー
ALBとNLBは設定可能なSSLセキュリティポリシーをサポートしており、ロードバランサーがクライアントから受け入れるTLSプロトコルのバージョンと暗号スイートを制御できます。AWSでは、脆弱性の発見に応じて更新される事前定義済みポリシー(例:ELBSecurityPolicy-TLS13-1-2-2021-06)を提供しています。
コンプライアンス要件によっては、特定のTLSバージョンが必要です。PCI-DSS 3.2.1ではTLS 1.2以上が必須であり、多くの最新標準ではTLS 1.0と1.1を完全に無効化することが推奨されています。非推奨のプロトコルと脆弱な暗号スイートを除外するポリシーを使用してください。前方秘匿性とパフォーマンスのため、TLS 1.3を含むポリシーを優先してください。
# List available SSL policies
aws elbv2 describe-ssl-policies \
--query 'SslPolicies[*].{Name:Name,TLSVersions:SslProtocols}' \
--output tableエンドツーエンド暗号化と終端の比較
ALBで使用できるTLSのアプローチは2種類あります。
- SSL終端(最も一般的):ALBがロードバランサーで復号し、ターゲットへ平文のHTTPを転送します。構成が簡単で、ルーティングのための検査が可能になり、サーバーのCPU負荷を軽減できます。VPC内のバックエンドトラフィックは暗号化されません。
- エンドツーエンドTLS:ALBが復号した後、ターゲットへ転送する前に再暗号化します(ALBとターゲット間はHTTPS)。CPU負荷が高く、ターゲット側に証明書が必要ですが、厳格なコンプライアンス要件がある場合でもVPC内の通信を暗号化できます。
NLBのTLSパススルーモードでは、NLBは一切復号せず、暗号化されたTCPをそのままターゲットへ転送し、ターゲットがTLSを処理します。アプリケーションサーバーが独自の証明書を管理します。
スティッキーセッションとは何か、なぜ必要か
スティッキーセッション(セッションアフィニティとも呼ばれます)を使用すると、同じクライアントからのすべてのリクエストが、ターゲットグループ内の同じターゲットへ継続的にルーティングされます。これは、ElastiCacheのような共有キャッシュではなく、個々のサーバー上のメモリにセッションデータを保存するステートフルアプリケーションで必要になります。
スティッキーセッションがない場合、ステートレスなロードバランサーがリクエスト1をサーバーA(セッションを保持)へ、リクエスト2をサーバーB(セッションデータを持たない)へ送る可能性があります。その結果、ユーザーがログアウトしたように見えたり、カートの内容を失ったりします。スティッキーセッションは、セッションの継続中、クライアントを特定のターゲットに固定します。
ALBでのCookieベースのスティッキネス
ALBは2種類のスティッキーセッションCookieをサポートしています。
- 期間ベースのスティッキネス(ロードバランサー生成Cookie):ALBが
AWSALBという名前のCookie(ALBの場合)を生成し、有効期間を設定します。Cookieにはターゲットへの暗号化された参照情報が含まれます。クライアントは以降のリクエストでこのCookieを送信します。 - アプリケーションベースのスティッキネス:アプリケーションが設定した既存のCookieを使用します。ALBは指定されたCookie名を読み取り、独自のCookieに暗号化した値を生成して、元のアプリケーションCookieを保持しながらスティッキールーティングに使用します。
スティッキネスはターゲットグループごとに設定でき、期間は1秒から7日まで指定できます。
# Enable duration-based sticky sessions on a target group
aws elbv2 modify-target-group-attributes \
--target-group-arn arn:aws:elasticloadbalancing:us-east-1:123456789:targetgroup/my-tg/xyz \
--attributes \
Key=stickiness.enabled,Value=true \
Key=stickiness.type,Value=lb_cookie \
Key=stickiness.lb_cookie.duration_seconds,Value=86400スティッキーセッションのデメリット
スティッキーセッションはステートフルアプリケーションの問題を解決しますが、次のトレードオフが生じます。
- 負荷分散の偏り:特定のクライアントが通常より活発だと、一部のターゲットにトラフィックが集中し、負荷分散の目的が損なわれる可能性があります
- スケーリングの制約:スティッキーなターゲットが異常になるとセッションが切断され、クライアントは新しいターゲットで新しいセッションを開始する必要があるため、メモリ上のセッションデータを失います
- 伸縮性の低下:スケールイン時にインスタンスから接続を切り離して終了することが難しくなります
ベストプラクティスは、セッション状態をElastiCacheまたはDynamoDBに外部化して、スティッキーセッションを不要にすることです。これによりアプリケーションが真にステートレスになり、完全な水平スケーリングが可能になります。
NLBのTLSリスナーとパススルー
NLBは、ALBと同様に、ポート443(または任意のポート)のTLSリスナーでTLS終端をサポートします。NLBはトラフィックを復号し、必要に応じて再暗号化してターゲットへ転送します。また、TCPリスナーを設定すれば、暗号化されたTCPトラフィックを復号せずにパススルーすることもできます。このモードでは、アプリケーションサーバーがエンドツーエンドのTLSを処理します。
ACMを使用したNLBのTLS終端では、ALBと同じ証明書管理のメリットを得られますが、HTTP層の機能はありません。TLS終端と静的IPの両方が必要な場合や、バックエンドプロトコルがHTTP以外(カスタムTCPプロトコルなど)の場合に、NLBのTLS終端を使用します。
コネクションドレインとスティッキーセッションの相互作用
スティッキーなターゲットの登録を解除すると(Auto Scalingのスケールイン時など)、コネクションドレインによって処理中のリクエストを完了できます。ただし、登録解除中のターゲットに対するAWSALB Cookieを保持しているスティッキークライアントからの新しいリクエストは、自動的に新しいターゲットへ割り当てられます。このクライアントのスティッキネスCookieは無効化されます。
登録解除の遅延とCookieの無効化を組み合わせることで、既存の長時間リクエストを完了させながら、そのクライアントからの新しいリクエストを正常なターゲットへスムーズに再ルーティングでき、エンドユーザーにエラーとして表示されることを防げます。
SSLとセッション管理のベストプラクティス
試験で重要なベストプラクティス:
- 自動更新のためにACM証明書を使用し、ロードバランサー上の証明書を手動で管理しないでください
- TLS 1.2以上のセキュリティポリシーを使用し、PCI/HIPAAコンプライアンスのためにTLS 1.0/1.1を無効化してください
- スティッキーセッションよりも、ステートレスアーキテクチャ(セッションをElastiCache/DynamoDBに保存)を優先してください
- ALBでSNIを使用すると、ロードバランサーごとに複数の証明書を用意せず、1つのリスナーから複数のドメインを提供できます
- 厳格なコンプライアンス要件がある場合(VPC内のデータを暗号化する必要がある場合)は、ロードバランサーでの終端だけでなく、エンドツーエンドTLSを使用するHTTPSターゲットグループを使用してください
クイックチェック
このレッスンで扱ったAWS Solutions Architect(SAA-C03)の概念について、理解度を確認しましょう。
レッスンのまとめ
このレッスンでは、ACM証明書を使用したALBのSSL/TLS終端により、複数ドメイン向けの自動更新とSNIが利用できること、SSLセキュリティポリシーがコンプライアンスのためにTLSバージョンと暗号スイートを制御すること、そしてスティッキーセッションはステートフルアプリケーションでユーザーを同じターゲットへルーティングする一方、セッション状態をElastiCacheに外部化して置き換えるのが望ましいことを学びました。次はAuto Scalingグループと起動テンプレートについて学びます。
よくある質問
「SSL 終端とスティッキーセッション」レッスンは無料ですか?
はい。「SSL 終端とスティッキーセッション」の完全なテキストはこのウェブで無料で読めます。インタラクティブに演習し(組み込みコードエディタと24時間対応のAIチューター)、AWS Solutions Architectコースの残りをアンロックするには、CoddyKit PROにアップグレードしてください。 AWS Solutions Architectコースには全4レッスンが含まれています。
「SSL 終端とスティッキーセッション」で何を学びますか?
ACM 証明書を使ってロードバランサーで TLS を終端し、ステートフルなワークロードでクライアントの固定性が必要な場合はスティッキーセッションを有効にします。 ブラウザで直接実行するハンズオンコードでAWS Solutions Architectを演習し、24時間対応のAIチューターがレッスンを進める中での質問に答えます。
AWS Solutions Architectを始めるのに経験は必要ですか?
事前経験は必要ありません。CoddyKitのAWS Solutions Architectは初級者から上級者向けに構成されているため、ここから始めるか最初から始めて、自分のペースで進むことができます。 これはレッスン4/4です。
「SSL 終端とスティッキーセッション」レッスンにはどのくらい時間がかかりますか?
ほとんどのCoddyKitレッスンは約5~10分かかります。各レッスンはコンパクトでインタラクティブなので、着実に進歩し、ウェブとアプリ全体で正確に前回の場所から再開できます。
このAWS Solutions Architectレッスンでコードを書いて実行できますか?
はい。すべてのAWS Solutions Architectレッスンに組み込みコードエディタが含まれているため、ブラウザでリアルコードを書いて実行し、即座のAIフィードバックを取得できます。ローカル設定は不要です。
このコースのすべてのレッスン
- ALB、NLB、GLB:使い分けのポイント
- ターゲットグループとヘルスチェック
- リスナールールとパスベースルーティング
- SSL 終端とスティッキーセッション