Specify Components of a Compute Solution Based on Workload Requirements — Lesson

A platform team at a logistics firm has spent the past quarter building a fleet of VMs to run a new image-recognition microservice. Throughput targets are unmet, the team is paged most weekends because a cron job inside a VM falls behind, and the bill from the autoscaling group has grown $3{\times}$ in three months. The architect who reviews the situation asks one question: "Why is this on VMs?" The team's answer — "We always start with VMs" — is the architecture problem in one sentence. The right answer was probably Azure Container Apps with a job-trigger queue, but no one ran the decision tree on paper. This lesson is about running that tree deliberately, every time, before someone signs a Bicep file.

We will work through Azure's compute decision framework the way the AZ-305 exam expects you to: distinguishing the four broad compute families (IaaS, containers, serverless, batch), mapping workload attributes (state, scale, latency, dev velocity, cost) to compute models, and recognising the cost/operability trade-offs each family imposes. Reference: the AZ-305 exam study guide, particularly Chapter 4 Skill 4.1 on compute decision-making and the Azure architecture centre's compute-choice trees.

Why This Matters

Compute choice is the single most expensive architectural commitment in any Azure design. A wrong choice can $5{\times}$ the cloud bill, $10{\times}$ the operational toil, or push deployment frequency from per-day to per-quarter. The AZ-305 exam tests this LO heavily because, in practice, half of the senior architect's daily decisions reduce to "which compute model is right for this workload?". Getting it right is the difference between a team that ships features weekly and one that spends most of its time patching VMs.

The financial case is concrete: a stateless, bursty web API costs roughly $10{\times}$ more to run on persistent VMs than on Azure Container Apps or Functions Consumption. A heavy GPU-batch job costs roughly $5{\times}$ less to run on Spot VMs or Azure Batch low-priority pools than on Reserved instances. A workload that "must run 24/7 with predictable cost" pays a $30{-}40\%$ premium for serverless that it does not need. If you can match a workload — bursty web, ML training, scheduled ETL, business-critical OLTP, hybrid edge — to the right compute model and defend the choice with cost and operability data, you will pass this slice of the exam and design compute like a senior architect. Every cloud-cost review, every "what should we modernise next?" workshop, and every platform-team mandate touches this LO.

Prerequisites

Before working through this lesson, make sure you can answer each prompt below in one or two sentences.

• Compute families. Can you list the four high-level families: IaaS (VMs / VMSS), containers (AKS, ACA, ACI, App Service), serverless (Functions, Logic Apps), and batch (Azure Batch)? — Self-check: which family runs your code without exposing the host OS?
• Pricing models. Are you fluent with consumption vs reserved vs Spot pricing? — Self-check: which one is cheapest for a long-running predictable workload?
• Statefulness. Can you describe the difference between stateless and stateful compute? — Self-check: which is easier to scale horizontally?
• Cold start. Do you know what a cold start is and why it matters for serverless? — Self-check: name two ways to mitigate cold starts in Azure Functions.
• Well-Architected Framework pillars. Can you list the five: reliability, security, cost optimisation, operational excellence, performance efficiency? — Self-check: which pillar most strongly favours containers over VMs?

If any of these feels shaky, pause and review the compute intro modules in Unit 4 of the AZ-305 guide before continuing.

Learning Objectives

By the end of this lesson, you will be able to:

1. Analyse a workload's attributes (state, scale shape, latency budget, OS/runtime needs, packaging) and translate them into a compute model recommendation.
2. Evaluate trade-offs between IaaS, containers, serverless, and batch families along the five Well-Architected pillars.
3. Recommend a primary compute service (VM, VMSS, App Service, Container Apps, AKS, ACI, Functions, Logic Apps, Azure Batch) for a given workload, with justifying reasons.
4. Design a multi-service compute topology where different parts of a workload use different compute models (e.g., web on App Service, async on Functions, batch on Azure Batch).
5. Recognise common anti-patterns — VM-based stateful services that should be containers, container clusters running a single 4-vCPU workload, Functions running multi-hour jobs — and rewrite them.
6. Compute the rough cost shape (consumption vs reserved vs Spot) of each candidate and defend the choice.

