Maximizing Azure Network Insights with VNet Flow Logs

Okay. I think we're gonna get started now. It is the top of the hour, one minute after. So welcome, and thank you for joining today's LinkedIn live, on maximizing Azure network insights with VNet flow logs. My name is Phil Gervasi. I'm joined today by Chris O'Brien, who is a leader in product management here at Kentik. And together, we're gonna be having a discussion on how Microsoft has expanded flow log capabilities, visibility capabilities beyond network security groups, otherwise known as NSGs or NSG flow logs rather, to provide greater insight and, you know, ultimately control visibility, observability over network traffic in your Azure environment. So thanks, Chris, so much for joining me today. Yeah. Happy to be here. Great. So before we get into VNet flow logs, and that's really the important part of the conversation today, but I think we have a little bit of a runway to to go down before we get there. You know, in discussing how VNet flow logs really bring a new level of Azure observability for for us, why don't we start with discussing, well, why? What are some of the weaknesses that we were experiencing with NSG flow logs? And that'll help us understand why Azure came out with VNet flow logs last year, and came out with them in the first place. So, Chris, I'll hand it off to you to kick us off. Yeah. You know, historically, Microsoft has provided flow, you know, that five tuple record of what traffic is transiting your the network. They provide that through their, NSG network security gateway flow logs. So that's great in that it provides some of that sort of traditional flow and detailed information about the traffic transiting your network. But the big issue was always that NSG flow logs are only available to export where you have NSG. So you can't get that level of visibility. You can't really understand what traffic is transiting your cloud network, in places other than where you have that NSG. And that's a real limitation. You know, a lot of folks use Flow in their on prem networks, and they certainly get, Flow out of their firewalls. But, I would say that's not even the number one place that folks export flow from. There's lots of places in their network that they need to see where what traffic is transiting. So that was a big deal, that limitation in NSG flow logs. You know? It might be that Microsoft, in its great wisdom, delivered to all of us in the world this architecture of, pervasively compartmentalizing all of our network, you know, subnets, all of our networks so that, they were secure in using NSG to do that. And, thus, if you export export from NSG, then you have visibility everywhere. But practically speaking, you know, that's more complex than it's worth for a lot of folks. A lot of our our customers were making the decision that if this is internal only, if I have a high degree of control, over this traffic anyway and there's low risk, I'm not gonna deploy some security architecture, specifically NSG beyond that. And so, you know, I think that not coming true left us with a world where folks felt like they had pretty low visibility of the traffic transiting, Azure. Yeah. Yeah. I mean, there are literally places where we have no visibility using NSG flow logs within a VNet, and that's that's a problem. When you think about the nature of traffic moving among, subnets and gateways, and you mentioned firewalls and express routes and all these other network constructs. Those flows, we have ingress and egress and various components of those, of those rather various components have ingress and egress to them. You know, to piece all of that together and to understand a single application flow or a file transfer requires that we have visibility into all those components. I think that's probably one of the major, drawbacks of NSG flow logs is that we are lacking visibility into certain of those components that are just not supported. Right? Yeah. And the more advanced you get with flow, the more you start exporting, flow from multiple steps in what is the same traffic path of, you know, the same packet because then you can see where things are stopping, where things are changing. And, you know, all of these network constructs you you mentioned, they make little changes to the packets or, where they're routing. And so seeing, flow from multiple points can be helpful to understand that. So, you know, the good news here is that VNet VNet flow logs, you know, address that. They make, flow logs come sourced from essentially where you have the VNet, deployed. So very similar to AWS's VPC flow logs, and VNets are just a much more fundamental and ubiquitous building block in Azure's networking cloud networking. So, now you can do flow log export from all over the place, and it it really starts it feels much more now like you have a complete visibility from a flow perspective in Azure, where Azure was for a long time behind AWS on this. Okay. Do you have any specific callouts that you'd like to make about some advancements or some some specific things that we could say add to this completeness that we were lacking with NSG flow logs that we do not now have with VNet flow logs. Yeah. Like, historically, one of the big challenges has been that you don't get bytes or packet counts with stateless flows. Mhmm. NSG wasn't providing that, and so you can now get that. You know, your stateless traffic, does not tend to be your most important traffic, but that doesn't mean you don't wanna see it at all, number one. And number two, a lot of folks are thinking about totals. What's my my total traffic? And they don't want a big question mark of for stateless there. They wanna know what that total is, particularly when they're thinking about billing and so forth. So that Yeah. Bytes and packet counts in stateless flows, is a great ad for VNet flow logs. Yeah. There is you know, because it is supported in because VNets are so much more fundamental, you know, they you get flow from a number of places that you didn't get it from network security, group flow logs. Mhmm. I think I said gateway. I said network security gateway. I'm not sure why I said that network security group flow logs. And that includes Azure's API management as well as Azure's application gateway, their, virtual network manager, their virtual machine scale sets. I guess scale sets were supported in NSG, but are also supported in VNet flow logs, VPN gateway, all of those that I listed, aside from virtual machine scale sets were not supported in in NSG, and they are now supported in VNet flow logs. I'll tell you the amongst the customers that I've talked to about it, the one that they're excited about the most is ExpressRoute. That ExpressRoute gateway being able to see flow, exported directly from that has been, something folks are looking forward to. Yeah. I can imagine that if you're running some kind of a hybrid network where you have a VNet and you have spokes and, you know, you're deploying NSGs everywhere, NSG flow logs everywhere to all the NSGs that are applied, that gets pretty complex, and you are gonna be missing some, visibility. So being able to apply it at the VNet level solves that problem in one of those kind of hybrid set, which which are very common scenarios when you have those, spoke networks, tunneling traffic back to a a particular VNet, perhaps a transit VNet, which we still do in the cloud. So yeah. Yeah. One other thing, a little bit more on the security side is, you know, if you look through all the fields that are supported in the VNet flow logs, there's not a lot different than NSG. It's it's definitely more about the points that you get visibility into rather than the data that is, exported about that visibility. One new field, one of the very few new fields is encryption status. Definitely security rate related. It's, seems like it might be interesting, but, honestly, you know, in talking with our customers, I have not spoken to a single, company that is, you know, interested in seeing that yet. Really. So time will tell if that's actually useful for folks. But Yeah. You know, there's a call out for something that has changed, but, not seeing a lot of interest in. I mean, one of the benefits, whether it's realized benefit or not, is that we can understand why encryption is not being applied, whether, you know, there's a hardware, problem or some sort of problem, that is gonna show up in the in the logs, in the VNet flow logs Yeah. In in the NSG flow logs, we wouldn't know. So we do have the status update, which is very important, and also some valuable information as to what might be wrong. So that's certainly in addition to your, your security posture. Yep. So why don't we move on to integration with third party tools, which is not something that we really struggle with too much with NSG flow logs, but I would like to cover that specifically with regard to other public clouds as well. Yeah. I mean, having, VNet flow logs being more aligned to VPC flow logs in terms of ubiquitous access and covering stateless traffic, better, you know, that being more in line with Amazon, I think makes it easier for for us at Kentik as as one of those, you know, third parties to Azure to normalize that data. And then what's what's important for a lot of the the folks we serve is after normalizing that data, I can define a query and have that query tell me about traffic that is transiting both, Azure and, AWS. Right. And so, you know, on the surface, that's interesting and can be valuable for folks, performing those queries. I I imagine that's true of many other third party tools that more consistency between the, cloud service providers generates more, you know, powerful queries and and particularly cross cloud queries in in their tools. It's also true that, you know, as we go more and more into machine learning, having those datasets normalized and available for, these ML models is super useful. Like, one of the things that we worked on is, a query assistant, which is basically, you can we we have quite an advanced query builder where an expert can go in and formulate a really interesting, novel, brand new question about the traffic that's going across their network, execute that query, and get an answer. The challenge with that is there's a lot of options, and there's a lot of fields, and and, you know, there's regex, and, like, there's a million different ways you can customize that query based on a decade of of, you know, advanced network engineers telling us, I need to be able to ask questions like this. And so that can, you know, for a new person, be a little bit daunting, and for an experienced person, just take some time. Yeah. And so with the query assistant, it's not rocket science. We're just translating what is natural language. Tell me about traffic from this, AZN to these different countries, and translating that into one of our, what we call data explorer query builder. Data explorer query, and then we just return the answer. In situations like that, again, the better we can normalize the data to to offer up to the machine learning model, the more accurate, which is really the, like, key question when it comes to ML, the more accurate we can get the translation from natural language question to data explorer query. Absolutely. I mean, the goal here is, near real time telemetry, being able to query that historical telemetry. And there is no room for, you know, hallucinations like folks like to talk about with which is really more relevant to generative AI than it is to ML classical, or traditional, application of ML models and ML techniques. And so for us to be able to do this in such a because we have these more advanced, more a more complete picture with VNet flow logs, for us to be able to do this do this doesn't only help the maybe more level one NOC engineer or cloud engineer that isn't necessarily adept at creating these complex queries, but also because remember, we are trying to troubleshoot problems and keep those applications flowing. Even in more advanced engineers to simply ask the question and get an answer back quickly, efficiently, and with a level of trust that this is these are metrics. This is real data. So there's a huge advantage here in having, increased visibility through the, you know, through the use of VNet flow logs normalized with other data as well, and then being able to generate those queries with natural language. So this is, this is a this is a really big advancement and I think a great way that we kind of approach all of this more from a data analysis perspective. Yeah. You know, one of the things, cloud network engineering is not the same as network engineering precisely. And one of the big things that I've been hearing, from our users is that, you know, the the team they have for their cloud network engineering team is a lot smaller than their network engineering team was. Great point. Yeah. Great point. And they field a lot of questions. In the nature. Many of those questions are from, application owner or a DevOps person or or, you know, one of these folks outside of their group saying, hey. This doesn't isn't working anymore. I don't know if it's the network or not, so go ahead and investigate that and tell me. Right? Which is very reasonable, very logical approach. But a number of our customers have been like, you know, this isn't the challenge is this is not particularly doesn't feel like particularly valuable work for us to do. It doesn't require a lot of our expertise. But, also, the people that are requesting, they do not have the knowledge they need and the permissions they need to log in to our traffic analytics tool, like with Kintik, and formulate a good query. So, we have a couple of customers now who have, you know, connected this, query assistant functionality into, for example, Slack so that someone can jump in. A non, you know, cloud network engineering team member can jump in and ask a net a question in natural language Mhmm. And can deliver the response to that question along with a graph, showing the history or other visualization right there in Slack. And, you know, you can do that with the cloud network engineering team still in the thread so that they can keep an eye on that, make sure that the answer looks right to them, but not do this you know, it's about democratizing that data. You know? Yep. Network engineers and I think everyone knows how much value there is in seeing what traffic is going on. A great example of that is you have a significant increase in a, you know, application that is popular and consistently used. That's a a red flag. Right? You might wanna look into it. And there's a million of these cases where the the network traffic is bit of a litmus test of the application user experience. So, you know, I think AI and generative, large language models particularly open the door to that democratization of of, traffic analytics. Absolutely. They augment, engineers trying to keep the lights on for sure. I'd like to move on, though, to something that we sort of have been discussing around, and that's the, the idea that, you know, NSG flow logs are a little bit more or much more cumbersome to configure and to deploy compared to VNet flow logs. And that's a big advantage that we have with VNet flow logs is the simplification of deploying, this functionality and thereby making getting visibility easier, not just complete, but also easier to manage from an operational perspective. So for a little color, NSG flow logs are well, you know, they operate at layer four. They show inbound and outbound flow information on a per NSG basis, like you mentioned, per NSG rule basis, which means that they are applied only where NSGs are applied. And so if you're applying and creating, network security groups at all of these components and elements, keeping in mind that not all components support it, like a some kind of a gateway inside of a VNet may not support NSGs, that's setting up those, NSG flow logs all over the place. Whereas with VNet flow logs, you you configure it at the VNet level. And, and and if you're using, you know, an Azure network watcher, you can simply, enable it for all of the VNets in a in an entire region, making it even that much more simple. Whereas NSG flow logs, you're gonna you're gonna tie that to a specific subnet or to a specific NIC, you know, if you wanna go down that road, in a in a, in a VNet. So, you know, if you have, as an example, something like a gateway running, a gateway usually with an associated subnet, you're gonna have that, you know, cordoned off. You can't apply an NSG to those. So you not only have a lack of functionality, but now you have an increased complexity in trying to figure out how do I get visibility from these other components. And another thing is that remember that in NSG, a network security group is right there looking at you know, it's applying rules inbound and in and and outbound into these into these components. But there are certain security rules, admin security security rules that get applied prior to that. So the NSG flow log themselves are not going to capture that information if you have an an allow or a deny rule that's being applied before it even gets to the NSG. And so there's an l there's an element of complexity in trying to, you know, maybe have multiple screens open and a staring compare of different logs and different, components there to figure out why traffic is blocked when it shouldn't be or allowed when it shouldn't be. Whereas VNet flow logs, capture that information, and you have it all in one centralized location, making their deployments and then, of course, like, like, just the operational usage much, much easier. So you're really just you're creating and applying it once and then solving a lot of those operational problems in one shot with the VNet flow logs. So Yeah. Totally. It's it's a better way to go about it for sure. Yeah. Yeah. And and, actually, I was gonna ask you if you had anything to add, on that note or anything in general that we haven't covered today. No. I think we we covered it. Just looking over my notes. I think I we covered everything I wanted to talk about. Great. Great. Okay. So on that note, thanks so much for our audience for joining us today for this LinkedIn live. It's been a pleasure, and thank you, Chris. And also stay tuned for future discussions just like this one that we had today. So network observability for your public cloud environments. Today, talking about Azure, but regardless of the public cloud that you're running is a really big deal. It's a really big part of what we do at Kentik. So please visit our website, Kentik dot com slash cloud to learn more. You're gonna see a ton of information there like, blog posts, demo videos, links to podcasts, a lot of really good information. So on that note, thanks so much for, watching today. We'll see you soon.