I am following best practices document and trying to implement Auto Scaling and would like to know about pricing perspective.
Robust-Apps-for-the-cloud
I would like to utilize custom auto scale to use multiple instances. I have configured the rules as shown here:
With this, I would like more information on how this will affect the pricing for my app service plan.
Note: My App Service Plan is S2.
App Service Plans are priced based on the size and number of instances you run, and they are billed on a per second basis. For your case on the S2 plan, a single instance will cost $0.20/hour.
I see on your autoscale configuration that the minimum and default number of instances you will be running on this plan is two instances. With this, if the autoscale triggers are not hit, your App Service Plan would cost $0.40/hour.
With the configuration you shared this could run up to $0.80/hour, if maximum four instances are run after the autoscale triggers are met.
As App Service Plans are billed on a per second basis, the cost will be prorated on a per second basis for the number of instances you run.
For example:
if you were running two instances for 40 minutes, three instances for 10 minutes, and four instances for the last 10 minutes of an hour. The total cost of the App Service Plan for that hour would be roughly: $0.50 for that hour.
If you were to scale up or down your App Service Plan tier you can see more information about how this could affect pricing using this tool here:
App Service Pricing
Related
On Azure's payment estimator, I can choose the number of hours that I want an app service to be active/paid for. As my app isn't required out of office hours or at weekends, I could reduce the number of hours and therefore the cost estimate considerably versus paying 24/7. I therefore used the estimator to come up with an (affordable for my organisation) estimate of having the services running for max of 500 hours a month.
What is not clear is how, now I have app services up and running on Azure, do I set the services to run on a schedule that matches the cost estimator? Is there an option or functionality hidden away somewhere to do this?
There is no option to suspend an azure app service plan. You can stop/start a web app running on a plan but that won't save any costs. I agree it is confusing that the pricing calculator makes it seem that you can suspend a web app plan.
The only thing I can think of is to scale down to a free tier plan during out-of-office/weekend hours and scale up to a paid plan but that is limited to some basic tiers (for example, since there are no slots in some lower tiers you will have problem if you want to use those). You will have to script this yourself.
The other option is to delete the whole app service plan and web app and create it / deploy again when needed. You can automate the creation using a bicep or ARM template.
References
https://learn.microsoft.com/en-us/answers/questions/278494/can-we-stop-azure-app-service-to-save-cost
Automate tier scaling
App Service unlike Azure VMs don't have the ability to pause billing. If the App Service exists, it is billing. Please see the below recommendations to control costs.
Optimize costs
At a basic level, App Service apps are charged by the App Service plan that hosts them. The costs associated with your App Service deployment depend on a few main factors:
Pricing tier Otherwise known as the SKU of the App Service plan. Higher tiers provide more CPU cores, memory, storage, or features, or combinations of them.
Instance count dedicated tiers (Basic and above) can be scaled out, and each scaled out instance accrues costs.
Stamp fee In the Isolated tier, a flat fee is accrued on your App Service environment, regardless of how many apps or worker instances are hosted.
An App Service plan can host more than one app. Depending on your deployment, you could save costs hosting more apps on one App Service plans (i.e. hosting your apps on fewer App Service plans).
Source: https://learn.microsoft.com/en-us/azure/app-service/overview-manage-costs
We currently using old cloud service classic which scale out to 100 instances.
We are interested to migrate to Azure Functions. Based on this doc, the best in terms of timeout and max instances is Premium Plan with timeout 30 minutes and max instances 100:
https://learn.microsoft.com/en-us/azure/azure-functions/functions-scale#scale
But when i read this doc, it mentioned max instance is 20 only, so i am confuse:
https://learn.microsoft.com/en-us/azure/azure-functions/functions-premium-plan?tabs=portal#always-ready-instances
Anyone has experience what's the max allowed scale out instance for Premium Plan? Thanks.
For premium plan, the pre-warmed instances can go up to 20; but total (or maxmium burst) can go up to 100.
When events begin to trigger the app, they are first routed to the always ready instances. As the function becomes active, additional instances will be warmed.
I have 2 questions first related to hosting, second related to sdk/library to use:
I need to write a kind of work allocation service scheduler to people, which will run say every 1 hour to run compute intensive logic in background and push the results in our database. The input may be number of days to create schedule for, number of people available, count of tasks to be done. So primarily its compute intensive.
Should i host it in App Service or in Azure Function (TimerTrigger)? This scheduler run as total background job and never called from UI or any backend API.
If i go App service way i have choice of either Hangfire or WebJob. How should i decide which is good for me.
Certainly quick execution with lesser cost is my criteia to move ahead.
One consideration for Azure function is how long the processing will take. Azure functions have a maximum time limit that depends on hosting plan. When you create a function app in Azure, you must choose a hosting plan for your app. There are three hosting plans available for Azure Functions: Consumption plan, Premium plan, and Dedicated (App Service) plan. An overview of hosting plans and their timeout durations is here: Azure Functions scale and hosting.
Unlimited duration is in Premium plan or Dedicated plan (Unlimited execution duration - 60 minutes guaranteed).
Maximum duration for Consumption plan is 10 minutes.
Can anyone please elaborate me the minimum and miximum price of below settings(for reference) while creating the FunctionApp in Premium Elastic plan(EP1).
Q. How does Plan Scale out
Minimum Instances,
Maximum Burst and
App Scale out
Pre-Warmed Instances settings of FunctionApp affects costs?
For your question, I summarized the pricing rules below for your reference:
Azure Functions Premium plan provides the same features and scaling mechanism used on the Consumption plan, but the difference is we can set the Pre-Warmed instances.
Premium plan can avoid cold start by setting the Pre-Warmed instances, for example we can set 1 instance for Pre-Warmed(but smaller than minimum instances size which you set), then if the function app hasn't been requested for a long time, we just need to pay for the warm instance. The price is shown as below:
The EP1 plan is 3.5GB for each instance, so we can calculate the price.
While the function app is requested, then it will billed on a per second basis based on the number of vCPU-s and GB-s(based on the number of the instance which your function app uses on a per secnond).
Hope it would be helpful to your question~
I got the answer: here
"You are charged for each instance allocated in the minimum instance count regardless if functions are executing or not."
Context: I am designing the auto-scaling (scale out) configuration for my .NET Framework 4.7 web app hosted on a Microsoft Azure App Service. I am using the P3V2 pricing tier. The application is CPU-bound. The app's 30 day CPU average is 30% usage while running on 2 instances, according to the stats indicated in the App Service plan. We occasionally have traffic spikes which will overwhelm the 2 instances: I want to implement auto-scaling.
I want to take into account the App Service Provisioning + App Startup Time when designing the metrics thresholds that decide when my app service scales out. I need to make my thresholds low enough to give Azure time to spin up a new app service instance but not so low that I am paying unnecessarily for processing power that's not needed. Budget is a significant factor.
Question: How long does it take for an Azure App Service instance to be available after a scale out? In other words, how long does it take for an Azure App Service to scale out?
P.S. I recognize that there is a lot more to scaling in/out that I am not addressing here. I'm trying my best to be succinct. :)
Generally, not long at all. By that I mean typically under one minute, but the time will vary depending on several factors, such as application size, time of day, region of deployment.
You could scale out manually and inspect the run history logs on the scale out tab.
FYI you can also use Azure Monitor to create auto-scale policies, in case this is of any use to you.