Is it better to create Azure storage account per app or one storage per region?

Question

So there are 2 scenarios that I consider here:

1. Create one big storage account per region (ex. West Europe) and a container per app. Storage account goes to a Resource Group per region.
2. Create one storage account per app in Resource Group containing other app resources.

Drawbacs for 1:

• containers are separated from other app resources, because they are in storage account per region

• containers are designed to have flat structure (you can create folders, but it's not obvious)

Drawbacs for 2:

• a lot of storage accounts

Looking at this, I would say that creating storage account per app is a better option, but maybe I'm missing something here.

So the question is: are there other things to consider here to make one option better than the other? Maybe costs?

I stumbled upon a somewhat similar question, but it's about having one big container or a lot of small ones. So the question is in a way quite different, because storage accounts as a whole are region-constrained, and don't have access policy. While all containers in an account are in the same region, but can have different access policy.

Forbiddance

Answer 1

No right answer to this question. But objectively you'll want to consider several things:

• If you separate tenants/apps by container, you will no longer be able to separate your app's assets by container - you will have limited yourself to a single container for all assets within an app.
• If you use one storage account for all tenants/apps, you might hit the 20K/sec transaction limit of a storage account (and possibly hit the 500TB 5PB total limit)
• If you use one storage account, and your app utilizes the storage account key(s), each app will actually have full access to all resources across the storage account. (you can mitigate this with shared access signatures & policies, but you need to also then consider queue/table usage as well).
• If your tenants/apps are in different regions, a tenant's access to a faraway storage account could be slower than with a closer region.
• If you are trying to limit access to a particular app, and only have one storage account, you may end up needing to give people access to the resource group where the storage account resides. And those people might be from teams building different apps. So it's possible you're exposing one app's resources to another team.
• If multiple teams share the same storage account, there's a risk that one team could inadvertently delete assets from another team's app.

There are probably other things to consider, that I'm forgetting.

Udine

Fair points. For first point - you can create folders, but still the access policy is on container level, so you can't have for example part of the assets with public access and part with private. My main concern regarding storage per app is that it may somehow cost more although I couldn't confirm it on Microsoft pages (it seems you pay only per GB and per operations) – Forbiddance

@Forbiddance - I don't understand your comment: there's no such thing as folders. Just containers, and you cannot nest containers (you can only pretend to, by using something like the / character in your path names). And there's no cost per storage account, just per consumed storage. – Udine

there are "virtual" folders. You can get/list files under specific path like dorszstorage.blob.core.windows.net/container/folder. And in Azure Storage Explorer you can upload a folder and it's at least mapped there in a way it looks like a folder :) It's also explainer here: #2619507 – Forbiddance

@Forbiddance - I thoroughly understand what they are. They are not folders, however. Try placing a few thousand blobs into a container, with various "folders," and then search for one folder. The entire container will still be scanned, and you will consume more transactions, the larger your asset list becomes. Asset management is not the same as dividing content between containers. I'm not saying not to arrange all of your data within a single container. I'm merely pointing out specific differences. – Udine

You're totally right. It's just a little misleading, because they allow creating blobs with "/" in the name and some client sdk's actually map the fake tree structure... But as you said there are only blobs and containers. – Forbiddance

Answer 2

I'm dividing storage accounts by DR/BC type. i.e do I need LSR, ZSR, GSR, RO-GSR. For example some of my servers need ZSR (like a DC), but others like an app web server or SQL OS need GSR. This then basically mimics what we've done for years in our on premise VMware datastores, where some are replicated to a DR site using SAN replication and others are not.

Hocuspocus

Is this a question, or an answer? – Contumacious