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!
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?
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.
You are right, it is quite cost change.
The starting costs for each seem to be:
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.
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.
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:
As I understand it:
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.
Id say your method is the most you can do for lowest cost, coupled with stopping and starting in the shell.
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.
Accumulated costs of my AppGateway.
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.