If I select an app service plan that allows scaling up to 10 instances, will I be charged the price stated for that plan or will I be charged 10 * [the Price of the plan]?
Azure App Service plans support a variety of pricing models, thus it depends on the type of plan.
Generally, the "idea" of Azure App Service plans is that you pay for a specific set of resources (CPU, memory, disk etc.) that are shared among all of your applications/ instances. That means you generally pay a "flat fee" for the plan and can run as many apps as you like, as long as the resources can support it - and you don't exceed any limits or quotas. If you run too many apps however, performance as a whole will degrade, due to shared resources getting exhausted.
Here is a good documentation explaining the concepts behind App Service plans.
Things get more complicated when looking at the more expensive plans. There are models where your applications are hosted on dedicated virtual machines. This may be consideres as "paying for a certain number of instances", but it depends on your opinion of what the term "instance" means.
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'm currently using an Azure Premium Service App (P3v3). I found that my function needs some boost, so I decided to look at how I can configure scaling.
I found two available options:
Set FUNCTIONS_WORKER_PROCESS_COUNT in the configuration section
Configure the number of instances in Scale-Out menu
But what is the difference between instances and workers? Haven't found any information about that or how it can affect costs.
what is the difference between instances (Scale-Out menu) and workers (FUNCTIONS_WORKER_PROCESS_COUNT)?
These are Microsoft Documentations to understand Workers and Instances in terms of Cost Management (Billing) and Functionality:
MSFT Sources of FUNCTIONS_WORKER_PROCESS_COUNT:
Azure Functions - Functions App Settings - functions_worker_process_count
Azure Functions - Best Practices - FUNCTIONS_WORKER_PROCESS_COUNT
MSFT Sources of Azure Functions Premium Plan Scale-Out Instances:
Azure Functions Hosting options Information
Azure Functions Premium Plan Instances Billing
AFAIK, FUNCTIONS_WORKER_PROCESS_COUNT limits the max no. of worker processes per Function host instance. These instances are kind of separate VMs where the FUNCTIONS_WORKER_PROCESS_COUNT limit is applied to each of them individually.
For example, If the FUNCTIONS_WORKER_PROCESS_COUNT is set to 10, it means 10 Individual Functions concurrently run by each host instance.
Multiple Workers means Multiple Process Ids of the Same Function App which is a logical collection of Functions.
One Worker Process can host all functions of one Function App where the Single Host has the default value as 1 to the FUNCTIONS_WORKER_PROCESS_COUNT and the Function Host means it is the Physical/Virtual Host where Function App runs as Windows/Linux Process.
Refer here for more information on mechanism of FUNCTIONS_WORKER_PROCESS_COUNT.
how it can affect costs.
As this Microsoft Azure Services Pricing Calculator Says, you'll be charged per instance when you scale-out.
When it comes to Cost Management, the incremental nature of the Scale-Out methodology is extremely beneficial.
Cost increases should be somewhat predictable because the components are identical.
Scaling out also allows you to respond more quickly to changes in demand.
In most cases, services can be quickly added or deleted to satisfy resource requirements. By just using (and paying for) the resources required at the time, this flexibility and speed effectively minimize spending.
Refer to this article for more information on cost management and the benefits of Scale-Up and Scale-out.
While creating an Azure Function. It provides an option to create an App Service Plan.
Let's say we select P2V2 which has 7GB Ram and 2 Cores. Here are the questions:
Let's say when the function is triggered, and each invocation consumes 1GB Ram. Does it mean that the same instance at maximum can concurrently run ~6 (leaving aside 1GB for OS let's say). Where all the 6 concurrent triggered functions re-use the same cores?
When does the App Service plan decide to scale out to multiple instances?
Yes, probably. As stated in Azure Functions hosting options - Service limits the number of Function apps per plan is unbounded, but:
The actual number of function apps that you can host depends on the activity of the apps, the size of the machine instances, and the corresponding resource utilization.
By default, an App Service Plan doesn't scale. In the same article I linked to before, it states that for a Dedicated Plan you can use Manual scaling or Autoscale. For autoscale, you control the rules.
For more information, see the documentation Juunas linked to in this comment.
Best practices for Autoscale
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.
This is my azure payasyougo usage cost for this month.
I'm struggling to understand why I would be charged for a Standard Medium App Service, I would of thought that it would be included in the compute hours? I have only one Cloud Service running and this seems a bit steep for a cloud service that is not doing much...
Any suggestions?
While pricing is off-topic, I think I can answer this from a general operational angle (even though this will likely be closed since it's not programming-related).
As your graphic shows, you are consuming resources for different services. Compute-hours equates to your virtual machines that you've deployed, and you're consuming those resources whether you're using 0% or 100% CPU / memory / network, whether you've deployed code or not. They are allocated and, as far as Azure is concerned, deployed for your use, no matter what you're doing (or not doing) with them.
When you created your App Service, that was yet-another set of resources deployed. And another set of resource-hours you're consuming (again, whether you use 0% or 100% is irrelevant).
Same thing would happen if you created a database instance or any other Azure service: You'd pay in whatever way is described for that particular service. And each service has its own specific cost which is described in detail in Azure's pricing page.
There's no nesting of separate services. In your specific case: there's no concept of creating an App Service inside a Virtual Machine (nor is there any hint of that anywhere). They are two separate services.
Computer covers only Virtual Machines and Cloud Services. Pricing can be found here:
https://azure.microsoft.com/en-us/pricing/details/virtual-machines/
App Services are "special", while they internally use compute resources behind the scenes, they are charged based on the tier of performance and SLA you want to achieve. Pricing for them can be found here:
https://azure.microsoft.com/en-us/pricing/details/app-service/
You will notice that there is a PREMIUM price for the same level of service on App Services. The theory is that the App Service stack is providing more managed value and thus worth more. For my use cases I have not found this to be the case and instead choose to run our environments under the PaaS VM / Cloud Service stacks.