Three Workloads, One Migration, One Storage Budget
Tailspin Toys is migrating three workloads. (1) A 12-year-old ASP.NET Web Forms app that keeps session state in memory and generates printable invoices; it must run unmodified and will not be rewritten this decade. (2) A thumbnail-generation job triggered whenever a customer uploads a photo: about 200 runs on a normal day, 50,000 on a product launch day, and each run takes under 2 seconds. (3) A monthly royalty calculation that pins one core for 5 hours and, if it fails, is deliberately restarted from scratch. Separately, 400 TB of scanned historical invoices are stored but a sample is opened roughly once a year, while 5 TB of current invoices are read every day. The storage bill is now the largest line item.
1. Choose a compute service for each of the three workloads and justify each choice against that workload's shape.
Read the worked answer
1. Legacy ASP.NET Web Forms, unmodified → Azure App Service (Windows). It runs the app without code changes and Microsoft patches the OS and runtime. The critical caveat is the in-memory session: it only works if the client keeps hitting the same instance (ARR affinity), and it is lost on scale-out, restart, or a slot swap. So this should run at a fixed instance count, or the session must be externalized. If neither is acceptable, a VM is the honest fallback - you accept patching the OS yourself in exchange for full control.
2. Bursty thumbnail job → Azure Functions on a consumption plan. It scales to zero between bursts (most days: 200 short runs) and scales out automatically on launch day (50,000 runs), and you pay per execution rather than for idle servers. The trade-off to state is cold start on the first invocation after idle; if that latency is unacceptable on launch day, a premium plan with pre-warmed instances is the fix.
3. Five-hour single-core, restartable → this is throughput work, not a request/response service. Azure Batch (or a VM with Spot pricing) is the fit, because interruption is tolerable given the restart-from-scratch design. Do not put it on a consumption-plan Function: there is a maximum execution duration, and a 5-hour run would be killed.
2. What storage tiers should the 400 TB and the 5 TB sit in, and what mechanism keeps them there?
Read the worked answer
Split by access frequency, because that is what the tiers price on.
- 5 TB read daily → Hot tier. Frequent access, low retrieval cost. Cool would add per-read retrieval charges and a 30-day minimum retention for no benefit.
- 400 TB opened about once a year → Archive tier. Archive trades storage cost for retrieval latency and retrieval cost: data is offline and must be rehydrated, which takes hours. That is acceptable once a year and unacceptable for anything on a dashboard. Note the early-deletion penalty if items are removed before the minimum archive retention period, so the historical set must genuinely be cold.
- Mechanism: a lifecycle management policy on the storage account that moves blobs to Cool then Archive based on last-modified or last-accessed time. Manual tiering of 400 TB does not survive contact with reality.
The storage bill is dominated by capacity at 400 TB, so the archive move - not the tier of the 5 TB - is where the saving is.
3. The team proposes making everything zone-redundant 'for safety.' What is the cost consequence and when is it not the right call?
Read the worked answer
Zone redundancy is a resilience decision with a price, and it should be applied per workload, not globally.
- It raises cost and can constrain options. Zone-redundant storage carries a premium over locally redundant storage, and ZRS is unavailable in regions that do not support availability zones.
- It does not help data that is already cold. The 400 TB archive is read once a year; a datacenter failure during that one read means waiting, not losing the business. Paying a zone-redundancy premium on 400 TB to protect a once-a-year read is poor value; backup or a second copy may satisfy the actual requirement at lower cost.
- It does not fix the legacy app. Zone-spreading the Web Forms app does not preserve its in-memory session, and its availability problem is the session design, not the datacenter.
- It does not protect against regional failure. Zones are within one region.
Rule to apply here: match the redundancy option to the recovery objective of each dataset and workload - zone redundancy for the live, daily-read 5 TB and the customer-facing tier; a cheaper durability mechanism for the cold archive.