Is there a version of AWS transit gateway in Azure? RRS feed

  • Question

  • Is there a version of "AWS transit gateway" in Azure?


    AWS's version of virtual gatewas is like a virtual router in the cloud provided as a service for VPC to connect.

    It is like a hub where spokes can connect to other VPCs in the cloud.

    AWS transit gateway is a virtual gateway where multiple VPC can connect via a single virtual gateway so that traffic can be routed to other VPCs.

    How would we do this in azure?,... what is the corresponding product?  

    This allows a connecting of separate VPCs to a single interface like in a hub and spoke design.

    In other words, if we need multiple VNETs to communicate is there a azure product that acts like a virtual gateway to allow this?   We do not want to directly configure a peering to each VPC but rather want a virtual gateway where the traffic can be routed to multiple VNETs.   There would be no need to have a separate peering between each Vnet.

    The below link shows a transit gateway however is there an actual virtual gateway because logically it appears as a transit vnet which is a hub which connected the other vnets.   Will this allow all the vnets to communicate with each other from the single transit vnet?



    • Edited by kimdav111 Wednesday, November 6, 2019 8:07 PM
    • Moved by Femisulu-MSFT Thursday, November 7, 2019 2:30 AM better suite here
    Wednesday, November 6, 2019 6:50 PM

