在SaaS解决方案中为跨多个客户的大量Event Hub使用共用Storage Account（且共用Resource Group）的潜在问题与考量

Great question—this is a super common pattern folks test out in SaaS environments to consolidate resources, but there are some critical pitfalls and considerations you need to think through before locking in this setup. Let’s break them down one by one:

1. Performance Bottlenecks & Throttling Risks #

Azure Storage Accounts have hard default limits on throughput and request rates (e.g., standard LRS accounts cap at 20,000 write operations per second and 100 Gbps of outbound bandwidth). When you share one account across dozens/hundreds of Event Hub instances (each potentially capturing event data, archiving logs, or writing checkpoint data), you’re pooling all those workloads against these global limits:

• If multiple customers have spikey event volumes at the same time, you’ll quickly hit throttling limits, leading to delayed event captures, failed writes, or even Event Hub backpressure.
• Troubleshooting throttling becomes a nightmare because you can’t easily isolate which customer’s workload is causing the bottleneck without custom monitoring tooling.

2. Poor Data Isolation & Security Risks #

While you can use separate containers per customer to segregate data, the Storage Account itself is a single security boundary:

• A single compromised account key gives attackers access to all customer data in the account. Rotating keys also becomes a massive chore—you’ll need to update the capture configuration for every Event Hub tied to the account, which is error-prone at scale.
• Granular access control gets complicated. If you need to grant a customer limited access to their own data (e.g., for auditing), configuring RBAC to restrict them to only their container is doable but requires meticulous setup. One misconfiguration could expose one customer’s data to another.
• You can’t use customer-specific encryption keys (BYOK) for data at rest—all data in the account uses the same key, which fails to meet compliance requirements for some enterprise customers.

3. Cost Tracking & Billing Complexity #

Consolidating into one Storage Account makes it impossible to get out-of-the-box per-customer cost breakdowns:

• You’ll have to build custom tooling to track storage usage, bandwidth, and request rates per container to bill customers accurately. This adds development and maintenance overhead.
• If one customer’s storage usage spikes unexpectedly (e.g., a bug in their app generates 10x more events), you’ll see a sudden jump in your overall bill with no easy way to attribute it to the culprit until you dig into container metrics.
• You can’t enforce per-customer storage quotas natively—Azure doesn’t let you set hard limits on container size, so you’ll need to build alerting and remediation workflows to prevent a single customer from hogging all storage resources.

4. Broad Failure Blast Radius #

A single issue with the shared Storage Account will take down event capture/logging for all your customers:

• If the account hits a regional outage, gets accidentally deleted, or has a configuration error (e.g., incorrect firewall settings), every Event Hub tied to it will stop writing data to storage. There’s no way to isolate the impact to just one customer.
• Recovery becomes all-or-nothing—you can’t restore service for a subset of customers; you have to wait for the entire Storage Account to be back online.

5. Operational & Monitoring Overhead #

All metrics, logs, and alerts for the Storage Account are aggregated across all customers, making day-to-day operations a slog:

• When a customer reports missing event data, you’ll have to sift through a single set of storage logs to find their container’s activity, instead of just pulling up their dedicated account’s logs.
• Setting up meaningful alerts (e.g., "storage usage is high") requires filtering by container, which adds complexity to your monitoring setup. You can’t easily create customer-specific alerts without custom logic.

6. Compliance & Data Residency Limitations #

Many enterprise customers have strict requirements around where their data is stored or how it’s isolated:

• If one customer needs data to reside in a specific region, but others don’t, a shared Storage Account (tied to a single region) can’t accommodate this. You’d have to split customers across accounts anyway.
• For compliance frameworks like GDPR or HIPAA, auditors may require strict logical or physical isolation of customer data. While containers are logically isolated, a shared account may not meet the "separation of duties" or "data segregation" requirements some auditors demand.

Quick Recommendation #

While consolidating resources might seem efficient upfront, the tradeoffs around isolation, scalability, and operational overhead make this setup risky for most SaaS scenarios. A better approach is to use dedicated Storage Accounts per customer (or per tenant group) paired with their Event Hub instances. This gives you clear data boundaries, native cost tracking, limited failure impact, and easier compliance alignment.

内容的提问来源于stack exchange，提问作者Ged