Cloud Bursting

Cloud bursting is the pattern of running normal load in one environment and sending demand above its capacity to another — typically from a datacenter or a reserved pool into a public cloud. NIST names it as an example of what binds a hybrid cloud together: “cloud bursting for load balancing between clouds.”

Portability can make bursting easier, but the actual requirement is that overflow work runs correctly in the second environment. Environment-specific configuration or implementations can be valid when behavior, data access, and operating contracts are compatible.

Distinguish it from capacity behavior inside one provider. A platform that lets a workload exceed its purchased capacity briefly and settles the consumption afterward is doing something else — see capacity bursting and smoothing for that mechanism. This entry is about sending work to a different environment.

Four conditions, all required

• The overflow work can run correctly. Verify compatible code, configuration, dependencies, and results. A burst worker may use a database or queue in the healthy primary environment; that dependency is acceptable only if its capacity, latency, and availability fit the burst requirement.
• The data is reachable there, current enough, at that moment. This is the condition that decides feasibility. Reading across the boundary on every request adds latency and transfer cost to exactly the requests you are struggling to serve; replicating in advance means paying to keep a copy current for a spike that may not come.
• Capacity is available when needed and quickly enough. On-demand capacity is not guaranteed by the absence of a reservation, and starting an environment takes time — if the spike lasts ninety seconds and the extra capacity is ready in six minutes, the mechanism did nothing.
• Traffic can be moved. Something has to decide to send the overflow, and that decision point — a load balancer, a queue consumer, a DNS change — must itself not be the bottleneck or the single point of failure.

Bursting and failover are not interchangeable. Cloud workers using an on-premises database or load balancer can absorb peaks but stop when the primary site fails. Conversely, a recovery procedure that meets a long recovery time objective may be too slow for a short peak. Test peak response time separately from primary-loss recovery, including data-loss limits and write ownership for failover.

What it costs to keep ready

The appeal is paying for peak capacity only during peaks. The costs are mostly in readiness rather than in the burst itself, and four of them are recurring.

• Keeping data available. Continuous replication, or the transfer at the moment of the spike. Either is a bill; the second is also a latency penalty under load.
• Keeping the second environment deployable. Images, dependencies, secrets, and network paths have to work today, not in the version they were left at last quarter — which means deploying to it regularly rather than only during incidents.
• Operating the environments. Maintain identity lifecycle controls, comparable policy outcomes, correlated monitoring, and responders for each environment and their dependencies. Shared tooling also requires maintenance and outage planning.
• Rehearsing. An unexercised burst path is a belief. Rehearsal costs time and produces the only evidence that the mechanism works.

Compare readiness cost with the alternative capacity plan using peak size, frequency, duration, deadlines, startup delay, and reuse of existing tools. A rare but very large peak can justify bursting; a frequent small peak may not. Frequency alone does not decide the economics.

Compare alternatives against the same service objective

Compare bursting with alternatives that meet the same service objective. Its integration and readiness costs can be substantial, but the relative cost depends on what is already available.

• Scale within the primary environment. Check service limits, available capacity, startup time, and cost before adding another environment.
• Reschedule or bound demand. Queue work, move batch jobs, or shed lower-value load only when deadlines and agreed behavior permit it. Compare the business impact with adding capacity.
• Serve the peak differently. Caching, precomputation, and a degraded-but-useful response handle many spikes without more compute.
• Burst one component, not the system. A stateless, compute-heavy, data-light part — image processing, a simulation, a batch scoring job — can be a suitable candidate when its inputs are reachable and startup fits the deadline.

Small or already portable inputs reduce the work needed to make data available in the burst environment. Larger or tightly coupled data adds transfer, synchronization, and latency requirements, which is data gravity deciding the design again. How bursting fits with connectivity, consistency, and availability across environments is worked through in Two Clouds, Twice the Operations.

References:

• NIST SP 800-145, The NIST Definition of Cloud Computing
• Google Cloud Architecture Center, Drivers for hybrid and multicloud architectures
• Google Cloud, Cloud bursting pattern
• AWS, Static stability