Burst-to-cloud keeps your steady-state workload on-premises and pushes only the peaks into public cloud over a private connection. You pay for cloud capacity when you need it, and the burst traffic never touches the public internet.
When to use it
Use this pattern when demand is spiky rather than steadily growing – seasonal retail peaks, batch runs, rendering or simulation jobs, end-of-period processing. Buying on-premises hardware for the peak wastes capacity for most of the year; bursting rents the peak and gives it back afterwards.
How it works
The baseline runs on-premises. When demand crosses a threshold, additional workload is scheduled into public cloud, and a private connection over IZO™+ Multi Cloud Connect carries the overflow – job data out to the cloud, results back. Because the path is private and bandwidth is shaped per connection, the burst is predictable and isolated from other traffic.
Two things make or break the pattern. The first is data gravity: if the burst workload needs a large dataset that lives on-premises, moving that data can cost more time and money than the compute you gained. Keep bursting workloads close to the data they need, or pre-stage the dataset. The second is egress: results returning from the cloud can incur egress charges, and a private connection reduces the per-gigabyte cost compared with internet egress. Size and schedule the return path deliberately.
Bandwidth is the design lever. You can hold a modest baseline connection and step it up in slabs for the burst window, then step back down – matching spend to demand the same way the compute does. The connection is provisioned once; the capacity flexes.
Example
A media post-production studio renders on-premises most of the month but faces hard delivery deadlines where its own render farm cannot keep up. During those windows it bursts rendering into AWS over a Multi Cloud Connect Direct connection, stepping the connection up for the peak. Frames flow to cloud render nodes and finished sequences return over the private path; when the deadline passes, both the cloud nodes and the extra bandwidth are released.
Bandwidth planning
Size the baseline connection for normal inter-site traffic, then define a burst slab sized for the overflow’s data movement within the burst window – not just the compute. If a burst must move several terabytes in a few hours, the connection, not the cloud, is the bottleneck. Model the transfer time explicitly before committing to a burst schedule.
MCC components in this architecture
Burst-to-cloud is a lean, single-shape build – bandwidth headroom on the two always-present components does the work:
Multi Cloud Connect Direct (private MPLS underlay):
-
Fabric Port – the on-ramp where your network meets the service (Hosted or Dedicated; L3 Private access is typical). Present in every solution.
-
Virtual Cloud Connection – a single landing on the burst cloud; step the bandwidth up for the peak and back down afterwards.
Multi Cloud Connect Flex (internet underlay with an in-path VNF):
-
Fabric Port – the on-ramp where your network meets the service (Hosted or Dedicated; L3 Private access is typical). Present in every solution.
-
Edge Connect – the short leg that carries traffic from the Fabric Port to the VNF
-
VNF – based on your burst path needs as an in-path function.
-
Virtual Cloud Connection
From the IZO™+ Multi Cloud Connect side, this architecture uses just a Fabric Port + Virtual Cloud Connection; the Tata Communications-billed parts run to the Virtual Cloud Connection, while the burst cloud’s port/attachment and (notably) egress sit on your cloud bill.
Considerations
-
Flex the bandwidth, not the topology. The Fabric Port and Virtual Cloud Connection are provisioned once, the capacity steps up in slabs for the burst window and back down.
-
Data gravity. Keep bursting workloads close to the data they need, or pre-stage the dataset – moving a large on-premises dataset can cost more than the compute gained.
-
Egress. Results returning from the cloud incur egress; a private Virtual Cloud Connection lowers the per-gigabyte cost versus internet egress, but it is still on your cloud bill.
-
Model. Direct is the usual choice for a plain burst pipe; use Flex only if an in-path function is needed during the burst.
-
Transfer time. Model the burst’s data movement against the connection rate – for large volumes in a short window the connection, not the cloud, is the bottleneck.
What’s on the cloud side
The burst compute and its cloud connection are created in the cloud provider’s console. This page covers how the private burst path is delivered and flexed on the Tata Communications side; for the cloud-side connection request and routing, see the relevant per-cloud section.