What is rapid elasticity in cloud computing?

Rapid elasticity is the cloud's ability to provision and release capacity quickly, often automatically, so resources scale out and in with demand. NIST lists it as one of the five essential characteristics of cloud computing. To the user, available capacity appears unlimited and can be taken in any quantity at any time, then handed back.

Key takeaways

• NIST SP 800-145 defines it as capabilities that "can be elastically provisioned and released, in some cases automatically, to scale rapidly outward and inward commensurate with demand".
• Both directions count. Releasing capacity when demand drops is what turns elasticity into cost savings.
• In practice it is delivered by auto scaling: metrics, scaling policies, minimum and maximum limits, and a load balancer.
• Elasticity is short-term and automatic; scalability is the long-term ability to grow. A cloud workload needs both.
• It only works if the application is built for it: stateless servers, external session storage and a database that can keep up.

The NIST definition, word for word

The US National Institute of Standards and Technology wrote the definition most textbooks and certification exams use. In NIST Special Publication 800-145, The NIST Definition of Cloud Computing, it reads:

"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 other four essential characteristics are on-demand self-service, broad network access, resource pooling and measured service. Each phrase in the definition has a practical meaning:

• "Provisioned and released": capacity goes back as well as out. A system that only grows is scalable, not elastic.
• "In some cases automatically": automation is common but not required. A person clicking "add five servers" and getting them in minutes still fits the definition.
• "Outward and inward": the definition describes horizontal scaling, adding and removing instances, rather than resizing one machine.
• "Commensurate with demand": capacity should track actual load, not a forecast made months ago.
• "Appear to be unlimited": the provider's pool is so large that a single customer rarely hits its edge, though account quotas still apply.

How does it work in practice?

Cloud providers deliver elasticity through auto scaling services. AWS Auto Scaling, for example, "monitors your applications and automatically adjusts capacity to maintain steady, predictable performance at the lowest possible cost". Azure and Google Cloud offer equivalent services for virtual machine groups, containers and databases.

A typical setup has five parts:

1. Metrics such as CPU use, requests per target or queue length, collected every minute or faster.
2. Policies that say when to act: keep CPU near 50%, add two instances when the queue passes a threshold, or add capacity every weekday at 08:00.
3. Limits: a minimum to stay available and a maximum to cap cost.
4. Provisioning from a template or image, so new instances are identical and start quickly.
5. A load balancer that sends traffic to new instances once health checks pass, and drains them before removal.

Microsoft's Azure Well-Architected Framework notes the design consequence: scaling out virtual machines "requires a separate load balancer, client-request handling, and externally stored state." Elasticity is an application design property as much as a platform feature.

Rapid elasticity vs scalability

Scalability is whether a system can handle more load when given more resources. Elasticity is whether it gets and releases those resources quickly and automatically as load changes.

For an enterprise view of the options, including VM auto scaling groups, containers and serverless, read our guide to elastic scalability in cloud computing.

Examples

• Retail sales events. An online shop scales its web and checkout tier out for a Black Friday campaign, then back to normal the next week.
• Seasonal businesses. A ski resort's booking and webcam sites carry most of their traffic in a few winter months.
• Media releases. A streaming or news service adds capacity when a popular release or breaking story drives a surge.
• Batch analytics. A finance team runs month-end reports on hundreds of cores for an hour instead of a few servers for days.
• Development and test. Test environments start for a load test or a pull request and are deleted afterwards.

The seasonal case is real for Opsio customer Branäsgruppen, one of Sweden's largest ski resort groups, with up to 15,000 riders per day at peak. Its on-premises VMware environment had to be scaled by hand before each demand peak, and performance dropped until it was. After the move to AWS, the Branäsgruppen case study describes web front-ends, middleware and database layers that now expand and contract automatically with seasonal demand.

Benefits and limits

The benefits are direct: you pay for peak capacity only during the peak, users get consistent response times, and nobody has to add servers by hand before a campaign.

The limits are just as practical:

• Start-up time. New virtual machines take time to boot and warm up. Very sharp spikes need headroom, pre-warmed capacity or serverless.
• The data tier. Web servers scale easily; relational databases do not. Plan read replicas, caching or a managed database that scales.
• Quotas. Account limits on instances or concurrency can stop scale-out. Raise them before known peaks.
• Cost surprises. A bug or bot traffic can scale you out quickly. Always set a maximum and budget alerts.
• Licensing. Software licensed per server or per core may not allow short-lived instances.

Does your workload have it? A quick check

• Can any single server be terminated without users losing their session or data?
• Is there a scaling policy with tested minimum and maximum limits?
• Does capacity actually drop after a peak? Check last month's instance count graph.
• Has the database been load tested at peak traffic, not just the web tier?
• Are service quotas high enough for your largest expected peak?

If several answers are "no", the workload is hosted in the cloud but not yet elastic. Opsio's AWS managed service and cloud consulting teams review and fix these gaps as part of architecture work.

Frequently asked questions

What is rapid elasticity in cloud computing?

It is one of the five essential characteristics of cloud computing defined by NIST: capacity can be provisioned and released quickly, sometimes automatically, to scale out and in with demand, and to the user it appears unlimited.

What is an example of rapid elasticity?

An online store that runs four web servers on a normal day, scales automatically to twenty during a sales campaign, and returns to four when the campaign ends. It pays for the extra sixteen servers only while they run.

What is the difference between elasticity and scalability?

Scalability is the ability to handle more load by adding resources, usually over the long term. Elasticity is adding and removing those resources quickly, often automatically, as demand rises and falls.

Is rapid elasticity the same as auto scaling?

Not quite. Elasticity is the characteristic; auto scaling is the most common way to deliver it. NIST's definition says provisioning happens "in some cases automatically", so fast manual scaling also counts, but in practice cloud teams automate it.

Why is elasticity important in cloud computing?

Because it removes the choice between paying for idle capacity and running out of capacity at peak. You size for today's demand, scale out when it rises and scale back in when it falls.

For hands-on delivery in India, see Opsio's scalability practice.

Related reading

• What Is Cloud Elasticity
• How Can Elastic Computing Optimize Your Cloud Costs?
• What Are the Key Benefits of Elasticity in Cloud Services?