概要
Key takeaways
- Elastic computing dynamically scales compute, memory, and storage as demand fluctuates, removing manual administrative intervention.
- De-provisioning idle resources when demand drops is just as critical as scaling up; scale-down efficiency directly dictates cloud cost savings.
- “Elastic computing” and “cloud elasticity” refer to the same operational capability and are used interchangeably across enterprise cloud architecture.
- Elasticity delivers maximum ROI for bursty, seasonal, and ad-hoc AI/analytics workloads. Continuous, steady-state reporting workloads benefit far less.
- Without hard scaling limits, real-time telemetry, and department-level cost attribution, dynamic auto-scaling can create unmanaged operational expenditure.
On this page
- Elastic computing defined
- How elastic computing works
- An example of elastic computing in practice
- Elasticity and scalability are not the same thing
- Where elastic computing pays off
- Enterprise considerations
- Elastic computing on Teradata platforms
- Conclusion
- Frequently asked questions
Elastic computing, defined
Traditional enterprise capacity planning relies on static forecasting: Infrastructure teams estimate peak resource requirements, purchase physical hardware or reserved instances to cover that peak, and absorb the financial cost of idle capacity during off-peak windows.
Elastic computing replaces static forecasting with a continuous operational feedback loop. The cloud platform monitors active workload telemetry and dynamically provisions or de-provisions resources in real time.
Two defining attributes separate genuine elastic computing from static reserved infrastructure.
- Automation: Resource adjustments occur programmatically based on real-time utilization triggers, requiring zero human intervention.
- Bidirectionality: Capacity contracts automatically when query concurrency drops, directly curbing variable cloud infrastructure costs.
Across cloud data warehousing, data lakehouses, and enterprise analytics, this architectural property is also called cloud elasticity. Both terms describe the underlying mechanism of matching compute supply to real-time processing demand.
How elastic computing works
What actually scales
In enterprise data platforms and AI architectures, elasticity spans three distinct infrastructure layers—each adjusting at different velocities.
- Compute: Processing capacity provisioned via isolated virtual nodes or execution clusters. Compute is the fastest layer to adjust and serves as the primary dial for managing workload spikes.
- Memory: Scaled alongside compute instances, system RAM is frequently the operational bottleneck for complex analytical joins, high-concurrency vector searches, and distributed machine learning algorithms.
- Storage: Modern cloud data architectures decouple compute from storage, leveraging shared object store tiers. This separation allows compute resources to expand and contract dynamically without repartitioning or physically moving underlying data sets within Teradata Database.
What triggers a scaling event
Scaling actions are governed by system-level monitoring engines tracking operational metrics against predefined policy thresholds. Common operational triggers include:
- Sustained CPU or node utilization exceeding defined limits (e.g., 85% utilization over a three-minute window).
- Growing query queue depths or concurrency limits during unexpected traffic surges.
- Surges in streaming data ingestion pipelines or real-time API requests.
- High-concurrency model scoring, feature engineering, or agentic workflows initiated via the in-database analytics capabilities of Teradata Database.
Enterprise platforms allow system administrators to set explicit upper and lower boundary thresholds, ensuring auto-scaling operates strictly within pre-approved parameters.
Scaling down is the harder half
Expanding capacity during a demand surge is simple; contraction is where cloud economic ROI is won or lost. If compute nodes de-provision too aggressively, subsequent query bursts encounter cold-start latency. If nodes remain provisioned long after execution completes, anticipated cloud cost savings quickly vanish.
With 84% of executive leaders citing cloud spend management as a primary operational hurdle, effective node teardown policies are critical. For an in-depth operational overview of instance provisioning, node teardown, and workload isolation, review the About Teradata Elastic Compute documentation.
An example of elastic computing in practice
Consider a global retail organization running enterprise analytics sized for daily transactional volumes. During an annual promotional event, concurrent user traffic spikes tenfold as supply chain, marketing, inventory, and customer experience teams execute ad-hoc analytical queries simultaneously. Concurrently, automated recommendation models execute continuously rather than in off-peak nightly batches.
Without elastic computing, the enterprise faces two expensive choices.
- Over-provision: Sizing infrastructure permanently for peak promotional volume leaves up to 70% of compute capacity standing idle during standard business weeks.
- Under-provision: Sizing infrastructure for median daily demand leads to query queue timeouts, degraded portal performance, and potential revenue loss during peak promotional hours.
However, with an elastic cloud architecture, independent compute clusters auto-scale outward as query concurrency builds, sustain throughput during peak hours, and automatically terminate when traffic normalizes. The enterprise pays for elevated compute capacity strictly during active operational hours.
Elasticity and scalability are not the same thing
Although often used synonymously, scalability and elasticity address fundamentally different engineering goals:
| Feature dimension | Scalability | Elasticity |
|---|---|---|
| Primary focus | The structural maximum capacity to handle cumulative workload growth over time. | The real-time velocity and automation of resource expansion and contraction. |
| Adjustment model | Adding capacity (vertically via larger hardware or horizontally via extra nodes). | Dynamic, policy-based auto-provisioning and automatic de-provisioning. |
| Operational goal | Supporting long-term, predictable business and data volume expansion. | Matching short-term, fluctuating demand spikes without overpaying for idle hardware. |
| Provisioning speed | Minutes to days (often involving manual admin provisioning or procurement). | Seconds to minutes (driven automatically by system telemetry triggers). |
A system can be highly scalable without being elastic. On-premises data warehouses often scale to petabytes of storage, but adding compute capacity requires hardware acquisition and permanent installation.
For a comprehensive comparative breakdown, read our detailed guide on cloud elasticity vs. cloud scalability.
Where elastic computing pays off
- Bursty and unpredictable workloads: When applications experience substantial variance between baseline and peak resource demands, organizations can see immediate financial returns from implementing on-demand compute allocation.
- Data science, AI, and model training: Training machine learning models, executing retrieval-augmented generation (RAG) vector searches, and running ad-hoc data science exploration require massive compute for limited durations. Elastic compute clusters allow teams to spin up dedicated nodes for execution and spin them down immediately upon completion.
- Seasonal and event-driven processing: Monthly financial closes, quarterly regulatory filings, and promotional retail sales create predictable spikes best served by dynamic allocation rather than permanent hardware expansion. These patterns are already documented in last year’s numbers, which makes them the easiest elasticity cases to justify.
Enterprise considerations
Cost predictability and guardrails
Recent enterprise research indicates that 29% of public cloud infrastructure spend is lost to waste—primarily caused by unmanaged compute scaling and idle developer environments. To maintain budget predictability, FinOps teams must enforce clear infrastructure guardrails: Consumption-based cloud pricing models make that spend visible, and a workload-level cost estimate shows what a given mix actually costs before it is provisioned.
Consider these infrastructure guardrails.
- Defined scaling ranges: Configuring strict upper and lower limits on auto-scaling instance creation to prevent runaway compute spend during query anomalies.
- Real-time telemetry and alerting: Logging scaling events to give platform administrators instant visibility into why resource expansions are triggered.
- Cost attribution and showback: Tagging dynamic compute instances by department, project, or business unit to enforce financial accountability.
Governance and access control
Ungoverned auto-scaling creates operational and security risks. Enterprise cloud deployments must enforce role-based access control (RBAC), ensure data encryption policies automatically extend across dynamic compute clusters, and log all scaling events for compliance auditing.
When elasticity is the wrong answer
Elastic computing is not a universal solution for every enterprise workload profile and may not make sense in these scenarios.
- Predictable baseline processing: Core enterprise data warehouse queries running at constant, high utilization operate far more cost-effectively on dedicated, reserved compute capacity.
- Ultra-low latency SLAs: Workloads unable to tolerate the brief initialization latency required to spin up new compute nodes require pre-allocated, always-on infrastructure.
- Storage- or I/O-bound bottlenecks: Adding compute clusters to an application bottlenecked by network throughput or storage disk I/O will not improve execution speeds.
To evaluate structural trade-offs between dedicated baseline infrastructure and dynamic compute, explore our analysis of The Always-On Reality.
Elastic computing on Teradata
Modern enterprise data architectures must support steady-state business reporting alongside unpredictable, high-concurrency analytics. Teradata Cloud unifies both compute models under a single workload management framework:

