Design Resilient Architectures
Scalable Compute and Stateless Design
CoreSeparate state, choose horizontal/vertical scaling, and compare serverless, containers, and instance compute.
Aligned to the current SAA-C03 exam guide, verified August 16, 2026.
Why this matters
Scalable compute begins by locating durable state. Once the request tier is replaceable, the architect can select an execution model and scale each component against its own demand instead of treating a larger server as the universal answer.
Must Know
- Keep session and durable data outside replaceable compute when possible so instances, tasks, or functions can be added, removed, and replaced safely.
- Horizontal scaling adds copies and improves failure distribution; vertical scaling enlarges one resource and may be necessary for software that cannot distribute, but it retains a stronger single-resource boundary.
- EC2 provides operating-system and instance control. Containers package long-running processes; Lambda runs event-driven functions; Fargate supplies serverless compute capacity for ECS or EKS tasks/pods.
- ECS is AWS-native container orchestration; EKS is Kubernetes. Choose EKS for a real Kubernetes compatibility/ecosystem requirement, not because containers automatically require it.
- Load balancers distribute traffic and perform health checks; EC2 Auto Scaling maintains and adjusts fleet capacity. They are complementary.
- Scale each tier from a metric that reflects its bottleneck: request rate, target utilization, queue depth, concurrency, latency, or another workload signal.
- Multi-tier and microservice designs earn their complexity only when boundaries improve ownership, scaling, failure isolation, or change cadence.
Compare and Distinguish
- Vertical vs horizontal scaling: vertical can preserve legacy design but reaches a ceiling and one-resource boundary; horizontal wins for stateless, elastic, failure-tolerant tiers.
- EC2 vs Lambda vs Fargate: choose server control/long-running compatibility, event-driven short-lived functions, or managed container capacity.
- ECS vs EKS: ECS wins for AWS-native simplicity; EKS wins for required Kubernetes APIs, skills, portability, or ecosystem.
- Fargate vs EC2 container capacity: Fargate minimizes host operations; EC2 capacity wins when host control, specialized capacity, or sustained fleet economics is decisive.
- ALB vs Auto Scaling: the load balancer routes around targets; Auto Scaling changes and repairs target capacity.
Scenario examples
- Scenario: A web tier stores sessions locally and cannot scale cleanly. Think: move session state to a shared durable store, then spread replaceable targets across AZs.
- Scenario: Sporadic events invoke brief code with no server requirement. Think: Lambda minimizes idle capacity and administration.
- Scenario: A portable long-running container needs Kubernetes APIs. Think: EKS is justified by compatibility; choose Fargate only if serverless pod capacity meets constraints.
- Scenario: Workers drain a queue with variable backlog. Think: scale workers from queue pressure, not web CPU.
Exam traps
- Auto Scaling does not make a stateful application stateless.
- Fargate is a compute option for containers, not a container orchestrator replacing ECS or EKS.
- Lambda is not the best answer when the runtime, duration, host control, or persistent-process model is incompatible.
- Kubernetes familiarity alone is not a hard requirement for EKS if ECS meets every need with less management.
- A load balancer does not create capacity.
Key takeaways
- Externalize durable state before scaling replaceable compute.
- Choose the execution model from runtime, control, duration, portability, and management constraints.
- Scale components independently using signals tied to their bottlenecks.
- Use the least operationally heavy platform that still meets hard requirements.
How it works
- A load balancer sends requests only to healthy registered targets according to listener and target rules.
- Auto Scaling replaces unhealthy instances and changes desired capacity from policy, schedule, or demand.
- Container orchestrators place and maintain tasks or pods; Fargate supplies managed capacity where supported.
- Lambda creates isolated execution environments as events arrive within service and downstream constraints.
When to use it
- Use EC2 for guest-OS control, custom agents, specialized hosts, or incompatible runtimes.
- Use Lambda for event-driven function execution and Fargate for managed long-running container compute.
- Use ECS for AWS-native orchestration and EKS when Kubernetes is a requirement.
- Use horizontal scaling for replaceable tiers and vertical scaling when the workload cannot distribute.
Security and governance implications
- Attach roles to compute instead of embedding credentials.
- Keep sensitive state in purpose-built protected stores.
- Spread production capacity across failure boundaries and restrict east-west traffic.
- Apply image, dependency, and workload vulnerability management to container and instance fleets.
Operational and diagnostic signals
- If scaling adds capacity but latency remains high, find the true bottleneck: database, dependency, lock, network, or skewed work.
- If targets churn, compare health-check behavior, startup time, deployment changes, and actual application health.
- If serverless calls overwhelm a database, add connection management, buffering, or controlled concurrency.
More detail
- Stateless does not mean no data; it means any compute copy can handle a request because durable state is external or replicated appropriately.
- Containerizing an application can reduce runtime change without automatically redesigning its data and coupling boundaries.
- Serverless minimizes infrastructure management but still requires concurrency, downstream capacity, retry, and security design.
- Managed services often reduce operations, but hard compatibility or control requirements can justify instances.
Ready for the quiz?
- Why does local session state impede horizontal scaling?
- Which constraint favors EC2 over Lambda or Fargate?
- When does EKS beat ECS?
- How do load balancing and Auto Scaling differ?
- Which metric should drive queue-worker scaling?
Related objectives
- D2.1.K4
- D2.1.K6
- D2.1.K8
- D2.1.K10
- D2.1.K12
- D2.1.K14
- D2.1.S2
- D2.1.S4
- D2.1.S5
- D2.1.S6