Design Compute Solutions — Lesson

Compute is the engine room of every Azure architecture. Whether you are running a monolithic ERP system on virtual machines, decomposing microservices into containers, triggering lightweight functions on events, or crunching thousands of parallel frames in a render farm, the AZ-305 exam expects you to pick the right compute service — and justify the trade-offs. This lesson integrates five learning objectives into a single module: the compute decision framework, VMs and scale sets, containers (AKS, ACI, Container Apps), serverless (Functions and Logic Apps), and Azure Batch. Reference: Ch. 4, §4.1, p. 139–148 of the AZ-305 exam book.

Why This Matters

Compute choices ripple through every pillar of the Well-Architected Framework — reliability, security, cost, operational excellence, and performance. Choosing Azure Functions when you need a long-running stateful workflow wastes engineering time; choosing a dedicated VM cluster when a container app would auto-scale to zero wastes money. On the AZ-305 exam you will face three to five scenario questions asking you to match business requirements (latency, state, compliance, burst capacity) to the right compute primitive. In production, these same decisions determine whether your cloud bill is $500/month or $50,000/month. Mastering the compute decision tree is one of the highest-leverage skills an Azure solution architect can develop.

Prerequisites

• Azure Resource Manager and subscriptions — Can you explain how a resource group organises related compute resources?
• Networking fundamentals (VNets, NSGs, load balancers) — How does a load balancer distribute traffic across VM instances?
• Basic Linux/Windows administration — Can you SSH into a VM and check running processes?
• Docker and container images — What is the difference between a container image and a running container?
• Event-driven programming concepts — Can you describe what a trigger and a binding are in general terms?

Learning Objectives

1. Analyse a set of workload requirements and recommend whether to use VMs, containers, serverless, or batch compute.
2. Design a VM-based solution with availability sets, availability zones, and Virtual Machine Scale Sets for high availability and auto-scaling.
3. Evaluate container hosting options (AKS, ACI, Azure Container Apps) and recommend the appropriate service based on orchestration needs.
4. Design event-driven and workflow solutions using Azure Functions and Azure Logic Apps, selecting the correct hosting plan and trigger type.
5. Recommend Azure Batch for embarrassingly parallel workloads and design pool, job, and task configurations for cost-efficient processing.

Building Blocks

Virtual Machine (VM) — Think of it as a "computer inside a computer." A VM is a full operating system (Windows or Linux) running on shared physical hardware in an Azure data centre. You control the OS, middleware, and runtime — Azure manages the host. Why it matters: VMs give maximum control but maximum responsibility; you patch, scale, and secure them yourself.

Virtual Machine Scale Set (VMSS) — A VMSS is a fleet of identical VMs managed as a single resource. Azure automatically adds or removes instances based on CPU, memory, or custom metrics. Think of it as "auto-scaling for VMs." Why it matters: VMSS is how you run stateless web tiers, batch workers, or microservices on VMs without hand-managing each instance.

Availability Set — A logical grouping that spreads VMs across fault domains (separate racks) and update domains (separate maintenance windows) within a single data centre. Analogy: putting your eggs in different baskets on different shelves. Why it matters: availability sets protect against single-rack failures and rolling updates, delivering a 99.95% SLA.

Availability Zone — A physically separate data centre within an Azure region, with independent power, cooling, and networking. Analogy: different buildings in a campus. Why it matters: zone-redundant deployments survive an entire facility outage, delivering a 99.99% SLA.

Azure Kubernetes Service (AKS) — Managed Kubernetes cluster. Azure provisions and maintains the control plane (API server, etcd, scheduler); you manage the node pools and workloads. Analogy: Azure runs the air-traffic control tower; you fly the planes. Why it matters: AKS is the go-to for teams that need full Kubernetes orchestration — service mesh, custom scaling, rolling deployments, and multi-container pods.