Building Blocks

Read this section as a glossary. Each term follows the same shape: an everyday analogy, a formal definition, then the reason it matters for the exam.

IaaS compute — Like leasing a building: you control the OS, the network, and the patching schedule. Formally, Virtual Machine and VM Scale Set resources where Azure provides hardware and hypervisor and the customer owns OS-and-above. It matters because IaaS is the highest-control, highest-toil end of the spectrum — and the right answer for workloads with custom OS/kernel needs, third-party software locked to OS, or strict licensing rules.

PaaS web / app compute — Like renting a furnished apartment: Azure manages the OS and runtime; you ship code. Formally, App Service (web apps, APIs), Azure Container Apps, Functions Premium / App Service Plans where Azure manages OS patching, runtime upgrades, and scale-out. It matters because PaaS is the right default for stateless web workloads — much cheaper to operate than VMs.

Container compute — Like shipping containers: a self-contained packaging that runs anywhere a runtime exists. Formally, Azure Container Apps (Knative-based, dapr-aware), Azure Kubernetes Service (AKS) (managed Kubernetes), Azure Container Instances (ACI) (single-container quick-start), App Service (custom container support). It matters because containers are the modern default for portability, fast deployment cycles, and microservice architectures.

Serverless event-driven compute — Like pay-per-trigger event handlers: you write a function, Azure executes it when an event arrives. Formally, Azure Functions (code), Logic Apps (low-code workflows), and event-driven scale-to-zero modes of Azure Container Apps. It matters because serverless is the cheapest model for sparse, event-driven, sub-second workloads.

Batch / job compute — Like a print queue for compute work: jobs are submitted to a pool that scales up, runs them, and scales back down. Formally, Azure Batch (HPC-style pools), Azure Container Apps Jobs, AKS Job/CronJob resources. It matters because batch is the right answer for embarrassingly parallel work — ML training, video transcoding, financial Monte Carlo.

Statefulness — Whether the compute holds session, cache, or persistent data on its local disk. Formally, "stateless" means the compute can be replaced without data loss; "stateful" means local data must be migrated or preserved. It matters because every modern compute model assumes stateless by default; making a stateful workload work on PaaS / containers / serverless adds complexity (sticky sessions, external state stores, persistent volumes).

Scale shape — The pattern of load over time. Steady, bursty (event-driven), cyclical (business hours), or batch (one-shot). Formally, a workload's request-per-second curve. It matters because cost-optimal compute differs by shape: steady $\to$ reserved VMs; bursty $\to$ serverless; cyclical $\to$ autoscale containers; batch $\to$ Spot pools.

Cold start — The latency penalty when a serverless instance is provisioned from zero. Formally, the time between an incoming event and the first byte of response when no warm instance exists. Functions Consumption cold starts are typically $100{-}3000$ ms; Premium plan with pre-warmed instances is $\le 100$ ms. It matters because user-facing APIs cannot tolerate cold starts; background processing usually can.

Spot / low-priority pricing — Compute capacity sold at a steep discount in exchange for eviction risk. Formally, Spot VMs and Azure Batch low-priority nodes are evicted with 30-second notice when capacity is needed. Discount $60{-}90\%$ off pay-as-you-go. It matters because batch / training / dev environments can absorb evictions for big cost savings.

Deep Dive

1. The four compute families and what each is for

Most workloads fit cleanly into one of four families. The question to ask first is "which family?", not "which service?" — once the family is set, the service follows naturally.

[!TIP] Start the decision at "could this workload be event-driven?". If yes, default to serverless or Container Apps with KEDA scalers. If no, ask the next question (state, scale, OS needs) before committing to a family.

2. The attribute-to-family mapping

Workload attributes drive family choice. The table below is the attribute matrix the AZ-305 exam tests repeatedly.

