Q65 — AWS ANS-C01 第1章

第 65/100 問 | ← 第1章

ある企業が、Amazon EC2インスタンス上で新しいWebアプリケーションを展開します。このアプリケーションは、Application Load Balancer（ALB）の後ろにある3つの可用性ゾーン内のプライベートサブネットで実行されます。セキュリティ監査担当者は、すべての接続を暗号化することを要求しています。企業はDNSにAmazon Route 53を使用し、AWS Certificate Manager（ACM）を用いてSSL/TLS証明書のプロビジョニングを自動化しています。SSL/TLS接続はALB上で終端されます。企業は単一のEC2インスタンスでアプリケーションをテストし、問題は観測されませんでした。しかし、本番環境への展開後、ユーザーはログインできるもののアプリケーションを利用できないと報告しています。すべての新しいWebリクエストでログインプロセスが再始動します。ネットワークエンジニアは、この問題を解決するために何を行うべきですか？

• A. ALBリスナー設定を変更します。トラフィックをターゲットグループに転送するルールを編集し、グループレベルのステッキネスを有効化します。期間をアプリケーションの最大セッション長に設定します。
• B. ALBをNetwork Load Balancerに置き換えます。TLSリスナーを作成します。プロトコルタイプをTLSに設定した新しいターゲットグループを作成し、EC2インスタンスを登録します。ターゲットグループ設定でステッキネス属性を有効化します。
• C. ALBターゲットグループ設定を変更し、ステッキネス属性を有効化します。アプリケーションベースのCookieを使用します。期間をアプリケーションの最大セッション長に設定します。 ✓
• D. ALBを削除します。アプリケーション名に対してフェイルオーバールーティングポリシーを指定したAmazon Route 53ルールを作成します。ACMを構成して各EC2インスタンス向けに証明書を発行します。

正解: C. ALBターゲットグループ設定を変更し、ステッキネス属性を有効化します。アプリケーションベースのCookieを使用します。期間をアプリケーションの最大セッション長に設定します。

解説

この問題は、Application Load Balancer（ALB）におけるセッションステッキネスの設定に関連しています。AWS公式ドキュメントによると、ALBのセッションステッキネスは、リスナールールではなくターゲットグループレベルの属性で管理されます。ユーザーがログイン後にセッションが切断される問題は、状態を持たないロードバランシングによりリクエストが異なるインスタンスに分散されることによって生じます。正しい解決策は、ターゲットグループでステッキネスを有効化し、AWSELB CookieまたはカスタムCookieなどのアプリケーション生成Cookieを用いることで、同一ユーザーのリクエストを同一インスタンスにルーティングすることです。選択肢Cはターゲットグループ設定を直接変更しており、AWSのベストプラクティスに合致します。選択肢Aは誤ってリスナールールに設定を配置しており、選択肢BおよびDは不要なアーキテクチャ変更を伴います。