 Hi, my name is Amy Collier, Senior Cloud Advocate at Microsoft, and I'm joined today with Sid Bean Blair, America's lead for Azure Landing Zones for the Azure VMware solution. Today we're going to discuss one of the more commonly adopted networking patterns in the Azure Landing Zone Accelerator, a traditional hub and spoke in Azure for connectivity to your Azure VMware private Cloud. Take it away, Sid Bean. Sure thing. Today we'll break down each component of this design, and we're going to link to all the information at the end. So you can get started at any time. This session is really for anyone looking to have a better idea of how to design for hybrid. So stay tuned to the end to see how many are reducing their deployment times with our Azure Landing Zone Accelerator. So today's topics include centralizing routing in Azure, Azure Route Server, how one of Microsoft's newer network offerings plays a vital role in bringing the design together, options for accessing the Internet for your AVS workloads, and ExpressRoute to ExpressRoute Transit. Is that even possible? I guess we'll find out and then we'll end off with a brief recap of everything covered today and take a peek at that Landing Zone Accelerator, and its most recent updates, which is the source of all the material you'll see presented here today. So back over to you, Sid Bean. Talk us through the drivers for this design, and why is it so popular? Yeah, sure thing, Amy. Let's think about it this way. Why do customers use this product called Azure VMware Solution in the first place? It's because many consumers of AVS do have the goal of keeping their workloads on the VMware hypervisor, but they have probably the end goal of going fully Azure native at some point in their Cloud Adoption journey. So they want to land in Azure, so doing so would make sense to keep your actual infrastructure footprint dedicated to Azure. Yeah, I would think so. Right. Many of our end users would agree with that. These are users that are looking to implement zero trust, migrate or modernize their workloads in Azure, and establish hybrid Cloud connectivity in their Azure Landing Zone. So where we commonly see this design is when the consumer of AVS has plans to or may already have one centralized networking in place in Azure. So this is a consumer that might be looking to extend their Cloud Platform over to the Azure VMware Solution. And then number two, bring your own license or pay-to-go licensing for infrastructure such as network virtual appliances. Another use case that's in number three, Centralized Routing Hub. So this is a use case that's often driven by security where that traffic needs to, you know, A, route through a centralized device, but B, it needs to be filtered and inspected. And this workload could be from AVS to AVS, or this could be internet traffic or just traffic that's talking to, you know, across virtual networks in Azure. Okay, so let's say day one, I come to use AVS and I have an on-premises or a lab environment. How can I get started? Yeah, so let's say we have Amy's on-prem, Amy Sandbox, and you're connected via VPN to Azure. That's the quickest, simplest way to have a connection from your environment over to Azure. And that connection is going to terminate on a VPN gateway. So this is what you'd see right here. If I just get the laser pointer up, so you're coming in and you're terminating on that VPN gateway. Now from AVS, as seen here on the right, you're gonna get an express route circuit. So that's what we're seeing right here. And with this express route, you're going to get a solution, you know, at no additional cost. So once you spin AVS up, you're gonna have the express route circuit. Now, in order to access Azure, you're also gonna have to create an express route gateway. So this wanna make it clear it's not a rate limited circuit, you're gonna get pretty hefty throughput. However, when you do create this gateway, it's gonna have different SKUs, right? So that's what's gonna provide those different port speeds whether it be one gigabit, 10 gigabits per second. There is a setting called FastPath that comes with some of our ultra-performance SKUs and that's gonna allow you to bypass that altogether. But for this example, let's keep it simple, Amy Sandbox, AVS, one gig skew. So going back to this diagram, I see here, you might want to go now and do this. So I can natively talk between those gateways today. And then this is where we see Azure Route Server come in. Okay. So, and what Azure Route Server is gonna do is it's gonna use BGP to dynamically populate route tables in Azure. So with ARS, does this mean Azure and on-prem can see all the networks in AVS? Yes, essentially because ExpressRoute is speaking BGP. So Azure Route Server can dynamically learn any network in AVS and help send that traffic over to its destination. And then the great thing about it is that you don't have to manually create a route table entry every time a new network is created. ARS is gonna take care of that. Oh, that's great. And then I do wanna just call out some key things if you're gonna use the virtual network gateway for the VPN. So for the VPN configuration, firstly, has to be active-active. That mode has to be enabled. So that's what you're seeing here on the left. Otherwise, if you don't have that enabled, you're gonna have to redeploy that gateway. We don't wanna do that. And secondly, when it comes down to Azure Route Server, that's not something that's gonna work by default by viewing that branch-to-branch communication to speak to other spokes and other networks. So that route propagation has to happen by hitting the switch right here, making sure it's enabled for that route-to-route propagation. All right, good to know. And then there are some other things to consider as well, such as maybe enabling BGP on your VPN gateway, but then if you enable BGP, there are some other considerations around ASN numbers, which ones should be assigned. A few different default settings you may want to keep. So this is our public repo that has detailed step-by-steps that discuss these options. And you can view it by going to aks.ms forward slash abs dash vpn dash ergw. And that's gonna take you over to our landing zone accelerator. Okay, so keeping everything the same here, let's shift our focus to that internet access we talked about, how do we turn that on? Right, so we have two options here. The one that you see on the left is the managed SNAT and then the public IP down to the NSX edge. And as you can see from the image on the left, managed SNAT super straightforward, it's exactly what the name says, source network address translation. You hit a button, you have a route to the internet, boom. And then as the name also suggests SNAT, being that it's outbound only. So really we recommend this for testing and POC scenarios. Now, if you want something more robust, more scalable, this is where the public IP option comes into place. It's bi-directional. It's more scalable. You can configure a lot more public IP address. And as you can see here, it has a dedicated internet edge. So that means that that traffic that's going up to the internet is not gonna co-mingle with any traffic that's destined for on-prem or Azure via the AWS ExpressRoute circuit. So we have flexibility here. You can keep that centralized routing in Azure, but you can also have a dedicated path to the internet. This is probably good for low latent workload, which is a low latent path from AVS to out to the internet. Okay, and also, how would I go about going out securely to the internet? Yeah, that is a question, right? Security is like a driver, everything. So with NXXT, which is VMware's networking layer, you do have the opportunity to use IDS IPS, so that's that intrusion detection protection services. And honestly, you can have a few options when it comes to advertising a default route using a firewall in AVS or NXXT. But for the purpose of this video, I'm gonna keep it short and simple. We're gonna keep all these capabilities centralized in Azure. And that does mirror what we see many users of AVS doing today and really gets into the bread and butter, the heart of this design. Okay. So just looking at some of those settings directly from the Azure portal. In AVS, you will have to tell it where you want to have that default route configured. So if we look at that image on the top left, we're gonna see that we're not selecting the managed net or the public IP options. We're hitting that first one that says, we're going to have our own method for advertising that default route. And in this case, that would be that network virtual appliance that we have in Azure. And then next, looking over here at the bottom, we wanna make sure that we have an express route connection from AVS to Azure in place in that hub VNet. And then just to ensure that this works, you're gonna have to have a BGP capable appliance to peer with the Azure route server. And then from there, that NVA could have that quad zero. So it's just looking at how that looks right now. You can see that here with that BGP capable device peer to the Azure route server. So at a minimum, you can see this here, your hub virtual network, it should look like this. You should have an Azure route server. It's gonna be peer to that BGP capable device. And then you're gonna have your gateway submit at minimum. And then here in this diagram, you're gonna see that we call out some of the different things in play here, the different types of BGP. So you see that we have this IBGP going from Azure route server to the gateway submit. That just means that they're gonna be assigned the same ASN number. So they know to keep that BGP internal. And then in terms of EBGP now, that connection simply means that your ASN for your device must be different. So your firewall is gonna have a different ASN from the Azure route server. And I know you might be thinking now, well, how do I know what to what? Like which ASN goes where? Well, we make that really easy for you. For Azure route server, you can't change it. It's gonna have that ASN number of that 65515 and then for the VPN gateway, it's gonna have that 65515 by default. So if it's changed, it's because you've changed it. So we do try to make this a little bit easier for you. Okay, and then right now I see two firewalls. How are we accounting for HA? So high availability, that can be a deep dive in itself. As there are many ways to design your NVAs, especially when it comes to high availability. So we'll likely have a separate video on that, but in short, the easiest thing to do is what you see here, which is taking this firewall NVA. We have two of them. So they're like clients is running on VMs and now they're sitting behind an internal load balancer of type standard. So that network virtual appliance will then have a user defined route that points to the load balancer. And we see the scenario in both multi-region and single region architectures. And there is a method called Next Hop. And this is something that Azure Route Server natively supports. And it varies from firewall to firewall vendor, but for Azure Route Server, there's just no configuration changes that we need to make to utilize that. It's just ideally, you're gonna tell your NVA where to send the traffic, and that Next Hop would be the IP of that internal load balancer. Yeah, so you can see from these images that you could approach this scenario using both a VPN gateway and an express route gateway. And that's what we kind of see here on the right where you're still able to have that pyramid NVA device if you have a VPN gateway also in that hub network. Okay, so this scenario you're using a VPN for mom promises, which would probably be more for the lab or the POC or intermediary until you get your express route connection in. Or even you can use that as a way to do that. You can use that as a backup to your express route. So have your express route to be the preferred connection from on promises, and then maybe VPN as a backup. Yeah, that's correct. That's one of the recommendations that we make. Great, so how hard is it to go from a VPN to express route only hub and spoke scenario? So VPN gateway, just for some background, the reason why we make that recommendation because of the bandwidth, it is going to be capped based on the SKU, let's say like a 10 gigs. And that's really where that recommendation comes from. So just looking from the perspective of the express route, the main thing I wanna mention here, which is very, very important is that with the express route, you don't need to transit to Azure, like at all. We have this method called global reach and that's what's recommended. It's easy to enable, it's a direct low latent connection and it's traversing over the Microsoft backbone. So that's what you would use to basically go from one express route to another, just communicating between those two edges. Now, with that said, there is still a preferred route if you want to go to Azure itself and that would be creating that express route connection. So that was something that we had mentioned before where if you are coming from AVS, you hit that edge, you configured express route connection and you still wanna come down here directly. We don't recommend hitting the edge, global reach, hitting the edge and coming out. Cause ideally what you're doing is you're in Azure, you're leaving Azure, going over to background and coming back into Azure, right? So this is the recommended path if you're going from AVS to Azure directly. That makes a lot more sense. For you in Azure. Yeah. And in our docs, we make it clear exactly which flows are covered in the scenario. So let's say for example, you want to have something like end-to-end filtering, that should be done at either end of the global reach. So you could have a firewall here. So that means that that traffic is already inspected and filtered before it leaves, or you could have that on-prem. That would be our recommendation for end-to-end traffic inspection. Right now what we're covering in this scenario is the different traffic inspection flows going from Azure. So this would be filtered via the firewall NVA from AVS to the hub. The hub can also filter down to the spokes. It could filter to the internet. And then you could also filter your traffic from Azure to on-prem. So the scenario is not for doing end-to-end traffic with a single NVA. I do want to highlight though, one of the more common questions that we get, which is can you transit on a single ExpressRoute gateway? Meaning that this traffic here from on-prem, it's on its gateway. This traffic from AVS is also on its ExpressRoute gateway. And the answer is usually no. It's a medium, soft-ish no. And there are some things that you could do, such as supernetting, so really collapsing your entire network into one big IP address space. And there are some caveats with that. You're going to be heavily relying on user-defined routes to send that traffic where it needs to go. So that is something I would just say to do with careful consideration if you do go down that route. Okay, wow. Yeah, I wouldn't want to handle that network. Yeah, if you're like a customer or network, you have like a lot of just smaller networks in general that you just want to keep small and segmented, I would not go down that route. If you only have a handful of networks in AVS, you could probably get away with that. Okay, so this is how it looks now when we put it all together. And to summarize, what are some of the key points when building this end-to-end that you want us to take away? Sure thing, just looking maybe here. One of the key things that we want to highlight is that you want to use ExpressRoute for maximum bandwidth from on-prem. But the VPN will work too if you do have those bandwidth constraints. And when using ExpressRoute, use GlobalReach to exchange those routes between the on-prem and the AVS. And it also use Azure Route Server and peer-at-wood-a-BGP capable firewall if desired. And if you do want to bypass that gateway, then you would enable FastPath by having a higher skew gateway. What about the VNets themselves? For example, is that spoke traffic also filtered? That's a great question. So let me just tackle that one. So in terms of the Azure VNets themselves, in the spoke, you want to hit this flag, you want to disable route propagation. And what that means is that you're no longer going to rely on Azure appearing because what happens is that traffic can natively bypass the firewall. That is the native behavior with Azure appearing to go directly to the gateway of the peer network. So by enabling this now, you're bringing the firewall into the equation and you'd have that return traffic go back now by using a UDR and you just make the next hop be that IP address of the NVA. And then in the hub itself, in the gateway subnet, you're going to create a UDR for that spoke VNET with a next hop of the NVA. And then just in terms of some of the peering between the hub and spoke, so if that spoke needs to talk back to on-prem, you just want to make sure that you're enabling a selling call remote gateway. So when you enable that for the hub, this will have the spoke VNET network advertised via express route on the hub. And then if you do need to go multi-region, you would just enable global peering between those two hubs. So that's kind of the scenario in a nutshell. And just even in terms of that multi-region guidance, we have a lot of information, design principles, and that's some of the latest additions to our GitHub repo. So please visit it. There's a lot of great information there. There's white papers. We really deep dive into some of those hybrid connectivity scenarios. So those are just some of the links that we have listed here. This case of the aka MS, go to ABS dual region and then also aka.ms AVF design basics. Great. So my last question, towards the end, we bring up using that VWAN hub with a customer managed WAN. Are there other reasons to go with the VWAN topology? That's another great question. And it's also like a top five hit when it comes to questions. So I think it's important to emphasize sometimes the use case a little bit more than the tool. And the reason I say that is because hub and spoke in Azure VWAN and theory they're solving the same use cases discussed earlier. So there are some key differences when it comes to how VWAN is gonna handle these use cases. The first one being that Azure VWAN is managed. So that transitivity that express route to VPN to a LAN to AVS is built in without the need for spinning up Azure route server. So that's the first thing. And then natively you can use Azure firewalls. So that's another strong selling point because Azure firewall today does not speak BGP, which is why you saw earlier, we were using that BGP capable NVA, I kept saying BGP capable. So the use case for Azure firewall is a really strong use case for Azure VWAN. But of course you could use an NVA there as well. Just look at, make sure it's some of those recommendations for using NVAs with the VWAN. And another thing that that secure VWAN does have more of an upfront cost, especially when you talk about Azure firewall or tacking on an NVA. However, a hub and spoke is gonna have a more variable cost. So if you go from a simple hub and spoke topology to a mesh hub and spoke topology to a multi-region hub and spoke topology, you could see how that cost would go up. But long story short, to answer your question, it's a design preference. If you're comfortable managing your networks and you use it to find routes and stuff like that, then you know, absolutely go hub and spoke. But if you know you're thinking that you have like 20 or so branch offices and heaps of express routes and VPNs, this might be an attractive look as well. So we do have step-by-step guidance for anyone that wants to go down that route. Okay, and you mentioned global reach. What if I'm in a region without having accessibility to global reach? If you don't have global reach, there's some things that you can do in your hub and spoke environment. There's some routes that you could configure, you know, between NVAs and using that as a router. Another option that you could look at is secure VLAN hub where there's the route intent and that can filter between two secure hubs using Azure firewall. So those are just some options there as well. Great. So we covered a lot of ground here today and I'm gonna try to recap it. We covered connectivity from on-premises with either a customer WAN VPN connection or customer purchase express route because you get an express route with your AVS solution. We described how to use a BGP capable firewall for default route advertisement and centralizing routing by peering it with Azure route server or ARS. And then we also showed ARS, using ARS for transit between express route and that VPN gateway. Then we disabled route propagation to steer return traffic into pure VNUTS back through the firewall. And then best practice was to note your traffic flows, what needs to route where, which routes need to be secure and which routes need to talk to the internet. Yeah, exactly. You did a great job, Amy. Thanks for capturing all of that. And you know, we not gonna just, so it leads us to chance, you can find all this information and more in our landing zone accelerator. So this GitHub also hosts the landing accelerator code where you can find codes such as Terraform, Bicep, Azure portal experience to really help you get this up and going based on some of the common patterns that we've seen. And we're only touching the tip of the iceberg here. There are so many things to consider when it comes to routing, not just for AVS, but Azure in general. So please see our network design page with in-depth white paper so that you have the information that you need to make a really informed decision. And just for the latest information on the product, always go back to the Azure VMware solution product page. That's always being updated frequently. You drive a lot of these requirements. So we're always looking there to just see some of the latest network design considerations just so from additional coverage on that hub and spoke architecture design patterns that we referenced today. Okay, well, thank you so much for this thorough explanation, not only of the design but giving kind of a clearer picture of some of the components to look for when you're building your AVS landing zone. So please be sure to check out some of our Get Started guides here in the GitHub repo as Sabine pointed out. Thanks for joining me, Sabine. Oh, anytime. Thank you for having me, Amy. No problem. Take care.