The Microsoft PaaS "Azure Bastion" is a popular service to make your Azure networks more secure. However, until now there was a drastic limit. Azure Bastion could only be used in the same VNet. VMs in a peered network could not be accessed via Bastion. This circumstance pushes up the costs, because with a hub-and-spoke topology you have to place a bastion in each VNet. But these times are over. Use Azure Bastion with VNet peering (since 05.11.2020 in preview).
Why Azure Bastion peering with VNet
A hub-and-spoke network topology is one of Azure's best practices. Many companies already have a hub-and-spoke network topology in place or would like to be able to follow the best practice design in the future. The previous limit for such a topology made the use of Azure Bastion impossible or disproportionately expensive. You had to place a bastion in each network where VMs were located that you wanted to access via bastion. So when Microsoft released Azure Bastion in its first version it was clear that this had to be changed. Thanks to this change you can now access all your VMs with a single Azure Bastion, as long as they are in the same or a peered network. With this change Microsoft is reacting to the community feedback, which has been requesting this feature since mid 2019.
Design of Azure Bastion with VNet peering
The following figure shows a possible design of how to use Azure Bastion in a hub-and-spoke network topology. Note that the VMs in the spoke VNets are located in different regions. Cross-regional connectivity is also no obstacle and works perfectly.
The hub VNet in this example is located in Western Europe and contains three subnets.
- The topmost subnet is the gateway subnet, which you can use as an example to connect to your on-premises environment.
- The middle subnet is the AzureBastionSubnet where the Azure Bastion is placed. From there an RDP or SSH session can be started with the connected VMs.
- The lowest and third subnet contains the central services, such as a Network Virtual Appliance (NVA), AD DS, DNS, etc.
- The network is in a peered ratio with both the Spoke-VNet-weu and the Spoke-VNet-neu.
The Spoke-VNet-weu is also located in Western Europe, like the Hub-VNet. In this example there is only one subnet in which the services are located.
- A VNet peering always applies to the whole network and not only to a specific subnet. So you don't need to limit yourself to one subnet and you can use multiple subnets.
- The connection between Azure Bastion and the VM is made via port 22 (SSH) or port 3389 (RDP). So you have to configure the NSG to allow this. No other ports are needed.
- The VNet is only with the Hub-VNet in a peered relation.
The Spoke-VNet-new is located in Northern Europe and therefore in a different region than the Hub-VNet.
- Despite a different region, the same applies to this network as to the Spoke-VNet-weu.
- The VNet is only with the Hub-VNet in a peered relation.
More information about Azure Bastion
You are not yet familiar with the features, benefits and implementation of Azure Bastion? You can find information about it in the following two posts.
Azure Bastion - Secure access to Azure VMs
Azure Bastion Planning and Implementation
General information about the hub-and-spoke network topology can also be found at this link
Sources:
https://docs.microsoft.com/en-us/azure/bastion/vnet-peering
English 
German