 Hey everybody, you've probably heard us talk about virtual network manager and how you can use it to manage your virtual network infrastructure. So today we're super excited to have Andrea Michael from the virtual networking team deep dive into network manager today on Wired for Hybrid. Hey everyone, my name is Andrea Michael. Thanks Michael for the intro. I'm one of the product managers working on Azure Virtual Network Manager and I'm really excited to deep dive into, what is it, why do we have it and demo how it works today. Awesome, it's so, so cool to have you on here with us, Andrea, we've been talking about virtual network manager on Wired for Hybrid for a number of months and we had the nice, we went generally available in March and so we've been talking about different things but I think it's super cool to have you on here to be able to deep dive into what I think is, I don't think it's just a tool for the enterprises. I know that a lot of larger enterprises are really looking at it but I really can see the long tail of this as being a tool that can be used by all sides of organizations that wanna manage their topologies, wanna manage their security profiles and have that central management as we all try to do more with less. So super excited for you to tell everybody about virtual network manager today. Yeah, absolutely. We can get into the slides and yeah, I'm really excited to talk to you about Azure Virtual Network Manager and where we always like to start off with is the why of it all. So when a lot of customers go into the cloud, they obviously have to set up their networks in the cloud and so in Azure what this looks like is they need to start creating virtual networks and inside these virtual networks they may have multiple subnets and they need to house resources, they need to house different services like storage, they need to have their VM set up and of course as you start to have a growing number of network resources, now you have to actually maintain and manage all of the network resources, right? So even to just manage five virtual networks, this is a bit of effort and upkeep already but then what happens when you have 10, when you have 12, 100 and even more than 100 virtual networks. Now you have to manage the connectivity, the security, the routing of it all. You need to make sure you're protecting all of your old resources and then any new resources you have make sure that they're all compliant as well and this becomes a real issue in one that we've become very familiar with in Azure and in Azure networking and we're trying to reduce costs as much as possible for the customer. We're trying to reduce that number of errors that you encounter, just either human error, misconfiguration, forgotten security rules, everything like that and we're trying to make this consolidated just go to one place where you can manage the connectivity, security and then the routing as well as protecting your old resources and your new resources. So with all of this in mind, this is where we arrived to the solution that we call Azure Virtual Network Manager and so as Michael mentioned, Azure Virtual Network Manager announced its general availability back in March and near end of March and we still have a few features that are under public preview but basically the way I want you to think about Azure Virtual Network Manager and how it works is through a three-step process. You group your virtual networks however way you want. You configure them for connectivity and for security and then you deploy those configurations in whatever regions that you want. So group, configure, deploy. We're about to introduce a lot of new concepts and have a lot of words on the screen, a lot of words verbally so I just wanna make sure that that really sticks out, group, configure, deploy. So when we create these groups, this is totally up to you. Whether you wanna create virtual network groups based on workload, based on environment, based on business function, it's up to you but the reason you wanna create these groups is because when you create your connectivity or your security configurations, this is where the power of skill comes in. You're not going to be selecting, hey, I want Bnet's one through 100 to receive all of these security rules or to be in this topology. You're going to say I want to create a hub and spoke topology or a mesh topology on these network groups or I want to apply these security rules onto these network groups. So again, instead of dealing with hundreds potentially of Bnet's all the time, you're now dealing with these groups that you've defined by yourself. So connectivity, no, go ahead, Michael. So quick question, how do we define those? Is there some way that, cause I know how it is with NSGs and some of these stuff is that as you start to scale out, you've got all these things that you can manage. How do we define that membership that's gonna make it easier for people to be able to manage to scale? Yeah, that's a great question. I'm going to go into it in a little bit but essentially there's two ways for you to define your network groups. You can either manually say I want Bnet A, and C to be a part of this network group. And you can also use something that we power through Azure policy and we allow you to conditionally set the membership of your network group. So let's say you knew all of your VNFs that were in some subscription, had some tag on them or had some naming convention and you were going to want to apply the same security rules or connect them through some topology. You'd want to create a network group for them and you can say, hey, I want this network group to contain all of my VNFs that are named a certain way or maybe they're part of a certain subscription. Maybe they have some tagging convention. You can chain all these conditions. But yeah, I'll go into that in a bit but that's a great question. And another little preview to those network groups is that these network groups will have membership across regions, across subscriptions and even across tenants. Very cool, awesome. So after you've had your groups and you've created them how you wanted to, then goes into your intent of what kind of connectivity or security do you want to apply on them? So on the connectivity configuration side, we basically try to take your intent in as pure form as possible and then we establish all the connectivity through AVNM behind the scenes. So what I mean by that is if you know, I want a certain topology. I want a mesh topology or a hub and spoke topology. You tell us that. You tell us what kind of topology you want. You define what network groups are going to be a part of that topology. And then AVNM will build all of that connectivity for you and it will maintain all that connectivity for you, moving forward. Again, we're gonna get into each of these features as we go through some of these slides but just a nice little sneak peek of what we can do. And then on the security side, we currently offer something called security admin rules. This is a new construct and it's unique to Azure Virtual Network Manager. And with admin rules, you can think of these as high priority security rules that will allow you to enforce your security policies potentially across an entire organization. So across all of your network groups which contain your virtual networks and these have a higher priority than network security group rules and as jewels. So you don't have to worry about conflicts. You can just pay attention to what do I want as my baseline rules? What do I wanna make sure I deny across multiple resources? What do I wanna make sure I force allow across multiple resources? And again, the whole benefit of AVNM, Azure Virtual Network Manager, is that not only do we build these rules and enforce these rules for you but we're also going to be maintaining them. And I'll talk a little bit how that maintenance and that automatic updating will work in a few slides. And then again, that last step we've gone through the grouping, we've configured all these different rules and topologies. And now that last step is that this is all staging before, right? So we need to deploy. And we give you the capability with Azure Virtual Network Manager to deploy in whatever regions, however many regions you want at a time. So what you could do is you could say, hey, I just wanna test my configurations. I'm not too sure about what I've done here or I just want to make sure the behaviors and as intended, I'm going to deploy to just one region. And if it works as expected, then I'll roll forward. Then I'll continue rolling out and deploying to multiple regions at a time. Or if you're feeling lucky, you can go ahead and deploy to all regions all at once. It's totally up to you. So we're just trying to give you as much capability and functionality as possible. Leave the control all up to you but still simplify it and abstract it enough that it's useful as scale when you're dealing with potentially hundreds of network resources. Very cool, yeah. So lots of, definitely lots of good stuff that I love the way that you explain that walking through that of doing the configuration and then going through it. I think that's the best way to think about it. You and I, for people that don't know, I'm the doc writer for Andrea and Jay for Virtual Network Manager. We've had numerous conversations, talked with customers and really trying to simplify this and Andrea really simplified it down to a way that really makes it easier for you to understand because as you know, as you know, I know everybody watching knows a lot of our stuff up there is pretty complicated but you don't have to know all the complication is that I think sometimes it comes across as over engineered when you start really diving into it but what you really need to do, it's not that hard. Just takes a little bit of thought, architecting it the right way, following the right processes and we're good to go. So thanks for that great intro. Yeah, absolutely. And I would say this too, I've really simplified it down, right? Obviously, Michael, ABNM is much more than group configured deploy. There's all these nuances in how customers want to achieve different scenarios but what I will say is our documentation it has a great amount of detail and covers I'd say most if not all of what you need to know about Azure Virtual Network Manager. So just a plug for that as well. And we will have all the links down below for you to check out. So with Azure Virtual Network Manager, we have seen some use cases among current customers, prospective customers, general things that folks have wanted to solve using Azure Virtual Network Manager. So on the connectivity side, we've heard that there is some trouble at times using just manual pairing to achieve connectivity across subscriptions, regions and especially across tenants. So this was a very basic tenet of what we wanted to solve with Virtual Network Manager. And also just building out these topologies, we can always diagram it out, right? We can always say we want BNET A to talk to BNET B to talk to BNET C in a mesh or we have some hub BNET and we know who wants to talk to what. In the end, somebody always has to build it out, right? And you're relying on at some point, somebody to just not fail in doing that or to make sure that their script is correct in doing this and building this topology. But again, maintenance of that after the fact, after you've created your initial topology can be quite difficult. And again, depending on the number of resources you have can also be very cumbersome to do. So we wanted to make this a very simple experience in Network Manager. And of course, allowing Virtual Networks to directly communicate, even if they're in a hub and spoke topology where you want your spoke BNETs to maybe talk to each other, reduce that latency of having, instead of having to go through the hub BNET, now you just have your spokes talking to each other. And this is something we also allow with Network Manager and I'll get into how we can do that. And then on the security side, essentially what all of these scenarios go down to is there's a bit of a balance beam issue between enforcements and flexibility. So usually at an organizational level or as a central governance team dealing with the security rules across an entire org, you have to choose. Are you going to be the central governance team managing all of the security of all of your application teams, all of your different business functions and putting all of that overhead onto yourself and your team? Or are you going to have flexibility and delegate this out, have a decentralized model and have everybody able to contribute to pieces of security, to their NSGs and be able to dictate the contract. In the past and without Network Manager, this has really been kind of a one or the other decision. And with Network Manager, we said why not have the benefits of both enforcement and flexibility while mitigating all of the cons of both models. And so to go through each of these use cases, creating standardized rules, having enforcement and saying, okay, we know what a baseline, we want some security policies out there, we know we want to block maybe some high-risk ports or other ports that we just know we have no business having traffic on. And at the same time, on the flexibility side, maybe there are VNet owners or subnet owners even who say, hey, I have a specific use case, I do need some traffic, maybe either on a risky port or I need some exception, I need to be able to have traffic on certain ports. And we still want to allow for that. We don't want to just say, hey, we're creating these gods here admin rules and now you can't change anything about it and now all of your traffic is blocked and you have no say in it. Admin rules, there is still a case for them to allow for flexibility and allow for VNet owners, non-network admins basically, to be able to define security as they'd like to. And also of course, it's not just about blocking traffic, sometimes you need to force allow certain traffic. So let's take Windows updates as an example, you wanna make sure your resources are having those Windows updates that also protects with security in a certain sense. This is something you can also do with admin rules, you can force allow traffic, make sure that no NSGs can accidentally or not accidentally block that traffic from going through. So this is definitely what we see with network management. I love the way, I'm the security thing, I love how intentional the team was and thinking about that. Cause a lot of our audience is traditional IT pros, CIS admins coming up and that's Pierre and myself and many of us, that's where we fell into and we always dealt with that balance theme with security that we would often be the enforcers of it, but there was somebody defining the policy and how do you create, how do you have that enforcement and the flexibility? So I love how, you know, this is actually the first time I heard this story. So I love the story, how intentional the team was about thinking about, I knew this was the problem that people have and us providing this way for people to be able to organize it in a way that one central body doesn't have to do all the security that you give that flexibility, which as we know, that's a, you know, that's one of the key pillars of any cloud infrastructure is being able to be flexible. And as organizations scale, maintaining a security profile is very difficult. So awesome stuff. So thanks for sharing that. Yeah, certainly. And I will say, you know, our existing security rules, if you look at NSG rules, very robust, very effective. These are issues that you start to hit when you get scale, right? When you start to have a number of network resources because now it's a pain to manage. Now you have all these NSG rules and now there's the possibility of, okay, now you have multiple teams touching NSG rules. Do first of all decide that you want multiple teams touching this or do you want to manage this all yourself or within a small team? Yeah, this is really about listening acutely to the scale issues that folks have encountered as they've just gone through their normal Azure story in networking. So moving on, we're going to dive deeper into each of those three steps that I mentioned. The group configured deploy. And going into the first one, Michael asked a really good question about these network groups, which is how do you create these network groups? And I take it even a step back and say, why would you want to create these network groups? Again, you want to create these network groups because this is how ABNM works at the base level. This is by itself, doesn't do anything, right? You're just defining whether you want your groups to consist of your production vNets, your dev vNets, your test vNets, or maybe your application team one vNets, your workload, your AKS workload vNets, whatever you want. But by itself, it's just a logical container and you define what vNets you want to be a part of this. The vNets that can be a part of your network group really consist of whatever vNets are in the scope of your network manager. The scope aspect will make more sense once I go into the demo. Essentially when you create a network manager, you define what subscriptions and what management groups you want to be managed by that network manager. And so any vNet that is a part of that scope you've defined for your network manager can be put into a network group. You won't be able to touch any vNets that are outside of your network manager scope though. So within your network group, again, you can define this however you want. And because all of the vNets within your network manager scope are up for grabs for your network group, this means that you can have vNets in a network group across subscriptions, across regions, and even across tenants. A vNet can also be part of multiple network groups. So you don't need to worry about having kind of perfect fit network groups that don't overlap at all. You can have subsets of network groups. You can have overlapping network groups, whatever you want. It's up to you. Because again, these are just containers that you define however you'd like. So getting back to Michael's question, how do you create these network groups? Once you have your empty container of your network group, then you can manually add network groups or vNets to your network group. You can say vNet A to your network group, maybe vNet B, vNet C. But you can also conditionally define the membership of your network group. And ABNM does this using Azure Policy. And so you can say, for example, in this diagram we have up here, you know that all of your vNets in your production environment have a convenient tag value of prod. So you can go ahead and say, hey, for this network group, any vNet that has the tag value of prod, go ahead and add it into this network group. And so what ABNM will do is it will evaluate this policy definition. And it'll say, okay, at this moment in time, when you created this policy and associated with this network group, I'm going to add all the vNets that are currently available and matching these conditions into this network group. But the real power is in the future, after you've already created the network group, already created the policy, will continually evaluate. So if you create a new vNet months from now that satisfies this condition, it has the tag value of prod, then it will get automatically added into this network group. And you may wonder, okay, well, that's pretty cool, but what do I care about automatic group membership? The reason is because any configuration that you have actively deployed on this network group, on this prod network group, it will automatically apply to any new members. So months from now, if you already had some security rules that were deployed onto this prod network group, if you have a new vNet that's been created and it matches these conditions, has the tag prod, it's added to this network group, it's automatically going to receive the same security rules. So you don't have to worry anymore about, oh, I just created a new vNet, I need to go through this mental checklist or physical checklist of, does it have the same security rules as the other production vNets? Is it connected topology-wise in the way that I expect, maybe in my hub and spoke topology? We will maintain that for you as long as you have an active deployment and as long as you have that membership set up through Azure Policy. So that's the real power of it. It seems quite simple at first, but the power of it is just that scale. You don't need to maintain that by yourself anymore. Absolutely, and what I love about this is this really fits into, it's a total buzzword along with everything we basically work with, but it totally fits into the way a lot of organizations are moving to infrastructure as code. So you're using code to maintain your infrastructure. That's exactly what the dynamic grouping in using Azure Policy is doing for you is it's allowing you to be able to choose your desired state, your configuration you want, and you don't have to worry about when you bring a new vNet on. You don't have to worry that your network engineer remembers to check a box when they bring a vNet in, that you don't have to worry from a security standpoint that that virtual network isn't covered, that using these allows you to be able to have that definition, which I think is super cool. And one of the reasons why I see this not only being, as I mentioned before, an enterprise large scale, but for those smaller organizations that are growing, that it allows them to, maybe they have a smaller workforce to be able to manage this, this allows those smaller IT teams to be able to leverage some of the tools that are used by the larger enterprises. Exactly. Operational overhead with this kind of scale management tool, and also just the risk of errors greatly decreases, right? No need to feel like, oh, you have to grow to a certain size in order to use network manager, encounter these pain points that we outlined at the very beginning before you use it. Save yourself the trouble. Just go ahead and use a tool that helps you automatically maintain all of these connectivity and security policies. Moving on to the next. So with the connectivity configuration side, I will also say, and kind of plug here as well, we are currently generally available. Azure Virtual Network Manager is generally available for the network manager resource, for that network group, construct that you just saw in the previous slide, and for deployment, as well as for the Hub and Spoke connectivity configuration piece. There are still a couple of pieces that are still in public preview, so including the mesh topology and also our security story, our security admin rules. But yeah, Hub and Spoke is generally available, so if there's any limitations or compliance issues in terms of using this product, you can go ahead with Hub and Spoke. Mesh and security pieces are still in public preview, so you can play around with them, but they do not yet have that GA level support. So that was just a quick note about what we have GA versus preview. Awesome, thanks. Yeah, but on the connectivity side, what we do have, again, we offer you the ability to create a topology using those network groups that you just defined. So in the GA case, let's say you wanted a Hub and Spoke, instead of having to establish N number of pairings between all of your Spoke vNets and your Hub vNet, whether that's through scripting or if you had some other way of doing this. Now what you can do with Network Manager is you just say, I wanna create a connectivity configuration. What type? Hub and Spoke. What do you wanna use as your Hub vNet? I will use my Hub vNet as my Hub vNet with whatever gateways it has inside of it. And then for your Spokes, instead of selecting hundreds of potentially Spoke vNets, you just select your network groups. So maybe one, two, three, four, five, however many network groups. And in the background, what Network Manager will do once you deploy this connectivity configuration is it will establish a pairing. It will connect all of those vNets. So it'll connect your Hub vNet to all of the member vNets inside of your Spoke network groups. So you don't need to worry about establishing all of that connectivity yourself. We'll do it for you. We even give you the option to delete existing pairings if you just wanna have cleaner pairings, lower costs that way, but otherwise feel free to manually clean that up yourself. And other topologies that we do offer that again are not yet GA are mesh and also Hub and Spoke with direct connectivity because it's essentially a mini mesh and relies on the same technology that we use for mesh. So for the mesh connectivity configuration, even simpler than Hub and Spoke where you just say what network groups you wanna be a part of your mesh and we'll establish the connectivity among all of the member vNets of all of the network groups. So the real power with this is we will be able to exceed the normal pairing limits that we currently have in Azure through this mesh configuration. And this is through a different way of connectivity than with pairing. Instead of doing a one-to-one mapping as pairing does, we're basically saying, hey, if all these vNets are part of a group, just go ahead and connect all the members in the group. I'm highly simplifying it, but this takes up less memory. And as a result, we can reach a much higher scale than we would with normal pairing. Hub and Spoke with direct connectivity between Spokes is literally just combining the two models where you have your Hub and Spoke, you define it the same way in AVNM, you define what network groups you wanna use as your Spoke network groups. And then you can say, hey, I want to establish direct connectivity among my network groups that I've selected for my Hub and Spoke topology. So what this does is it effectively lays a mini mesh on top of the network groups that you've chosen as your Spokes, not a big mesh among all of your network groups, but just within your network groups. And we'll get into how we cannot know, how this can look in a second. Let me see. Oh, before we get to that, actually I'll just say one more piece about that connected group. Again, with the mesh and direct connectivity piece of AVNM, we are not using pairing, we're using something called a connected group behind the scenes. So again, this is not a once one mapping and this allows us to exceed normal pairing limits. Instead of 500, we're testing even in thousands. And members in the connected group just can talk to each other directly. Again, a lot more complicated than that, but in terms of what you need to know, just know that it works very similarly, effectively as peering. And it still establishes the same connectivity that you would expect as peering. But this will display a bit differently when you're looking at it from a VNet perspective. And again, just enables that higher scale that you can take advantage of in AVNM. Very cool. Having played around with it, I've just amazed, because I've done the traditional peering and anybody that's worked with more than, I'll say five virtual networks and had to do peering between those, it starts to get messy and it starts to get hard to track. And as you start to scale, keeping track of that and what's peer to what and it's a pain. And so this is just a really a game changer as far as that comes for being able to just define, I want all of these connected together. I want them to all communicate. Go. Certainly. We wanted to give you, maintain all that functionality. You can create all of this connectivity, but also abstract it enough that it's not difficult to maintain. It's not difficult to build, to maintain or to track afterwards. Yeah. So one example of how you can use a hub and spoke, especially with direct connectivity. And again, that direct connectivity piece is still in public preview, but hub and spoke itself is in GA, is let's say you wanted to connect all of your production vnets to some hub vnet, which had an express route gateway. And maybe you also have a bunch of debt vnets. You also would like to use the same hub vnet just for simplicity of the whole topology. And so what you can do is you can build with ABNM, a hub and spoke topology with direct connectivity. And so first step would be, I need to define my network groups. So maybe you have multiple network groups. You have one for your production vnets for application one. Maybe you have another set for production vnets for application two, or maybe you just have one big network group consisting of all of your production vnets. However you decide to do it, you have your production vnets, you have your debt vnets, and they're in separate network groups. So then when you're creating your topology, you say, I wanna have a spoke topology and I'm going to have my hub vnet, which has my express route gateway as the hub vnet for this topology. And then for the spokes, I'm gonna select my prod network group and my dev network group. And this way what you've already created just now is now a basic hub and spoke topology where that hub vnet would be connected to all of the production vnets and all of the dev vnets. But then you say, I actually do want my production vnets to talk to each other. I want my dev vnets to talk to each other, but I don't want them, I don't want my prod vnets to talk to my dev vnets. So that would be the whole purpose. So what you can do is you can enable direct connectivity within your network groups. Check that box for your prod vnets, check that box for your dev vnets. And again, that mini mesh will be laid on top of your production vnets on top of that whole network group. And then separately you have that mini mesh also laid upon your dev vnets in their network group, but they still can't talk to each other. You still achieve that security, that network isolation, without the complexity of having to build that yourself, of having to maintain that yourself. And now by establishing this direct connectivity, you've also reduced latency because you've reduced the need for a production vnet to hop through the hub vnet before talking to another production vnet. Same thing for dev. Very cool. And so we got a little out of order, but the security piece can be quite lengthy. So what we will say for now is let's get to the deployment aspect of this. You have grouped, you've configured, and now you're ready to deploy. Again, everything up until now, there's no effect. It's taking no effect, it's all in staging until you actually deploy. So when you deploy, again, you choose what configurations you want to include in your deployment, and then you select what regions you want to be deployed to. And so let's say all of your vnets are in two regions. They're in East US and they're in West US. What you could do is you can deploy to maybe just East US first, see how your configurations behave, make sure everything is intended, all of your security rules are in line, all of your connectivity configurations, your topologies that you're building out are as you intend. And then once you see, okay, everything's working well, you can roll forward and you can say, okay, I'm going to deploy all these configurations to West US as well. Or if you find that there's something wrong, you can easily roll back. You can say, you know what, deploy none. We're going to deploy no configurations back into East US. We need to go back and change some stuff before we want this taking effect in our vnets in those regions. So we give you that complete control to do so. And I think, you know, sometimes with this additional control, maybe there is some confusion that, you know, you can go upon because we kind of treat deployment as a goal state. We give you the capability to define all of the configurations that you wanted your deployment all at once. It's not additive. But once you get used to this aspect, you know, and you can handle that power with great responsibility, it becomes quite a powerful tool that you have. And so moving to the security configuration piece. This is one of the most unique offerings that we have at Network Manager. And this is currently in public preview. So feel free to test it out, you know, at your own risk. But feel free to test out security configurations in public preview. What we offer right now is something called security admin rules. So these admin rules are not NSGs, but they are very similar. The parameters are very similar. You would define your direction, your protocol, your action type, your source destination information, all of that, right? But the biggest difference between admin rules and NSGs is that admin rules are defined at the vNet level. They're going to be applied on the network groups, which consists of virtual networks, right? And that already provides with it blanket security across your vNets, which means blanket security across your subnets that it contains and also your VMs, other resources that your vNets contain. And security admin rules also take a higher priority than NSGs. They take full precedence before NSGs. So whatever admin rule you define, even if it's the lowest priority admin rule, what will happen is it will always be evaluated first before the NSG. So there's never any room for conflicts. You never have to worry that your admin rule isn't going to be followed in favor of some other NSG. So the target audience for using these admin rules is of course your network admins, any central governance teams that have had to deal with the security and put all of that burden on themselves. And admin rules, again, they apply to all resources inside of your network groups that you're targeted. And so again, your vNets, and so therefore their subnets and their VMs, and it would overwrite essentially all conflicting rules. And what you would do is you would say, hey, I want maybe some baseline security policies to be applied across, let's say all of my virtual networks in my organization. Maybe you have one big network group that contains all of the vNets inside of the entire network manager scope. And so this could be cross subscription, cross region, even cross tenant again. And so all of these vNets, you can define a base set of security rules. Maybe you want to block SSH traffic. Maybe you want to block RDP traffic. Create those rules, target your overarching network group, and now by default, all of your vNets have these same sets of security admin rules. They have blocked RDP and SSH traffic. You don't have to worry about NSG rules down the line, conflicting with this, or even accidentally allowing this traffic because that traffic will never hit those NSG rules if they've hit certain types of security admin rules. We'll go into those types and how they interplay with NSG rules in a second. So I think if people, if you want the TLDR on this is this is for those instances where you have shadow IT or somebody that just deploys a VM and they check the checkbox to leave RDP open and they throw it on your network, this prevents that from happening. So that's why this is such a cool tool is because you don't have to worry about how people are deploying these things, your resources that are in those virtual networks is that you're protecting them at that overall layer and you have that right out of the gate. Exactly. And again, this is something that you really hit at scale and just in general, I think everyone when they come to Azure networking with this idea of I want to establish security on this level, I want to establish these NSG rules. They always come with some base intent. I want to block some traffic and I want to allow some traffic. And then over time, as their architecture gets more complex, as their network resources scales grows, then you start having to deal with, okay, well, different teams may not be clued in to that original intent or just appear human error, somebody accidentally creates an NSG rule that's conflicting with that original intent. And then once again, you've had to go off kilter of that balance beam of enforcement versus flexibility, which one do I pick? And so this is where admin rules really comes into play. We're trying to bring it back again to that intense. This is all about, AVNM is all about intense. How do we translate that intent and have you apply it onto your network resources at scale in as easy a way possible while still giving you, if you want all the nuance and all the functionality, you still give you that. So we'll look into, again, how admin rules works and why we have admin rules. Once again, we've talked about this balance beam quite a few times, enforcement, flexibility, right? Which side do you pick? And so some common models that we've seen without admin rules and previously is that if on the enforcement side, you have NSGs they're managed by one team, one central governance team. So they have a high operational overhead. Those admins need to manage all of the NSGs. And as soon as the number of NSGs grows, now you're under burden. And maybe you only have five vNets, but inside of those five vNets, you may have dozens of subnets. And so your NSGs, you'll have to have an appropriate number of rules in order to account for those number of subnets, right? And so it's very easy to hit that operational overhead. Very easy to hit that level of scale where it becomes just a pain in the butt to manage your security. And on the other side of that balance beam, you have flexibility. You say, you know what? I'll leave it up to the individual teams. You all can worry about your NSGs about your security. So great, it's flexible. No single team is under too much burden, but as a result, you can't enforce security rules. And what this can lead to is very high risk situations where certain ports are wide open. This can lead to security incidents and other things that honestly would be more difficult to address when you have that flexibility because there's no way to go back an emergency patch in an enforced way. Some team can always modify an NSG or create new NSGs, high priority NSGs that say, no, we're just gonna keep some port open or we're not going to allow for updates for certain services, which leads to other security issues. So somewhere in the middle, there is a model that we've seen where you have that flexibility. NSGs are managed by individual teams, but there are also the standardized NSGs that are created by a central governance team where changing those centralized and those standard NSGs would end up triggering a notification. The thing is now you have the flexibility, but you still don't have hard enforcement. And now you have to manage not necessarily the industries themselves, but you have to manage all of these notifications potentially of people modifying NSGs that they should not be modifying. So this is where admin rules comes in. It says, let's do away with this balance beam completely. Let's make it all one big benefit, one big set of benefits and get rid of all these risks and downsides here. So with admin rules, you obviously have enforcement because they take priority over NSGs. And on the other hand, you have flexibility because we offer you an admin rule type and we'll get into what this type is. We offer you a type of admin rule where you can soft allow some traffic through. If you want to say some traffic, we actually don't care about hard enforcing or hard blocking and we're going to let NSGs down the line still evaluate this traffic. So this way you have the flexibility where you want it but you still have enforcement and you're basically just pinholing through the flexibility wherever you know that you don't need that enforcement. So this way you have both benefits but you don't have to worry about operational overhead. You don't have to worry about applying this to all of your subnets and VMs. You're applying this at the VM level, at the VNet level. And so again, blanket security with some pinholes as you intend. So again, going into more of that interplay between admin rules and NSGs, what happens when traffic hits an admin rule? The answer is it depends and it depends on the type of admin rule that you have. If you have an always allow or a deny security admin rule, what will happen is the traffic hits those two types of admin rules and then traffic evaluation completely stops after that admin rule. So in the case of always allow, you've always allowed some traffic with your admin rule, it gets delivered directly to its destination. Never hits the NSG. And then with your deny admin rule, what happens is the traffic hits it, blocked traffic is done. Again, never hits the NSG down the line. The only way that traffic can hit NSG rules is if you either kind of soft allow, there is an allow type with admin rule. If you allow traffic through with your admin rule, then that traffic sees the admin rule and says, okay, I can go on through. And then it can hit whatever NSG rules also happen to match that traffic down the line. Or even just implicitly by not having your admin rules, that traffic can go through to NSG rules. The reason you may want to have some allow rules though is to keep track of what traffic you are intentionally allowing through. Sometimes this is for compliance purposes, it really depends on the scenario of the customer. But again, through always allow and deny, this is how you achieve that hard enforcement. And another thing that I'd like to mention is from the VNet owner level and also from the VM owner level, you can see security admin rules in a couple of different ways. So in the VNet perspective, if you go into your virtual network instance, what you'll be able to see is there's even on the portal, you can go through this in the demo in a bit, but there's a whole blade for network manager and you'll be able to see all the security admin rules that have been applied to your VNet. So you know very clearly what traffic may be blocked or allowed or always allowed from security admin rules. But then on the VM level, you do see this with your get effective Apple, your get effective access control lists. And you'll be able to see again, what admin rules are applied to your VMs, Nick, just the same way that you would be able to see your NSG rules. It lives in the same place. You can query this list through APIs. And so we're trying to make sure, even if you're not a network admin, you still have that visibility. Great, that's awesome to have that, being able to see that. Cause I know that's a problem with a lot of people when they're deploying into the cloud, is they're like, maybe you don't know where everything is or what somebody else has done. It's great that those people at those lower levels are able to see, okay, here's what my NSG's applying, here's what I'm getting from the security admin rules, from a network manager, oh, I'm at a VM. I can take a look at the CL and see, oh, this is effectively what my permissions are. And then they can work their way up to try to figure out, okay, if they're having an issue, it gives them a place to start from. So it's great. Exactly, and we want to make sure we're alive. Yeah, we want to make sure we're not pushing that operational overhead, just kicking it down the street, right? Into troubleshooting territory of, okay, I'm a VM or a VNet owner and I don't know why some traffic isn't getting received. It's breaking some function or some connectivity to a service that I have. And now they have to go ahead and ask network admin or the central governance team, why is this happening? No, we try to give them that visibility out the gate. And so that they can see this and they can see, oh, okay, something called network manager is affecting me and this is an intentional rule that's being placed upon me. It's not some other misconfiguration that I have with my connectivity or other resources. Yeah, so we try to give that visibility upfront. Awesome. So some common design patterns that we've seen with admin rules being applied in folks' environments is what we'll see is kind of again, that pinhole kind of model where in general, maybe you'll have some admin rules that allow certain traffic through for energy rules to evaluate down the line but everything else is blocked by default. And so again, this is kind of, you can think of it as a blanket with a pinhole model. Another design pattern that we have seen is just denying certain traffic, everything else is implicitly allowed through. So the reverse of that. And some ways that you can apply security admin rules. So again, to kind of bring it back into that group configured deploy model, when you've created your network groups, the way that your admin rules will apply onto those network groups is through rule collections. So you have your groups and then on the security side, you have your security configuration, you have your rule collections within your configuration and then you have multiple rules within those rule collections. So very similar hierarchy as NSGs, right? And what you will do is you will apply your rule collections onto your network groups and you can apply them to one network group or to multiple network groups. And this is how it will take effect. So let's say you have your network groups segregating your organization's virtual networks. You have some sub org one, some sub org two, all of those vNets under those respective organizations. And you know, at a baseline, you need to have some security admin rules that dictate the security policies across all of the organizations. Doesn't matter if it's org one or org two. So you can have a rule collection that targets both organization one and organization twos network groups. But you can still achieve modularity. You can still say, okay, you know what? Actually for org one, I need more specific security policies. For org two, I need different specific security policies. So then you can define other rule collections. You can say, hey, for org one, here's some additional rules for org two. Here's some other rules. And then you target those rule collections respectively to those network groups that represent those orgs. So again, this is a way that you can lay a baseline security policy set, but you can still achieve the modularity. You can still make sure you have specific security rules for each of your network groups, however they're segregated. Again, we've kind of given the example here of organizations, but your network groups could be segregated based on the environment, based on workload, other business function, what have you? Yeah, lots of flexibility, lots of scalability, granularity and stuff. Yeah, definitely. And I also realized, we're talking about a lot of this in theory and on slides. I think a lot of this will also start to hit home once we can show what this looks like in the Azure portal and walk through, what are we trying to achieve? How do we achieve this with network manager? So as I mentioned, maybe your network groups aren't based on organization, maybe they're based on workload instead. Again, same idea. You're targeting your admin rule collections on your network groups. So maybe you have specific admin rules, specific security policies that you want for different workloads. So again, you've grouped your VNS by workload, now you have your admin rules and each of these rule collections are segregated based on whatever workload you want to target for. And then you target, you say, hey, this rule collection for maybe my Azure Virtual Desktop, I'm going to target that rule collection onto my network group for Azure Virtual Desktop VNS. And that's how you associate. Nice. Nice. Yeah. And so looking at the bigger picture for security and hierarchy, probably what most people have is they have one management group at least and then they have multiple subscriptions under those network groups or under those management groups. And maybe their hierarchy all differs a bit, but what it boils down to is you have your management groups, your subscriptions, and then your VNS under them, right? And so what you can do with Virtual Network Manager is you can say I'm going to scope my Virtual Network Manager at the root management group level. And what this means is your network manager instance will be able to see all of the VNS that live under that root management group. And so you can see all of your subscription, all of your subscriptions, virtual networks. And this means that you can apply configurations onto any of these virtual networks. You have that ability. And so maybe you're applying some baseline admin rules again. You're saying for the entire organization for all of these VNS, I want to apply some baseline admin rules, we're going to deny inbound SSH traffic. And again, admin rules unless they're blocking or always allowing all the traffic in the world, they can still work together with NSGs. Again, it's only if they're denying or always allowing traffic that the traffic will not hit NSGs after it hits admin rules. So different teams can still work together. You can still have some network admin team that defines those security rules across the entire organization and says with an admin rule, I'm going to deny inbound SSH traffic. But if another team says I want to create an NSG rule to allow inbound TCP from whatever port, they can still do that. They can still do that as long as the traffic is not denied or always allowed by an admin rule. And something we've encountered even internally with Microsoft is this exception scenario. What if a team needs an exception to a security admin rule? How do you create that whole for those teams? So maybe in general, you have used a network manager to deny SSH traffic on all of your VNets, right? And this is applying to all of your network groups, every single application team's network groups and so all of their VNets. What you can then do is you can create another admin rule, a higher priority admin rule than your baseline admin rule. You can say, you know what? Actually, here's our exception rule right here. We're going to allow inbound SSH traffic but we're not going to apply this to all of our network groups. We're going to apply this just to the network groups, that consists of the VNets of the team that is requesting the exception. So if application team one is requesting an exception to this admin rule, and they say, you know, we really need SSH traffic. We're so sorry about this. Then what you can do is you can create that higher priority admin rule to allow SSH traffic. You target just that application team one's network group. So they're VNets only. And now that takes effect but everyone else is still protected by that lower priority admin rule that's denying SSH traffic. Everyone else is still protected. You've just created a pinhole using a higher priority admin rule. And now everybody's happy. And that application team one, they can use their NHG to allow traffic if they want on SSH. Maybe they want to deny the traffic in the end, whatever they want, it's up to them. But this way you can create an exception. Nice. Yeah. And this is our generic ending slide, but we have plenty of other links that we'll make sure we link out in the bottom. And of course we're always open to any feedback, whether you're testing things and still in public preview. So the mesh and the security piece, or if you even have any feedback for us in GA with the hub and spoke and the rest of AVNM, we're always happy to hear it. So with that, Michael, any questions that you have, otherwise we can move on to the demo. No, I think we can call in. I'm excited to have you come into the demo for us. Cool. Okay, so let's go into the demo for Azure Virtual Network Manager. We're gonna show you what this looks like in the Azure portal. Awesome. So when you arrive here, you can simply just search in the marketplace for network managers. Or like me, if you use network managers a bunch, you'll have this available. Pretty easily. You don't have any network managers yet. So the first step is to create one. And at first that create flow should look pretty straightforward. You just pick which resource group and which region you want this network manager resource to live in. So conveniently we have this filled out for me automatically. We're just going to call this maybe our virtual network manager. I'm gonna create this in East US. Now the region itself won't matter in terms of the resources that you're managing. So if I'm creating my network manager in East US, I don't need to create a network manager for managing vNets in East US and then another one for West US, whatever. It doesn't matter. My virtual network manager in East US will be able to manage and see virtual networks across regions. So we don't need to worry about this aspect here. I'll keep this in East US. And here's some fields that are specific to network manager. So scope and features. I've mentioned scope a few times during the PowerPoint presentation but what scope consists of is whatever management groups and subscriptions you want your network manager to be able to see. Reason this matters is because this affects the virtual networks that your network manager can see for you to group, for you to configure and then deploy, right? So if I selected this top level management group, what would happen is all of the vNets inside of all of these nested management groups, subscriptions, all of these vNets would be visible to my network manager and I'd be able to manage the connectivity and security of all of those vNets. That's not really what I'm intending to do. So I'm going to select just this one subscription where I know some vNets live and I just want to manage the vNets inside of those this one subscription. So I'm going to add that one subscription to my scope and then for features, these features are just asking you what capabilities for configurations do you want your network manager to have? So we have connectivity and again, that hub and spoke piece is currently GA or we have our security admin and in the future, we also have some other types that are going to be available for configurations. So I want my network manager to be able to create connectivity and security admin configurations, so I've selected both but maybe in the future, you want to have your network manager, you want to have one for each maybe one admin is in charge of just your productivity maybe one admin is just in charge of your security admin configurations. You can segregate it this way. And a quick note on why this matters is you can't create two network managers that have the exact same scope and features. So now that I'm creating this network manager nobody else will be able to create a network manager with the same scope of the same subscription and with the exact same features. So this is another reason why if you want to manage the connectivity and security of this one scope, the subscription here but maybe you want to delegate out the roles for who manages security and the connectivity you can do that. You can have one network manager just managing security another one scope to the same subscription just managing connectivity. In my case, I'm one person and I just want to manage everything for this subscriptions minutes. And so we're going to create this network manager. So that deployment succeeded and now it's complete and let's take a look at our virtual network manager that we just created. So here we can see again, you know the stuff that we use to create this network manager. So what subscription and resource group is this resource live in? Where is it located? What subscription is it a part of? And we can also see the features and scope that we created this with. So we can see that we enable both the connectivity and security pieces for our network manager. So this means that they this network manager will be able to manage the connectivity configurations and security admin configurations. Display does not loading. But we can see here that this is what we can do. And then for scope, we originally created this network manager to just have this one subscription inside of its scope. And so we can actually update the scope if we need to. So if you have created your network manager and then you realize I actually needed to modify my scope I need to add a few more subscriptions or maybe remove a couple of subscriptions. You can do this after the fact. And as you can see, you actually even have the capability to have a cross tenant scope. And so the cross tenant connection in virtual network manager, it's basically a two way handshake you dictate to your virtual network manager with subscriptions across tenants. You'd be that you'd like to manage. And then that tenant in their subscription would need to also send a request and say, hey, I'm okay with being managed by this network manager resource. And so once there's that two way agreement, then you can now use those cross tenant scopes as part of your network manager. And so you'd be able to add virtual networks across tenants into your network groups to be managed by the connectivity security configurations of this instance. So otherwise, this network manager is pretty empty. And so again, first step is group and then we'll configure and then we'll deploy. So going to the network groups, here's what I want to achieve. With my network manager, I created this because maybe I want to have all of my production and all of my test vNets all be a part of the same hub and spoke topology. I have one hub vNet and it has some gateway in it. And I want to make sure that this gets propagated out to all of my vNets no matter the environment that they're a part of. But I also wanted to create some security admin rules and have some baseline rules to be applied across all of my vNets. Again, regardless of environment, but then I also want some modularity. I had some specific other rules that I wanted to apply to my production vNets. So this is what I want to achieve. And I want to achieve this in all regions. So my first step is to create my network groups. So we'll create a network group for our production vNets. As you can see, there's no logic at all in this. This is just an empty container. Creating our prod network group. We'll do the same thing again for our test vNets, test network group. And now this is where some of the magic comes in. So if we go into our prod network group, again, we intend to fill this network group with a bunch of virtual networks that are supposedly our production virtual networks. And so again, we have two ways of doing this. We can manually add members and we can also use Azure policy to dynamically add members. And so by some set of conditions that we define ad group vNets to this network group. And then these conditions will always be continuously evaluated. So any new vNets that you create again will be added into this network group if it matches those conditions. Take a quick look at manually adding members what this looks like. The vNets that should populate this blade here. This is going to consist of all the vNets that are within my network manager scope. So within that one subscription, we have all of these vNets. And maybe I'm not so confident in my policy making ability. So I just wanna make sure if nothing else I want prod vNet one to be a part of this network group. So we're gonna manually add that vNet into this network group. And we're also at the same time going to start creating our conditions. So maybe we'll call this policy our prod vNet policy. And so this policy is going to be associated with this network group, with this prod network group. And below we're going to define that policy definition which are the set of conditions that will dictate the membership in the network group. So we have two ways of doing this. We have this GUI editor here and we also have an advanced JSON editor. And so what you can do is can select a parameter whether it's your vNet name, ID tags and location or your subscription name ID tags, resource group name and ID, an operator. So what is that string contained? Does not contain other operators and then some value. Fortunately, all of my prod vNets have the same naming convention. I know that the name all contains prod vNet which is very, very, very, very convenient. But maybe I would want to chain some conditions. Maybe I know the name is a containing prod vNet and maybe the tags contains or does not contain some key. Maybe I also want to do this by subscription or some other parameter here. So we give you the ability to do that, right? Something else I want to point out real quick is although we have subscription ID and name as a parameter here for your policy definition, we also give you the ability to choose out of your scope, choose a subset of your network manager scope or where you want this policy to be evaluated. So this is another way to just kind of filter down the vNets that are going to be part of this network group by your subscriptions that are in your scope. If we switch to the advanced editor, we'll be able to see the JSON, pure JSON version of this policy definition. So all of the vNets where the name value will contain this string of prod vNet, it's all going to be added into this network group. So we'll save this policy that we just created and this will take a minute or two to evaluate. So while it's doing that, why don't we go back and do the same thing for our test network group. We might create a policy that basically does the same thing for our test network group and it's going to say, hey, all of our vNets out of all of our vNets inside of our network manager scope whichever ones have some naming convention by test vNet, go ahead and add that vNet into this network group. And again, I just really want to hit home on this point. The reason this is so powerful, the reason this is so powerful is because any deployments, any configurations that are deployed onto this network group, if you have a vNet in the feature that's going to be added to this network group automatically, it's automatically going to receive the same configurations that are actively deployed on that network group. There's a reason that is so powerful. You know, another thing that's nice here with the Azure policy portion of this is that, we all know that a lot of organizing, the cloud kind of consistently keeps changing and a lot of organizations make decisions when they originally built their infrastructure such as a naming or something like that. Because of the flexibility and the ability to use Azure policy, it's really difficult to rename all of your infrastructure, but it's super easy to tag, to script tag hundreds if not thousands of resources. So with that, it would allow people to easily scale up to this by making some changes by using things like tags on the backend that aren't going to have any impact on your organization, but they're gonna allow you to be able to still take advantage of these. Yeah, certainly. And something else I'll note real quick is that while we support the tags parameter in this basic GUI, as you can see from the operator, the GUI only allows for you to look at the key of the tag instead of both the key value pair or even just the value itself. But you can still achieve this by using the advanced JSON editor. You can specify the tag value to be maybe prod, test or whatever it is that you're trying to use to evaluate your network group membership here. So that's a really flexible way to do this. Absolutely. And while we're not showing that to you here, we do have that in our documentation because it has been a question that we've been asked. So we have that documented for you. So we'll have the link for you to check that out if you wanna play around with it. Yeah, thanks, Michael. Something I wanted to point out real quick that I failed to do on our first network group is we do have a preview resources button. So once you create your policy definition set, if you wanna test it out and say, what VNS are gonna be caught by the conditions that I just created, you can do that. So using that condition where I said the VNet name contains some string called test VNet, all of these resources, all of these VNets under my network manager scope are matching these conditions. So 151 VNets. And so this is quite a fair number of VNets here. 251 to be exact. And I noticed that there is a spare VNet that I actually do not want. So I'm gonna go ahead and chain a parameter. And name does not contain. So you can get quite unique and complex with these conditions. But again, the most flexibility you'll get is using the advanced JSON editor. If I preview resources, this should be an even 250 now. Perfect. So we're going to save this policy. So now we have our production VNet network group and our test network group. Both of these are set up. And this test network group will also take some time to evaluate, but if we refresh and we look at our production network group, this one should have 250 group members and the test network group. As we saw with the preview resources button, this will soon catch up to 250 VNets as well. So it really only takes a couple of minutes to fully evaluate. And of course, it depends on the size of your scope that you're evaluating and the number of resources that are gonna match those conditions. But give or take a few minutes and your network groups are set up. So now we're just going to go ahead and move on to the configuration piece. So the first type of configuration we want to create is the connectivity configuration where we're going to dictate what kind of topology we want among our VNets and our network groups. So we know we want a hub and spoke. Now I'll keep the camel case consistent here. Apology. And so true to name, we want a hub and spoke topology, which again, hub and spoke is in GA. Mesh is the topology that is still in preview as is direct connectivity with the hub and spoke. And apologies, I seem to have some trouble with scrolling, but I will show you as much as I can here where we're selecting our hub that we want in this hub and spoke topology. And conveniently, I know that I have a VNets called a hub VNets. So this is indeed the VNets we want to use as a hub. And although I have no gateways inside of my hub VNets, perhaps you will have a VNets that has express route gateways, VPN gateways, whatever other gateways, and you'll be able to select for your spoke network groups to use this VNets as a gateway. We have this very, very humble option here called delete existing pairings. It's quite powerful. It does exactly what you think it would do, where once this connectivity configuration is deployed, it would delete all existing pairings in your selected network groups. And it would just replace it with the connectivity that AVNM establishes here. And so it's just offering to do some cleanup for you. Again, it's not checked by default, so you don't feel pressured into doing this if you're not comfortable with it. But this is an option, an easy cleanup option if you so choose. So we'll add some spoke network groups. Again, instead of choosing 500 VNets that you would want to be a part of this topology, we're just going to choose the two network groups that we've created that each have 250 VNets in them. So we want our production VNets to talk to this hub and we want all of our test VNets to talk to this hub. But we don't want them to talk to each other. And again, apologies for the lack of scrolling here, but I hope you will trust me in knowing that all of those network groups have been added as spokes here. Let's double check this. We currently have a visualization tool that's currently in public preview. And what this tool allows you to do is actually view the topology that you just tried to build. And so we just said we wanted a hub and spoke topology with our hub VNets and then these two network groups. So you can see some information about this hub VNets. We can expand this out for more details. Maybe I have some gateways in it or some other resources in it. We look at our prod network group which is connected to our hub VNets. We can see that our prod network group is connected to our hub VNets. Our test network group is connected to our hub VNets, but indeed there's no connectivity established between our test and our prod network group. So if we expand this network group, then we'd be able to see, wow, look at all of these VNets. We have all these VNets inside of here. You'll notice that none of these are directly connected to each other. Unless we selected that option, which that would have been an option that we can select back in the topology section where we can enable that mini mesh, again, enable that direct connectivity among our network groups. We chose not to do that. So we're just showing here's all the VNets that are a part of this network group. We can see the options here. Direct connectivity is disabled. We're not using the hub as a gateway and we don't have a global mesh so this is automatically disabled. So this is just a way for you to gain confidence in the topology that you're building. So if we review and create, yep, we're creating a hub and spoke topology with our hub VNets as the hub and with the spoke network groups having our product and test network groups. So we're creating. And again, nothing has been done yet. We're just staging because what's that third step? That third step is deployment and we're not there yet. The last thing I wanna do before doing a deployment, though I could do a deployment at this point, is to create a security admin configuration. And so I can create a security admin configuration. Let's call it security admin. And this is going to consist of rule collections which of course consists of rules. And so let's add a rule collection in here. We're going to call this our baseline security rules. Security rules. We know what a baseline we want to block SSH traffic. Everything else, you know, maybe it'll depend on the network group, right? But baseline security rules, we're going to target both our prod network group and our test network group. So all of the VNets are going to be receiving the same set of rules that we define inside of this full collection. So let's go ahead and create that. And our security admin rule that we'll create here is we want to block port 22, which carries SSH traffic. We're going to make this, you know, medium priority. You can choose a zero to 99 for the priority or it's one to 100. Someone will test this out and correct me on this. But we're going to deny the traffic that's coming inbound to our VNets on the TCP protocol for port 22. And we'll add this rule. So this is a simple deny rule with admin rules. Again, any traffic coming in on port 22, it will hit this admin rule and then it will just be denied. Any NSGs that say otherwise won't even be read. They will not be evaluated whatsoever. This is hard enforcement here. So we are just going to add this rule collection. So again, we're targeting both network groups with this one rule because we know no matter what the network group is we know that we want to block SSH traffic. But maybe I want to add one more rule collection because I want my production network group to have a more stringent set of security rules than my test network group. So maybe I'll add some extra ones for just my production VNets. And maybe I'll do something like blocking some other traffic. Maybe I'll force allow some Windows updates. Let's see where we want to go. Let's block the traffic over port 20. We'll make this a higher priority. Across your security admin configuration you need to have unique priorities. So if I created a rule in the previous rule collection for priority 50, and as you can see, I get this error here. And this is to prevent any sort of conflicts again. So you couldn't add a rule that says actually allow traffic on port 22 and make the same priority. We won't let you do that. So that would lead to 100 rules, right? Yep, yep, within one configuration. Yeah, yeah. So if you know in general you want to blanket deny everything, this is quite an effective rule, right? Because then you can create maybe, let's say five rules where you have four rules where you're pinholding some traffic in and you're allowing or always allowing that traffic. And then you have one rule that says block everything, deny all traffic on everything, have it a low priority of 99 or something. And it's one way to really optimize the number of rules that you're creating and not hit that limit. So we're having this be a pretty high priority. We're gonna deny inbound TCP traffic coming into port 20. Okay, we created this rule. We could create as many rules as our priority allows here but I'm pretty happy with this for just my production fee nets. So again, we've achieved that baseline set of security rules but still have some modularity in dictating specific rules that are just going to apply to our prod network group but not to our test network group. So with this, I'm pretty happy with my admin configuration. We're gonna create that. And then the last step, let's see all of our configurations in their query. We have our haven't spoke topology so our connectivity config and we have our security admin config with all of those rule collections and rules. Last step is to deploy. Now we could do it from this blade here but let's do it from here because why not? So there's a lot of text on this page but all you need to take away from this is that when you deploy your configurations you need to select the configurations by type that you want to be effective all at once. So if I was just going to do my connectivity configs I would need to select all of the connectivity configs that I want to be effective. Here it's easy because I just have one. I have my haven't spoke config but maybe I would have multiple meshes and multiple haven't spokes. If I wanted them all to take effect I would need to select all at once. This is because deployment in AVNM is not additive. We won't make any assumptions in terms of what you want to deploy or not. So you need to tell us explicitly check box all of those configurations that you would like to be deployed in your regions. So let's do both security and connectivity configs at once. Currently we only allow you to deploy one config at a time but remember you can have multiple rule collections and this is just to prevent the scenarios where you might end up conflicting and having multiple configurations for a security side means that you could potentially have conflicts and this just gets a lot trickier messier and honestly kind of goes against the whole idea of making that scale management easier. So we foresee to do this in one and actually I'm still running into that scroll issue so I am going to un-include the security for a second. I'm going to target whatever regions I want. Now I know that all of my venus happen to be in West US region but just in case I'm gonna select everything I'm feeling lucky I'm going to deploy in all regions at once but again you have the capability to just go one region at a time deploy, monitor, see if your configurations are doing as you expect and then roll forward or roll back as you need. So we'll target everything and now we'll add that security configuration and then we just have a quick review page of kind of the Delta for each region where we're seeing let's say West Central US region. Originally there were no configurations inside of this region and now we're adding two different configurations we're adding the hub and spoke topology connectivity configuration and the security admin configuration. So let's deploy. Yeah, that's very quick and easy. In what? I took some time to explain but in just a few minutes really I was able to group all of my production and test venus into their respective network groups. I created a hub and spoke topology so effectively 500 pairings all at once with a hub vNet and then I created some security admin goals that are highly enforced and they're going to apply onto my cloud network group and also on my test network group. So we have baseline rules and product specific rules and now I've deployed this in all regions and it's still in progress but it should be effective in some regions starting now. So we achieved all of this in just a few minutes and now this is automatically going to be maintained because again once you create let's say a VM, you provision a new VM inside of a vNet that's already covered by these admin rules VM is automatically protected. Let's say you create a new vNet that matches the conditions of let's say your prod network group. You create a new prod vNet has the same naming convention matches the conditions new prod vNet is added into this network group and is going to receive the same security and connectivity configurations that are currently deployed on it. So it's going to be grandfathered into this topology and also going to receive the same security admin rules. So, and real quick, I want to point out on the visibility side let's visit one of our prod vNets and see what network manager has done. It might take a quick second because as we could see it was still deploying in a couple of regions but I do want to point out that if you know what you're looking for you can find the network manager blade inside of your virtual network instance. And inside of this network manager blade you'll be able to see security rules admin rules that have been applied and also connectivity configurations that have applied and I think it's still rolling out in the West US region so this is why we don't see it currently but it will show up. The same thing is true for VMs if you are owning a VM and you're wondering what effect network manager is having on you you'd be able to look into the Get Effective Accol for your NIC and you'd be able to see the security admin rules that are applied. Very cool. Well, that was an awesome demo. I think that shows everybody, we talk a lot of stuff but I think once they saw it I think for most people out there they're going to be like, oh, okay this makes a lot of sense I group all my stuff together, configure and then deploy. Super simple, super easy it's laid out that way in the portal you don't have to go five million different places to do things. It's very step by step and like you pointed out with the deploy after you get using it for a while after you do the config you can choose your config you can go up and click the deploy that there's that built in where you can do the next step usually in the previous steps very where you're looking at it so a lot of flexibility, very easy to use all of this we've got heavily documented I'm also taking notes as we're going through here I'm like, oh wow, we should document that we should document that so I've got a lot of work to do to add some of this great stuff that you've shown us today about Virtual Network Manager. Yeah, I mean, certainly there's so many things that you can do with Network Manager but you really got to the heart of it which is like we're trying to be the same thing of class for all of these networking needs that you have for your virtual networks and the network resources that they contain and again, I would really encourage I know we're introducing so many new concepts through this video and through all the public documentation that's available the best way to get into it is by playing with it go into the Azure portal and just testing it out, tinkering with it and getting a feel for that three step process that group configured deploy because we're introducing a lot of new contracts but we're also introducing a new way to approach network management at scale so with all of this I really appreciate the time to be able to speak about Azure Virtual Network Manager and to demo and show off how it works. Absolutely, it's been great having you and just to kind of tag along on that we will have plenty of links to we've got some great tutorials and how to's that'll walk you through basically very similar to this demo so you can do everything you can create a hub and spoke you can create a mesh you can do security admin rules all of that will take you from beginning and creating the virtual machines through to the end and you can definitely walk through that one other thing I wanted to throw in there real quick is while we did all this in the portal today you can do all of the same things with PowerShell through Azure PowerShell through Azure CLI you can also use Azure Resource Manager templates and something that I've been working on that we're gonna get in our documents very soon is you can also use Terraform as well so kind of my last thought on this why I think this is so cool is that when I talk to customers one of the big things that they often run into is because the cloud has changed so quickly I'm not saying they planned improperly at the beginning they may or may not have but things have changed and how they need to use it so this is such an amazing tool if you've got an organization and you're like we need to have a hub and spoke that you could literally sit down figure out where all of this is create your groups based on your design create your configuration and then you could roll it out by region and be able to if you were to having to redo hundreds of manual peerings that would probably be a job that I'd be walking out the door on I mean, yeah, you could build an ARM template to do that and maybe one of these GPT thingies or AI could build that for you but I don't trust that this is such a great tool for those organizations that not only are starting out but they're existing that you can put it into place it works with your existing peering and there's no downtime and there's no downtime which none of us like downtime yeah, exactly awesome well, hey, thanks, Andrea it was great having you on today covered a ton of material and I appreciate you taking the time and look forward to talking to you at a later date when we dive into some more of the stuff on other pieces of virtual network manager when it becomes GA definitely, we have a lot more pieces coming thanks so much, Michael look forward to mesh security admin and a bunch of other features that we have coming out very soon so super excited awesome well, hey, everybody thanks for watching Wired for Hybrid our deep dive on Azure Virtual Network Manager I gotta do the typical YouTuber thing make sure to smash that like button give us a thumbs up and if you have any topics that you wanna hear about maybe you wanna hear more about something with Virtual Network Manager or another Azure Networking topic let us know either on the blog post on the comments you can hit us up at Michael Bender on Twitter at Wired Kanook on Twitter with that thanks for me, for Andrea and Pierre have a great one we'll see you next time