Moving out of App Service Environment?

Most of the companies when starting a new product expect a heavy traffic to their website or APIs. Everyone expects the product will be a game changer in the market on launch.

Obviously with such expectations, you would want to go for high end app service plans for your services. Also considering security without doing much, App Service Environment is a dedicated secure environment provided in Azure which gives VNet feature with private IP for application gateways to point to.

But pretty things doesn’t come easy, they have a running cost and a high fixed monthly cost.

Unfortunately there is no feature in azure out of the box to scale down from Isolated ASP(App Service Plan) in ASE (App Service Environment) to non Isolated ASP.

I had the same problem where business asked to scale it down and there was no direct solution.

Below are some gotchas when you want to move your services out of ASE without much impact to live users.

  • You can’t create any resource with the same name. If you are using Azure durable functions, it’s better to create a new resource group , delete the old function and create it again in the new resource group. After that you can move the storage used by function from old resource group to the new one.
  • If you are using App Service, I would recommend creating another App Service with a new name and later change the DNS entry to point to new App Service. Once done, take the other app service down.
  • With App Service, you need to be ready with certificates if using SSL for the new name.
  • Be ready with old DevOps release definition for a rollback plan.
  • As you are compromising on security to cost, you can implement a security strategy,

 

Below is the security strategy that I implemented.

  • I made sure that all the requests to the API and Http triggered functions should come through WAF.
  • I created rules in WAF to add a custom header for all the requests.
  • I checked at API level for any incoming request, if it is having that header value or not.
  • To validate the values, I used two tokens which were stored in a Vault – Primary and Seconday tokens.
  • I created an automation which on a schedule will change the keys in Vault and then at WAF. This ensured that even if the token is compromised, it will be replaced with the new value after some time.
  • In Azure, there is a feature with which you can directly refer Vault tokens in AppSettings. This saves the coding overhead to fetch the latest value from Vault regularly.
  • Additionally, I added IP Restrictions on the function to allow traffic only from App Gateway IP and deny everything else.

 

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out /  Change )

Google photo

You are commenting using your Google account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )

Connecting to %s