In a hub-and-spoke scenario, cloud access is mediated by a hub. The cloud can act as the hub that all spokes reach, or as a spoke that only the hub reaches. Either way, access is added as a separate bandwidth-shaped service without changing your existing spoke routers.
When to use it
Use this scenario when your network already concentrates traffic through a hub - typically a head-office or regional site - rather than being fully any-to-any. It also applies when you want the cloud itself to be the central point that all your sites reach, and when the sites needing the cloud sit on a connected data-centre or partner network.
The two models
Cloud as hub : The cloud is positioned as the hub, and all your spokes reach cloud services through it. By default there is no direct path between your existing network hub and the cloud hub - they are separate hubs. If you need traffic to flow between them (for example, head-office systems talking to the cloud workload), an extranet is configured to join the two hubs.
Cloud as spoke : The cloud is positioned as a spoke that only your network hub reaches. Other spokes do not reach cloud services directly; they reach the cloud only via the hub.
Data-centre or partner network as a spoke : Where the sites that need cloud access sit on a connected data-centre or partner network, that network is brought in as a spoke of the cloud hub. The same hub-and-spoke mechanics apply, with bandwidth shaped at the hand-off.
How it works
A dedicated logical connection is created for your service over the shared cloud-facing port and associated with your existing hub-and-spoke network at one end and the cloud connection at the other. Routing is exchanged over BGP so cloud routes reach your network and your routes reach the cloud. Bandwidth shaping restricts traffic toward the cloud to the rate you ordered, and - as with every scenario - this is done without changes to your existing spoke routers, so the hub-and-spoke service runs uninterrupted.
Example Scenario
A retail bank with around 200 branches already backhauls all branch traffic through its head-office hub in Mumbai. When it migrates its core banking workload to Microsoft Azure, it positions the cloud as the hub that every branch reaches. Branches connect to Azure through the established hub design, with no change to their local equipment. Because head-office systems also need to reach the cloud workload, an extranet is configured to link the Mumbai hub and the Azure hub. The bank keeps its familiar centralised routing while adding the cloud as a controlled, central destination.
Bandwidth planning
The cloud connection must be sized for the traffic directed at it through the hub. If several services share one cloud connection, size it to their aggregate; an individual service can be shaped only up to the bandwidth remaining within the cloud connection’s subscription. Where a data-centre or partner network is brought in as a spoke, account for its traffic in the same aggregate.
What’s on the cloud side
The cloud connection at the far end is created in the cloud provider’s console. This page covers how hub-and-spoke access is delivered on the Tata Communications side; for the cloud-side connection request and routing, see the relevant per-cloud section.