6
votes

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.

2

2 Answers

13
votes

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.

0
votes

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.