I had an enterprise customer that needed to setup a multi-environment (prod/non-prod) Azure network that also comprised of a separate Shared Services. The customer needed complete isolation between the Azure prod/non-prod vNets. The Azure Shared Services vNet had to be accessed as a direct connection from the Azure prod/non-prod vNets, but also could be accessed from on-prem directly if needed.
- Single region end-to-end redundancy
- This example uses Australia East (Sydney)
- On-prem datacenter redundancy, multiple ExpressRoute circuits terminating in different ExpressRoute peering locations.
- Azure vNets to be consolidated within each environment (Prod/Non-prod) using appropriate option (Hub vNet / Azure vWAN Hub).
- Each Azure environment (Prod/Non-prod) to connect individually to on-prem via dedicated private peering.
- Shared Services environment to be utilised by each environment (Prod/Non-prod) via direct peering within the cloud, not traversing ExpressRoute.
- Prod and Non-Prod environments can only interface via on-prem. Need to ensure prod and non-prod cannot talk to each other direct or by using the Shared Services vNet as transit.
I came up with a couple of options.
The diagram below uses Azure Virtual WAN and Azure Private Link for the secure/direct connectivity to the Shared Services vNet from each environment (Prod/Non-prod).
The diagram below uses a traditional hub/spoke using standard Azure vNets.
This traditional one directly above can be deployed with a single click using my GitHub Azure template – https://github.com/marckean/HybridSharedServices
- Assign a higher weight to the local connection than to the remote connection
- You can also influence routing from VNet to your on-premises network, if you have multiple ExpressRoute circuits, by configuring the weight of a connection instead of applying AS PATH prepending. For each prefix, we will always look at the connection weight before the AS Path length when deciding how to send traffic.