Session state for a citizen portal currently lives in memory on a single EC2 instance, blocking scale-out. What should the architect do?

Citizen portal session state living only in memory on a single EC2 instance blocks scale-out because every new or replacement instance lacks those sessions. Externalizing sessions to a managed store such as Amazon DynamoDB or Amazon ElastiCache lets compute remain ephemeral and stateless: any healthy instance can serve the next request after sticky affinity is removed or reduced. That change is foundational before Auto Scaling can actually help a municipal portal survive seasonal traffic or instance patches without logging citizens out randomly.

Increasing instance size only while keeping sessions pinned forever still leaves a single-host SPOF and vertical limits that will eventually cap concurrency. Disabling Auto Scaling so the sticky instance never leaves abandons elasticity by policy and turns maintenance windows into outages. Writing sessions to instance store ephemeral disk treats stop, hibernate, or replacement loss as acceptable for all citizens—an availability and experience failure for a public portal.

Exam caveat: “externalize state” is the core theme—DynamoDB, ElastiCache/Redis, or similar—before horizontal scaling; sticky sessions alone are a temporary crutch, not the target architecture. Operational check: move session reads/writes to DynamoDB or ElastiCache, disable sticky dependence, terminate an instance under load and confirm users stay signed in, and autoscale the fleet on CPU or request count.