The new "Consumption" tier plans that you can utilise for Functions don't allow you to change the process bitness via the Portal. Is some other way I can flip the process to 64 bits as it's required for DocDB access.
You can set this by API. But note that it is not officially supported until you see the option show up in the portal.
Here is an easy way to do it:
Go to https://resources.azure.com/
Find your function app, and go under config/web under it in the tree
Edit and change use32BitWorkerProcess to false
Currently, 64-bit selection is disabled for Azure Functions (both, in consumption and app service plans). We're working on some validation to enable that, so customers requiring a 64-bit can make that change.
One thing to note is that the DocumentDB team has added 32-bit support to their latest release (1.11.3), and although we haven't upgraded to that yet (which will happen), you can reference their package directly and use their client in Functions running in 32 bit.
David's answer also gives you a way to enable 64-bit today.
Azure Functions consumption plan is billed based on resource
consumption and executions. Consumption plan pricing includes a
monthly free grant of 1 million requests and 400,000 GB-s of resource
consumption per month. Customers can also run Functions within their
App Service plan at regular App Service plan rates.
Source: Functions Pricing
Try to Kudu into the Function App based on the Consumption pricing tier App Service Plan, found out that the total disk space is 1GB, which is equivalent to the Free or Shared pricing tier of the standard App Service Plan.
Bitness
The Basic, Standard, and Premium tiers support 64-bit and 32-bit
applications.
The Free and Shared plan tiers support 32-bit applications only.
Source: https://learn.microsoft.com/en-us/azure/app-service-web/web-sites-scale#bitness
The conclusion is the Consumption pricing tier App Service plan is equivalent t0 Free/Shared pricing tier App Service plan, which explains why it can only support 32-bit.
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
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 ... 🤔
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 have an azure function that reads jobs from a storage queue. It then executes these jobs and grabs more. I have been getting more jobs for it to run lately and noticed that the queue is building up.
What can I do from an Azure Perspective to get better performance out of this? Each job runs in its own little world so adding a new instance or adding threads or attaching to a "better" machine would all work fine.
Things come to mind with the information provided:
For more pure power: Host your Azure Function in a dedicated App Service plan instead of using the consumption plan. You can scale up (better hardware) or out (more hardware). Be aware that this could also be worse in theory. I would give it a try. Or try the "premium consumption plan" mentioned by Ken.
More parallelism: If your queue builds up even though you are not using most of your resources. Try playing with the configuration parameters batchSize and newBatchThreshold.
Changed execution logic: Depending where most of your time is spent during function execution, durable functions might help. Based on your comments you might also try to cache the external data using static or Azure Redis Cache.
Look at the most common performance considerations
Premium plan (Preview)
Azure Functions Premium plan provides customers the same features and scaling mechanism used on the Consumption plan (based on number of events) with enhanced performance and VNET access. Azure Functions Premium Functions plan is billed on a per second basis based on the number of vCPU-s and GB-s your premium functions consume.
In order to use the Azure Functions Premium Plan private preview your subscription needs to be added to an allowlist. Please apply for access via http://aka.ms/functionspremium.
More Info:
https://github.com/Azure/Azure-Functions/blob/master/functions-premium-plan/overview.md
In our development environment (in Azure) we are experiencing an issue which we are sure could be due to bandwidth limitations of the underlying VM. By scaling our App Service up a pricing level (from Basic to Standard), the issue stops occurring. Utilisation of the CPU, memory, connection, threads, are all very low.
What are the actual network/bandwidth limitations for the different Azure App Service tiers?
These pages provide nothing on the matter:
Azure Web App sandbox
Azure subscription and service limits, quotas, and constraints
Could you elaborate on what the issue was that you were facing.
There are other restrictions for Azure App Services, which are defined here:
https://github.com/projectkudu/kudu/wiki/Azure-Web-App-sandbox
Most of the restrictions in Azure App Service are specific:
Size of the VM
Pricing Tier
The problem you described seems to be related to size than pricing tier.
For free tiers, well explained here:
App Service free quotas
All the free app services will stop working if bandwidth is the issue
Less than 200MB daily, about 5GB per month