This topic shows you how to implement and manage the hub and spoke model when using Managed Microsoft AD.
Hub and spoke on Google Cloud
The hub and spoke model is a network design where the central device, or hub, is connected to multiple other devices, or spokes. To implement this design on Google Cloud, you create a Virtual Private Cloud (VPC) which is connected to your on-premises network via either Cloud Interconnect or VPN. The VPC serves as the hub. Using VPC peering, you can create connections to other projects and your on-premises resources, or spokes.
Though this model works for immediate peers of the hub, it doesn't scale to peers of peers. VPC peering is non-transitive and custom route exchange only supports propagating routes to an immediate peer, not to peers of peers.
Impact on Managed Microsoft AD
To provide connectivity with authorized networks hosted in user projects, Managed Microsoft AD uses VPC peering with route exchange enabled by default. This allows connectivity between the authorized networks and the tenant projects hosted by the VPC. You can also set up Cloud Interconnect or VPN directly with an authorized network.
However, if the authorized network is a spoke or if it is peered to a network that is connected to the on-premises network, Managed Microsoft AD resources will not be able to reach on-premises resources, and vice versa. There are two possible workarounds to allow connectivity.
Using Shared VPC
If possible, use a Shared VPC. It does not rely on peering, so it is not impacted by same route exchange limitations.
Using VPN
You can also use VPN between the hub and spokes instead of VPC peering to overcome the route exchange limitation.
Figure 1. Using VPN to avoid the route exchange limitation.
This workaround is less ideal because it requires more network planning and incurs the extra cost of VPN tunnels. When you create a VPN between hub and spoke, Managed Microsoft AD is considered a direct peer of the authorized network and the routes to the hub network will be exported. When using this approach, we recommend using DNS peering between the authorized network and the hub and spokes so that DNS requests can be forwarded to Managed Microsoft AD network via the authorized network configuration.