3 Scalability and Elasticity

Scaling to support growth

Scalability describes whether a system can handle a growing workload by increasing capacity while continuing to meet performance requirements. Capacity may be increased by changing the resources available to existing servers or by adding more servers or instances.

Vertical scaling (scaling up) gives an existing server more resources, such as CPU or memory. Horizontal scaling (scaling out) adds servers or other instances so work can be shared among more resources. A web application experiencing steady traffic growth might move to larger servers, add application instances behind a load balancer, or do both. Scaling for growth may be planned or initiated manually.

Adjusting capacity with demand

Elasticity is the ability to add capacity as demand rises and release it as demand falls, often automatically and quickly. Rather than keeping peak capacity running at all times, an elastic workload adjusts capacity to track changing demand. Rapid elasticity is described as provisioning and releasing capabilities to scale outward and inward in line with demand.

For example, an online store may receive a short-lived traffic surge during a sale. An elastic system can add application instances to serve the extra requests and remove them after the sale ends. This can help maintain responsiveness while reducing the cost of unused capacity. The results depend on how quickly resources can be added and whether the application and its dependencies can use them effectively.

How scalability and elasticity differ

Scalability asks whether a system can handle more workload by increasing capacity; it commonly supports sustained growth or larger workloads. Elasticity asks whether capacity can adjust upward and downward as demand changes; a typical pattern is to add resources during a surge and release them when it passes.

The concepts are related, not opposites: elasticity uses scaling mechanisms to adjust capacity as demand changes. A system may be scalable but not elastic—for instance, staff might add servers for growth but have to remove them manually, or leave them running after a temporary peak. An elastically scaling system still needs a design that can distribute work across added capacity and remain functional when capacity is reduced.

Matching the approach to demand

Choose an approach based on the workload’s shape:

• Steady, long-term growth: Plan for scalability by adding capacity or redesigning components as the workload grows.

• Short, predictable peaks: Use Scheduled scaling where appropriate, increasing capacity before a known event and reducing it afterward.

• Unpredictable or rapidly changing demand: Use Demand-based elasticity with policies that respond to useful signals, such as request rate, queue depth, or resource utilization.

• Steady growth combined with spikes: Design for scalability and add elasticity so the system can adapt to short-term changes on top of its baseline capacity.

Planning and testing capacity changes

Scaling is not instantaneous in every system because provisioning takes time. Maintain enough baseline capacity to serve demand while additional resources start. Choose signals that reflect the workload: for a background job-processing system, queue depth may be more informative than CPU utilization.

Test both scale-out and scale-in behavior. Confirm that performance is maintained as capacity is added and that reducing capacity does not interrupt work. Automating scaling and testing workloads under load are also recommended practices.

AWS scaling examples

Amazon EC2 provides on-demand compute capacity that can be increased or decreased as needs change. An EC2 Auto Scaling group can manage a group of instances and adjust capacity according to configured scaling policies. This supports horizontal scaling by adding instances when more capacity is needed and removing them when demand drops. Application Auto Scaling is also available for supported services beyond EC2. The appropriate service and scaling policy depend on the workload and its response-time requirements.

For a video-processing application, jobs might wait in a queue while worker instances process them in parallel. As the queue grows, the application can add workers; as the queue drains, it can reduce their number. The queue is a signal directly tied to pending work. The scaling policy should also account for worker startup time and any minimum capacity needed to keep the service responsive.