[!IMPORTANT] A workload often has multiple compute types inside it. A typical SaaS app: web tier on App Service (PaaS), async on Functions (serverless), nightly reports on Azure Batch (batch). Resist the urge to homogenise — different parts of the workload have different attributes.

3. The cost-shape lens

Beyond the family decision, pricing shape often determines which service within a family is right. The four shapes — steady, bursty, cyclical, batch — map to four pricing models.

The takeaway: cost optimisation is rarely about cheaper hardware — it is about matching the pricing model to the shape. A "steady" workload on Functions Consumption overpays by $30{-}40\%$; a "bursty" workload on Reserved VMs overpays by $5{-}10\times$.

[!NOTE] maxPrice: -1 tells Azure to keep Spot instances running up to the pay-as-you-go rate (i.e., evict only on capacity pressure). A small positive value would cap your willingness to pay — common for cost-bounded batch.

4. Statefulness and the modernisation gradient

State on local disks is the single biggest determinant of which family is feasible. The conventional modernisation gradient is: VM with local state $\to$ VM with externalised state ($\to$ Premium SSD/Azure Files) $\to$ container with the same external state $\to$ stateless function reading external state on demand. The exam tests this gradient with "we cannot use serverless because X" prompts — usually X is state and the fix is to externalise it.

5. Cost benchmark — a single workload, four families

Imagine the same stateless web service running at 50 RPS sustained ($\sim 4.3 M$ requests / day). Approximate cost shape across families illustrates how dramatically the model — not the hardware — moves the bill:

The serverless line wins on cost only because the per-request work is small ($\sim 100$ ms). At higher per-request work, the lines reverse. The exam tests this intuition: cheapest model depends on shape and per-request cost.

6. Real-time vs background — synchronous and asynchronous flavours

The compute pattern most architects miss is splitting a workload across synchronous and asynchronous halves. The synchronous half answers user requests; the asynchronous half processes work after the user has been told "we're on it". This usually lets the synchronous half stay light (App Service or Container Apps) and the asynchronous half use a much cheaper compute model.

The pattern reduces sync-tier capacity needs and makes the async tier auto-scale with the queue. The AZ-305 exam loves this pattern because it tests both compute choice and asynchronous-design skills.

[!WARNING] Azure Functions Consumption has a hard execution-time limit of 10 minutes per invocation. Workloads that run longer must use Functions Premium / App Service plan (60 minutes), Container Apps Jobs (hours), or Azure Batch (unbounded).

Worked Examples

Easy — pick a family for a bursty webhook receiver

Problem. A team needs to expose a public HTTPS endpoint to receive webhooks from a third-party SaaS. Volume is bursty: zero most of the day, then spikes of 1000 events per second for $5{-}10$ minutes when the upstream system triggers. Each event triggers $\sim 100$ ms of work writing to a queue. Recommend a compute family.

Solution. Serverless. The pattern is the canonical webhook-receiver shape: bursty, event-driven, sub-second per event, scale to zero between bursts. Use Azure Functions with an HTTP trigger, Consumption plan, and a queue output binding. The cost during idle periods is near zero; the cost during bursts is fractions of a cent per million invocations.

[!NOTE] If the third-party SaaS requires consistent low-latency response (the cold-start penalty is unacceptable), upgrade to Functions Premium with $1{-}2$ pre-warmed instances. Cost rises but cold-start is eliminated.

Medium — pick services for a multi-tier SaaS

Problem. A SaaS product has (a) a web UI used by $5{,}000$ concurrent users, (b) an async image-processing pipeline triggered when users upload photos, and (c) nightly reports that crunch 50 GB of telemetry. Recommend a compute topology.

Solution. Three different families, three different services:

This kind of split is the recurring AZ-305 question form: "design the compute for these three subsystems". Resist the urge to homogenise — three different families is the right answer.

Hard — modernise a stateful VM workload

Problem. A workload runs on 20 VMs in East US. Each VM holds session state, uploaded files, and config files on its local disk. The platform team wants to move the workload to Azure Container Apps to cut cost. What does the modernisation plan look like?

