Quota Design for a Shared Stamp with a Noisy Tenant
Fabrikam runs a multi-tenant Azure Stack Hub stamp for three internal business units. The stamp has 6 nodes. Business unit A runs batch jobs that spike to 400 vCPUs for two hours each night. Business unit B runs steady-state line-of-business apps at 120 vCPUs. Business unit C is a new tenant with unknown demand. The operator set a single plan with a 500-vCPU quota for all three units, and all three subscribe to it. Within a month, unit A's nightly spikes consume the shared quota, and unit B's apps begin failing to scale. Unit C has not yet onboarded. The operator wants to keep one offer but must prevent unit A from starving unit B. The operator also wants to give unit C a small initial quota that can grow.
1. Explain why the current quota design caused the failure and propose a corrected design that keeps a single offer.
Read the worked answer
The failure is caused by a shared quota across tenants. A plan's quota is enforced at the subscription level, but when all tenants subscribe to the same plan, each subscription receives the plan's quota. The problem is not the plan quota itself but the lack of per-tenant differentiation and the absence of a cap that reflects each tenant's actual need. Unit A's spikes consume its subscription's quota, and because the underlying stamp capacity is finite, unit B experiences contention at the physical layer even though its own quota is not exhausted.
Corrected design within a single offer:
- Create separate plans per tenant profile: a Burst plan for unit A with a quota that matches its spike plus headroom, a Steady plan for unit B sized to its 120 vCPU baseline plus growth, and a Starter plan for unit C with a small quota.
- Attach the appropriate plan to each tenant's subscription. The offer can contain all three plans; each subscriber selects or is assigned the correct plan.
- Set unit A's plan quota so its nightly spike fits, and set unit B's plan so its baseline is protected. Because physical capacity is shared, also monitor stamp-level utilization to ensure the sum of quotas does not exceed safe capacity.
- Give unit C the Starter plan and raise its quota after measuring demand.
The judgment: quotas are per-subscription controls, but physical contention is stamp-wide. Design quotas per tenant profile and validate the aggregate against stamp capacity.
2. What should the operator monitor to confirm the corrected design works, and what signal indicates the design still needs adjustment?
Read the worked answer
Monitor three layers. First, subscription-level quota consumption for each tenant to confirm each tenant stays within its plan. Second, stamp-level CPU and memory utilization during unit A's nightly spike window to confirm unit B's baseline is not degraded. Third, unit B's application health metrics, such as failed scale operations and latency, to confirm the user-visible symptom is resolved.
The signal that the design still needs adjustment is contention at the stamp level during the spike window even though each subscription is within quota. That means the sum of quotas exceeds safe physical capacity, and the fix is to lower unit A's quota or shift its batch window, not to raise unit B's quota. A second signal is unit C consistently hitting its Starter quota, which indicates it is time to move it to a larger plan.
The judgment: quota compliance and physical health are different signals. A tenant can be fully within quota and still cause stamp-level contention.