Study guide
Technical reference and lesson notes
Purpose of This Lesson
Scaling decisions determine how an application handles increased demand and how resilient it is to infrastructure failures. AWS architects must distinguish between scaling up a single resource and scaling out across multiple resources, while also understanding whether application state is stored locally or externalized.
The preferred approach for many web workloads is to scale out across multiple instances and Availability Zones. However, some components—especially certain databases and stateful systems—may require vertical scaling or a different architecture.
Key Concepts
Stateful vs. Stateless Applications
A stateful application retains information about a user, session, transaction, or other interaction. Examples include:
- An e-commerce application tracking browsing history or purchases.
- A database recording orders and customer information.
- An application storing files or session data on a local server filesystem.
A stateless application does not depend on information stored on a particular application server between requests. Each request can be handled by any suitable instance. A simple weather website is an example when it only returns current weather information and does not maintain user-specific session data.
State does not necessarily belong in the web tier. For example:
- Cart data may be stored in a browser cookie, making the web server itself stateless.
- Purchase records belong in a persistent database, which is stateful.
- Files created by the application may need to be stored in a shared or external service rather than on an individual instance.
The key architectural question is not whether the overall system has state, but where that state is stored and whether any single application instance depends on it.
Scaling Up: Vertical Scaling
Scaling up, also called vertical scaling, increases the capacity of an individual server or resource.
For an Amazon EC2 instance, this usually means changing to a larger instance type with more:
- vCPUs
- Memory
- Network capacity
- Other instance-specific resources
For example, replacing a small instance with a larger instance provides more capacity to the same operating system and application process.
Vertical scaling may require a restart or interruption when changing the instance type. It also leaves the workload concentrated on one resource unless additional redundancy is introduced.
Scaling Out: Horizontal Scaling
Scaling out, also called horizontal scaling, adds more instances or resource nodes to distribute the workload.
A typical web-tier design uses:
- Multiple EC2 instances running the same application.
- An Elastic Load Balancing load balancer distributing incoming requests.
- Auto Scaling to add or remove instances as demand changes.
- Multiple Availability Zones to reduce the impact of an individual instance or Availability Zone failure.
Horizontal scaling works best when any instance can process any request. This generally requires the application tier to be stateless or to have its state externalized.
Externalizing Application State
A stateful application can often be redesigned so the application servers remain interchangeable. Common examples include:
- Moving shared files from an instance filesystem to Amazon EFS.
- Moving relational data to Amazon RDS.
- Using Amazon DynamoDB for suitable non-relational application data.
- Keeping session or other shared state in a purpose-built external data store.
Externalizing state allows multiple application instances to serve users without requiring a specific user to return to the same server. The exact service depends on data model, consistency, access pattern, performance, and durability requirements.
Scaling and Failure Impact
Scaling out can reduce the impact of an individual instance failure. If one of several web servers becomes unavailable, the load balancer can stop routing traffic to it while the remaining instances continue serving requests.
This is not the same as eliminating failure. The system still requires:
- Health checks and failure detection.
- Appropriate load-balancing behavior.
- Capacity to handle the remaining workload.
- Deployment and recovery processes.
- Multi-AZ placement where appropriate.
Exam-Relevant Takeaways
- Scaling up means increasing the size or capacity of one resource.
- Scaling out means adding more resources and distributing workload among them.
- Scaling up is also called vertical scaling; scaling out is also called horizontal scaling.
- Stateless web servers are strong candidates for horizontal scaling behind an Elastic Load Balancing load balancer.
- A database may be difficult to scale horizontally, particularly for writes, and may initially require vertical scaling.
- Local files, local sessions, or instance-specific state can prevent a web tier from scaling out cleanly.
- Externalizing state allows multiple instances to remain interchangeable.
- Horizontal scaling can improve availability because a single instance failure has a smaller blast radius.
- Placing instances across multiple Availability Zones improves resilience beyond simply running multiple instances in one location.
- Scaling out is often preferred for web and application tiers, but it is not automatically the right answer for every workload.
Architecture Decision Guide
| Requirement or workload characteristic | Typical approach | Important consideration |
|---|---|---|
| Stateless web application | Scale out with multiple EC2 instances | Use Elastic Load Balancing and distribute instances across Availability Zones |
| Application stores files on local instance storage | Externalize files, then scale out | Amazon EFS may be suitable when shared filesystem access is required |
| Relational database requiring more write capacity | Often scale up first | Horizontal database scaling may require partitioning, sharding, replicas, or application changes |
| Static website or identical content-serving instances | Scale out | Any healthy instance can generally serve the request |
| Dynamic application with local session or file state | Redesign state handling before scaling out | Move shared state to an appropriate external service |
| Single instance with insufficient CPU or memory | Scale up | May require an instance-type change and restart or interruption |
| Workload where one server failure is unacceptable | Scale out and deploy redundantly | Include health checks, load balancing, and multi-AZ placement |
Common Exam Traps
- Confusing more powerful with more instances: Changing an EC2 instance type is scaling up, not scaling out.
- Assuming a database should always scale out: Relational databases often require vertical scaling for additional capacity, especially when write coordination is important.
- Ignoring local state: Adding instances does not solve problems caused by sessions, files, or data stored only on one server.
- Treating cookies as server-side state: If cart information is stored in a client-side cookie, the web server may remain stateless, although cookie size, security, and integrity still require consideration.
- Assuming multiple instances automatically provide high availability: Instances should be distributed across Availability Zones and managed with health checks and appropriate routing.
- Using a load balancer without making the application interchangeable: Requests can fail when users are sent to instances that do not have the required local session or file data.
- Believing scaling out is always cheaper or simpler: It may require application redesign, external data services, coordination, and operational complexity.
Real-World Engineer Notes
- Design the web and application tiers to be disposable. An instance should be replaceable without losing user or business data.
- Separate compute from durable state. EC2 instances can host application processes, while databases and shared files should use services designed for persistence and availability.
- Evaluate write behavior separately from read behavior. A system may scale reads using additional nodes or caching while still requiring vertical scaling or partitioning for writes.
- Scaling out should be combined with capacity planning. If one instance fails, the remaining fleet must have enough capacity to handle the increased load.
- Test instance replacement and Availability Zone failure rather than assuming redundancy works as intended.
- Do not externalize data blindly. Choose between services such as Amazon EFS, Amazon RDS, and Amazon DynamoDB based on access patterns and data requirements.
- State externalization can introduce latency, consistency, throughput, and cost tradeoffs. These should be included in the design rather than treated as free improvements.
Quick Reference Summary
- Scale up / vertical: Make one resource larger.
- Scale out / horizontal: Add resources and distribute traffic.
- Best fit for scale out: Stateless web and application tiers.
- Typical AWS components: EC2, Elastic Load Balancing, Auto Scaling, and multiple Availability Zones.
- Main obstacle to scale out: State tied to a particular instance.
- Common state solutions: Amazon EFS for shared files, Amazon RDS for relational data, and Amazon DynamoDB for suitable key-value or document data.
- Database rule of thumb: Scaling up is often simpler for write-heavy relational workloads, though more advanced horizontal designs are possible.
- Resilience benefit: Multiple instances reduce the effect of an individual instance failure.
Flashcards
1. What is scaling up?
Scaling up, or vertical scaling, increases the capacity of a single resource, such as changing an EC2 instance to a larger instance type.
2. What is scaling out?
Scaling out, or horizontal scaling, adds more instances or nodes and distributes workload across them.
3. Why are stateless applications easier to scale out?
Any healthy instance can process a request because the application does not depend on state stored on a particular server.
4. What AWS service distributes requests across multiple EC2 instances?
Elastic Load Balancing.
5. Why can local files prevent horizontal scaling?
A request routed to another instance may not find files created on the original instance. Shared files should be moved to an external or shared storage service when appropriate.
6. Give an example of state stored outside the web server.
Cart data stored in a client cookie or purchase data stored in a database.
7. Which scaling approach is often initially used for a relational database?
Scaling up, especially when additional write capacity is needed and horizontal partitioning is not yet implemented.
8. How does scaling out reduce failure impact?
Traffic can continue through healthy instances when one instance fails, reducing the affected capacity and blast radius.
9. Why should EC2 instances be distributed across Availability Zones?
To reduce dependence on a single Availability Zone and improve resilience against localized failures.
10. What must be addressed before putting a dynamic application behind a load balancer?
Session data, files, and other state must either be externalized or handled so that requests can safely reach different instances.
Practice Questions
Question 1
A company runs a web application on one EC2 instance. CPU usage frequently reaches 95%, but the application stores no session data or files on the instance. The company wants improved capacity and better tolerance of an instance failure. Which design best addresses both requirements?
Correct answer: Deploy multiple EC2 instances across Availability Zones behind an Elastic Load Balancing load balancer, with Auto Scaling configured as appropriate.
Explanation: The application is stateless, so it can scale horizontally. Multiple instances distribute traffic and reduce the impact of a single instance failure. Merely changing to a larger instance would increase capacity but would not provide the same redundancy.
Question 2
A dynamic application stores uploaded files on the local filesystem of its EC2 instance. The team adds more instances behind a load balancer, but users cannot always see files they previously uploaded. What is the best architectural improvement?
Correct answer: Move the shared files to an external storage solution such as Amazon EFS when shared filesystem access is required, then use interchangeable application instances.
Explanation: Local filesystem state is tied to a particular instance. Externalizing the files allows requests routed to different instances to access the required data. The final service choice should also consider the application’s access pattern and storage requirements.
Question 3
A MySQL database is experiencing insufficient write capacity. The application uses relational transactions and has not been designed for sharding. Which scaling approach is generally the most direct initial option?
Correct answer: Scale up the database resource to provide more capacity.
Explanation: Increasing the capacity of the individual database is often simpler for a write-intensive relational workload. Scaling horizontally may be possible, but it can require sharding, partitioning, replication, or significant application changes.
Question 4
An architect changes an EC2 instance from a small instance type to a larger instance type. Which statement is correct?
Correct answer: This is vertical scaling, also called scaling up.
Explanation: The architecture still uses one instance; only the capacity of that resource has changed. Adding additional instances would be horizontal scaling, or scaling out.
Question 5
A company runs six identical web-server instances in one Availability Zone behind a load balancer. What additional change most directly improves resilience to an Availability Zone failure?
Correct answer: Distribute the web-server instances across multiple Availability Zones and configure the load balancer to use those zones.
Explanation: Multiple instances in one Availability Zone protect against an individual instance failure but not against an Availability Zone failure. Multi-AZ placement reduces this larger failure domain.