Solution. Externalise the state, then containerise. The migration plan in three phases: (1) Replace VM-local session state with Azure Managed Redis. (2) Replace VM-local file uploads with Azure Blob Storage and Azure Files (ZRS). (3) Replace local config files with Azure App Configuration and Key Vault. After all three are done, the workload is genuinely stateless and the container migration is mechanical: build an OCI image, push to Azure Container Registry, deploy to Container Apps with min replicas $= 2$ and an HTTP scaler. Expect total cost reduction in the $50{-}70\%$ range for stateless workloads of this shape.

[!IMPORTANT] The order matters. Containerising a stateful VM workload directly will reproduce the state problem inside containers — and containers are worse at state than VMs. Externalise first.

Visual Explanations

Figure 1 — Compute decision flow

The tree's top-most branch ("custom OS?") removes IaaS as the default. Most modern workloads end at PaaS containers or serverless. The exam often tests the gating questions one at a time — "the workload needs Windows Server 2019 with a custom driver" is a "yes" to question 1 and lands on IaaS even if everything else points to containers.

Figure 2 — Compute family vs Well-Architected pillar fit

Use this matrix when defending a recommendation in an architecture review. The "Owner" / "Shared" / "Azure" row for security indicates who patches the OS — IaaS makes you the OS owner; serverless gives the OS entirely to Azure.

Figure 3 — Service quick-pick by shape and scale

Common Mistakes

❌ Myth: Containers are always cheaper than VMs. ✅ Reality: Containers cost less only when the workload's scale shape benefits from scale-to-zero or fine-grained scaling. A steady-state $24/7$ workload on Reserved VMs is often cheaper than the same workload on Container Apps with constant minimum replicas. Why it's tricky: Vendor marketing pushes "containers are cheaper". The honest answer is "containers are cheaper for the right shape".

❌ Myth: Azure Functions is the right answer for any "small" workload. ✅ Reality: Functions is the right answer for event-driven small workloads. A small but steady-throughput API may be cheaper and simpler on Container Apps with min replicas 1 — and easier to debug. Why it's tricky: "Serverless" sounds like "smallest cost" but the model only wins when the load is genuinely sparse.

❌ Myth: AKS is the right answer for "container-native" workloads. ✅ Reality: AKS is the right answer for workloads that need Kubernetes — multi-tenant, complex deployment topologies, third-party Helm charts. For simple stateless services, Container Apps is one fewer thing to operate and often the right choice. The exam tests this: ACA vs AKS is a frequent distractor pair. Why it's tricky: Teams reach for AKS because it is the most flexible; the cost is operational toil for cluster ops.

❌ Myth: Spot VMs are a cost-saving option for production. ✅ Reality: Spot VMs can be evicted with 30 seconds' notice. They are appropriate for batch, training, dev/test, and stateless replicas that can tolerate eviction. They are inappropriate for the only instance of a production service. Why it's tricky: The $60{-}90\%$ discount is tempting; the eviction risk is hidden in the small print.

Practice Exercises

🟢 Exercise 1. A workload runs Windows Server 2019 with a vendor-supplied kernel driver. Recommend a compute family.

▶💡 Hint

The kernel driver is the constraint.

▶✅ Solution

IaaS — Virtual Machine or VMSS. The kernel driver constrains the workload to a Windows OS image that Azure does not let you install on PaaS or containers. Use VMSS Flexible for HA and scale, with Reserved pricing if the load is steady.

🟡 Exercise 2. A workload receives one HTTP request roughly every 2 minutes. Each request takes 100 ms to handle and updates a Cosmos DB document. Cost matters. Recommend a compute service.

▶💡 Hint

Extremely sparse, low-effort requests.

▶✅ Solution

Azure Functions Consumption plan. With load that sparse, total compute cost is essentially the per-invocation fee — fractions of a cent per million invocations. Even a small App Service plan would cost tens of dollars per month for the same workload. Cold start is acceptable here because the workload is internal and tolerates a 1–2 second first response.

