Design infrastructure solutions
Compute Platform Selection and Workload Design
CoreChoose virtual machines, managed web platforms, containers, serverless services, and batch compute from control, portability, scaling, state, and operations requirements.
Aligned to the current AZ-305 study guide, skills measured as of April 17, 2026, verified August 25, 2026.
Why this matters
Compute selection sets the long-term operations burden and often determines how quickly a design can scale, recover, and evolve.
Must Know
- Select the most managed compute platform that still meets the workload's runtime, operating-system, networking, and control constraints.
- Distinguish container packaging from the orchestration, ingress, scaling, and state capabilities supplied by a hosting platform.
- Use event-driven serverless compute only when its execution and runtime boundaries fit the workload.
- Reserve Azure Batch for managed pools of parallel jobs rather than treating a request-serving platform as a batch scheduler.
Compare and Distinguish
- Virtual machines maximize guest control; App Service manages web hosting; Container Apps manages application containers; AKS exposes Kubernetes orchestration; Functions runs event-driven code.
- Containers package applications but do not by themselves provide orchestration, ingress, scaling, or state management.
- Azure Batch schedules large parallel pools and jobs; general application orchestrators are not automatically batch schedulers.
Scenario examples
- Scenario: A vendor appliance requires kernel drivers. Think: virtual machines because the guest boundary must be controlled.
- Scenario: A stateless HTTP container needs scale to zero without Kubernetes operations. Think: Container Apps.
- Scenario: Thousands of independent rendering tasks need managed pool scheduling. Think: Azure Batch.
Exam traps
- Choosing AKS only because a workload uses containers adds unnecessary orchestration complexity.
- Serverless does not fit every long-running or highly customized runtime.
- A VM lift-and-shift may meet compatibility while missing cost and operations goals.
Key takeaways
- Use the highest-level managed platform that still satisfies hard requirements.
- Treat state, networking, deployment, and operations as part of compute selection.
- Choose Batch for scheduled parallel jobs rather than stretching a request-serving platform.
How it works
- A managed application platform accepts an application package or container image, starts instances on platform-managed infrastructure, exposes configured ingress, and changes instance count through its supported scaling controls.
- An event source invokes a Function through a trigger and bindings connect supported inputs or outputs; the platform allocates workers according to the hosting plan while durable state remains in an external service.
- Azure Batch creates a pool of compute nodes, groups work in a job, schedules tasks onto available nodes, and lets tasks stage inputs from and write outputs to storage.
Objects and administrative surfaces
- Runtime compatibility, operating-system control, networking, identity, scaling, deployment, state, availability, and cost are compute design inputs.
- Managed services reduce platform operations but impose supported-runtime and platform boundaries.
- Batch pools, tasks, data staging, autoscale, and completion behavior differ from long-running service design.
When to use it
- Use VMs for hard guest requirements, AKS for explicit Kubernetes needs, and Container Apps for managed application containers.
- Use Functions for bounded event-driven code whose state and durable data remain in external services.
- Use Azure Batch for finite parallel jobs that need managed pools and release compute after completion.
Security and governance implications
- Assign workload identities and network access at the hosting layer while keeping image, artifact, and secret supply chains controlled.
- Account for patching, node or guest hardening, ingress, egress, and runtime isolation that remain with the selected platform.
How to validate and revise the design
- For scaling failures, inspect platform limits, triggers, minimum capacity, startup time, downstream throttling, and state dependencies.
- For deployment failures, compare image or package compatibility, identity, network policy, environment configuration, and health probes.
More detail
- Scale-to-zero can reduce idle cost but adds activation latency, so a latency-sensitive request path may require minimum warm capacity or a hosting model without that behavior.
- A container image improves packaging portability, but identity, networking, persistent storage, autoscaling rules, ingress, and upgrade behavior still differ among Container Apps, AKS, and self-managed virtual machines.
- Runtime support, execution duration, background-processing needs, specialized hardware, and operating-system control are hard filters; cost comparisons are meaningful only after those constraints are satisfied.
Ready for the quiz?
- Which operating-system, runtime, portability, networking, state, or scaling constraint rules out the more managed compute options?
- Does the container requirement need Kubernetes control or only managed ingress and event-driven scaling?
- Is the work a request-serving application, a bounded event handler, or a finite pool of parallel batch tasks?
Related objectives
- D4.1.S1 — Specify components of a compute solution based on workload requirements
- D4.1.S2 — Recommend a virtual machine-based solution
- D4.1.S3 — Recommend a container-based solution
- D4.1.S4 — Recommend a serverless-based solution
- D4.1.S5 — Recommend a compute solution for batch processing