App Service environment isolated: Making security & internal network connectivity easier and cheaper

Azure App Services

Azure App Services is arguably the most popular Azure PaaS service, allowing you to host Web Sites and App Functions in a fully managed service. Once you had created your App Service Plan, and Web App, API App, Logic App or Function you can upload your code and have a simple website, API, Logic App or Function up and running in under 10 minutes. Of course, there are a number of other configuration options, such as binding a domain name, adding an SSL Certificate and the 'out the box' ability to do blue / green deployments. However, it was simple to get up and running and like any PaaS, Service should be, simple to manage. Azure App Servers runs in a multi-tenanted Environment. In short, your App Service shares the same hardware as other Azure Customers, and while this provided a cost-effective hosting solution, the multi-tenanted aspect introduced a number of restrictions around scalability and security. To address this, in June 2015, Microsoft Azure released App Service Environments (ASE), a premium tier of Azure App Services, which allow you to run App Services isolated within a subnet of your own Virtual Network.

As a premium service, ASE comes with a premium price tag, so if you are architecting a solution that included an ASE, (compared to the multi-tenanted and cheaper equivalent) you have to make sure your business case can justify it. If you need:

 - Your App Service to connect to infrastructure within your local network, via a site-to-site VPN, Express Route of VNET Peering,

 - Your App Server hosts internal or Line of Business Application that should not be publicly accessible,

 - Layer 3 Network Access Control, on both inbound and outbound traffic,

 - A Static Outbound IP Addresses that can be whitelisted on on-premises or third-party firewalls, including securing connections to AzureSQL,

 - You need more compute resource (without an ASE, you have can have a maximum of 10 compute resources, with an ASE you can have up to 100),

 - You wish to place a Network Virtual Appliance in front of your App Service, or,

 - You require a fully isolated & dedicated compute resource,

In July Microsoft released the next generation ASE: App Service Environment Isolated or ASEv2, but what are the differences between ASE Isolated and the Original (ASEv1) and should you migrate?

What has changed?

User Experience

If you are used to deploying ASEv1, the biggest change you will notice is that they have made using an ASE simpler, and there is less to set up and manage. It feels a lot more 'PaaS' like and is generally a good experience. Gone is the configuration overhead of ‘Front End Workers’ and ‘Backend Workers’, and you no longer need to worry about ensuring you have additional workers for fault-tolerance and scaling - this is all now managed for you.

Pricing

This change means that there is a large change to how an ASE is priced. There are two components you need to be familiar with to be able to price an ASEv2:

1. The App Service Environment Base Fee which covers the costs of running your ASE in “a private dedicated environment”, these include load balancing, high-availability, publishing, deployment slots, and general configuration that takes place at an ASE level. This cost (which varies by region, in UK South the pricing currently stands at £782.88/per month) remains consistent provided you don't alter the default Front-End Configuration - one I1 instance for every 15 worker instances. The Front-End Instances only handle SSL termination & layer 7 load balancing. In this case, the default settings will work in the majority of cases, and while they do, regardless of how many worker instances you have the base fee will not change. If you scale up the Front End instances, (or the I2 or I3 instance type) or decrease the number of workers per Front-End Instance, your base feel will increase with every additional core above the default configuration.
2. Isolated Workers (the compute that excuses your code) - you decide how many workers you require to run and scale your app and as such, you have control of the costs of the worker layer. This is charged per hour, so if your workers are scaling to meet demand, this cost may not be consistent each month.

Compute Resource

ASEv2 only supports the ‘I’ series of virtual machines - these are all Dv2 based machines, which means faster cores, SSD storage and twice the memory per core when you compare to ASEv1. In short - the Dv2 almost doubles the performance compared to the previous generation.

Fault-Tolerance

As part of the process of making ASEv2 simpler, fault tolerance is now managed for you. You no longer need to have, or pay for, standby workers.

Scaling

In ASEv2, they have simplified how the scaling works to bring it inline with you auto-scale your App Service Plan outside of an ASE. You no longer need to worry about ensuring you have enough workers at the ASE level to enable your scaling actions to happen, and again, means you are not paying for computer resource that you're not using.

Cost Savings

If you do a head to head cost comparison of ASEv1 and ASEv2, you might question if ASEv2 is any cheaper. However, when you consider that you are getting almost twice the compute power in the ‘I’ series of computer resource (and therefore should need less of them) and that you no longer need to pay for fault-tolerance or workers ready to scale, ASEv2 will work out cheaper.

Should we migrate?

Microsoft Azure has taken the end user feedback and each of the changes we have listed above bring real benefits. Nordcloud has already seamlessly migrated a number of its clients from ASEv1 to ASEv2 and they are already benefiting from the cost savings, both directly and indirectly from the reduced effort of operating the ASE.

If you would like to talk to Nordcloud about if an ASE is suitable for your requirements, or how we can help quickly and seamlessly migrate you from an ASEv1 to and ASEv2, please get in touch today.