Azure Application Gateway in arcgis server cost too much

[yaronmmichlm]

in my  Academic organization recently installed the arcgis server 10.8.1 ON microsoft azure cloud usinge the cloud bulider,.Right now just for the sake of experimenting

and we foud  up that Azure Application Gateway that install with arcgis ,is working for all the time inIn a situation he spends every month more then 100 $.

how do we lower the price for the Azure Application Gateway Today we only run the server for a few hours for a trial, but the 

[ChristopherPawlyszyn]

Hello @yaronmmichlm,

I came across a request to simplify the process on the Microsoft Azure Networking improvement site, but currently the only method to reduce cost would be to stop the Azure Application Gateway via the Azure CLI when not in use, then start it before use using the CLI.

This blog post gives a solid explanation of how to do so.

How to stop Azure Application Gateway – UseIT | Roman Levchenko
https://rlevchenko.com/2020/07/28/how-to-stop-azure-application-gateway/

Start and stop Application Gateway on Azure portal – Customer Feedback for ACE Community Tooling
https://feedback.azure.com/forums/217313-networking/suggestions/34819891-start-and-stop-application-...

Hope that helps!

[yaronmmichlm]

thanks a lot for the answer

i did as you tall ,but whaen  i reopen the Gateway  and the server with the arcgis cloud bulider

i get 502 Bad Gateway ,is there is a way to solve it?

[ChristopherPawlyszyn]

The 502 response from the Azure Application Gateway is usually due to the backend target health failing, so I would start in your Azure portal console to look at the status of the backend machine.

[Anonymous User]

You are right, it is quite cost change. 

The starting costs for each seem to be:

App GW WAF V1 from US$0.13 / hr + traffic if >10TB

App GW WAF V2 from US$0.44 / hr + traffic if >10TB + scaling if massive # connections 

Bare in mind they calculate the final total cost quite differently from each other as they are diff generation of service product / Azure SKU.  The App GW WAF V2 is much more advanced, more features, elasticity, stability, security etc.

I believe V2 was first enforced to be deployable in ArcGIS Cloud Builder for 10.8.0+ which uses Azure App Gateway WAF V2, whereas ArcGIS Cloud Builder for 10.7.1 and lower used V1 (I think).

To save costs you can try:
1. Removing the App Gateway WAF V2 from your current deployment and deploying and configuring a App Gateway WAF V1 instead. You may need to update ArcGIS Enterprise settings as well, I am not quite sure.

OR

2. Deploy the older 10.7.1 using the older ArcGIS Cloud Builder linked above which will use the cheaper App Gateway WAF V1. Then attempt to upgrade ArcGIS Enterprise 10.7.1 to 10.8.1+ or whatever desired newer version.

@ShanonLoughton 

[DavidHoy]

The V1 Gateway does not provide URL rewrite features https://docs.microsoft.com/en-us/azure/application-gateway/rewrite-http-headers-url.
In 10.8.+ Enterprise deployment pattern, URL re-write is used to allow a single URL to be the entry point for the Enterprise site and federated servers - passing requests to Portal and AGS sites using a path context e.g. /portal or /gis or /image and rewriting to use :7443/arcgis or :6443/arcgis instead as required.
If you drop back to V1 AGW, you either need multiple Gateways or reintroduce Web Adaptors to do the re-write.

I believe Chris Pawlyszyn's approach may be the better way to deal with the additional expense for a V2 AGW. 

[SimonGIS]

I also stumbled on that same post to start/stop AGW and helped me resolve some other issues, now using it for cost savings on my sandbox environment.

Wanted to still lower costs, and saw some conflicting info online about manual Vs Autoscale.  However this post and this help article are worth reading.  

Two options to lower costs, suited for a sandbox environment and maybe some production environments that have steady traffic, depending on SLAs:

1. Manual, you can set to minimum of 1 instance over default 2.
2. Autoscale, you can set min of 0 and max of 2.

As I understand it:

• Autoscale says that even with 0, 'High availability is ensured, even if set to zero.'  (so no cold start with fresh/new connections)
• Autoscale will always reserve capacity units as long as AGW is started. 
• Autoscale costs should be lower than manual for a low traffic site.

I will report back on how the monthly bill looks.  

Of course, for a sandbox environment, maybe the best approach is to start/stop the gateway with a manual instance of 1, just when you need it.  Currently doing that via the history in the GUI-powershell to do this, but I will likely forget!  Should probably look into a local powershell script to spin up/down the environment that starts/ends with spinning up the AGW.

@ChristopherPawlyszyn @DavidHoy - let me know if you have learnt differently from this, will also report back on how autoscaling option helps with my azure costings in a month or so. 

[ShanonLoughton]

Id say your method is the most you can do for lowest cost, coupled with stopping and starting in the shell.

[DavidHoy]

I don't have personal experience with stopping/starting AGW v2 or with the scaling options, so I am interested to hear the results of your testing Si.
@ShanonLoughton may have experience or opinion?
In another site, we dropped back to simple Load Balancer sharing to Web Adaptors - this allows simple context based routing with a single front end URL and is way cheaper and easier to deploy manually than using AGW.
I like Web Adaptors - when I hear people saying they are a bottleneck, I think they are likely blaming the bad performance of underlying services on an innocent party.

[SimonGIS]

Accumulated costs of my AppGateway. 

• The rising cost is when I left the AppGateway started (its default state) 
• Flattening of the curve correlates to me Stopping the AppGateway every time I spin the VM down
• Typically use the VM/AppGateway for about 3hrs a week. 

Lesson here - turn off the AppGateway for your dev environments to avoid eating into your Azure credits.  I have still not automated it, need to have a shell script that starts/stops the Gateway/VM to avoid human error.