 Hey, you want to talk about custom IP prefixes, you want to talk about private endpoints, and you want to learn some more about DNS in an hybrid situation, stay with us on Wired for Hybrid. Hey everybody, Michael Bender here, and happy to be here in Wired for Hybrid. I am a senior content developer at Microsoft in Azure Networking, and I'm here with my good friend Pierre Roman. Hey Pierre. How are you doing? I'm good. Hey, we're doing this show. What is this about? This is something that I think a lot of our audience is really going to get into this. You can go places and find out what's new and what's happening, but where are you going to get you and me together on the big screen talking about Azure Networking and bringing our decades, I age myself, of experience on-prem, in the Cloud, in a hybrid. We're going to bring you what's new in Azure Networking. We're also probably going to work in some deep dives into some cool new tech that we see coming in 2023. Some special edition episodes. Special edition episodes. Definitely stay tuned. We're planning on doing this on a monthly rotation with what's new and then throw some other things out there. That's what we're looking at. What do you think Pierre? Sound like fun? I think that's great. Distilled to like a 15-ish minute. What's new in the last month with Azure Networking? That's a fantastic idea, Michael. I'm on board. Awesome. Hey, we don't want to waste your time, so let's get to it. Pierre, what is new in Azure Networking from Ignite? This one is new and not new. Does that make sense? It was GA, but now it's GA for every region, including the US government regions. For anybody in North America, it's fairly important. It's the custom IP prefix or bring your own IP, now available to all regions and including the US government regions. What that does, when you own your own IP, so if you're a large company or if you're very secure, and you're not using your ISPs bank of IP addresses, you've actually bought your own and you've got your BGP AS number, and you're basically hosting and broadcasting your own addresses. Typically, these are for highly secured environments where who you're connecting to, that address cannot change. But if you decide to move that workload to the Cloud, either you have to route it internally or you can bring your own IP into Azure. In this case, it goes through a onboarding process where we start broadcasting your own IP addresses for you so that you don't have to change any DNS settings at your end at all because it's the same IP address, it's just being hosted somewhere else. You don't have to worry about maintaining your IP reputation. So if you're in a company that does mailing lists, if you're MailChimp, for example, I'm not sure if they're doing it the war, where they're doing it from. But a company like that, you don't want to have to get blackballed for some reason because that IP address is suddenly a brand new IP address that's flooding email systems everywhere. So you don't have to do anything like that because it maintains your IP reputation. All of our B2B partners, your business-to-business business-to-wherever, that have rules to allow traffic coming from your IP addresses, none of these have to change because your IP has not changed. So it's a great way of having your IP range hosted in Azure while you maintain ownership of it but you don't have to worry about routing it through your network, through an express route, for example, into your Azure system. Very cool. So this is truly that next step to making your hybrid environment seamless. Not that there aren't little seams there, but this really is that next step to, you know, okay, is this live or is this Memorex? You know, is this in your data center or is this in the cloud? That this changes that for those outside things. So this sounds really cool. So this works for IPv6 too, right? That's correct. So IPv4 and IPv6, the only kind of prerequisite is that you must own and have those IP address or that range registered with Aaron or RIPE online. And so if you're using an ISPs address or anything like that, don't even try it, it's not going to work. So you have to be fully owned and have your own BGP AS number. Very cool. Very cool. How about you? Do you have something new for us? Yeah, I've got a couple of things. So we've got a couple of things around private endpoints that have come around for the customization of properties. So, you know, just kind of really to bring up people up to speed, you know, what a private endpoint is, it's that net, it basically creates a private network interface using a private IP address inside of your virtual network. So it allows you to connect privately and securely to your Azure workload. So it allows you to basically have Azure storage or Azure SQL right inside your virtual network through an IP address. So traditionally how that would work is that you create a private endpoint and it would random, random, whatever random is, it would pick an IP address out of your range of addresses, which for many workloads that works kind of fine. But let's say you are one of those organizations where you're putting in security rules that require filtering at the IP address level. It's like, it's either this IP address or nothing's going through. If you have a private endpoint, that IP address... It's dynamic. It's dynamic. So it changes. So now you have these rules that get broken and then, you know, we all write scripts. A lot of times we have those scripts that have IP addresses in them specifically and they're not using DNS. Because of that dynamic feature, we can run into some problems. So now what we can do is we can deploy our private endpoints, putting in a static IP address from your reserved IP addresses. So this is gonna make for those instances, for those security rules, for, you know, really just think about, we've had those situations on-prem for so, so long where you need to have a static IP address. That's why DHCP has had reserved addresses and all those things since the beginning. Same thing in the cloud. We have those needs for a reserved static address. So if you have that need for a reserved static address for your private endpoints, you can now do that in Azure. The one caveat here is the only time you can set it up is when you create it. Okay, so if I've got, exactly, if I've got private endpoints right now, I'd have to basically recreate them or create new ones and then repoint my systems to that new one. Correct, correct, yeah. So there's, you can do it in the portal, you can do it in Azure CLI, you can use Azure PowerShell, so you can do it across the board. But the one thing is, you know, right now the only way to do it is at creation. So I think that's a really cool thing for, you know, lots of organizations, probably more an enterprise sort of thing, but, you know, as- I think anybody who deals with security and security rules will be on board with that. Perfect. You have another one too with private endpoints, didn't you? Yes, I did. So, one of these issues I've had over the years, and it kind of goes back to my old days when I worked for a Fortune 500 telecom and I worked on the Windows side and we had the Linux team and they named their servers Bart and Lisa and Homer. We know in Azure that a lot of our names, you know, those were pick names. I have no idea who Homer is. I know who Homer Simpson is on TV, but I have no idea in my network what Homer does. Yes. In Azure, we often have this problem where we create a resource and it auto-generates a name. So like with private endpoint, when you create a private endpoint, it creates a name, Microsoft.privateendpoint-guid. Oh yeah, that's very easy to remember. Yep. And, you know, the challenge for, I think for everybody is as your environments start to scale, you're gonna have hundreds of these and when you're trying to find a resource and it goes by a GUID, you know, that's keystrokes, that's time. And so now what you do- And it leads to error because nobody can remember a 32 character GUID. Exactly. Exactly. Now with private endpoints, we can create a custom network interface name during the creation of the private endpoint. So what's interesting here is this is it's called you rename the private endpoint, but you're renaming it while you're creating it. So you can do it with Azure CLI and Azure PowerShell right now. So instead of having that long thing, Microsoft.privateendpoint-guid, let's say I wanted to be my web app PE-VNet01. So when I see that, I know that, oh, hey, this is the private endpoint for my web app, web app that's in VNet01. So from a naming convention standpoint, boom. I know exactly what that is. I can find that. You know, it's easy to go through. So there's a couple of different ways you could do it. With PowerShell, there's a specific parameter that you put in for the, when you create the private endpoint with PowerShell, it's a dash custom network interface name parameter. And then Azure CLI, very similar. And of course, Azure CLI seems to be somewhat more user friendly. It's dash, dash, nick, dash, name. And, you know, being a PowerShell fan, you know, I mean, I read that parameter, I'm like, okay, that's totally good for me. But I do, I do understand- It's not like you have to type this every day too. Yep. And you use tab complete. So it fills in the parameter for you. So, you know, that's the beauty. And most of this stuff is going to be automated, right? Absolutely. You're gonna have this in your- Infrastructure as code type of deal. Infrastructure as code, whether it's ARM, whether it's bicep, you know, when you're deploying your stuff, scaling out and, you know, you're not gonna be, chances are you're not gonna be typing this in. You're just gonna be put it in. So, but- Those are two very, very interesting and kind of like removing splinters that we've had in our fingers for a long time kind of updates. Yep. So I'm glad to see that in GA now. Yep. It's great to see these type of things coming along because it's obvious that, you know, you and I spend a ton of time with customers over the years and, you know, even before my days of Microsoft, you know, always knowing people in the industry and, you know, a lot of times hearing the pain points and everything's not great, but things like this kind of show that, hey, we are listening to you and we are trying to make your experience better. And now that the, like you kind of lead me into this one, it's almost like we rehearsed this. The pain points and listening to our customers, it's a known fact that managing naming resolution across a hybrid environment has always been a pain. Absolutely. Like a death by a thousand cuts or death by a thousand C name records. But now this became globally available or GA right at the beginning of Ignite. And it's one of my favorite. It's the Azure DNS Private Resolver. And the way it works, the Private Resolver is an engine. It has an input queue and it has an output queue. All of your other environments, so if you've got hybrid, so on-prem, you would configure your DNS on-prem to do a conditional forwarding to the input queue of the resolver. Your private DNS zones that you may have everywhere in Azure, or if you've got another DNS zone that's hosted in a third party or another cloud that you've got all connected, all of those DNS would go to the input queue. And if the resolver can't find the address within the environment that it's got set up, it uses the output queue to go to your, whatever forwarder you set up, or your internet routes server. So it's a way without having to manage because what we used to do is spin up a couple of VMs and install a DNS on that, and then create all of our zone transfers and stuff. You don't have to worry about anything like that. It's all done with conditional forwarding type of rules or DNS rule sets in Azure to say, if it's this directory or this domain, this is the server that's hosting it. If it's this domain, this is the server that's hosting it, but it puts it all into like one umbrella as a private resolver. Makes hybrid name resolution really, really easy going forward, so it's easy to grow with it. And you don't have to worry about having to manage new instances of a DNS. So it grows with it. It's a managed service, so it has multiple instances in the background. You don't have to manage any of that. And from what I understand, I don't have the exact pricing, but it's a single price per month. So you don't have to worry about if you're going two, three, four VMs to run your DNS. You don't have that cost doesn't vary. It's like the set cost per month. So very easy or fairly easy to set up and addresses a ton of headaches when setting up hybrid name resolution. That's awesome stuff. And it kind of goes with that comment I made previously to where the bring your own IP address is helping to get to that seamless point of like your hybrid environment is just your hybrid environment. And this is that next step here. And the thing that I love the way that you put, you describe that because it took me back to my days of teaching of teaching DNS that every IT pro that works on Prem knows exactly what you're talking about and they're going to be able to do this because this is how we did this on Prem. So now they can work with Azure DNS, use private resolver and set it up the way they've set up conditional forwarding previously. I see this as being one of those, sometimes the IT pros feel kind of like left out and world in the cloud sort of thing. This is one of those things where they're bringing along their knowledge that they have to be able to put these two things together to take their organizations to hybrid. So super cool stuff. Absolutely, absolutely. And again, like you mentioned, it's where we're stopping the pain points one at a time. Hi, Michael, we want to keep this short. So next month we're going to have a new slow of what's new in Azure networking. We haven't like set up on a date but stay tuned with this channel, hit the bell to subscribe and be notified when our new episodes would come in. And Mike, we'll see you next month in the cloud. Take it easy PR, take care everybody.