Azure App Service and Virtual Network Integration Options

hey everyone in this video i want to talk about the relationship and the interaction between app services and virtual networks because there seems to be a lot of questions coming in about or do i use a private endpoint do i use v-net integration do i use a gateway so let's kind of look at this so app services were actually one of the original azure services way back when it first started they've gone through really a lot of innovation around there so i can think about well i have my app service plan now normally this is a multi-tenant model i.e there's a certain stamp of infrastructure that has front ends there's data roles there's file services so that is shared by the customers on that particular step there's a single inbound ip address you can get a unique ip address if you really want it through the kind of uh ssl option then there's multiple outbound ip addresses we have this shared set of front ends the data roles the file servers and then unique per customer you have a number of workers these are the things where you say hey this is the type of worker and the sku these can auto scale and this is where when you create your particular kind of web app etc it's running on your workers so the workers they're unique to you then there's that other shared set of infrastructure and then you have kind of your virtual network so over here i'm creating my v-neck which again is kind of a set of ip addresses and the challenge we have is really two the first one is the apps running in my app service plan want to be able to reach resources running in my v-net and or or maybe there's other v-nets that i have peered them and or there's on-premises resources that i happen to have connected by a site-to-site vpn or express route so from the act maybe there's a database there's some other tier of service i want to be able to get to things here and then i've got resources running here that want to be able to privately get to the app remember the multi-tenant model there's an inbound ip address that's public facing and maybe i want to lock that down so what can i do with that so we have these two different requirements now when we think about that let's start off thinking about going to our application and the first solution is kind of a very familiar one it's service endpoints so if we think about well hey look we've got our virtual network here and we think about well we divide this into subnets so i can think about well i have a particular subnet here and what i can do is i can turn on the service endpoint so the service endpoint is going to be that microsoft dot web now this particular subnet can be known to app services so now on this app service it has kind of its set of inbound controls i can actually specify hey well on those inbound controls you can imagine it's kind of like a a firewall into the app service i'm only going to allow in we'll call this subnet one well i'm going to say subnet one yes um you're allowed so it's still technically going through the public ip address but when i do the service endpoint remember it creates the optimized route so it's not just bouncing around the regular edge routers etcetera it's doing a very direct route as really as optimized as it can get and i'm now restricting it through its rules to say hey only coming from this particular subnet now the challenge with this is service endpoints it's just for things in the subnet what about if i want to get to it from other networks or on-premises so one of the things i can kind of add to this is well i can actually do something like app gateway if i deployed app gateway into that subnet with the service endpoint the microsoft.web other things would come into the app gateway and essentially proxy through and then go via that path so this gives me that ability so it's still going the public endpoint but it's completely locked down i can't get to it from anywhere other than the subnet with the service endpoint that i have enabled so this is all about hey from rvnet wanting to go to that particular app the other option well there is one other but the other main option for controlling giving access that way is private endpoints so that's obviously very very common today more services are kind of adopting this so the private endpoint there's a an ip address is consumed from a particular subnet in our virtual network that essentially is enacting the traffic to that i could now completely again lock down the app to not allow anything other than this particular private endpoint and that's going to work for kind of windows apps linux apps even windows containers today so at this precise moment as i'm recording it's preview but i think it's going to come out of that any day so again that's the other option private endpoint i would then access that ip address and the great thing about private endpoint is it is just an ip in this v-net so any network that is connected to this v-net can see the ip and use it i just have to make sure i have the consistent dns in place so it works and resolves to the private endpoint i mentioned there was another there is of course ip address restrictions that i can use on this thing so if i know the ip address the request is coming from i can restrict it to just that ip address so for example i could have a nat gateway i could have a standard load balancer with outbound walls i know the outbound ip i could use that as well but honestly if i'm talking about something in the v-neck talking to it that service endpoint is a better option it's really locking it down to that particular subnet so great that addressed things going from the v-net talking to the app what about the other direction now my application wants to be able to talk to things actually within the virtual network now option one is not really well suited to this option one is suited to the idea that hey there's some resource on premises could be a database um some other component that i want the app to talk to and this is where we actually go and use hybrid connections so with hybrid connections we have this hybrid connection manager that we deploy it establishes an outbound connection over 443 to azure relay which then lets the app talk to the service now this is only tcp it's a particular tcp port an endpoint so i'd have to have one of these for each different sort of sets of things i want to talk to it's tcp only i can't do udp over this thing but now it's established the outbound connection which now enables the app to go and talk to whatever source this is kind of offering it could be a database for example so technically i could deploy a hybrid connection manager in my v-net it would establish that outbound 443 to the azure relay which would now enable that direction of connectivity so absolutely i can do that it doesn't make the most sense in the world though there's better solutions for that and we have two so the first is a gateway required v-net integration so as the name kind of suggests i have to have a gateway so i can think about we use a different color so here i'm going to have a gateway and it has to support point to site vpn so we're going to do the route based dynamic and what's going to happen here is my app is essentially going to establish a point to site vpn connection so it is going to go and connect to the gateway so i have to have the gateway remember the gateway lives in its own kind of dedicated subnet and then from there well it would be able to talk to those things now this does not allow me to go and traverse to things like express route what is nice about this gateway option is well actually that gateway could live in any azure region so maybe the app service plan is south central i want to go and talk to a v-net that's in east or west or europe this will work i can have a gateway in other regions and it will be able to talk to it also this will work with classic virtual networks so the old style before arm i could have the gateway there and i could do a point-to-site vpn connection to it so that that's one option the preferred option is regional v-net integration so we're going to kind of draw this in yeah another color we'll do this in gold so if regional v-net integration as the name kind of suggests we have a particular subnet now this is going to be delegated for this app to integrate in so now what we're going to do is this app is essentially going to take over this subnet and it's going to consume my p addresses within that subnet this has to be in the same region as the app that's why it's regional v-net integration i i cannot use this if i want to talk to a v-net that's in a different region i cannot use this to talk to a classic virtual network so this is the best solution if the v-net is in the same region as the app but if it's a different region it's classic i'd have to go for the gateway approach now what's going to happen here remember these workers each worker is going to consume an ip address in this kind of delegated subnet and i can't use this subnet for anything else it's locked down only the app service plan so if i had three workers i'd be consuming three ip addresses so when i'm sizing this subnet i have to think about what's the maximum scale i'm ever going to do and then double it because let's say i was going to have eight workers at max remember if i resize my workers the way azure works is it spins up eight new ones of the new size make sure they're working and then deletes the old one so that the eight existing the eight new ones and then it would delete the old so i'd have double that number so nothing about sizing make sure it's double the maximum number of workers you're ever gonna have remember you lose five ip addresses sort of the the host the the broadcast then the three azure ones that it steals so make sure you size this subnet so you're gonna size this subnet so if i thought i was gonna have eight workers i think well i need 16 usable ip addresses then i probably make that kind of a 27. if you're not short on ip addresses maybe just give it a slash 24 but make sure you size it correctly so from here it can now go and talk to things in that virtual network it can talk to things over the express route so i can go and talk to that as well it cannot talk to peered networks so if i had another network that's appeared it's not going to work if it was a regional peer it's not going to work that's what's good regional being appearing doesn't support peering itself today it's just a regional integration now if i had private endpoints within this virtual network talking to other services maybe i've got a particular storage account or something well now this app through the vena integration can go and talk via the private endpoint to that storage so i can start to lock those things that way it can work together like that so what do we kind of have to the app i i can do ifp access restrictions but generally we're going to do a service endpoint for the microsoft.web if i need beyond the subnet i can always proxy via app gateway or i can use private endpoints from the app to my resources well yeah i can use the hybrid connections it doesn't make the most sense i can use the gateway point-to-site works across different regions best option is the v-net integration today v-net has to be the same region actually has the app itself one caveat to all of these things and there's different types of kind of app that i can run an app service plan web apps mobile apps api apps and functions now remember functions can be serverless if i want to use functions and i want to use these kind of capabilities with the exception of the service endpoints and the ip restrictions if i want to do functions i have to run it in kind of a dedicated i i'm running it in a regular app service plan with workers or i think it's kind of the elastic premium which is fairly close to a kind of dedicated i i cannot do the pure consumption the regular consumption can't smell um functions will not work for most of these things because it can't there's no dedicated set of resources to establish this so if you use azure functions and i want to use private endpoints um i want to use the bina integration i need to run it on a dedicated app service panel or elastic premium then i can get that now there is of course one other option and this is the ace so if i just draw a brand new picture for this one super quick i can think about once again i have my virtual network so i have my v-net and remember before we talked about there's all those shared components like the the data stores the file servers the front ends and then there was the workers with an ace what actually happens is i have a particular subnet and then i deploy my app service environment into that directly so i can think about within here i have kind of the front end i have kind of the file servers and i have my workers so these are now actually running in the subnet in my virtual network so it's dedicated it's all dedicated to me so now if there are other resources in the v-net or cover connected well there's no other integration required this stuff's sitting in the subnet there's different types of base there's uh internal external in terms of what it's facing you would do internal if you wanted that direction but now it's on the subnet inside that ace i would create one or more app service plans where i'd run my apps and they'll now have that full kind of connectivity to it so that's the other option the downside is the ace is more expensive because i'm not getting the benefit of those shared components anymore i kind of split the cost with other tenants and they're all running inside my subnet but this was kind of the traditional way we had to have kind of that private connectivity in the past but now we have all those other great private endpoints service endpoints v-net integration etc one note if you do this remember there is still kind of the azure resource manager management plane and lots of other things this still has to be able to talk to that if you do a bunch of controls and locks and things on this and lock it down so much uh you can break it there's actually a lot of different communications required they're all documented but don't think i can just deploy an ace and then turn everything off it's gonna break so there's still communications required with the kind of arm management but this is another option it's just there in your v-net that wouldn't be my first choice because of the cost there's more things involved um ideally you'll kind of look at these and in the ideal world it's the same region i'm probably going to use the the regional network integration option and top private endpoints or those kind of service endpoints will hopefully do what you need so again i hope this was useful i was trying to clear up the distinction i'm going to need one of each v net integration doesn't provide me with the ability to talk to the service integration is at talking stuff here and then private endpoints or service endpoints going the other way so there's different technologies they're all unidirectional they do one of the requirements we have hope this was useful again please like comment subscribe and share if it was until next time take care you

Channel: John Savill's Technical Training

Views: 60,024

Keywords: azure, virtual network, azure networking, service endpoints, private endpoints, app service plans, app service environment, vnet integration, hybrid connections

Id: 5P14Q--Q9vE

Length: 19min 58sec (1198 seconds)

Published: Thu Sep 10 2020