We are looking into moving a number of websites to Microsoft Azure. We believe the App Service standard tier S1 service will meet most of our needs.
App Service plan details
Unfortunately, it offers a maximum of 50Gb of storage. Is it possible to add storage to the service plan overall? (e.g. the storage will be available to all of the apps on the app service).
I know you can add blob storage to each app individually, but we would prefer to increase the available storage on the service plan as a whole.
It seems to me that 50GB is the limit on a standard plan.
App Service limits
Standard; 50GB.
Premium; 500GB.
I suppose this leaves you with (at least) the following options.
Upgrade your plan to Premium.
See if Microsoft will raise your limit.
Azure subscription and service limits, quotas, and constraints
If you want to raise the limit or quota above the Default Limit, open
an online customer support request at no charge. The limits can't be
raised above the Maximum Limit...If there is no Maximum Limit column, then the resource doesn't have adjustable limits.
Find some other solution which removes the need to place data on your App Service. Such as a dedicated Azure storage mechanism, e.g. blobs, CDNs, Redis Cache, SQL, etc.
Look into App Service Environment.
App Service limits
The storage limit [of an App Service] is the total content size across
all apps in the same App Service plan. More storage options are
available in App Service Environment.
App Service Environment Storage
Each ASE is configured with 500 GB of storage. This space is used across all the apps in the ASE.
Azure subscription and service limits, quotas, and constraints
App Service limits
App Service Environment Storage
File system quota for App Service hosted apps is determined by the aggregate of App Service plans created in the region and resource group.
You can create one or more standard app service plan which will give you multiples of 50GB (50GB * x) file system storage. You can decide not to deploy anything in the additional app service plan you created, just use it to increase your storage size. Remember that it should be in the same region and resource group.
Related
If I set an app service plan to an S2 and there are 2 (or more) app services on it is the cost 146/month or 146/month * 2?
You pay per instance in the App Service plan, the amount of apps you run there does not affect that cost.
You do have to pay some pennies for network traffic going out of your apps, that's per app.
With the exception of the Shared tier though where you pay per app.
So the main thing affecting the price is the Scale Up and Scale Out settings on the App Service plan (size of VMs + amount of VMs).
https://azure.microsoft.com/en-us/pricing/details/app-service/windows/
Shared tier mentions for me:
~€8.003/month
per site
Basic and Standard tiers mention:
Pricing is based on the size and number of instances you run.
You can host up to 100 apps in a single app service plan, but the key thing to know here is that as with the free plan you are charged per app, not per app service plan.
When you pick the shared plan it is charged per instance in the app service plan.
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.
SUMMARY: Can I use an Azure Storage Plan as additional storage that is available to an Azure Web App?
DETAILS: We have a very simple Web App using a low amount of CPU and large amount of storage (all it does is list and allow you to download files). I need at least 50GB of storage for video and audio files for this app and to get that amount of storage on a plan pushes me up to unreasonable CPU and other resources that I don't need with the consequences of a much higher price.
My plan (hope) is that I could create a Web App and remap the root directory of the Web App to a Storage Plan that is 50GB. Two challenges that I have spent the last day researching but at this point, I have not been able to find an answer.
I have created the Web App. I see that /wwwroot is on the D: drive of the Web App. I also created a storage plan and have created a sharable area of 50GB on the storage plan.
So... Can anyone give me some insight into the following:
How do I tell the Web App to use the 50GB of storage which is now available to it?
How can I map a drive letter to the area in the storage plan?
How do I tell the Web App that it should use the 50GB area on the storage plan as the root drive instead of using D:/Webroot
Many Thanks!
Refer this feedback link on a similar request: https://feedback.azure.com/forums/169385-web-apps/suggestions/13536996-the-ability-to-store-iis-logs-in-azure-file-storag - it has been denied.
By default, on Azure WebApps, all files are stored in the file system with the application, including the media files. You may wish to know about the main types of files (https://github.com/projectkudu/kudu/wiki/Azure-runtime-environment) that are dealt on Azure WebApp (Persisted files, Temporary files and Machine level read-only files)
Refer to the article (https://github.com/projectkudu/kudu/wiki/File-structure-on-azure) File structure on azure to know the sets of files & dirs on Azure WebApp, and check the directories which include the possible increasing files, such as LogFiles, site/repository, site/deployments(for deployment slots) and your directory for uploading files.
To verify you can go to your scm site's debug console
(https://{sitename}.scm.azurewebsites.net/DebugConsole) and query for the free space on d:\local. The “Disk Space” depends on the App Service plan you're using. It's 1 GB for Free, 10 GB for Basic, 50 GB for Standard and 250 GB for Premium, refer the document for more details on these limits: https://azure.microsoft.com/en-us/pricing/details/app-service/.
If your requirement fits you may use ASE - Azure App Service Environment is an Azure App Service feature that provides a fully isolated and dedicated environment for securely running App Service apps at high scale.
https://learn.microsoft.com/en-us/azure/app-service/environment/app-service-web-how-to-create-a-web-app-in-an-ase
According to Microsoft Azure Support:
"... since the Product Group confirmed that it is not possible to mount
additional storage to the web app, you can integrate Azure storage
with the Azure SDK or rest API. But you can't mount the drive and use
it as storage.
Another option that you have would be to replicate the scenario on a
Virtual Machine where you can choose its capabilities (Number of
cores, RAM, and Storage Memory)."
So there you have it. It appears that WebApps are pretty fixed configurations which means that when you scale up a Web App, you get more CPU resources AND more Disk storage. It's a packaged deal most likely designed for ease of deployment. Nothing, it appears, you can do about that.
The best alternative, it seems, is to spin up a VM with your chosen OS and then add additional disk storage as needed. It's a "do-it-yourself" approach but the best solution that seems to be available.
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
I already have a cloud storage account. I am looking at hosting either an Azure Website or a cloud service, in node.js, but I am confused on a number of points listed below:
If my storage account is in 'Europe North' and if I host a new Node azure website/cloud service also in 'Europe North' then I'm wondering firstly if there's a cost differential between the two possible configurations listed?
*Azure Website (Node.js) <---> Table Storage.
*Azure Cloud Service (Web/Worker role) <-----> Table Storage.
Also is there any performance gain going with a Cloud Service over the Azure Website?
Whether you have a web site or cloud service: when locating storage are in the same data center, you won't incur bandwidth costs. You'll still pay for egress (free tier gives you 165MB free egress daily; shared tier gives you 5GB free egress monthly, and you pay standard rates after that).
Performance: You have different bandwidth availability on the NIC. With a cloud service, you have 100Mbps per core (or 5Mbps with XS). With web sites in free or shared tier, you're sharing the NIC. With reserved tier, you should have the same bandwidth as cloud service, since you have reserved instances.