All replies

  • Moving to the Azure networking forum for the best possible response.
    Thursday, November 7, 2019 2:29 AM
  • Hi, 

    The similar product for Virtual Gateways in Azure is Azure VPN gateway. 

    You can create multiple VNETs and peer it with the VNET which has gateway. By doing that you will be able to access On-prem from all the VNET and vice-versa. 

    Reference: https://docs.microsoft.com/en-us/azure/architecture/reference-architectures/hybrid-networking/hub-spoke

    In the above article, Express route is used to connect from On-Prem to Azure. You can use VPN gateway instead. 



    Thursday, November 7, 2019 4:08 AM
  • Does this vnet hub allow communication between the vnets in the cloud and not just between the vnets to the on-premise network?  In other words, is the traffic in the diagram only allowing traffic to the hub?  The spoke Vnet would not be able to communicate with each other?   Does Azure have a type of virtual router as a service to allow this type of communication?   What are the design options given the vnet communication requirement described below.   In your link's diagram, spoke virtual network 1 (vnet 1) does not communicate with spoke virtual network 2 (vnet 2),... does this require a virtual router.   We would be having at least two more spoke vnets,... so this would require a virtual router?  Connecting a vnet to a virtual router would not require a peering?

    Does the hug spoke architecture allow for traffic between spoke virtual network 1>>hub virtual network>> spoke virtual network 2 without the use of a virtual router?

    We are also looking for a gateway which allows inter vnet communications.  Not finding any virtual product that provides transitive communication between vnet (this does not include the hub vnet to other spoke vnets).  (in our scenario we have 4 vnets which will need to communicate with each other in the cloud.  The communication to the cloud will route to vnet 1 (main path) and to vnet 2 ( management path/jump servers ).  From vnet 1 and vnet 2 there will be communication with other vnets specific for production(vnet 3), development(vnet 4), and test (vnet 5).   The on premise traffic will be using a express route only ( VPNs do not have sufficient bandwidth so we will be using Express Route only) into the cloud.  We want to be able to communicate within the cloud (between vnets)  while also having certain vnets needing to communicate with on premise.)

    In the diagram in your link, are you saying that hub vnet would be configured as a vnet to communicate with an on premise gateway however the diagram has a jumpbox/nsg in this hub vnet.  Is this jump box required?,.. we were expecting a type of virtual gateway without any servers.   It appears to me that the hub vnet is simply a vnet associated with the express route gateway?   Do we need to have a jump box in the hub vnet because in the AWS virtual gateway the gateway is more like a router where peering can be routed to different VPC?    In other words can this hub vnet route traffic to other vnets?  For example, vnet 4 (development) may need to communicate with vnet 3 (production),... can traffic flow from vnet 4 <<>> hub vnet <<>> vnet 5?   We are trying to avoid having direct peering between every vnet to simplify the cloud networking


    In the diagram there are jump boxes in each vnet,... we were only planning on having a jump box on only one vnet  ( in this case vnet 2 which is our management vnet).   

    Where is the virtual gateway for vnets to communicate with each other,... I only see the express route virtual gateway?   What I am expecting to see is that there is one virtual appliance /SaaS which makes it easier to communicate between vnets in the cloud.    



    The diagram at the top has a spoke-rm <> hub-rm <> spoke -classic.  Can spoke-rm communicate with spoke-classic?  Can this hub-rm act as a hub for traffic going to other spoke - rm(s)?  We will not being using a VPN.  Why is "rm" being used here?  There are no Vnet created from the classic portal but all vnets will be ARM based.


    • Edited by kimdav111 Thursday, November 7, 2019 4:07 PM
    Thursday, November 7, 2019 1:07 PM
  • Hi, 

    Does this vnet hub allow communication between the vnets in the cloud and not just between the vnets to the on-premise network? yes, it does provide communication between Vnets, when you peer them. 

    The diagram is just a representation of deploying different resources in different VNET and having Jump Boxes. You don't need Jumpboxes anymore. You can connect to any VNET from On-premises with the Hybrid deployment where you peer all VNETs with each other and connect the HUB vnet to On-premises. 

    You can choose Azure Bastion which is used to RDP/SSH to VMs via Browser using Azure portal. You can forget about Jump boxes and start using Azure Bastion. 



    Thursday, November 7, 2019 4:45 PM
  • The azure bastion is a web console and we want a real mstsc (rdp) connection aka a genuine jump server.   this azure bastion is in market release,... it recommended only for testing and not production.

    your statement : 

    Does this vnet hub allow communication between the vnets in the cloud and not just between the vnets to the on-premise network? yes, it does provide communication between Vnets, when you peer them.

    reply:  We are not wanting to have peering between every vnet to every other vnet.    This is 16-32 peering relationships for our environment.

    Please clarify but one of my links says that the relationship is not transitive.   The traffic does not go from one hub spoke vnet >>hub vnet >> spoke vnet using the hub and spoke architecture model.   If we were to peer between each spoke vnet and the other spoke vnets this would require lots of peering,... which is complex if you have several vnets.    Would you agree that in order to avoid making all these peering connection a better solution might be to place a virtual router for spoke vnet communications ( communicate only between spoke vnets).   If we used a virtual router would we need to use a peering connection?,... please confirm peering is not required.   

    Which is easier and less expensivie.  With 4 vnets you have 16 peers.( 32 peers since they are bidirectional), this is a lot of peering so again would it be better to create one virtual router (cisco 1000v) to connect these vnets?   Which model would be less expensive.


    • Edited by kimdav111 Thursday, November 7, 2019 9:26 PM
    Thursday, November 7, 2019 9:23 PM
  • Hi, 

    Azure VNET peering relationship is not transitive. So you will need to create mesh between VNETs which is less expensive but when you have more VNETs then it is difficult to manage. 

    What about connecting multiple VNETs to the same Express route circuit? You can do this approach but it will be expensive as you need to deploy gateway in every VNETs. 

    You can have NVA in one VNET and try to route accordingly but you need VNET peering as a pre-requisite as you want traffic from One VNET to be passed to other VNETs via NVA. 

    I think the best option would be to use Azure Virtual WAN and deploy P2S gateway, VPN gateway and express route gateway and add VNETs as connection. It is easy to manage as well as cost effective when compared to other options. 



    Friday, November 8, 2019 5:08 PM
  • Hi, 

    Just checking in if you have had a chance to see the previous response. If this answers your query, do click “Mark as Answer” and Up-Vote for the same.



    Monday, November 11, 2019 12:49 PM
  • Hi, 

    Just checking in if you have had a chance to see the previous response. If this answers your query, do click “Mark as Answer” and Up-Vote for the same.



    Thursday, November 14, 2019 1:27 PM
  • Hello,

    Is this issue got resolved? or are you looking for some help? Please let us know so that we can dig in to it for further analysis.

    Tuesday, November 26, 2019 1:31 PM