App Service Environments Architecture and Cost
I love using App Service Environments; however, the cost is shocking. We like that our App service can communicate over our express route to our data center. I gained some new understandings with how these services work on the back-end and it seems confusing. I have an understanding that normal App Service Plans operate such that a fault tolerant pair is available in a different part of the data center and in the event of a failure, your code is moved to the other pair. This is great and I love that. With ASE's the architecture changes and the use of fault tolerant VM's is used instead. This seems to break away from the original architecture of App Service Plans. It seems more logical if you could drop a Resource (maybe not necessarily an App Service Plan) inside a VNET (and on an existing subnet) that would have a fault tolerant partner hidden in the back end just like with the public versions of these services (I'm ok if you even have to reserve IP's for the services). This would operate much like Availability Sets for VM's. This would also seem to cut costs down for customers and allow us to deploy a great many of these services. I would even be OK with managing a series of NAT rules for external services. Currently, the scale time and usability of ASE's make it really hard for me to justify the costs.
If any part of my understanding is incorrect, I would appreciate clarification.
Ed Gillett commented
Likewise, it pains me to see the CPU utilisation lying idle on what I have to deploy within an ASE just to leverage an ExpressRoute connection. In my case I don't need the scale, I just want the agility to control my own deployment environment, but leverage an ExpressRoute connection for access to an on-prem SQL server that can't yet be moved.
Prices are better at larger scale than you might think as compared to multi-tenant. There is the cost per ASE which is a pain but that covers the ASE infrastructure. The higher pricing per core covers the higher internal prices for the HW as well as the infrastructure needs as we scale out. With that said, in many regions the price per core matches Premium. On top of that the better VMs used for ASEv2 give you an over 100% improvement per core. That sorta means that the price is half of premium, at scale. When you think of it that way then the markup from Standard is actually only 1.5 times Standard, again at scale. So if you have a lot of stuff to host, then ASEv2 is pretty darn good for pricing and you have the network isolation which is so very useful.
With respect to putting an ASP into a VNet, it doesn't work like that. The traffic to your apps go through Front End roles that distribute the traffic to the roles hosting your apps. As the multi-tenant App Service is in a multi-tenant network, we cannot simply attach the networks.
With that said, this is an area we are actively working to improve both for ASEs so they are even better and also to enhance our network options for the multi-tenant App Service.