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.”

Note the company it keeps in that definition. The binding has to enable “data and application portability,” which is precisely the requirement bursting depends on and the reason it is harder than the diagram suggests.

Distinguish it from capacity behaviour inside one provider. A platform that lets a workload exceed its purchased capacity briefly and settles the consumption afterwards 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 workload runs in the other environment. Same artifact, same configuration, same dependencies available. A workload that needs a component only the primary environment has does not burst; it fails over to something that cannot serve.
• 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.

Those are the same conditions as failover, which is the useful thing to notice: a team that can burst can usually fail over, and a team that cannot fail over cannot burst either, whatever the architecture diagram shows.

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 two environments. Identity, policy, and monitoring have to hold in both, which is the recurring consistency cost any second environment brings. The published guidance on multicloud lists exactly this: “increasing management complexity” and “achieving consistent cross-cloud performance and reliability.”
• Rehearsing. An unexercised burst path is a belief. Rehearsal costs time and produces the only evidence that the mechanism works.

Against that, the saving is the difference between provisioning for the peak and provisioning for the normal level — so the comparison is worth doing with real numbers, including how often the peak occurs and how long it lasts. A spike that arrives twice a year for an hour rarely justifies a permanently maintained second environment; one that arrives every month for a week may.

Cheaper alternatives to rule out first

Bursting between environments is the most complex answer to a peak, so it is worth being the last one considered.

• Scale within the primary environment. If that environment is a public cloud, this is usually the whole answer and the rest of this entry is unnecessary.
• Move the peak rather than absorb it. Queue the work, shift batch jobs out of the busy window, or shed low-value load deliberately. Cheaper than any capacity, and often acceptable.
• 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 — is a realistic candidate, and it is the shape of most bursting that works in practice.

That last item is the honest scope of the pattern. What limits it is not the compute but the data: the workloads that burst well are the ones whose inputs are small or already portable, 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.