My app deployed in Azure with basic tier having 10GB space. Now it showing the usage warning error in Server. So I want change the scale from basic to standard. Then which instance size should choose having ( Small-1 core, Medium-2cores and Large- 4 cores) ? Also while saving following notifications are showing
In Standard mode, if a web app is stopped, billing continues, and changing the scaling for an app affects other apps. Are you sure you want to continue?
This will scale the following web apps in the East US 2 region. This can take several minutes to complete. Your web apps will keep running during the process.
please help
To answer your question, here is a table with App Service sizes in which you can see that the Standard size has 50GB and the Premium has 500GB of disk space.
To answer your other questions:
The reality is that you pay for the App Service Plan, each plan can host dozens of Apps. Think of it as a Platform running all the time that hosts your Apps, if you stop one App, the Platform is still running (because you might have other Apps running on it), and thus, you are still charged for it.
Like I said, because what you pay is the App Service Plan, scaling the Plan will automatically scale all the Apps contained in it, that's the reason of the second message.
Think of the App Service Plan as a server in which you run your Apps, the moment you delete all the Apps in the Plan, the Plan stops billing, but as long as you have at least one App (running or stopped) in it, it will keep charging.
Related
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.
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!!
I have B3 service plan with 7GB RAM and 3 app services into a resource group. One service requires over 4GB but it throws out of memory exception after 2.4GB usage. It looks like available memory is divided between 3 services evenly. How can I manage RAM usage?
One way I can think of would be to put the apps on separate app service plans. One of your apps requires quite a lot, so why not give it its own plan?
Then you would have one Basic 3 service plan for that app, and maybe a Basic 1 plan for the other 2 if that is enough for them?
Yes, you are correct. The RAM listed for each instance size based on the pricing tier that you choose is for the underlying VM. So, this includes the OS and various infrastructure processes, in addition to IIS and your Web Apps. It is also shared with the App Services deployed under the same App Service plan.
This issue could be related to your web application, you may try the following:
View the memory utilization in Azure new portal
(http://portal.azure.com).
Use kudu Diagnostic Dump to see the information of memory
consumption.
Move the Web App to another App Service plan that has only one Web
App.
I would suggest you refer the blog post How to view the memory utilization of your Azure Web Site for more details.
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.