Azure Container Instances (ACI) — Serverless containers. You hand Azure a container image and it runs it — no cluster, no nodes, no orchestration. Billed per second of vCPU and memory. Analogy: a taxi — pay per ride, no car ownership. Why it matters: ACI is ideal for short-lived tasks, burst workloads, and sidecar containers that don't justify a full cluster.

Azure Container Apps — A managed platform built on Kubernetes and KEDA (Kubernetes Event-Driven Autoscaling). It abstracts away the cluster and gives you scale-to-zero, Dapr integration, traffic splitting, and revision management. Analogy: a managed apartment building — you bring your furniture (containers), the building handles plumbing and electricity (infrastructure). Why it matters: Container Apps fills the gap between ACI (too simple) and AKS (too complex) for microservice architectures.

Azure Functions — Event-driven, serverless compute. Write a small piece of code (a function), attach a trigger (HTTP, timer, queue message, blob upload), and Azure runs it on demand. You pay only when the function executes. Analogy: a light that turns on only when someone enters the room. Why it matters: Functions excel at glue code, event processing, and APIs with unpredictable traffic.

Azure Logic Apps — Low-code/no-code workflow orchestration. Design workflows visually with 400+ pre-built connectors (Office 365, Salesforce, SAP, Twitter). Analogy: IFTTT for the enterprise. Why it matters: Logic Apps let non-developers automate business processes; architects use them for integration workflows that don't justify custom code.

Azure Batch — Managed HPC (high-performance computing) service. You define pools of VMs, submit jobs composed of tasks, and Batch schedules them across the pool. Analogy: a print shop — you submit print jobs, the shop allocates printers. Why it matters: Batch is purpose-built for embarrassingly parallel workloads — rendering, transcoding, Monte Carlo simulations, genomics — where you need hundreds or thousands of cores for hours, then nothing.

Deep Dive

LO29 — The Compute Decision Framework

Before selecting a service, map your workload against five decision axes:

The official Azure compute decision tree follows this logic:

[!TIP] On the exam, eliminate options by duration first. If a scenario says "process runs for 6 hours," Azure Functions on the Consumption plan (max 10 minutes) is immediately disqualified. This single check often narrows four options to two.

See the LO-level lesson for the full decision matrix with 12 scenario patterns.

LO30 — Virtual Machines and Scale Sets

When to choose VMs: lift-and-shift migrations, legacy applications that require specific OS versions or kernel modules, workloads needing GPU (N-series) or high-memory (M-series) SKUs, and scenarios where the customer mandates OS-level control for compliance.

Availability architecture:

VMSS design patterns:

[!WARNING] Over-provisioning (the default) means Azure creates extra VMs during scale-out and deletes the surplus once the target count is confirmed. This speeds up scaling but can briefly exceed your vCPU quota. If your subscription quota is tight, set overprovision: false or request a quota increase before going live.

Key design decisions for the exam: choosing between Flexible and Uniform orchestration modes, selecting the right VM series (D-series for general purpose, E-series for memory, F-series for CPU, N-series for GPU), and combining VMSS with Azure Load Balancer (Layer 4) or Application Gateway (Layer 7).

See the LO-level lesson for more on custom images, ephemeral OS disks, and Spot VM pricing.

LO31 — Container Solutions (AKS, ACI, Container Apps)

Service comparison:

AKS architecture essentials:

[!IMPORTANT] Always separate system and user node pools in AKS. The system pool runs critical add-ons (coredns, metrics-server). If your application pods compete with system pods for resources on the same pool, a noisy-neighbour spike can crash DNS resolution for the entire cluster.

Container Apps is the exam's favourite "middle ground." It supports Dapr for service-to-service invocation, pub/sub, and state management — without requiring you to install or manage Dapr on Kubernetes yourself. It also supports traffic splitting for blue-green and canary deployments out of the box.

See the LO-level lesson for more on AKS networking (kubenet vs. Azure CNI), ACI virtual nodes, and Container Apps revision management.

LO32 — Serverless: Azure Functions and Logic Apps