- Teradata active compute: Delivers always-on, dedicated compute nodes for predictable enterprise data warehousing, operational reporting, and core dashboarding at stable rates.
- Teradata elastic compute: Provides dynamic, on-demand compute cluster scaling for exploratory data science, ad-hoc departmental analytics, and AI model execution. These isolated clusters scale independently from underlying object storage (including open table formats such as Iceberg and Delta) and automatically de-provision when workloads finish.
By coordinating active compute and elastic compute under unified workload management, enterprise organizations eliminate resource contention, maintain strict cost upper-bounds, and power continuous analytics without over-provisioning infrastructure.
The same workload management applies wherever the platform is deployed across AWS, Microsoft Azure, and Google Cloud.
Conclusion
Elastic computing has redefined how modern enterprises architect and pay for cloud analytics. By dynamically matching compute supply to processing demand in real time, organizations eliminate the need to over-provision expensive infrastructure for brief usage spikes. However, capturing the true financial benefits of cloud elasticity requires deliberate operational governance. Without strict scaling upper-bounds, real-time telemetry, and clear cost attribution, auto-scaling capabilities can rapidly exacerbate cloud spend waste.
The most effective enterprise data strategies combine elastic scaling with dedicated baseline compute, ensuring bursty analytics and AI workloads scale on demand while steady-state reporting runs predictably at maximum cost efficiency.
Ready to optimize your cloud data architecture?
Build a scalable, cost-controlled data foundation
Discover how to balance predictable enterprise workloads with dynamic, on-demand scaling on the Teradata Autonomous Knowledge platform. Explore Teradata Cloud or review the About Teradata Elastic Compute documentation to build a cost-controlled, highly scalable data infrastructure.
弾性コンピューティングの例は何ですか?
弾性コンピューティングの例は何ですか?
明確な例としては、リテールデータプラットフォームが、ピークプロモーションイベント中にクエリ量が急増すると自動的に追加の計算クラスターをプロビジョニングし、需要が正常化するとそれらのクラスターを解除し、企業がアクティブな計算時間のみを支払うことを保証します。
弾力的コンピューティングとはどういう意味ですか?
弾力的コンピューティングとはどういう意味ですか?
エラスティックコンピューティングとは、運用需要の変動に応じてリアルタイムで計算、メモリ、ストレージのリソースを自動的にプロビジョニングおよび解除するクラウドプラットフォームの機能を指します。
弾力性とスケーラビリティの違いは何ですか?
弾力性とスケーラビリティの違いは何ですか?
スケーラビリティとは、長期的な成長に対応するためのシステムの最大構造能力であり、時間をかけて資源を追加することで達成できる能力です。弾力性とは、変動する需要に対応するためにリアルタイムで自動的に容量を拡張・縮小するシステムの能力です。
弾性計算はクラウドの弾力性と同じですか?
弾性計算はクラウドの弾力性と同じですか?
はい。エンタープライズクラウドアーキテクチャ、データエンジニアリング、FinOps全体で、「elastic computing」と「cloud elasticity」は自動計算スケーリングを表す同義語として使われています。