SAA-040
EC2 Auto Scalingで稼働するWebアプリケーションで、スケールインやインスタンス障害が起きるたびに一部のユーザーがログアウトされてしまいます。セッション情報は各インスタンスのローカルディスクに保存されています。最も適した改善策はどれですか？
選択肢
解説と正解
解説と正解を読む（先に自分で回答してから開くのがおすすめです）
正解：C. セッション情報をAmazon ElastiCacheやAmazon DynamoDBなどの外部データストアへ移し、アプリケーション層をステートレスにする
解説
根本原因は、インスタンスというライフサイクルの短いリソースに状態を持たせていることです。セッション情報をElastiCacheやDynamoDBといった共有データストアへ外部化してアプリケーション層をステートレスにすれば、どのインスタンスが終了してもセッションは失われません。
選択肢ごとの解説
A. Application Load Balancerのスティッキーセッションを有効化し、同じユーザーを常に同じインスタンスへ転送する
スティッキーセッションは同じインスタンスへ転送し続けるだけで、そのインスタンスが終了すればセッションは失われます。障害時のログアウトは解消せず、負荷の偏りという別の問題も生みます。
B. 各インスタンスに専用のEBSボリュームをアタッチし、セッションファイルをそこへ保存する
EBSボリュームは単一のインスタンスにアタッチされ、単一のアベイラビリティーゾーンに固定されます。インスタンスが終了すればそのセッションを他のインスタンスから読むことはできません。
C. セッション情報をAmazon ElastiCacheやAmazon DynamoDBなどの外部データストアへ移し、アプリケーション層をステートレスにする
正解です。状態を外部化することで、インスタンスを「いつでも捨てられる」使い捨てのリソースとして扱えるようになります。
D. Auto Scalingグループの最小台数を引き上げ、スケールインが発生しないようにする
最小台数を上げてもインスタンス障害やヘルスチェック失敗による置き換えは起こります。コストが増えるだけで根本解決になりません。
実務での使いどころ
Auto Scaling を前提にしたアーキテクチャでは、インスタンスは「いつ終了してもよいもの」として設計する必要がある。スケールインの対象になる、ヘルスチェック失敗で置き換えられる、AZ 障害で消えるといった事象は正常系の一部であり、そのたびにユーザー影響が出る構成は水平スケールの前提を満たしていない。セッション情報やアップロード中の一時ファイルのように「そのインスタンスにしかない状態」を持たせないこと、すなわちアプリケーション層をステートレスにすることが基本設計になる。 セッションの外部化先としてよく使われるのが Amazon ElastiCache（Redis / Valkey / Memcached）と Amazon DynamoDB である。ElastiCache はインメモリで応答が速く、TTL によるセッション期限管理も自然に書ける。Redis 系はレプリケーションと自動フェイルオーバー（Multi-AZ）に対応するため、キャッシュ層自体の可用性も確保できる。DynamoDB はサーバーレスでキャパシティ管理が不要、TTL 属性による自動削除に対応し、グローバルテーブルを使えばリージョンをまたいだセッション共有も可能になる。一方、ALB のスティッキーセッション（セッションアフィニティ）は既存アプリの暫定対処としては使えるが、インスタンス障害時のセッション消失は解決せず、特定インスタンスへ負荷が偏る副作用がある点を理解しておく。同様に、共有が必要なファイルは EBS ではなく Amazon EFS や S3 に置く。 SAA-C03 では「スケールインのたびにログアウトされる」「インスタンスが置き換わるとカートの中身が消える」といった症状から、状態の外部化（ElastiCache / DynamoDB）を選ばせる出題が定番である。誤答にはスティッキーセッションの有効化、最小台数の引き上げ、EBS へのセッション保存が並ぶ。EBS が単一 AZ・単一インスタンスにひも付くリソースであるという性質は、この判断の決め手になる。