Azure Functions hosting plans:

Choosing between Functions and Logic Apps:

Durable Functions extend Azure Functions with stateful orchestrations. They support patterns like fan-out/fan-in, function chaining, async HTTP APIs, and human-interaction workflows. The orchestrator function replays its history to reconstruct state — no external database required.

[!NOTE] Logic Apps Standard (single-tenant) runs on the same runtime as Azure Functions and supports VNet integration, private endpoints, and deployment slots. Logic Apps Consumption (multi-tenant) is simpler but lacks VNet injection. For enterprise workloads requiring network isolation, always choose Standard.

See the LO-level lesson for more on trigger types, binding expressions, Durable Functions patterns, and Logic Apps connector licensing.

LO33 — Azure Batch for Parallel Workloads

When to use Batch: rendering (Autodesk, Blender), transcoding (FFmpeg), financial risk modelling (Monte Carlo), genomics (BLAST), and any workload described as "embarrassingly parallel" — thousands of independent tasks that don't need to communicate.

Batch architecture:

Cost optimisation with low-priority (Spot) nodes: Batch supports a mix of dedicated and low-priority nodes. Low-priority nodes use Azure Spot pricing — up to 80% cheaper — but can be pre-empted. Design your tasks to be idempotent and retriable so pre-empted tasks restart on another node without data loss.

[!TIP] Use taskSlotsPerNode to run multiple tasks per VM. If your render task uses 2 cores and the VM has 8 cores, set taskSlotsPerNode: 4 to maximise utilisation. Without this, 75% of each VM sits idle.

See the LO-level lesson for more on auto-pool configuration, application packages, task dependencies, and multi-instance tasks (MPI).

Worked Examples

Easy: Web application with predictable traffic

Problem: Contoso runs a .NET web application serving 500 concurrent users during business hours. Traffic drops to near zero at night. They want 99.95% availability and auto-scaling. They already have Docker images.

Step-by-step solution:

1. Deploy to Azure Container Apps — supports Docker images, scale-to-zero (saves cost at night), and built-in ingress.
2. Set min replicas = 2 (for availability), max replicas = 10 (for peak).
3. Configure HTTP scaling rule: scale on concurrent requests (100 per replica).
4. Enable zone redundancy for 99.95% SLA.
5. Estimated cost: ~$$120$/month (vs. $$400$+ for a 3-node AKS cluster running 24/7).

[!NOTE] Container Apps is preferred over AKS here because the workload is simple (single service, HTTP traffic, no custom Kubernetes resources). AKS would be over-engineering.

---

Medium: Migrating a legacy Windows ERP system

Problem: Fabrikam has a 15-year-old Windows Server application that requires .NET Framework $4.7, a local D: drive for temp files, and a specific Windows hotfix. They need 99.99% availability in a single region.

Step-by-step solution:

1. Azure VMs — only option for legacy OS-level requirements (.NET Framework $4.7, hotfix, local disk).
2. Deploy across 3 Availability Zones for 99.99% SLA.
3. Use Standard_E8s_v5 (memory-optimised) with Premium SSD for the D: drive.
4. Front the VMs with Azure Load Balancer (Standard SKU, zone-redundant).
5. Use a custom image baked with the hotfix via Azure Image Builder.
6. Configure VMSS in Flexible mode with zone balancing.

[!NOTE] Containers and serverless are eliminated immediately: the application requires a full Windows OS with specific patches. This is a classic lift-and-shift scenario.

---

Hard: Multi-service e-commerce platform with mixed compute

Problem: Tailwind Traders is building a new e-commerce platform. Requirements: product catalogue API ($1\text{M}$ requests/day), order processing (asynchronous, 5-step workflow), image resizing on upload, nightly recommendation model training (200 GB dataset), and a 3-hour video transcoding pipeline for marketing.

Step-by-step solution:

