What's changed: Deepened AZ-305 Chapter 4 (added comparison tables, scenarios, FAQs, exam traps, deep-dive paragraphs to each section; localized figures to Japanese)
4.1Designing Compute
Understand compute choices—VMs/VMSS, App Service, Azure Functions, and AKS/ACI/Container Apps. Pick the runtime that fits the workload.
Compute selection is central to infrastructure design. From VMs to serverless, choose by control needs and how managed you want it.
4.1.1Compute options
- VM/VMSS: full control down to the OS (IaaS); VMSS autoscales identical VMs.
- App Service: PaaS to host web/API easily (autoscale/deployment slots).
- Azure Functions: event-driven, pay-per-use serverless.
- AKS/ACI/Container Apps: AKS = Kubernetes, ACI = one-off/batch, Container Apps = serverless microservices.
Common on AZ-305: full OS control = VM, scale identical VMs = VMSS, easy PaaS for web/API = App Service, event-driven pay-per-use = Functions, Kubernetes = AKS, one-off containers = ACI, serverless containers = Container Apps. Prefer managed (PaaS/serverless) to reduce operational overhead.
AZ-305 compute design probes "choosing the optimal runtime from control needs, scaling characteristics, cost model, and portability." VM/VMSS give full OS control for legacy or special requirements, but you design patching/availability/scale yourself (VMSS autoscales identical images, spreads across zones, and uses spot/low-priority for cost). App Service is PaaS to host web/API quickly, with deployment slots (staging→prod swap for zero-downtime releases), autoscale, and custom domains/certs, with App Service Environment (ASE) for isolation. Azure Functions is event-driven, choosing from Consumption (pay-per-use, autoscale, cold starts) / Premium (pre-warmed, VNet integration) / Dedicated, with Durable Functions for stateful orchestration. For containers, distinguish AKS (standard Kubernetes for large/complex orchestration), ACI (lightweight, one-off/burst, a single serverless container), and Container Apps (KEDA-based autoscale, Dapr-integrated serverless microservices without managing Kubernetes). The key is to evaluate toward minimal operational overhead (IaaS → PaaS → serverless), descending toward control only when portability (K8s) or special requirements demand it.
| Requirement | Choice | Key point |
|---|---|---|
| Full OS/middleware control | VM / VMSS | IaaS; self-managed patch/scale |
| Web/API with low ops | App Service | PaaS; slots/autoscale |
| Event-driven/intermittent | Azure Functions | Consumption/Premium/Dedicated; Durable |
| Containers | AKS / ACI / Container Apps | K8s / one-off / serverless micro |
Scenario: Run a microservice web backend that scales to zero on events without bearing Kubernetes operational overhead. → Choose Azure Container Apps (KEDA-based autoscale to zero when idle, Dapr for inter-service comms). Front the public API with API Management as a gateway, and handle intermittent background work with Azure Functions (Consumption). Switch to AKS only if fine-grained Kubernetes control is required.
FAQ: AKS or Container Apps? If you need standard Kubernetes APIs, existing manifests, or fine-grained control (custom operators, special networking/storage), use AKS. To run containerized microservices serverlessly without managing Kubernetes (autoscale/scale-to-zero, built-in Dapr/KEDA), use Container Apps. For a single one-off/batch container, ACI is the lightest.
Exam trap: Choosing VM (IaaS) for "host a web app with minimal operational overhead" is wrong—VMs require self-managing OS patching/scale/availability, the highest overhead. Choose App Service (PaaS) or serverless containers. Likewise, satisfying "event-driven pay-per-use" with always-on VMs/dedicated plans is inefficient—the answer is Functions Consumption plan.
4.1.2Section summary
- Control = VM/VMSS / web = App Service / events = Functions
- Containers = AKS (K8s) / ACI (one-off) / Container Apps (serverless)
Sign in to track progress — Log in.
Quick check
(just a quick review)Q1. Host a web app with minimal ops, using autoscale and deployment slots. What?
Q2. Run short event-driven processing with no servers, paying only for use. What?
Q3. Orchestrate containers leveraging existing Kubernetes assets. What?
Keep track of your progress
The full study guide is free to read. Sign up free to practice with the question bank, track what you have read, review your mistakes, and highlight passages.