Domain 2 Wrap-Up — Review Checklist

Cost Framing (bridge to Domain 4)

Auto-scaling to match demand isn't just a performance/availability lever — it's a cost lever too, since you only pay for what's provisioned. Full cost optimization treatment comes in Domain 4, but the connection is made explicit here: right architecture = right cost.

HA vs. FT vs. DR — Confirm You Can Separate Them

Restated as a checkpoint, not new content — see D2_HighlyAvailableAndFaultTolenrantArchitecture_Insights (unresolved) for the definitions. The wrap-up expects instant recall, not re-derivation.

AWS Global Infrastructure Dependency

Designing resilience across AZs and Regions requires understanding the Global Infrastructure model as a prerequisite — this is called out again as foundational, not optional background.

Self-Healing, Single-AZ Scope

• Self-healing against a single EC2 instance failure or loss of an entire AZ = Elastic Load Balancing + Amazon EC2 Auto Scaling. Know this pairing as the default answer.

Extending to Cross-Region Resilience

• Same self-healing base, now add: Route 53 (failover routing or latency-based routing) or AWS Global Accelerator for cross-Region HA.

DR Strategy Recall

• Backup and Restore, Pilot Light, Warm Standby named again explicitly as the set to have memorized (multi-site active-active is the implied fourth, covered in the task-statement lesson).

Monitoring Service Choice

• CloudWatch vs. AWS X-Ray — know which fits which monitoring need (metrics/alarms vs. distributed request tracing) well enough to pick correctly from a scenario stem.

Independent Scaling & Loose Coupling

• Reaffirms: different app parts should scale independently via loosely coupled design.
• Horizontal vs. vertical scaling, EC2 Auto Scaling vs. AWS Auto Scaling — know the scope difference.
• Many AWS-managed services have built-in resilience already — SQS, Lambda, Fargate — know their capabilities/use cases rather than assuming you must engineer resilience yourself.

Serverless Patterns: Stateless vs. Stateful

• Understand the stateful/stateless distinction for serverless and container patterns.
• Legacy stateful app that writes to disk, needs horizontal scale → Amazon EFS (shared, POSIX, scales automatically) is the fit; FSx serves the Windows/Lustre-specific case instead.
• Stateful containers: achieved via volume storage, not service-to-service messaging — this is a more tightly coupled pattern (common storage protocol, not a service call), e.g., mounting/attaching network volumes decoupled from container lifecycle.
• ECS + EFS integration: gives containers an elastic, managed, "serverless storage" option to persist state in a cloud-native way.

In-Memory State & Load Balancer Stickiness

• If an app keeps state in-memory, horizontal scaling is at risk unless you use sticky sessions on an Application Load Balancer — binds a user's session to one specific target instead of default independent per-request routing.

Decoupling & Read-Offload Toolkit (final recap)

• Decoupling: SQS, Elastic Load Balancing.
• Read/traffic offload: ElastiCache, DynamoDB Accelerator (DAX), Read Replicas.

Practical Examples

Sticky sessions, concretely: A legacy shopping-cart app stores the cart in the web server's local memory (not in a shared store). Behind an ALB with default routing, a user's second request could land on a different instance and see an empty cart. Enabling ALB sticky sessions (session-affinity cookie) pins that user to the same target for the duration of their session — a stopgap, not a real fix (the real fix is moving cart state to ElastiCache/DynamoDB so any instance can serve any user).

EFS for legacy stateful scale-out: An old on-prem-style Linux app writes uploaded files directly to local disk and you need to run it on 10 EC2 instances behind a load balancer. Point all 10 instances at the same EFS mount instead of local EBS — now every instance sees every file, and you can scale the fleet horizontally without rearchitecting the app's file-handling code.

ECS + EFS for persistent container state: A containerized WordPress deployment on ECS Fargate needs its wp-content/uploads directory to survive container restarts and be shared across tasks. Mount an EFS access point as an ECS volume — this is the "serverless storage for containers" pattern, distinct from a service-to-service call.

Built-in resilience, don't over-engineer: A team spends a sprint building custom retry/failover logic around their SQS queue and Lambda consumers "just in case." That's largely wasted effort — SQS already durably stores messages across multiple AZs and Lambda already has built-in retry and dead-letter-queue support; the team should configure DLQs and redrive policies rather than reinvent them.

Choosing Route 53 failover vs. Global Accelerator: A static marketing site hosted in two Regions just needs "if Region A's health check fails, send everyone to Region B" — plain Route 53 failover routing is sufficient and cheap. A latency-sensitive multiplayer game server needs the fastest possible path to whichever healthy Region is closest, riding AWS's backbone network instead of public internet — that's Global Accelerator.

• D2_ScalableAndLooselyCoupledArchitecture_Insights (unresolved)
• D2_HighlyAvailableAndFaultTolenrantArchitecture_Insights (unresolved)