What the exam asks
- Make tiers stateless by moving sessions, files and caches off the instances.
- Choose horizontal or vertical scaling, and identify the component that limits scale.
- Break a monolith into microservices that each own their data store, and migrate one piece at a time.
- Match a business need to a managed AI service.
- Pick purpose-built services such as Transfer Family, AppFlow and Amplify so that nobody has to run servers.
Core ideas
Multi-tier and stateless design
A classic three-tier design has three tiers, each in its own subnet layer and scaled on its own:
- a web or presentation tier (ALB and ASG, or CloudFront and S3);
- an application tier (ASG, containers or Lambda);
- a data tier (RDS, Aurora or DynamoDB).
A tier can scale horizontally only if any instance can serve any request, so state must live elsewhere:
| State | Move it to | Notes |
|---|---|---|
| User sessions | ElastiCache (Valkey or Redis OSS) or DynamoDB | Removes the need for sticky sessions |
| Uploaded or generated files | S3 (objects, needs code changes) or EFS (a shared POSIX mount, no code changes) | EFS spans AZs; S3 scales without limit |
| Cached query results | ElastiCache or DAX | Offloads the database |
| Scheduled or background work | An SQS queue and a separate worker tier | The web tier stays responsive |
Horizontal versus vertical scaling
- Vertical scaling (a bigger instance) is simple and needs no code changes. But it has a ceiling, usually needs a restart, and keeps a single point of failure.
- Horizontal scaling (more instances) needs stateless components and a load balancer or queue in front. In return you get elasticity and multi-AZ resilience.
- The usual limit is the relational writer:
- scale reads with read replicas or caching;
- move key-value or spiky workloads to DynamoDB;