1. Product catalogue API → Azure Container Apps: containerised, auto-scales on HTTP, scale-to-zero at night.
2. Order processing → Durable Functions (Premium plan): 5-step orchestration with checkpointing, handles retries and compensation logic.
3. Image resizing → Azure Functions (Consumption): blob trigger fires on upload, resizes to 3 sizes, writes back to storage. Short-lived, event-driven.
4. Recommendation model training → AKS with GPU node pool (Standard_NC24ads_A100_v4): Spark or PyTorch job scheduled nightly, node pool scales to 0 when idle.
5. Video transcoding → Azure Batch: submit 500 tasks (one per video segment), use 200 low-priority Spot VMs for cost (80% savings), tasks are idempotent.

[!NOTE] This scenario demonstrates that real architectures mix compute services. No single service fits all five workloads. The decision tree (LO29) is applied independently to each component.

Visual Explanations

Compute Service Spectrum: Control vs. Abstraction

Azure Batch Architecture

Container Hosting Decision Tree

VM Availability Comparison

Serverless Plan Comparison

Cost Model Comparison Across Compute Services

Common Mistakes

❌ Myth: "AKS is always the best choice for containers — it's the most powerful." ✅ Reality: AKS is the most flexible but also the most complex. For a team running 3–5 microservices without custom Kubernetes resources (CRDs, operators, service mesh), Azure Container Apps provides the same auto-scaling, ingress, and Dapr integration with far less operational overhead. Reserve AKS for workloads that genuinely need the Kubernetes API. Why it's tricky: AKS appears in most Azure architecture diagrams, creating a "default" bias. The exam rewards candidates who choose the simplest service that meets requirements.

---

❌ Myth: "Azure Functions can run any workload — just increase the timeout." ✅ Reality: Consumption plan caps at 10 minutes; Premium extends this but isn't free. Functions are designed for short, event-driven bursts. For long-running processes ($> 60$ minutes), use Durable Functions with checkpointing, Container Apps, or Azure Batch. Forcing a 3-hour job into Functions leads to timeout failures, lost state, and debugging nightmares. Why it's tricky: Durable Functions blur the line by supporting long orchestrations, but each activity within the orchestration should still be short. The orchestrator replays history and can hit memory limits on very long chains.

---

❌ Myth: "Availability Zones and Availability Sets are interchangeable — just pick one." ✅ Reality: They protect against different failure scopes. Availability Sets protect against rack-level failures within a single data centre (99.95% SLA). Availability Zones protect against entire data-centre failures (99.99% SLA). You cannot combine both — a VM is either in a set or in a zone. If you need 99.99%, choose zones. Why it's tricky: The names sound similar, and both appear in the VM creation blade. The exam tests whether you know the SLA difference and when to pick which.

---

❌ Myth: "Azure Batch is just for rendering — it's too niche for our workloads." ✅ Reality: Batch handles any embarrassingly parallel workload: data processing, ETL fan-out, Monte Carlo simulations, machine learning hyperparameter sweeps, and genomics. If you have $1{,}000$+ independent tasks that don't communicate, Batch is cheaper and simpler than spinning up an AKS cluster or $1{,}000$ Functions instances. Why it's tricky: Batch is less visible in marketing materials than AKS or Functions, so candidates forget it exists. The exam specifically tests whether you recognise "embarrassingly parallel" as a Batch signal.

Practice Exercises

Exercise 1: Quick Compute Selection 🟢 Easy

A startup needs to run a Python script that processes uploaded CSV files (average 2 MB, processing time 15 seconds) triggered by blob uploads. Budget is minimal. Which compute service do you recommend?

▶💡 Hint

Consider the trigger type, execution duration, and cost model. Which service charges nothing when idle?

▶✅ Solution

Use Azure Functions on the Consumption plan with a Blob Storage trigger. The execution is short (15 seconds, well under the 10-minute limit), event-driven (blob upload), and the Consumption plan charges per-execution with scale-to-zero. Estimated cost for $1{,}000$ files/day: < $$1$/month.

---