🟡 Exercise 3. A team has $10{,}000$ video files to transcode this weekend. Each file takes $5{-}30$ minutes on a 4-vCPU GPU VM. Cost matters and the deadline is Monday morning. Recommend a compute service.

▶💡 Hint

Embarrassingly parallel, time-bounded, GPU-heavy.

▶✅ Solution

Azure Batch with a low-priority GPU pool. Submit one task per file; let Batch scale the pool up to thousands of nodes, run the jobs, and scale back to zero. Low-priority pricing gives $60{-}90\%$ off; if a node is evicted mid-job, Batch reschedules. By Monday morning all jobs complete and the bill is fractions of a Reserved-instance baseline.

🔴 Exercise 4. A SaaS workload has steady traffic of 200 RPS during business hours and drops to 5 RPS overnight. The team uses App Service Premium v3 with 4 instances $24/7$. Recommend a cost optimisation.

▶💡 Hint

The shape is cyclical, not steady.

▶✅ Solution

Enable autoscale: minimum 2 instances (for HA), maximum 6 during business hours, with CPU-based rules and a schedule. Overnight the plan runs at 2 instances, cutting cost by roughly 40%. Alternative: move to Azure Container Apps with HTTP scaler — even more granular scaling and scale-to-zero is possible if the workload tolerates a $\sim 1$ second cold start at night.

🔴 Exercise 5. A startup builds a workload that must remain on Functions Consumption to control cost. One step in the workflow generates a PDF that takes 12 minutes on a fast VM. Recommend a redesign.

▶💡 Hint

Consumption Functions cap at 10 minutes.

▶✅ Solution

Split the PDF generation off into a Container Apps Job triggered by a Storage Queue message. The Function enqueues the request and returns immediately; the ACA Job runs the long step in a container that can take an hour. The Function continues to scale to zero between events; only the queue-driven job pays compute time when it runs. Cost stays low; the 10-minute cap is no longer in the request path.

🟢 Exercise 6. True or false: Azure Container Apps and Azure Kubernetes Service are interchangeable.

▶💡 Hint

Both run containers but the operational model differs.

▶✅ Solution

False. Container Apps is a managed serverless container platform — Azure operates the underlying Kubernetes; you ship images and configure scale rules. AKS exposes Kubernetes directly — you have access to nodes, namespaces, Helm, CRDs, and you operate cluster upgrades. ACA is the right default for simple stateless microservices; AKS is the right choice when you need Kubernetes features.

🟡 Exercise 7. A workload runs an in-memory cache that holds 50 GB of session data. The cache is critical to performance. Where should it run?

▶💡 Hint

The cache is the state.

▶✅ Solution

Use Azure Managed Redis Premium or Enterprise — not custom compute. Custom compute (VMs with in-memory cache) loses the cache on restart, requires manual sharding for $> 50$ GB, and adds patching toil. Azure Managed Redis is a PaaS service that abstracts the cache as a managed resource. If the cache is the bottleneck, scale it independently of the application compute.

Summary & Concept Map

The headline takeaways from this lesson:

• Start with the family question. IaaS, containers, serverless, or batch — pick the family before picking the service.
• Statefulness is the most decisive attribute. Stateful workloads constrain you upward (VMs), stateless workloads liberate you downward (serverless).
• Cost shape, not headline price, drives the service choice. Steady $\to$ Reserved; bursty $\to$ Consumption; cyclical $\to$ Autoscale; batch $\to$ Spot.
• Different parts of one workload usually want different compute. A web tier on App Service, an async tier on Functions or ACA Jobs, and a nightly tier on Azure Batch is the canonical multi-tier pattern.
• Functions Consumption is capped at 10 minutes. Long jobs belong on Functions Premium, Container Apps Jobs, or Azure Batch.
• Container Apps is usually the right serverless container default. AKS is the right answer when you need Kubernetes-specific features.
• Spot / low-priority pricing is for eviction-tolerant work. Batch, training, dev/test — not production singletons.

The concept map enumerates the questions in priority order. Walk it during the exam: most questions land at the second or third decision point. If you stop early, you usually have the answer.