I have an app service that I use from time to time (test env). How to configure it to auto-close when I do not use it?
App Service always incurs cost so that is not possible. You can create it when you need it using some sort of automation (powershell\cli\arm templates\etc) and delete it after you dont need it.
another option - colocate it with some other App Service which you need all the time, so it will just use small fraction of that app resources (wont cost anything extra).
I would recommend to use Dev/Test option if you are really worried about pricing.
Dev/Test pricing applies only when you run the resources within an
Azure subscription that is based on one of the Dev/Test offer
May be a delayed answer but I have found an elegant solution. There is a "Always ON" flag in the settings page that can be used for this purpose.
Location
AppService --> Configuration --> General Settings --> Platform Settings --> Always On.
Usage
Always On: Keeps the app loaded even when there's no traffic. When Always On is not turned on (default), the app is unloaded after 20 minutes without any incoming requests. The unloaded app can cause high latency for new requests because of its warm-up time. When Always On is turned on, the front-end load balancer sends a GET request to the application root every five minutes. The continuous ping prevents the app from being unloaded.
Always On is required for continuous WebJobs or for WebJobs that are triggered using a CRON expression.
For dev/test there is an app service plan that is free (it has the "Always On" setting turned off and disabled). Create a Free F1 app service plan and then assign your app service to use that plan.
Related
When hosting an Azure Function in an App Service Plan, are there any significant differences compared with using an App Service (EDIT: for a restful API) associated with the same App Service Plan? I assume the only difference is that the Function offers additional out of the box triggers. Any differences I'm missing that would lead to preferring one over the other?
I'd also like to confirm that hosting Azure Functions in an App Service Plan can actually limit scalability if scaling is not configured on the App Service Plan. As I understand it, Functions automatically scale as needed when using Consumption or Premium hosting without additional configuration.
When hosting an Azure Function in an App Service Plan, are there any significant differences compared with using an App Service associated with the same App Service Plan? I assume the only difference is that the Function offers additional out of the box triggers. Any differences I'm missing that would lead to preferring one over the other?
Well, an Azure Function is a different beast than an App Service. An Azure function is triggered by an external event or a timer. It then executes the code of the function. When hosted on a consumption plan this execution is allowed to run for 5 or 10 minutes max. When you need a longer execution time you need to run it on an App Service Plan.
An App Service can host any app you've created. Like a website (that runs continuously and doesn't need to be triggered before it starts doing something) or an api for example.
I'd also like to confirm that hosting Azure Functions in an App Service Plan can actually limit scalability if scaling is not configured on the App Service Plan. As I understand it, Functions automatically scale as needed when using Consumption or Premium hosting without additional configuration.
Correct, when hosting Azure Functions in an App Service Plan you are responsible for making sure the app service is scaled to allow the function to perform well under load. Thats why the consumption plan is designed to handle this so the developer can focus on the functionality and does not need to worry about the infrastructure.
So, for integration scenario's azure functions are a very natural fit. For web sites an App Service might be the best solution.
To address your comment:
I should have mentioned that this question was in the context of hosting a restful API and not a UI application. In this scenario, I'm not seeing much difference between a Function and App Service, but please correct me if I'm missing something
A couple of things: For one, there is a certain sweet spot. If traffic is heavy enough a consumption plan based azure function might be more costly than having a dedicated app service plan. That depends of course on a lot of factors (CPU usage, request duration etc.). Also, you won't be able to use things like Asp.Net Core Middleware out of the box.
Finally, I'd argue that if your api is becoming large enough managing a single asp.net core solution may be easier than having to manage a lot of azure functions with small functions or one azure function project with lots and lots of functions, but hey, that's just my opinion (haven't actually dealt with it to be honest)
Some resources to consider:
https://www.taztopia.com/single-post/2019/07/28/azure-function-vs-web-app-aka-serverless-vs-paas
https://dasith.me/2018/01/20/using-azure-functions-httptrigger-as-web-api/
The main difference is in how you pay for it:
Azure Functions Consumption plan you pay per execution
Azure Functions in an App Service (dedicated plan) you pay for the allocated hardware per minute.
You also have control of which VNET your functions run in when you use an app service plan. You may have security requirements that make this important.
You are correct that if you run it in an app service that is not configured to scale, then throughput will be limited by the allocated hardware.
For details see: https://learn.microsoft.com/en-us/azure/azure-functions/functions-scale
If you are having limited and predictable workload then deploy az function in AppService plan with supports VNET integration for private compute otherwise go for Premium plan which will provide autoscaling capability of your compute environment.
I have a very simple asp.net core hosted blazor wasm application on a S1 App Service with 2 slots: Integration and production. When I just publish into my integration slot that takes around 50 seconds. But when I swap the integration with the production slot it takes over 7 minutes. Both apps slots are after that very slow, often taking over a minute before they react again. During the swap both are not responding at all.
There are only 2 settings and the connection string to change. And I don't have any manual warmup.
Is the swap functionality just not really meant the be used on such a low configuration or can I adjust something in my configuration to speed things up?
Adding some information here regarding Azure App service deployment slot swap might be helpful:
Some apps might require custom warm-up actions before the swap. The applicationInitialization configuration element in web.config lets you specify custom initialization actions. The swap operation waits for this custom warm-up to finish before swapping with the target slot.
During the swap operation the Web App’s worker process may get restarted in order for some settings to take effect. Even though the swap does not proceed until the restarted worker process comes back online on every VM instance, it may still not be enough for application to be completely ready to take on production traffic.
Try enabling Application Initialization Module to completely warm up your application prior to swapping it into production.
More detailed explanation of that process is available at How to warm up Azure Web App during deployment slots swap
To add to this if the swap operation takes a long time to complete, you can also get information on the swap operation in the activity log. On your app's resource page in the portal, in the left pane, select Activity log. A swap operation appears in the log query as Swap Web App Slots. You can expand it and select one of the sub operations or errors to see the details.
Please refer to below links for more details on this:
https://learn.microsoft.com/en-us/azure/app-service/deploy-staging-slots#what-happens-during-a-swap
https://ruslany.net/2017/11/most-common-deployment-slot-swap-failures-and-how-to-fix-them/
https://ruslany.net/2019/06/azure-app-service-deployment-slots-tips-and-tricks/
I've had to switch from the Shared tier to Basic, to avail of SSL support and with that I knew there would be a price hike. But for me it has gone up exponentially - this is going to cost me an extra £50+/month.
I have turned off the "Always On" setting and from analytics I can see that there is no traffic between 11pm and 5am most nights yet im averaging a bill of 22 hours per night service for the last 23 days...that's effectively "Always On".
Anyone know if I need to tweak something else to reduce the costs? Is there a setting that determines how long before the service goes to sleep?
The cost that you pay for the instances in App Service runs all the time, traffic does not matter.
If you have 1 instance in the plan, you pay for that 1 instance all the time. Always On just prevents an app from idling. It won't reduce billing if you turn it off.
At minimum on Basic tier and up you pay for 1 instance + outbound data traffic.
As juunas stated that Always On could not help you to save the cost, it just be put to sleep and free up resources for other web apps on the same service plan.
Anyone know if I need to tweak something else to reduce the costs? Is there a setting that determines how long before the service goes to sleep?
Even if you stop your app, the App Service plan charges still apply, and the service plan could not be stopped. For a workaround, you could schedule a task and invoke Azure Management SDK to switch the App Service Plan (Shared, Basic).
Use Microsoft.WindowsAzure.Management.WebSites with the authentication using a management certificate. Here is the core code, you could refer to it:
Change pricing tier from Basic to Shared
using (WebSiteManagementClient webappClient = new WebSiteManagementClient(credential))
{
//you could leverage webappClient.WebSpaces.List() to retrieve your webspace
//the format of your web space would be: "{resource-group-name}-{location-of-your-appserviceplan}webspace"
var webSpace="{your-web-space}";
webappClient.WebHostingPlans.Update(
webSpace,
"{The name of the web hosting plan}",
new Microsoft.WindowsAzure.Management.WebSites.Models.WebHostingPlanUpdateParameters()
{
NumberOfWorkers = 1,
SKU = Microsoft.WindowsAzure.Management.WebSites.Models.SkuOptions.Shared
});
}
Note: After change the pricing tier to Shared, your configured SSL certificates would be reserved and until you change it back to Basic, you could retrieve and modify it and it could take effort. Moreover, if you scale out your app into multiple instances, you need to specify the property NumberOfWorkers when you changing pricing tier to Basic. For more detailed steps, you could refer to this similar issue.
I thought one of the advantages of Azure was that I could turn services on and off depending on when I want them to be available.
However I cant see how to pause my App Service Plan.
Is it possible?
I want to use the S1 tier so that I can play with what it offers. However I want to be able to pause the cost accumulation when I am not using it.
I see from the app service pricing help that an app will still be billed for even though it is in the stopped state.
Yet the link also clearly states that I only pay for what I use. So how does that work?
If you put your hosting plan onto the free tier, you will stop being charged for it. However if you have things like deployment slots and certificates these will be deleted.
The ability to turn services on and off, is more to do with being able to scale services, so if you need 50 servers for an hour you can easily do that.
What you can do to make your solution temporary is to create a deployment script, using Powershell or Resource manager Templates then you can deploy your solution for exactly as long as you need it and then delete it again when you don't. In this sense you can turn your services on and off at a whim.
Azure provides building blocks for you to create the solution you need, it is up to you to figure out how to best use those building blocks to create the solution you seek.
Edited to answer extended question.
If you want to use the S1 pricing plan, and not have it charge when you are not using it, the only way of achieving that is by using automation. Fortunately, this is reasonably trivial to achieve.
If you look at this template it is pretty much all configured to deploy a website from Github to Azure on demand. If you edit that to configure it to your needs you can have a new Azure website online with 2 minutes of running the script.
Then you would have another script that deleted it once you had finished.
Doing it this way you would loose no functionality, and probably learn quite a bit about what is possible with Azure along the way.
App Service Plan
An app service plan is the hardware that a web app runs on. In the free and shared tier your web apps share an instance with other web apps. In the other tiers you have a dedicated virtual machine. It is this virtual machine that you pay for. In that case it is irrelevant whether or not you have web apps running on your app service or not, you still have a virtual machine running and you will be charged for that.
To change the App Service Plan via PowerShell, you can run the following command
Set-AzureRmAppServicePlan -ResourceGroupName $rg -Name $AppServicePlan -Tier Free
I was able to accomplish this using the dashboard by selecting the App Service Plan, clicking Scale up (App Service Plan), and then from there if you click Dev/Test you can select the Free tier.
As others have mentioned, you need to script this. Fortunately, I created a repository with one-click deployment to your Azure resources.
https://github.com/jraps20/jrap-AzureVerticalScaling
The steps are intended to be as simple and generic as possible:
Execute the one-click deployment from the repo readme
Select the subscription, resource group etc.
Deploy resource to Azure
Set up your schedule to scale up and scale down as-needed
The scripting relies on runbooks and variables to maintain the previous state of each App Service Plan and App Services within those plans. Some App Services cannot be scaled due to specific settings being used (AlwaysOn, Use32BitWOrkerProcess, ClientCertEnabled, etc.). In those cases, the previous values are stored as variables prior to down scaling and then the original values are reapplied when the services are scaled up.
For more clarity, I have written a blog post that goes into detail. The post is pertaining to Sitecore, but applies to any App Service setup- Drastically Reduce Azure PaaS Hosting Costs in Non-Prod Environments With Scheduled Vertical Scaling. It also includes a brief video tutorial to show its use case.
Myself and others have been using this repository/approach for well over a year and it works great. I mostly use it for POC's to reduce costs when I'm not actively working on something. However, its main intention was for targeting non-prod environments to save costs during non-work hours.
Azure App Service Plan is just an logical concept of a set of features and capacity that you can share across multiple apps. I don`t think you can "pause" a plan, instead you can pause your service. and depends on billing model of each service, you might or might not get charged.
Pausing = Delete or lower tier.
Scripting is the key.
Design Diagram
Use scripts to create (also consider shared resources)
Delete using scripts
Use scripts to recreate.
eg: If we use resource group properly per environment then
Export-AzureRmResourceGroup will create a template for us (everything in the resource group will be pulled out as script). So we can delete it and recreate it anytime.
To pause a VM and stop billing you need to shut is down and deallocate it. Just shutting down still has the capacity reserved as if its running.
Storage can't be shutdown - it can be moved to lower cost tiers.
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.