Rapid elasticity is one of the five essential characteristics of cloud computing per NIST SP 800-145. The definition: ‘Capabilities can be elastically provisioned and released, in some cases automatically, to scale rapidly outward and inward commensurate with demand.’ In practice: the workload scales up when traffic increases, scales down when traffic decreases, and the scaling is automatic (or near-automatic). The team that runs a workload with rapid elasticity has a cost that matches the load; the team that runs a fixed-size cluster over-provisions most of the time.
Table of contents
- The NIST definition
- What it looks like in practice
- Rapid elasticity vs scalability
- The four patterns of elasticity
- The implementation options
- The hidden costs
- How this fits the rest of the stack
- FAQ
The NIST definition
From NIST Special Publication 800-145 (‘The NIST Definition of Cloud Computing’, by Mell and Grance, 2011):
‘Capabilities can be elastically provisioned and released, in some cases automatically, to scale rapidly outward and inward commensurate with demand. To the consumer, the capabilities available for provisioning often appear to be unlimited and can be appropriated in any quantity at any time.’
The key words: elastically, provisioned and released, in some cases automatically, scale rapidly outward and inward. The team that hits these is doing cloud right.
What it looks like in practice
An e-commerce site handles a flash sale:
-
Normal load: 10 web servers, 50 database connections.
-
Sale starts: load increases 10x in 5 minutes.
-
Auto-scaling adds 90 more web servers (now 100). Database adds read replicas (now 5).
-
Sale ends: load drops back to normal over 30 minutes.
-
Auto-scaling removes the 90 extra web servers (back to 10). Database removes 4 read replicas (back to 1).
Total capacity matches demand the whole time. The user-facing experience is consistent (no slowdowns during the spike). The cost matches the demand (no over-provisioning during normal hours).
The team that does this is the team that uses cloud-native patterns: horizontal scaling, auto-scaling groups, serverless, container orchestration with HPA.
Rapid elasticity vs scalability
The terms are related but not the same:
Scalability is the ability to handle increased load. A system that scales from 1 to 1000 servers is scalable.
Elasticity is the ability to scale up AND down, automatically, in response to demand. A system that scales 1 -> 1000 -> 1 automatically as load changes is elastic.
A system can be scalable without being elastic (you can scale up, but you do it manually, and you forget to scale down). The team that has scalability but not elasticity over-provisions.
The four patterns of elasticity
Manual scaling - the human adds/removes resources based on observed load. The team that does this watches the dashboard and adjusts. The least efficient pattern; common in small/legacy setups.
Scheduled scaling - the system scales at known times (e.g., scale up at 9 AM, down at 6 PM). The team that has predictable traffic patterns (business hours, weekday traffic) uses this. AWS Auto Scaling supports scheduled actions.
Reactive (metric-based) scaling - the system scales based on a metric (CPU > 70% -> add 2 servers). The team that uses HPA in Kubernetes, target tracking in AWS Auto Scaling, or similar metric-based policies uses this. The most common pattern.
Predictive (ML-based) scaling - the system uses machine learning to predict load and pre-scale. AWS Predictive Scaling uses historical data to anticipate. The team that has spiky traffic (e.g., TV-show-driven) uses this for the best results.
The implementation options
AWS Auto Scaling - EC2 instances, target tracking policies, scheduled actions, predictive scaling.
Google Cloud Autoscaler - MIGs (managed instance groups) with similar features.
Azure VMSS - Virtual Machine Scale Sets with autoscale rules.
Kubernetes HPA - Horizontal Pod Autoscaler, scales pods based on metrics. VPA (Vertical) and KEDA (event-driven) are the variants.
Serverless - AWS Lambda, Google Cloud Functions, Azure Functions. The cloud provider handles the scaling; the user writes the function.
Container services - AWS ECS Fargate, Google Cloud Run, Azure Container Apps. Serverless containers with automatic scaling.
The team that picks the right pattern has a system that scales with demand. The team that picks the wrong pattern has either over-provisioning (cost) or under-provisioning (user-visible degradation).
The hidden costs
Rapid elasticity has hidden costs:
-
Cold starts - new instances take time to boot, warm caches, establish connections. A new EC2 instance is ready in 30-60 seconds. A new Lambda is ready in milliseconds.
-
Database scaling is harder - adding web servers is easy; adding database capacity (sharding, read replicas) is much harder. The team that has an elastic frontend and a fixed-size database has the database as the bottleneck.
-
Stateful services don’t scale as easily - a web server is stateless and scales linearly. A session server (with sticky sessions) does not. A database with strong consistency does not.
-
Cost variability - elastic systems have variable cost. The team that budgets for the average and gets a 10x spike has a surprise bill.
FAQ
Is elasticity the same as auto-scaling?
Close. Auto-scaling is the implementation of elasticity. A system with auto-scaling is elastic. A system with manual scaling is scalable but not elastic.
Can I have rapid elasticity with on-prem servers?
Yes, but with caveats. Kubernetes HPA works on-prem. The catch: the physical hardware is fixed, so you cannot scale beyond the cluster’s capacity. The team that runs on-prem and wants true elasticity (scale beyond the local cluster) bursts to a public cloud.
What is the difference between vertical and horizontal elasticity?
Vertical: scale up a single instance (more CPU, more RAM). Horizontal: scale out (more instances). Horizontal is more common in cloud (easier, no downtime); vertical has limits (you cannot scale a single VM beyond the largest available size).
How fast can auto-scaling respond?
AWS EC2 auto-scaling: 30-60 seconds for a new instance to be ready. Lambda: milliseconds (the function is already running, the platform just routes more requests). Kubernetes HPA: 30-60 seconds for a new pod. The team that needs millisecond response uses serverless.
What is the difference between elasticity and scalability?
Scalability is the ability to handle increased load. Elasticity is the ability to scale up AND down, automatically, in response to demand. The team that has a scalable system can handle a spike; the team that has an elastic system handles it without manual intervention.
How this fits the rest of the stack
For a sense of what the full project costs before it commits, the RunxBuild hosting calculator shows the line items together. The API, the database, the storage, the worker, the bandwidth - each one is a separate number, and the team’s mental model for the platform is the sum of those numbers.
Useful related references: