A license portal still stores session files and uploads on a single instance’s local disk, so any instance death loses state. How should the architect redesign for distributed resilience?
Select an answer to reveal the explanation.
Short Explanation
Local disk is a backpack chained to one runner—when that runner falls, the bag is gone. Park shared files on EFS, S3, or a DB so any web box can vanish. Bigger local disks just make a heavier backpack.
Full Explanation
When a citizen web application keeps user uploads and session files only on each EC2 instance’s local disk, any instance failure loses that citizen’s data and sticky routing becomes a fragile crutch. The resilient fix is to move shared state to Amazon EFS, Amazon S3, or a database so any instance can fail without losing data. Externalizing state lets Auto Scaling replace instances freely and lets load balancers distribute traffic without depending on one host’s local filesystem for municipal content.
Upsizing to a larger instance type in the same AZ fails because a bigger local disk in one AZ does not remove the SPOF or protect against instance or AZ loss. RAIDing the instance store and disabling Auto Scaling replacements fails by doubling down on ephemeral local storage and by preventing the self-healing behavior ASG provides. Pinning sticky sessions forever so users never move off the instance that holds their files fails conceptually: stickiness masks state anti-patterns and still loses data when that instance dies.
Exam caveat: choose EFS for shared POSIX files, S3 for object uploads, and a database for structured session or metadata—do not treat them as interchangeable without matching access patterns. Operational check: migrate uploads off local disk, confirm new instances serve existing citizen files, and run instance-termination tests proving no data loss.