Classic Solutions Architectures

Memory hook: Make compute replaceable by putting necessary state in services with deliberately chosen durability, access and failure behavior.

Must remember

Case 1: a public status service

• A service generating independent responses can begin with one EC2 instance/EIP, but one instance remains one serving failure point.
• Route 53 supplies stable naming; an ALB distributes HTTP requests; an ASG maintains/scales the fleet. Naming, routing and capacity lifecycle are separate responsibilities.
• Run sufficient healthy capacity across AZs. Two eligible subnets with desired capacity one offer placement choices, not two active application replicas.
• An EIP preserves a regional public address, but reassociation is not equivalent to distributing traffic across a resilient fleet.
• Keep the web tier stateless: any healthy instance should handle the next request. Necessary state can remain in other tiers.

Case 2: a shopping-session service

• A cart in one server's RAM depends on that server. ALB stickiness provides affinity; failure or scale-in can still destroy local memory.
• Move sessions to an appropriate ElastiCache/Valkey/Redis or other shared store. Choose replication, failover, persistence and expiry according to the consequences of losing sessions.
• Cache repeated product reads to reduce database load, with invalidation/TTL. Carts, inventory and descriptions can have different freshness requirements.
• Read replicas offload suitable reads, not general writes. Replication lag matters immediately after purchases or inventory changes.
• Multi-AZ databases address availability; backups preserve recovery history. Database choices distinguishes readable clusters from classic non-readable standbys.
• Security-group chaining: clients→ALB, ALB SG→application SG, application SG→database/cache SG on required ports. SG references identify sources; they neither copy rules nor create routes.

Case 3: a collaborative editorial site

• EFS fits shared uploads when Linux applications expect filesystem semantics. Use appropriate regional storage/access resilience.
• Aurora or another relational database stores structured content. Filesystems are not databases, and caches do not replace persistent uploads.
• If applications support object APIs directly, S3 can serve media through an appropriate access/CDN design. It is not interchangeable with shared POSIX operations without integration.
• Scale and secure each tier independently. Web availability depends on filesystem, database, session-store and network availability too.
• Managed services still need backups, deployment rollback and recovery testing.

Faster launches and safer replacement

• A golden AMI preinstalls common dependencies, shortening launch time but requiring image maintenance and patching.
• User data finishes environment-specific bootstrap. Long installs and external dependencies delay readiness; repeatable scripts reduce replacement surprises.
• Snapshot restoration recovers disk content. Application consistency, initialization performance and endpoint cutover determine usable recovery time.
• Meaningful ASG/ELB health should check application readiness, not merely a running OS.
• Deregistration delay allows in-flight work to finish; it does not make target-local state durable.

Managed application environments

• Elastic Beanstalk deploys supported applications using underlying AWS resources such as EC2, load balancers and scaling groups. Configuration choices and resource charges remain.
• An application organizes versions/environments; an environment is a running deployment; a supported platform supplies runtime/web-stack configuration.
• Web-serving environments handle incoming application traffic. Worker environments can process queued background work, separating synchronous responses from slower tasks.
• Deployment strategies trade interruption, rollback capability and temporary extra capacity. Managed deployment is not inherently serverless billing.
• Keep durable data independent of disposable environments when recreating application infrastructure must not delete business records.

Choose under exam pressure

Traps

• Stateless compute is not a stateless system. External stores become dependencies needing their own resilience.
• Managed is not automatically cheap or highly available. Capacity, configuration and retained data still matter.
• Solve the failed requirement. Stickiness cannot provide durable sessions; more read replicas cannot resolve write contention.

Active recall

Terraform anchor: Toggles change individual attributes; safe replacement also depends on explicit state ownership and resource dependencies.

Sources

• Stateless-system design — external state and replaceable compute.
• Elastic Beanstalk — application environments.
• Amazon EFS — shared files.
• Aurora architecture — relational storage and compute.