Exercise 2: Choosing Between AKS and Container Apps 🟡 Medium

A fintech company runs 8 microservices. They need Dapr for pub/sub, scale-to-zero for 3 of the services, traffic splitting for canary releases, and VNet integration. They do not use custom Kubernetes operators or CRDs. Which service fits best?

▶💡 Hint

Map each requirement to the service that supports it natively. Does one service cover all four without extra setup?

▶✅ Solution

Azure Container Apps. It supports Dapr natively (no Helm install needed), scale-to-zero by default, traffic splitting between revisions for canary deployments, and VNet integration via managed environments. AKS could do all of this, but it would require installing Dapr via Helm, configuring KEDA manually, and managing an Ingress controller — significantly more operational overhead for no additional benefit since CRDs and operators are not needed.

---

Exercise 3: Designing a Batch Processing Pipeline 🟡 Medium

A media company needs to transcode $10{,}000$ video files (1 GB each) from H.264 to H.265. Each transcode takes 20 minutes on a 4-core VM. Budget: minimise cost. Deadline: 48 hours.

▶💡 Hint

Calculate the total compute hours needed. How can Spot/low-priority VMs reduce cost? What's the risk?

▶✅ Solution

Total compute: $10{,}000 \times 20 \text{ min} = 200{,}000 \text{ min} \approx 3{,}333 \text{ hours}$. With 48-hour deadline and 4-core VMs running 1 task each: need $\lceil 3{,}333 / 48 \rceil \approx 70$ VMs running continuously. Use Azure Batch with 70 Standard_F4s_v2 nodes: 15 dedicated + 55 low-priority (Spot). Low-priority saves ~60%–80%. Risk: pre-emption causes retries. Mitigation: tasks are idempotent; Batch auto-retries failed tasks on available nodes. Estimated cost: dedicated ($$15 \times 48$ hr $\times$ $0.17$) + low-priority ($55 \times 48 \times $0.03$) $\approx $122 + $79 = $201$ total.

---

Exercise 4: Serverless Plan Selection 🟡 Medium

An API receives $50{,}000$ requests/day with an average latency requirement of < 200 ms. The function calls a SQL database inside a VNet. Cold starts of 2–3 seconds are unacceptable. Which Functions hosting plan?

▶💡 Hint

Two requirements disqualify the Consumption plan. What are they?

▶✅ Solution

Premium (Elastic Premium) plan. Two reasons: (1) VNet integration is required to reach the SQL database — Consumption plan does not support VNet integration. (2) Cold starts are unacceptable — Premium keeps at least 1 pre-warmed instance. Set minimum instances = 2 for availability. The Dedicated plan also works but is more expensive for this scale and doesn't auto-scale as elastically.

---

Exercise 5: Multi-Compute Architecture Design 🔴 Hard

Contoso's logistics platform has four workloads: (a) real-time GPS tracking API ($10{,}000$ WebSocket connections), (b) nightly route optimisation (runs 4 hours, CPU-intensive), (c) invoice PDF generation triggered by order completion (500/day), (d) legacy .NET Framework $4.5 scheduling service requiring Windows registry access. Design the compute architecture.

▶💡 Hint

Apply the decision tree to each workload independently. Consider: WebSocket support, duration, event triggers, and OS requirements.

▶✅ Solution

(a) AKS — WebSocket connections at $10{,}000$ concurrent need persistent connections and session affinity. AKS with an NGINX Ingress controller handles WebSocket upgrades natively. Container Apps also supports WebSockets but AKS gives more control over connection limits.

(b) Azure Batch — 4-hour CPU-intensive job running nightly is a classic Batch use case. Create a pool with Spot VMs that auto-scales to 0 after the job completes. Much cheaper than running AKS nodes 24/7.

(c) Azure Functions (Consumption) — blob or queue trigger fires on order completion, generates PDF, saves to storage. Short execution ($< 1$ min), event-driven, low volume. Consumption plan keeps cost near zero.

