Elasticity

Elasticity means adjusting resource capacity as demand changes, in both directions. An elastic application can acquire additional capacity during a traffic spike and release that capacity afterward. The goal is not simply to make a system larger; it is to keep capacity appropriately aligned with the work being performed. Cloud platforms make this practical by providing resources through APIs instead of requiring engineers to purchase, install, and later retire physical equipment.

Consider an online store that normally needs two application servers but requires twelve during a sale. An elastic design adds servers as demand rises and removes the additional servers when traffic returns to normal. Without elasticity, the business might keep twelve servers running continuously or accept poor performance during the sale. Releasing unnecessary resources can reduce usage charges, although retained storage, minimum capacity, and other supporting infrastructure may still incur costs.

Elasticity and scalability are related but different. Scalability describes a system's ability to handle changing workload levels by changing capacity. Elasticity emphasizes matching capacity to fluctuating demand and relinquishing resources when they are no longer needed. Horizontal scaling adds or removes instances, containers, or workers; vertical scaling changes the resources assigned to an individual component. Both can support elasticity, but vertical changes may require restarts and have tighter size limits.

Automatic scaling is a common mechanism for implementing elasticity. Policies can respond to CPU utilization, request volume, or queue backlog, while scheduled actions can prepare capacity for known events. For example, background workers might scale out when queued jobs accumulate and scale in after processing catches up. On AWS, Amazon EC2 Auto Scaling provides elasticity by adjusting the number of EC2 instances according to configured policies and capacity limits. Provisioning a fixed set of cloud instances does not automatically make an application elastic.

Application design determines whether additional resources are useful. Stateless request handlers, shared session storage, distributed work queues, and graceful shutdown procedures make it easier to add and remove workers safely. A database bottleneck or an external API limit can prevent extra application servers from improving throughput. Scaling signals should therefore reflect the actual constraint rather than relying on CPU usage alone.

Elasticity is not instantaneous or unlimited. Resource quotas, available capacity, instance startup time, application initialization, and scaling-policy settings affect response speed. Minimum capacity can protect latency during sudden bursts, while maximum capacity limits spending and resource consumption. Scale-in must allow active requests or jobs to finish, and poorly tuned policies can repeatedly add and remove resources.

Elasticity is also distinct from high availability and agility. High availability keeps a workload accessible despite failures, typically through redundancy and fault isolation. Agility is the ability to experiment and deliver changes quickly. An elastic workload can still have a single point of failure, and a highly available workload can use fixed capacity. For exam questions, associate elasticity with matching resources to changing demand, high availability with continued operation, and agility with faster experimentation and delivery.