1
votes

I have two webapps on separate plans each has multiple instances of large size (P3) and it says I get 250GB of storage on P3.

I also have azure storage to store photos.

I want to know, how is Azure storage related to the webapp plans... meaning, what if I reduce the webapp to S3 where it's only 50GB, how will that affect storage?

Also, do I get 50GB for each instances or for the entire plan?

Thank you

2

2 Answers

3
votes

Azure App Service plans represent the collection of physical resources used to host your apps.

App Service plans define:

  • Region (West US, East US, etc.)
  • Scale count (one, two, three instances, etc.)
  • Instance size (Small, Medium, Large) SKU (Free, Shared, Basic, Standard, Premium)

If you scale down your App Service plan to S3, yes you will get 50GB storage.

This storage includes/stores all of the resources and deployment files, logs etc.

You can only store data/files up to the available Storage according to the pricing tier that you choose. To increase the storage you can scale up your pricing tier.

Also, note that increase/decreasing instances is nothing but increase/decrease the number of VM instances that run your app. You get only one Storage account for all the instances not individual Storage.

Before scaling based on instance count, you should consider that scaling is affected by Pricing tier in addition to instance count. Different pricing tiers can have different numbers cores and memory, and so they will have better performance for the same number of instances (which is Scale up or Scale down).

For more details, you may refer the Azure App Service plans in-depth overview and App Service pricing.

Hope this answers your questions.

1
votes

App Service storage is completely different than Azure Storage (blobs/tables/queues).

App Service Storage

For a given tier size (e.g. S1), you get a specific amount of durable storage, shared across all instances of your web app. So, if you get 50GB for a given tier, and you have 5 instances, all 5 instances share that 50GB storage (and all see and use the same directories/files).

All files in your Web App's allocated storage are manipulated via standard file I/O operations.

App Service Storage is durable (meaning there's no single disk to fail, and you won't lose any info stored), until you delete your web app. Then all resources (including the allocated storage, in this example 50GB) are removed.

Azure Storage

Azure Storage, such as blobs, is managed completely independently of web apps. You must access each item in storage (a table, a queue, a blob / container) via REST or a language-specific SDK. A single blob can be as large as 4.75TB, far larger than the largest App Service plan's storage limit.

Unlike App Service / Web App storage, you cannot work with a blob with normal file I/O operations. As I mentioned already, you need to work via API/SDK. If, say, you needed to perform an operation on a blob (e.g. opening/manipulating a zip file), you would typically copy that blob down to working storage in your Web App instance (or VM, etc.), manipulate the file there, then upload the updated file back to blob storage.

Azure Storage is durable (triple-replicated within a region), but has additional options for replication to secondary regions, and even further, allowing for read-only access to the secondary region. Azure Storage also supports additional features such as snapshots, public access to private blobs (through Shared Access Policies & Signatures), and global caching via CDN. Azure Storage will remain in place even if you delete your Web App.

Note: There is also Azure File Storage (backed by Azure Storage), which provides a 5TB file share, and acts similarly to the file share provided by Web Apps. However: You cannot mount an Azure File Storage share with a Web App (though you can access it via API/SDK).