I am trying to understand the azure service plan and how it effect our project's budget.
To give some background, we have two web applications running under Azure Cloud services in single instance auth.foo.com and api.foo.com. This was a good and convenient way to save some money as you still have to pay for one cloud service. We were doing this using hostheaders to deploy two apps on a same IIS instance.
With new WebApp model I understand we can not do the same thing.
Enter the app service plan. I understand its a grouping mechanism to group your apps so that they can be under one roof. The thing I am not clear about is how its billed? So If I have both apps under a same app service plan does it mean I get billed for two apps or just for one?
Think of an App Service Plan as a mapping from sites to servers. So you can have a large amount of small apps running on a couple of servers, or a small amount of large apps running on the same couple of servers. Provided that your App Service Plan is the same SKU and there are the same amount of instances in each, these will be the same cost.
That's why the billing page: https://azure.microsoft.com/en-us/pricing/details/app-service/plans/ has unlimited for the number of web apps. So to answer your question specifically, you will get billed for one App Service Plan regardless of the number of apps you have in it, since regardless of the number of apps, you'll be using the same amount of servers.
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 couple unrelated websites that I host using the free subscription of Microsoft Azure. They are currently all under the same Resource Group and same App Service plan (though I don't understand those concepts well enough to know if they should or shouldn't be).
In the past, I've had a problem with individual apps eating up large amounts of some resource, like CPU Time or Data Out. The issue is that they all share one quota... so if Website A has a problem that consumes all the CPU Time for the day, then Website A, Website B, and Website C ALL go down until the quota resets, even though Website B and Website C aren't contributing to the problem.
In short, how do I prevent that so that each website has its own quota (not a shared quota)? Can I separate the websites into different Resource Groups? Different App Service plans? I tried to understand Microsoft's documentation on how these quotas work, but I was unable to find the answer to my question.
Thanks!
I have a couple unrelated websites that I host using the free subscription of Microsoft Azure. They are currently all under the same Resource Group and same App Service plan (though I don't understand those concepts well enough to know if they should or shouldn't be).
Resource groups define a way to group multiple related azure resources together. Typically all resources in the same resource group are deployed together, for example using ARM/Bicep templates.
An App Service plan defines a set of compute resources for web apps to run.The free tier provides 60 minutes of cpu time per day. You can host multiple web apps on the same plan, as you do. But in that case they all consume parts of that 60 minute cpu time quota.
In short, how do I prevent that so that each website has its own quota (not a shared quota)? Can I separate the websites into different Resource Groups? Different App Service plans? I tried to understand Microsoft's documentation on how these quotas work, but I was unable to find the answer to my question.
If you do not want to share the cpu time between the multiple web apps on the same app service plan you can create a free tier App Service Plan per web app, and deploy each web app to their own dedicated free tier App Service Plan.
We had a legacy monolith website application that is hosted on Azure windows server and had 10 customers using it, now as the application data grows the bandwidth of the application is affecting each customer because they were hosted in single server as a single website. Now the client wants to split the database as per customer separately to reduce the database load, so we divided the databases as per customer.
Regarding the website, we still had a dilemma on how to proceed, so we already divide the databases so we are thinking as
it is better to host each customer website on separate servers?
create a different website on a single server for each and every customer?.
Because the clients want this to be scalable and 100%, that one client’s activities and usage will not affect another, as well as be able to easily distinguish cost.
The client also asked to differentiate how much cost occurring for each customer on the resource groups,
previously we had a shared resource group.
Could anyone suggest how to solve this problem?
If your requirement fits you could leverage Azure App Service WebApps (PAAS solution).
You can host apps in the same App Service Plan or isolate your app into new App Service plan (as per your requirement) by having tradeoff between level-of control and costs.
Or to have greater control on the underlying VMs you could leverage Azure VMs (IAAS solution).
To start with, kindly take a look at this approach - Common web application architectures – monolithic application design using Azure App Service.
You could create the web application as separate App Service apps. This design lets you run them in separate App Service plans so they can be scaled independently. If you don't need that level of scalability initially, you can deploy the apps into the same plan and move them into separate plans later if necessary.
The pricing tier of an App Service plan determines what App Service features you get and how much you pay for the plan.
Azure App Service plan overview
App Service plans pricing
Azure offers a number of ways to host your application code.
Kindly checkout this architecture guide on compute decision choice
Resource Group is a just a container that holds related resources for an Azure solution. The resource group can include all the resources for the solution, or only those resources that you want to manage as a group. It doesn't have direct cost implications, but the resources/services (in this case App Service) under it does.
You may wish to know:
Explore and analyze costs with cost analysis
Prevent unexpected charges with Azure billing and cost management
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.
I am concerned about the load performance of my Chat bot deployed in Chat bot service.
If for my Bots in production, there is sudden load of huge number of users chatting simultaneously, will my Bot handle that load.
Do I need to consider special criteria for auto scaling different than app service
As we know that Bot Service provides two hosting plans for your bots: App Service plan and Consumption plan.
And Consumption plan scales automatically, even during periods of high load.
Besides, if you host your bot application with an specified App Service plan on Azure web app and you configured autoscaling for the plan, then your bot application and other apps in that plan are scaled out together based on the autoscale settings.
As Fei Han mentioned above, Azure functions provides two option based on scaling and hosting capabilities: App Service plan and Consumption plan.
This article provides guidance to improve the performance and reliability of your serverless function apps.
The Consumption plan automatically allocates compute power when your code is running, scales out as necessary to handle load, and then scales down when code is not running. You don't have to pay for idle VMs and don't have to reserve capacity in advance.
With an App Service plan, you can manually scale out by adding more VM instances, or you can enable autoscale. And the other reason to consider this is, they support Linux.
You can decide by comparing both based on your business requirements. Hope this helps!!