(d) Azure VM — .NET Framework $4.5 and Windows registry access require a full Windows OS. No container or serverless option supports registry manipulation. Deploy a single Standard_D2s_v5 VM with an availability set or zone.

---

Exercise 6: Cost Optimisation for Idle AKS Clusters 🔴 Hard

Your development AKS cluster (5 nodes, Standard_D4s_v5) runs 24/7 but is only used during business hours (8 AM–6 PM, Mon–Fri). Monthly cost: ~$$2{,}400$. How would you reduce this by at least 50%?

▶💡 Hint

Think about what happens to the cluster and its nodes outside business hours. Can you stop them?

▶✅ Solution

Three strategies combined:

1. AKS Stop/Start: Use az aks stop at 6 PM and az aks start at 8 AM via Azure Automation or a cron job. Stopped clusters incur no node charges (only disk). Savings: $\sim 60\%$ (running 10hr/24hr on weekdays, 0 on weekends = 50hr/168hr).
2. Cluster auto-scaler: Set min nodes = 1, max = 5. During low-activity periods, the cluster scales down to 1 node.
3. Spot node pools for user workloads: dev/test tolerates pre-emption. Cost: 60%–80% discount. Combined savings: 60%–75%, bringing cost to $$600$–$$960$/month.

Summary & Concept Map

Key Takeaways:

• Use the decision tree first: match workloads to compute services based on control, state, duration, scale pattern, and cost model. Never default to a single service for all workloads.
• VMs are for lift-and-shift and OS-level control: combine with VMSS for auto-scaling, Availability Zones for 99.99% SLA, and Spot instances for cost savings.
• Container Apps is the new default for microservices: unless you need the full Kubernetes API (CRDs, operators, service mesh), prefer Container Apps over AKS for reduced operational complexity.
• Functions handle event-driven glue code: Consumption for sporadic triggers, Premium for VNet and low-latency APIs, Durable Functions for stateful orchestrations.
• Logic Apps automate business workflows without code: choose Standard for enterprise features (VNet, deployment slots), Consumption for simple integrations.
• Azure Batch is purpose-built for embarrassingly parallel workloads: combine dedicated and low-priority nodes, set taskSlotsPerNode to maximise utilisation, and design idempotent tasks for retry safety.
• Real architectures mix services: apply the decision tree independently to each component of a system, then connect them with queues, events, and APIs.

Connections & Next Steps

This lesson integrates five Learning Objectives. Read them in this order:

1. LO29 — Compute Decision Framework: the full 12-scenario decision matrix and Well-Architected Framework trade-off analysis.
2. LO30 — VMs and Scale Sets: deep dive on VM series selection, custom images, ephemeral disks, and Spot pricing.
3. LO31 — Container Solutions: AKS networking (kubenet vs. CNI), ACI virtual nodes, Container Apps revision management, and Dapr patterns.
4. LO32 — Serverless (Functions and Logic Apps): trigger catalogue, binding expressions, Durable Functions orchestration patterns, and Logic Apps connector licensing.
5. LO33 — Azure Batch: pool configuration, application packages, task dependencies, multi-instance tasks (MPI), and auto-pool lifecycle.

Related Topics and Units:

• Unit 4, Topic 2 — Application Architecture: how compute services plug into broader app patterns (microservices, event-driven, CQRS).
• Unit 4, Topic 3 — Network Solutions: VNet integration, Private Link, and NSG rules that constrain compute placement.
• Unit 3, Topic 1 — Business Continuity: how availability zones, VMSS health probes, and multi-region deployments support RTO/RPO targets.
• Unit 1, Topic 1 — Logging and Monitoring: configuring Azure Monitor, Application Insights, and diagnostic settings for each compute service.

Exam Strategy: expect 3–5 compute questions. At least one will be a multi-service scenario (like Worked Example 3). Practice applying the decision tree to each component independently, then verify your choices against the Well-Architected Framework pillars.