App Plan Settings
App Plan Price Tier
We need to scale up the app service plan for already deployed function app. But Scale up option is disabled in Azure portal ? Please any one have experience on this
It looks like you have an Y1 App Service Plan which is a so-called Consumption plan:
Scale automatically and only pay for compute resources when your
functions are running.
On the Consumption plan, instances of the Functions host are dynamically added and removed based on the number of incoming events.
Source: Overview of plans
So you can't scale your Consumption plan because it scales automatically. You might consider switching to a dedicated plan (See: Dedicated hosting plans for Azure Functions)
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
I have a durable function app to handle xml file in blob which size is between a few megabytes and hundreds of megabytes.
The requirement requires up to 20 files to be process at the same time.
I've scaled out the durable function app to 4 instances, but when requests increase rapidly, only 2 instances encountered the problem of too high CPU, while the other 2 did not.
This results in very slow file processing.
Is there a problem with azure's built-in load balance?
See this picture to check the high CPU issue
Generally, the scaling logic in Azure Functions currently works well when the function is triggered by things like queues or Event Hubs.
if you're running your Function in an App Service (also known as a Dedicated Plan), it will by default only scale instances within the possibilities of the App Service Plan you defined.
Using an App Service plan, you can manually scale out by adding more VM instances. You can also enable autoscale, though autoscale will be slower than the elastic scale of the Premium plan. [...] You can also scale up by choosing a different App Service plan.
If you run your Function App on Consumption Plan (the true serverless hosting plan option since it enables scaling to zero)
For further information check the below provided links.
Azure Functions Scalability Issue.
Azure Functions Hosting Plan.
Consumption Plan Scaling Issues.
While doing some research for a customer some doubts have rise regarding how the pricing on App Service plans work and what would be the best way to configure the ARM templates for different projects.
What I would like to confirm (and I don't think that Azure documentation is very clear on that) is if you pay only for the App Service Plan itself, even if you don't have any web apps running.
Imagining that I would like to have 2 web apps running on a Standard tier, is there any difference of having a different app service plan for each that I can later change independently for a single project? (e.g. one of the web apps may require more compute power in the future while the other doesn't).
And if by any change we remove the web apps from the subscription but still leave there the App Service Plan configuration... is anything paid in that case, even if there is no computing happening?
Thanks for the help everyone. Cheers
TL;DR You pay for an App Service Plan, not for an App Service.
Looking at App Service Plans details, you see the number of Apps an App Service Plan can have.
A Free plan can have 10
A Shared plan can have 100
A Consumption plan for Functions can have 500
All other plans can have unlimited
Now for your question: you don't pay per App Service. You pay per App Service Plan. And this is regardless the number of apps. This is because you pay for the fact the plan is there, ready and waiting. You've reserved the resources specified in the tier you selected. The fact you're not using them isn't of influence.
Of course, consumption plan is the odd one out, since there you do pay only for compute used.
If you take a look at Pricing - App Service, you also see the pricing tables specify pricing for App Service Plans, not the App Services.
EDIT:
I would pay more for 2 service plans with 1 app each than 1 service plan with 2 apps on top
Yes.
Since an App Service Plan is an abstraction for (something like) a virtual machine, having 2 App Service Plans means having 2 virtual machines that are reserved for you.
EDIT2:
As #Juunas said in his comment:
you do pay per VM in your plan, so if you set scale out to 3 instances, you have 3 VMs running your app, so pay 3 times more than with scale out set to 1.
So 1 plan with 1 instance and 2 apps is cheaper than 2 plans with 1 instance and 1 app per plan. But if the 1 plan has 2 instances and 2 apps, you pay the same as in the 2-plans-1-instance scenario.
This is starting to get complex ... 🤔
If I set an app service plan to an S2 and there are 2 (or more) app services on it is the cost 146/month or 146/month * 2?
You pay per instance in the App Service plan, the amount of apps you run there does not affect that cost.
You do have to pay some pennies for network traffic going out of your apps, that's per app.
With the exception of the Shared tier though where you pay per app.
So the main thing affecting the price is the Scale Up and Scale Out settings on the App Service plan (size of VMs + amount of VMs).
https://azure.microsoft.com/en-us/pricing/details/app-service/windows/
Shared tier mentions for me:
~€8.003/month
per site
Basic and Standard tiers mention:
Pricing is based on the size and number of instances you run.
You can host up to 100 apps in a single app service plan, but the key thing to know here is that as with the free plan you are charged per app, not per app service plan.
When you pick the shared plan it is charged per instance in the app service plan.
Does Azure charge only for the utilization of App service plan resources or for the number of app services we create under that App service plan? Does the number of app services created under a app service plan effects cost?
I am developing a microservices project and I am unsure of whether to deploy each microservice in a dedicated app service or deploying all in one app service as virtual directories. Cost is a concern for our project.
Thanks.
Does Azure charge only for the utilization of App service plan resources or for the number of app services we create under that App service plan?
Ignoring the Free and Shared tiers, you'll pay only for the App Service Plan (cost per selected machine size x number of instances). You'll pay the same whether you have 0 or 50 Apps on the Service plan (although any other I/O, Storage etc consumed by those Apps will be additional).
(Whereas the free tier allows a max of 10 Apps, and the Shared tier allows 100 Apps)
In theory you can then add as many App Services (apps, e.g. Web Apps, Services, Function Apps etc) as you like on each App Service Plan, however in practice you'll be limited by the overall resources of the VM size and plan you've selected (e.g. 10GB Disk space on Basic, and a B1 only has 1.75GB RAM).
From the Microsoft docs, the recommendation is:
Isolate your app into a new App Service plan when:
The app is resource-intensive.
You want to scale the app independently from the other apps in the existing plan.
The app needs resource in a different geographical region.
I would also add the opinion:
If applicable, keep your environments (Dev, UAT, Prod) isolated, either at App Service Plan level, or consider isolation at Resource Group or Subscription level.
Unless your apps are maxing out CPU usage, while installing as many apps per Service Plan as makes logical sense, but monitor performance and the resource usage on the VM instances as you go.
In my situation, I've typically found that RAM to be the bottleneck, so I would typically try to scale up to a VM size with more RAM to host more Apps before separating out the Apps and adding more Service Plans.
If you are on .Net Core or another stack which doesn't need Windows, I would recommend looking into the Linux Service Plans - they are considerably cheaper than Windows instances. One caveat - as at present, there's a weird limitation which doesn't allow mixing of Windows and Linux Service Plans in the same resource group.
Each App is logically fairly well isolated on the Service Plan instances, so you can add, delete, and deploy apps without interfering with the others.
Although Docker containers can be deployed as an App Service, you might find AKS a better fit.
And More Detail
The terminology around the Azure Managed App Service Plans is somewhat confusing, but to clarify:
An App Service Plan (Service Plan) can have 1 or more managed VM instances
e.g. 1 Service Plan scaled to 3 Instances = 3 VMs to pay for.
Ignoring the Free / Shared tier (on the shared tier you pay for each App), and also ignoring the Isolated tier, you'll pay a fixed monthly cost for each Instance
You can add multiple Apps to each App Service Plan - e.g. Web Apps, Function Apps, Misc. Console Apps, and Docker images. These will be deployed to all instances in the plan.
On the Standard tier and above, you can also configure Deployment Slots on your Apps, which provides the ability to smoke-test and provide continued uptime during deployments, especially in your production environment.
App Service Plans (microsoft.web/serverfarms) account for approximately 40% of our overall Monthly Azure costs
This cost can quickly multiply, especially if you are running multiple isolated environments (Dev, UAT, Prod etc) and if you need to scale out to more than one instance per environment for redundancy or scale reasons.
As at time of writing, indicative VM instance costs on US East are approximately
Dev B1 1.75GB RAM are ~$15pm Linux / ~$50pm Windows
Prod P1V2 3.5GB RAM are ~$80 Linux / ~$150pm Windows
So it's only natural to try and minimize costs by deploying multiple apps to a single VM, especially in a fine-grained Microservice enterprise or system.
I would add to this that if you have an app that is memory intensive, I would definitely isolate it to its own App Service Plan. Since usage limits are at the plan level, you don't want to get errors for mission critical apps due to a runaway app or an app experiencing higher traffic. Another good tip is to set up auto scaling with rules you define by your needs, this will prevent downtime if higher traffic than what the plan allocates is experienced.
Though yes, money can definitely be saved by grouping apps together in the same plan.
Yes, you can save cost by hosting multiple apps in one app service plan. You do not need a separate web app plan for each web app.
Generally the price you pay is for the app service plan and not the web app (Exception here is the shared plan) so your costs do not increase as you add more applications to the same plan.